За даними IDC, 38% корпоративних хмарних міграцій перевищують запланований бюджет, а кожен третій проєкт не вкладається в дедлайни. Компанії переносять монолітні системи на хмарні платформи у розрахунку скоротити інфраструктурні витрати, а за рік отримують рахунок, більший за той, що був на власних серверах.
За даними IDC, 38% корпоративних хмарних міграцій перевищують запланований бюджет, а кожен третій проєкт не вкладається в дедлайни. Компанії переносять монолітні системи на хмарні платформи у розрахунку скоротити інфраструктурні витрати, а за рік отримують рахунок, більший за той, що був на власних серверах.
Михайло Красовський, Lead Solution Architect у Trinetix, понад 18 років працює з корпоративними системами й бачить одну з причин таких невдач у виборі архітектури: останні роки він веде проєкти для однієї з компаній «Великої четвірки» у сфері аудиту та консалтингу, серед клієнтів якої — компанії з Fortune 500 та S&P 500.
Зокрема, Красовський відповідав за перенесення великого корпоративного продукту з власної серверної інфраструктури на хмарні мікросервіси платформи Amazon Web Services і зумів на третину скоротити витрати на хостинг та експлуатацію, прискоривши при цьому можливості оновлення продукту. dev.ua поговорив із Красовським про те, чому хмарні міграції йдуть не за планом і що відрізняє архітектурне рішення, яке працює, від того, яке виглядає правильним лише на папері.
Міграція в хмару у 2026 році, за даними Gartner CIO Survey, стала другим за значенням пріоритетом, поступившись лише кібербезпеці. При цьому в багатьох компаніях, за словами Красовського, міграція починається з вибору хмарного провайдера та узгодження бюджету — перш ніж архітектор має змогу провести аналіз системи — і саме в цьому криється причина, чому cloud-проєкти не дають очікуваної економії.
Перенесення монолітної системи в хмару, як показала його практика роботи з великими проєктами, саме по собі нічого не вирішує — разом із кодом переїжджають перевантажені процеси та архітектурні обмеження, що накопичувалися роками. Хмарний провайдер не оптимізує те, що отримує — він це тарифікує.
«Коли я заходжу в такий проєкт, перше, що роблю, — намагаюся якомога раніше повернути розмову до архітектури, — каже експерт. — Поки немає розуміння, як розбити систему, будь-яке рішення про переїзд — це вибір тарифу, а не архітектурне рішення».
У великих продуктах, розробкою яких керував Красовський, значна проблема монолітної архітектури полягає в неможливості масштабувати високонавантажені компоненти окремо від усієї системи. У хмарі це перетворюється на прямі витрати: провайдер тарифікує всю виділену потужність, навіть коли 80% навантаження припадає на один компонент із десяти.
Перше питання, яке Красовський ставить у таких проєктах, — як розділити систему на незалежні частини. Саме це рішення визначає вартість хмари за рік. За його словами, те саме обмеження стримувало й темп команди:
«Команди впиралися в архітектуру раніше, ніж у завдання. Ти не можеш прискорити виведення нового функціоналу, якщо вся система оновлюється лише цілком», — пояснює він.
В одному з проєктів міграції, за який Красовський відповідав як архітектор усієї системи, такий підхід дав змогу знизити витрати на утримання продукту на 30%. Проєкт передбачав декомпозицію монолітного продукту на мікросервіси та перехід на інфраструктуру Amazon Web Services.
Головним результатом для бізнесу Красовський вважає можливість швидше втілювати новий функціонал — від ідеї до реалізації. Після переходу на мікросервіси команди перестали чекати одна на одну, завдяки чому швидкість виведення нових функцій зросла у 2,5 раза.
«Так вийшло не само собою. Ми одразу проєктували сервіси так, щоб кожен можна було розгортати незалежно. Якщо не закласти це на етапі декомпозиції моноліту, — каже експерт, — мікросервіси перетворяться на розподілений моноліт із тими самими проблемами або навіть гіршими».
Такий підхід до архітектури Красовський сформував задовго до роботи з компанією «Великої четвірки». У складі команди OpenText він брав участь у розробці системи управління бізнес-процесами, яку використовували компанії з Fortune 500. Зараз він також керує архітектурною практикою в Trinetix, де координує роботу 50 архітекторів і займається стандартизацією підходів для великих enterprise-проєктів. За словами Красовського, робота з корпоративними системами змінює погляд на розробку: архітектурні рішення ухвалюються з урахуванням наслідків для бізнесу.
«Коли систему використовують десятки тисяч співробітників, перестаєш думати лише про функції. Починаєш думати, скільки коштуватиме кожна наступна зміна або що буде, якщо критичний сервіс „впаде“ у п’ятницю ввечері перед закриттям фінансового періоду», — каже він.
І підкреслює, що архітектура для великих компаній уже стала інструментом управління довгостроковими ризиками. Від неї залежить, наскільки дорого бізнесу обійдеться розвиток продукту і чи вдасться уникнути інфраструктурних криз.
