У цій доповіді ми розглянемо практичний кейс впровадження ефективного автоскейлінгу інфраструктури з використанням HPA, VPA та Cluster Autoscaler. Працюючи зі стандартним VPA, ми зіткнулися з обмеженнями: нестачею гнучкості в налаштуванні інтервалів обчислення та конфліктами при одночасній роботі з HPA. Тому ми вирішили створити власний кастомний VPA-контролер. У новому рішенні ми: - Забезпечили коректну спільну роботу VPA та HPA на одних і тих самих ресурсах. - Реалізували механізм фільтрації короткочасних піків CPU на етапі запуску подів. - Оптимізували архітектуру: об'єднали функціонал трьох стандартних компонентів у єдиний под. - Використали нові можливості In-Place Pod Resize, які з'явилися у Kubernetes 1.33. Головний результат: оптимізація споживання ресурсів та зменшення вартості інфраструктури на 20–40%.

У High-Load системах вартість інфраструктури часто зростає не через саме навантаження, а через неефективні архітектурні рішення: overprovisioning, надмірне використання managed-сервісів, зайвий data movement, неправильні SLA-рішення та відсутність прозорої cost-моделі. На конференції поговоримо, як підходити до cost optimization як до повноцінної архітектурної практики, а не як до разового скорочення ресурсів. Також поговоримо про аналіз workload profile, пошук реальних bottleneck’ів, побудову unit economics для інфраструктури, оптимізацію трафіку, кешування, CDN, observability та контрольовану деградацію сервісів. Окремо розберемо trade-off між performance, reliability та cost: де потрібна максимальна відмовостійкість, де достатньо eventually consistent підходу, а де managed-рішення варто замінити простішою self-hosted архітектурою.

Як залишатися успішним у світі, де AI змінює індустрію? У цій доповіді ми розглянемо дослідження та практичні приклади, що допоможуть зберегти стабільність кар’єри й навчитися ефективно використовувати AI для власного професійного розвитку.

Уявіть, що одного дня вашій команді передають систему, яку 4 роки створювали шість різних команд, просто щоб перевірити гіпотези. Ніякої документації, просто гігантська монорепа і Jenkins для деплою. Саме в таких умовах ми вирішили зробити повну інвентаризацію — і почали з Architecture as Code. У цьому виступі я розповім, як ми системно підійшли до опису архітектури: від побудови C4-діаграм до створення Service Documentation, ERD та Sequence Diagram-ів. Ви дізнаєтесь, як ми на практиці відновили розуміння системи, впровадили архітектурну прозорість, а також які інструменти (PlantUML, Mermaid) та підходи спрацювали найкраще. Це не лише про діаграми — це про виживання в хаосі, командну синхронізацію та архітектурну еволюцію через прозорість.

Чи працюють бізнес-підходи в оборонній сфері? Як збалансувати зручність та безпеку? Поділимось досвідом створення, розробки та впровадження з нуля інфраструктури DOT-Chain

Проговоримо про нашу історію. Як ми починали проєкт з невеликою векторною базою менш ніж 2 млн записів. Згодом прийшов запит на +100 млн записів, потім ще +100… І так поступово ми вийшли майже на 1 млрд. Стандартні інструменти швидко вичерпували себе — ми впирались у перформанс, розмір індексу та дуже обмежені ресурси. Після довгої серії проб і помилок ми зібрали власний low-cost кластер, який сьогодні стабільно обробляє тисячі запитів до понад 1B векторів.

Серед сотень списків AI-інструментів для маркетингу багато компаній використовують лише найочевидніші рішення. Але що, якщо існують менш відомі, проте значно ефективніші інструменти, які можуть кардинально змінити підхід до маркетингу? У цій доповіді я поділюся реальними AI-рішеннями, які я і моя команда застосовуєм для кожного з напрямків маркетингу. Розповім, як саме ці інструменти допомагають нам оптимізувати витрати, підвищувати ефективність і значно скорочувати маркетинговий бюджет. Чесно і без клікбейту!)