"From Monolith to Microservices: The Evolution of a Banking Platform", Serhii Koliadych.pdf

For many years, our corporate banking platform ran on a large, reliable monolith. Over time, however, technical debt, long release cycles, and module dependencies slowed us down. It was time to rethink.
This is the story of an evolution for 150,000 clients: from running monolith and microservices in parallel to Domain-Driven Development with over 20 platform and product teams, from JSP to microfrontends and design systems, from IBM to Open Source.

2. Колядич Сергій​

3. 70% цифрових трансформацій у банках
перевищують бюджет або строки, 

або не виконують поставлені цілі
McKinsey — Why most digital banking transformations fail
До 95% ініціатив цифрової трансформації 

не приносять очікуваної бізнес-вигоди
Empirical Study: Impacts of Business Architecture in the Context
of Digital Transformation (Dennis O’Higgins, JBMS 2023)​

4. WEB: Кабінет
клієнта для
небанківських
послуг
2016–2017
WEB:
Стратегічне
рішення
побудови
Інтернет-банкінгу
під потреби ФОП
Перехід на
філософію Agile
2018
WEB:
нарощування
функціональності​
та розробка
продуктів під
потреби ЮО
2019–2020
WEB:
розширення
функціоналу​
MOB: перший
реліз мобільного
застосунку
2021–2022
Початок
масштабування:
з однієї великою
команди
створено
4 окремих​
2023
Старт
Трансформації
Cтворення 20+
автономних
команд
Зміна принципів
та підходів в
роботі
2024
ПУМБ Бізнес
наша Історія

5. Фінансове управління
Мобільний і веб доступ до рахунків
та операцій
Швидкі розрахунки
Платежі, регулярні перекази, масові
виплати
Безпека
AML, шифрування, кіберзахист, 2FA
Фінансування
Кредити, ліміти та інші інструменти
з простим доступом
Фінтех-екосистема
Партнерства для нових цифрових
продуктів
Автоматизація та API
Інтеграція з Creatio CBF, відкриті API
150 000+
38 000
Web ПУМБ Бізнес
Веб-версія
для сучасного
бізнес-клієнта

6. Web ПУМБ Бізнес
Назад у 2015

7. Web ПУМБ Бізнес
Старий добрий моноліт…​

WebSphere — примарне й непередбачуване
Бізнес вимагав більше фіч і команд розробки
→ потрібна паралельна розробка​
Реліз на сервері IBM займав ~40 хв, при багфіксах
і відкатах — ×2 / ×3 → неприйнятно для клієнтських
сервісів​
Ринок розробників з IBM-стеком — надто вузький
для масштабування команди​
Монолітне рішення
Єдиний беклог і застосунки​
Було прийнято компромісне рішення, де не змінювалася 
технологія Java EE, а лише виконувалося відокремлення 
фунціоналу в невеликі UBER-jar​

8. Web ПУМБ Бізнес
2016-2017: Uber-JAR ​

значно швидше, ніж весь важкий EAR/моноліт на WAS
Менший blast radius — зміни в окремому модулі
не чіпають увесь застосунок, зменшується ризик
“покласти” все середовище
Незалежний життєвий цикл — кожен Uber-JAR можна
збирати, тестувати й деплоїти окремо від основного
моноліту
Легший пошук і адаптація розробників —
стандартний Java-стек без необхідності занурюватися
в ESQL або специфіку IBM Integration Bus
Поступова міграція — дозволяє виводити функціонал
з IBM-середовища маленькими кроками, без великого
freeze і ризиків для бізнесу
Окремий Uber-JAR для робочого місця операційних
менеджерів дозволив ізолювати цей функціонал
і оптимізувати взаємодію з іншими сервісами
Приходить розуміння, що IBM дорого та повільно

9. Web ПУМБ Бізнес
2018-2019 Майже «в тренді»​
Еволюційні:​

лише те, що пов'язане з підписами та підписанням​
Введено сервіс для організації живих чатів клієнта
з менеджерами
Дизайн:​

— прийнято рішення перейти на сучасні технології​
Рух банку до open source, мікросервісів
та поступова відмова від IBM ESB
Заміна продукту IBM ESB на новий IBM IIB

10. Web ПУМБ Бізнес
2018-2019 Майже «в тренді»​

→ перехід на сучасний фронтенд-
стек
Повна відмова від IBM WAS
Liberty Profile
→ мінус ще один “великий”
моноліт
Фронтенд на Angular у
Kubernetes
→ гнучке масштабування, CI/CD​
Backend на Spring Boot
→ швидка розробка сервісів,
стандартний Java-стек, легша
підтримка​

