У цій доповіді ми розглянемо практичний кейс впровадження ефективного автоскейлінгу інфраструктури з використанням 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 архітектурою.

Коли дані розкидані по десятках сервісів — класичні підходи не працюють. Розкажемо, як ми побудували агреговану read-модель для 30M+ документів, витримали 1500 write RPS і чому Elasticsearch став ключовим компонентом каталогу.

Усього за 20 хвилин Сергій Сарайчиков, засновник A42 і один із топових білих хакерів Prozorro, покаже чому 80% атак починаються зі звичайного збору даних про вашу компанію. Ви дізнаєтесь, які типові помилки відкривають шлях до зламу, як автоматизовані системи знаходять ваші слабкі місця швидше, ніж ваші команди, та як побудувати моніторинг активів, який реально запобігає витокам. Це must-see для СТО, які хочуть бачити інфраструктуру очима атакуючого й отримати готову стратегію контролю ризиків без зайвих витрат.

У кожного інженера — своя дорога в IT. Моя почалася не з красивих презентацій і чітких планів, а з того, що мене на крані піднімали ремонтувати екран на стадіоні «Металіст». Потім були телеком-проєкти, автотести, Red Hat, OpenStack, OpenShift — і постійний пошук, куди рухатися далі. З часом прості кострубаті скрипти, які я писав лише щоб зекономити собі кілька годин, почали тримати прод. «Пожежі» стали приводами для нових рішень, а експерименти — досвідом, який справді працює. І десь у цьому всьому були моменти, коли я хотів піти з IT. Але натомість з’явилися DevOps01, ком’юніті, а згодом — AWS та HashiCorp-амбасадорство. У цьому виступі я розповім, як постійний пошук себе у професії та професії в собі став тим самим двигуном, що змінив не лише кар’єру, а й життя. Як маленькі ініціативи виростають у великі системи, а спільнота відкриває нові двері.

Дискусія з представниками високоризикових систем про те, чому архітектуру безпеки потрібно закладати ще на етапі проєктування та розробки, а не додавати після виходу в продакшен. Ми поговоримо про ризики відкладеної реалізації контролів, поширені ілюзії безпеки та практичні підходи до інтеграції безпекових практик у роботу продуктових команд.

Ви коли-небудь замислювались, що насправді відбувається під капотом розподілених систем? Не тих, що «типу кластер» на 3 ноди, а справжніх, що на ексабайтних масштабах? На цій доповіді ми разом зазирнемо за лаштунки сучасної інфраструктури. Як працюють системи, що обробляють гори даних? Які патерни, принципи та інженерні рішення ховаються за scalable архітектурами? Обговоримо: * Як виглядає життя розподіленої системи зсередини * Чим відрізняється розподілений застосунок від справжньої системи * Як схеми зберігання даних трансформуються у сучасні БД, черги й логи * Чому PostgreSQL у клауді, це вже не PostgreSQL? * Чим Northguard крутіший за Kafka? * Як працюють нові гравці типу NewSQL? Якщо ви архітектор, техлід, розробник або просто хочете зрозуміти, чому інфраструктура масштабується так, як масштабується - приходьте! Поділюся інсайтами, які, можливо, зможете застосувати у власних проєктах або розглянете їх під іншим кутом. P.S. І так, буде трохи магії ✨та багато правди про розподілені системи, які рухають цей світ ?

Уявіть, що ви вирішили врятувати старий, зношений корабель, замінивши його двигуни на найсучасніші. Але замість того, щоб “полетіти у світле майбутнє”, він починає тонути ще швидше. Це історія про те, як Clean Architecture може стати і рятівним кругом, і каменем на шиї проєкту. У першій частині — хроніки болю: спроба впровадити архітектурну красу у хаос легасі коду, де навіть успіхи здавались випадковістю та чому "Ми просто робимо Clean Architecture" не завжди працює. У другій — історія “тріумфу”: коли зріла команда і правильний підхід перетворили Clean Architecture на фундамент масштабованої, гнучкої та живої системи. Дві історії з реальної практики, що показують, чому той самий підхід може як провалити, так і врятувати проєкт.

Ми хотіли зробити сервіс швидким для користувачів у будь-якій точці світу. Edge Computing виглядало як ідеальне рішення. На практиці ж ми отримали і зменшення latency, і цілу купу несподіваних проблем. У цій доповіді я розповім: - як ми проектували edge-архітектуру для глобальних користувачів; - edge-провайдери та інфраструктура: що обрали і чому; - які оптимізації справді дали відчутний результат; - архітектурні компроміси, що вплинули на дизайн системи; - де edge перетворився на “edge-case” і змусив шукати нестандартні обхідні рішення; - наші факапи, та best practices;