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

Ви коли-небудь замислювались, що насправді відбувається під капотом розподілених систем? Не тих, що «типу кластер» на 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;

Як проєктувати архітектуру для продукту, який уже має успішний прод, але всередині нього хочеться запускати стартапи? Як не завалити стабільну систему, зберегти довіру користувачів, і водночас дати бізнесу простір для експериментів? - Болючі кейси "важких фіч", що не прижились - Як перетворили бажання бізнесу "більше й швидше" на архітектуру - Успішний кейс швидких фіч: Таємні бокси в Expirenza - Проблеми після успіху "тимчасової" фічі - Зміна майндсету команди розробки

Зараз дуже багате різноманіття інструментів для документування архітектури програмного забезпечення. При цьому з часом виникає питання, а чи є інструмент, який дозволяє не тільки зображувати архітектурні блоки як взаємопов'язані сервіси чи компоненти, а й включати комплексну інформацію про бізнес-прцеси, інформаційні системи та ІТ-інфраструктуру в єдиному вигляді? Таким інстурментом є Archimate. ArchiMate — мовa моделювання для опису, візуалізації й аналізу корпоративної архітектури, що разом з TOGAF стає потужним інструментом в руках архітектора. Під час доповіді розповім на прикладах про мову моделювання Archimate, покажу які є можливості в Archi для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.

Протягом багатьох років наша платформа для корпоративних клієнтів працювала на великому, надійному моноліті. Але з часом технічний борг, повільні релізи та залежності між модулями почали гальмувати розвиток. Настав час для переосмислення. Це історія еволюції для 150 тис. клієнтів: від паралельної роботи моноліту та мікросервісів — до Domain-Driven Development із понад 20 платформеними та продуктовими командами, від JSP до мікрофронтендів і дизайн-системи, від IBM до Open Source. Ключові інсайти: Чому стабільного моноліту вже недостатньо для сучасного банкінгу Як переходити без шкоди бізнесу і клієнтам Паралельна робота моноліту та мікросервісів — практичні уроки Domain-Driven Development у масштабі 20+ команд (платформені та продуктові) Мікрофронтенди та дизайн-система для швидших релізів Коли Open Source — правильний вибір, а коли варто купити

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

Що може піти не так, якщо дозволити кожному сервісу напряму звертатися до бази даних? У стартапі це здається швидким і зручним рішенням, та з часом система масштабується, і зʼявляються проблеми, про які ніхто не здогадувався. У своїй доповіді я поділюся досвідом Solidgate у трансформації архітектури: від хаосу прямих підключень до сервісної моделі доступу до даних. Розповім про стадії переходу, bottlenecks і про те, як ізоляція вплинула на підтримку інфраструктури. Чесно покажу, що спрацювало, а що — ні. Словом, розберемо всю контроверсійність цієї теми.