11. Web ПУМБ Бізнес
2020: Йдемо в Open Source​

Відмова від IBM ESB → продукт замінювався
на IBM IIB, але обрали інший шлях​
Ріст команд розробки → колізії залежностей
під час розробки​
Рішення: нова архітектура внутрішніх API на
базі мікросервісів​
Перехідний період: старі й нові API працюють
паралельно​
Нові API одразу деплояться в Kubernetes​

12. Web ПУМБ Бізнес
2020: Йдемо в Open Source​

— виводимо з експлуатації
Усі нові сервіси:
Spring Boot + Kubernetes
Існуючі Java EE / WildFly
— поетапна міграція на нову
архітектуру
IBM IIB
— зведено до ролі proxy/DAO
до core-систем

13. Web ПУМБ Бізнес
Наш час: сучасні виклики – сучасні рішення​
Фронтенд масштабується гірше за команди: 

десятки версій лендінгу й кабінету одночасно 

→ конфлікти та релізні ризики

Окремі домени, незалежні деплої, спільна
дизайн‑ система
DDoS на рівні L7 став регулярним: операторський
захист не рятує

rate‑ limiting, TLS‑ термінація)
Плюс CDN: edge‑ кеш, менший TTFB, кращий UX
Зрілість платформи зросла: прокачали 

компетенції з Kubernetes
K8s‑кластерів під різні задачі
Більшість нових API одразу розгортаються в
Kubernetes (HPA, observability)
Ефекти для бізнесу​
енше колізій, швидші
релізи FE
Стабільність під атаками
та швидші сторінки
Еволюція без «великого
фризу» для клієнтів

14. Web ПУМБ Бізнес
Наш час: сучасні виклики – сучасні рішення​

