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

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

Презентація буде сфокусована на maintainability quality attribute - як зробити бізнес-логіку ізольованою, консолідованою, інкапсульованою та консистентною. А також як інтегрувати її з інфраструктурою зберігання, обміну повідомленнями, etc. Розглянемо особливості застосування таких підходів: - OOD / Rich Domain Model / DDD - Hexagonal layered architecture - CQRS/Persistance/ORM Всі особливості будуть продемонстровані на прикладі реального завдання та підходу до його реалізації (приклади коду будуть на .NET)

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

Запуск Diia AI всупереч усім труднощам Що потрібно, щоб створити розмовного AI-асистента для мільйонів громадян? Подорож зі створення Diia.AI, національного цифрового асистента України, почалася з простого й багатообіцяючого Proof of Concept. Але перехід від контрольної демо-версії до живої, продуктивної системи, що працює з чутливими даними та реальними державними сервісами, виявився шляхом, сповненим несподіваних викликів. Ця доповідь — чесний, закулісний погляд на нашу архітектурну еволюцію. Ми заглибимося у реальні виклики, з якими зіткнулися: від боротьби з непередбачуваними "галюцинаціями" LLM та інтеграції зі складними державними реєстрами, до проєктування системи для національного рівня безпеки й масштабування під екстремальним тиском. Це не історія бездоганного успіху; це історія вирішених проблем — від абсурдно простих до монументально складних. Приєднуйтесь, щоб дізнатися практичні уроки, яких немає в підручниках. Ми розповімо, як проєктували систему з урахуванням стійкості, застосовуючи RAG-підхід для боротьби з дезінформацією, впроваджували надійні Guardrails для забезпечення безпеки та будували масштабовану, відмовостійку екосистему. Ця сесія буде корисною для архітекторів, розробників і продуктових лідерів, які хочуть зрозуміти справжні «шрами від битв» та важко здобуті інсайти, що приходять із запуском масштабної AI-платформи всупереч усім труднощам.

Ми хотіли зробити сервіс швидким для користувачів у будь-якій точці світу. 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 — правильний вибір, а коли варто купити