Моноліт чи мікросервіси: як вибрати архітектуру проєкту та не прогадати

Архітектура проєкту (Software Architecture) — це правила, за якими розробляється продукт. Від архітектури залежить, як буде організована структура продукту, як взаємодіятимуть між собою основні компоненти, чи зручно буде масштабуватися та підтримувати програмне забезпечення (ПЗ). 

Хто вибирає, якою буде архітектура? Залежно від розміру проєкту та організації роботи в ньому, це може бути архітектор (Software/Solution Architect), Техлід (Tech Lead), CTO або головний розробник.

Як перевірити, чи правильно вибрано архітектуру? Amazon пропонує AWS Well-Architected Framework — набір інструментів, що дозволяють оцінити архітектуру за 6 основними напрямками:

• Операційна досконалість (Operation Excellence) — чи зручно управляти системою;
• Безпека (Security) — чи захищені дані на кожному етапі;
• Надійність (Reliability) — чи витримує система збої, чи може вона відновитися;
• Ефективність роботи (Performance Efficiency) — як використовуються ресурси, чи можна масштабуватися;
• Оптимізація витрат (Cost Optimization) — чи не переплачує компанія;
• Сталість (Sustainability) — як архітектура впливає на екологію.

AWS надає змогу зрозуміти стан системи, виявити ризики та запланувати зміни.

Існує кілька видів архітектур. Монолітна та мікросервіси — найпоширеніші з них.

Монолітна архітектура — модель розробки програмного забезпечення, в якій всі частини продукту, включно з інтерфейсом, бізнес-логікою та базою даних, об’єднані та розгортаються разом.

Це традиційний підхід до розробки ПЗ, адже моноліт з’явився значно раніше за мікросервіси.

Моноліт дозволяє розробляти продукт і розгортати інфраструктуру швидко. Завдяки тому, що код централізований та локалізований в одному місці, його легше моніторити та змінювати на початкових етапах. Монолітна архітектура оптимально підходить для невеликих проєктів та стартапів, де важливо швидко випустити MVP (мінімально життєздатний продукт) та протестувати його.

Основний недолік цього методу в тому, що збій у роботі одного компонента може вразити всю систему. Якщо потрібна гнучка архітектура, яку легко змінювати та масштабувати, — частіше вибирають мікросервіси.

Мікросервісна архітектура — це підхід, у якому продукт складається з окремих сервісів. Кожен із них містить одну бізнес-функцію та спілкується з іншими через API.

Сьогодні це найпоширеніший варіант для розробки продуктів. Мікросервіси добре поєднуються з CI/CD моделлю та принципами DevOps.

Мікросервіси надають змогу:

• паралельно працювати над різними частинами продукту;
• продовжувати роботу, навіть якщо десь стався збій;
• об’єднувати команди, кожна з яких працює над окремим завданням;
• використовувати окрему базу даних та різні технології для кожного сервісу;
• тестувати, розгортати та масштабувати окремі елементи без впливу на інші.

Мікросервісна архітектура використовується для складніших та вимогливіших продуктів, які будуть масштабовані в майбутньому та мають високі вимоги до безпеки.

Наприклад, в інтернет-магазині один сервіс може відповідати за нові замовлення, інший — за обробку їх на складі, третій — за платежі та виплати, четвертий — за базу даних покупців і так далі.

Недолік мікросервісної архітектури — інфраструктура складніша, ніж у моноліту. Сервіси не об’єднані, тож комунікаціям варто приділяти окрему увагу.

Коли архітектор планує, як відбуватиметься робота над проєктом, він враховує:

• Чи буде продукт масштабований — для невеликих підійде моноліт, для більших — мікросервіси;
• Чи є обмеження в термінах і бюджетах — розробка на моноліті зазвичай швидша та дешевша;
• Чи багато в продукті функцій, чи планується інтегрувати його з іншими системами — якщо відповідь «так», то краще вибирати мікросервіси;
• Чи будуть регулярні оновлення — тоді потрібні мікросервіси.

Архітектуру можна змінити в процесі розробки. Багато компаній починали робити продукти на моноліті та з часом перейшли на мікросервіси, наприклад, Netflix та Uber.

Amazon Prime Video, навпаки, переосмислила бізнес-процеси та перейшла з мікросервісів на моноліт. Їхній інструмент моніторингу якості відео Video Quality Analysis (VQA) контролював тисячі відеопотоків одночасно. Витрати на те, щоб масштабувати продукт, були величезними. Перехід на моноліт знизив їх на 90%.

Окрім мікросервісної та монолітної, існують:

• Сервіс-орієнтована архітектура (Service-Oriented Architecture, SOA) — всі частини системи представлені у вигляді окремих сервісів, які можуть обмінюватися інформацією. Подібна до мікросервісів, але ширша — може охоплювати не один продукт, а всю IT-інфраструктуру компанії;
• Подійно-орієнтована архітектура (Event-Driven Architecture, EDA) — побудована навколо подій, тобто невеликих повідомлень, які надсилаються, коли в системі щось відбувається. Сервіси реагують на ці події;
• Безсервісна архітектура (Serverless Architecture) — дозволяє запускати функції без управління серверами;
• Клієнт-сервісна архітектура (Client–Server Architecture) — має чітке розділення ролей. Клієнтська частина потрібна для взаємодії з користувачем, сервісна — щоб обробляти дані.

На практиці часто використовують гібридні методи, що поєднують у собі можливості різних архітектур. Наприклад, мікросервіси + EDA = мікросервіси обробляють події в реальному часі.