Firewall → Load Balancer
Frontend: Digital Cabinet як мікрофронтенди (Angular)
у Kubernetes — незалежні деплої, спільна дизайн-
система
Доступ: Keycloak для клієнтів (OIDC/OAuth2) + LDAP
для співробітників; Redis як кеш
Backend: Spring Boot-сервіси у Kubernetes —
внутрішні API, горизонтальне масштабування
Дані/інтеграції: Core Systems, Data Warehouse
(Historical), Digital DB (Main//File Storage), CRM
Deprecated Area: технічний борг — ~20% ємності
команди в кожному спринті​

15. Web ПУМБ Бізнес
2023: Що було?​
5–7 розробників працюють з проєктом
без критичних проблем, команда орієнтується
в коді, знає, що де знаходиться​. АЛЕ

регрес у всьому проєкті​
Довгі синхронізації релізів
Два окремих репозиторії: один під лендінг, інший — під кабінет​
Кабінет:​

Загальні утиліти, сервіси та константи розкидані 
по shared-файлах без чіткої структури​
Код писався у різні періоди різними людьми 
— без єдиного підходу
Проблеми:​

а оновлення відкладаються роками​
Багато залежностей давно позначені як deprecated,
але продовжують використовуватись​
У проєкті є дубльовані бібліотеки: кілька різних пакетів
для однакових задач (наприклад, робота з датами
чи формами

16. Web ПУМБ Бізнес
Хочемо більше розробників ​
Старий підхід перестає працювати при
розширенні до 20+ розробників​

синхронізацію між командами​
Важкий онбордінг — навіть для маленької фічі треба
розуміти майже весь проєкт​
Вічні регреси і затримки релізів​
Шукати розробників під стару версію Angular складно
— люди охочіше йдуть ​на свіжі технології

17. Web ПУМБ Бізнес
план
Об’єднати всі частини в один
мультирепозиторій
— щоб мати єдині правила по кодстайлу, залежностях
і лінтерах​
Перейти на структуру в стилі DDD
— розділити проєкт на ізольовані контексти.​

Це зменшить кількість конфліктів при паралельній
розробці​
Налаштувати окреме деплойment
і тестування для кожного домену
— не чекати, поки перевіриться і збереться весь
проєкт, не витрачати час на синхронізації​

18. Web ПУМБ Бізнес
Мультирепозиторій​
Спочатку розгорнули все на NX, але згодом виявилося,
що це overkill. Хоч NX і дає багато можливостей, але ціна
цих можливостей...​
Десятки однакових конфіг-файлів
Сотні npm-залежностей, які потрібні лише для NX.
Декілька разів були випадки, коли після оновлення
до останньої версії хтось у якомусь пакеті щось зламав.
Також виникали проблеми з різною поведінкою під час
локальної розробки на Windows та Linux
Хоч і можна користуватися NX, але їх бізнес-модель
побудована так, щоб ми використовували їхній cloud
Рішення:
Використовувати стандартний angular-cli
та tsconfig.paths (Keep it simple) 

— швидше, надійніше, допомагає тримати
проєкт більш консистентним

19. Web ПУМБ Бізнес
Структура проєкту ​
Структура проєкту побудована а-ля DDD: ізольовані скоупи 
помножено на C4 модель
Відкриваєш папку домени — бачиш список усіх доменів 
(рахунки, кредити, депозити…)​
Заходиш у конкретний домен — там набір фіч (список рахунків, 
обороти, виписки)​
Навіть у коді принцип такий самий: замість стандартного
порядку — декларація по регіонам. Тобто  input user
(властивість) і getDisplayName() (метод) стоять поруч, далі 
наступний input, inject і методи для іншого  регіону.​ ​
Це дозволяє швидко знайти і розібратися в конкретній логіці 

без заглиблення у всі інші частини  проєкту

20. Web ПУМБ Бізнес
Структура проєкту ​(приклад доменів)​
Кредити
Список кредитів​
Заявка на кредит​
Кредитний калькулятор
Кредитні пропозиції​
Депозити
Список депозитів ​
Оформлення депозитів​
Рахунки
Картки
Виписки
Обороти
Баланс
Easy Entry​
Відкриття рахунку
Юридичній особі​
Відкриття рахунку
ФОП​

21. Web ПУМБ Бізнес
Separated Deployment ​
Кожен домен можна зібрати окремо, для цього 

в  кожному з них є кілька entry-point у папці public
В процесі збірки ми перехоплюємо резолвінг імпортів
і перевіряємо: якщо це імпорт із   (тобто npm-
залежність, щось  із нашої папки shared чи з іншого
домену), і якщо потрібно — кажемо резолвити import 
як external (тобто просто залишаємо  як є
у транспільованому коді) і додаємо цей новий файл 
у чергу на збірку
shared
Після збірки маємо набір чанків + окремий файл із 
метаданими (modules.metadata.json), де зазначено, 
який чанк за яку бібліотеку відповідає та її версію
Це все деплоїться як nginx сервер зі статичними 
файлами і проксірується на /_/<domain>
Логіка деплойменту змінила парадигму:​

Тепер не просто деплоїмо проект цілком (наприклад,
Лендінг чи Кабінет), а можемо деплоїти окремі частини
бізнесу — наприклад, «Кредити». При цьому
збирається все, що стосується кредитів, і йде в прод:
зміни оновлюються одразу і на лендінгу, і в кабінеті
“
”

22. Web ПУМБ Бізнес
Як це стає одним додатком ​
Маємо:​
shell (node.js), який періодично ходить по всіх

 і обирає 
найостанніші версії всіх бібліотек
/_/<domain>/modules.metadata.json
Формується:​
script[type=importmap], який  вставляється в index.html.
Стандартним механізмом  браузера всі  імпорти, які 
залишили external, починають підхоплюватися 
з потрібних чанків
Кредити
Депозити
Рахунки
Shell
Easy Entry​
20+ доменів​

23. Web ПУМБ Бізнес
Результат​
Спростили структуру проєкту та організували код 

у ізольовані домени
Зменшили ризик регресу при змінах і пришвидшили
релізи
Легше масштабувати команди та швидше онбордити
нових розробників
Відмовились від зайвих складних тулінгів на
користь простих та надійних рішень
Усі частини проекту підтримуються консистентно та
за єдиними правилами
Вся кодова база є повністю сумісною з нативним
білдером Angular ​

24. Web ПУМБ Бізнес
ЩО ДАЛІ?​
AI
персоналізація,
антифрод/скоринг,
асистенти; пілоти 

→ прод за KPI
AWS
перенесення
частини фронтенд-
інфраструктури 

у хмару (S3/
CloudFront, EKS/
ECS для SSR), IaC 

та стандарти
безпеки
EU Certificate
відповідність GDPR,
eIDAS/PSD2/NIS2;
ISO 27001/PCI DSS
за потреби
DDD
bounded contexts,
ubiquitous language;
межі сервісів 

за доменами;
швидший
онбординг/релізи
Резерв
Open Banking, ISO
20022, FinOps,
SRE/Observability 

— готові до
підключення

25. Дякую
за увагу
Працюємо, ПОКРАЩУЄМОСЬ