8 міфів про монолітну архітектуру. Спростовуємо з Head of Engineering у Universe Group

Монолітна архітектура — традиційний підхід до розробки ПЗ. Програма створюється як єдине ціле, і увесь код зберігається в одному місці. Зараз «моноліти» часто сприймають як застарілий концепт і протиставляють мікросервісній архітектурі, де частини програми — сервіси — розподілені.  

Як зазначає Ігор Закутинський, Head of Engineering у компанії Universe Group, до популяризації мікросервісної архітектури призвели: 

• розвиток хмарних сервисів (як AWS, Google Cloud, Azure). У cloud-based середовищі мікросервіси часто виявляються зручнішими завдяки своїй гнучкості та можливості незалежного масштабування;

  
  

• зміна підходів у веб-розробці. Раніше більшість веб-застосунків створювали як моноліти з використанням мов на кшталт PHP, у яких логіка обробки та генерації HTML відбувається на сервері. З часом з’явилися SPA (Single Page Applications), зросла потреба в API-first підході, і на перший план вийшла JavaScript-екосистема. Це дало поштовх до масового використання асинхронних рішень, які стали основою мікросервісного підходу;

  
  

Але багато програм базується на монолітній архітектурі. Разом із Ігорем Закутинським ми розібралися в міфах навколо неї. 

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

• Невеликих та середніх проєктів, які ще не потребують складної масштабованості чи розподіленої інфраструктури.

  
  

• Продуктів на ранніх стадіях розвитку, коли головне — швидко протестувати гіпотезу, випустити MVP та зібрати фідбек.

  
  

• Команд із невеликою кількістю розробників, де мікросервісна архітектура лише ускладнить CI/CD (DevOps-практика безперервної інтеграції та безперервної доставки — Ред.), інфраструктуру та моніторинг. У монолітах немає проблеми міжсервісної комунікації, що спрощує взаємодію між різними частинами системи.

  
  

• Проєктів із жорсткими вимогами до продуктивності, де важлива мінімальна затримка між викликами. У моноліті взаємодія між модулями здійснюється в рамках одного процесу — без мережевих затримок. Це критично, наприклад, для систем реального часу.

  
  

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

Але це працює не завжди й не всюди. Деякі компанії, як-от Basecamp чи GitHub, на практиці зіткнулися з недоліками мікросервісів. Зокрема, у них виникали проблеми з міжсервісною комунікацією: наприклад, коли сервіс A мав викликати функціонал сервісу B, кожен запит проходив мережею, що призводило до збільшення затримок та ускладнення дебагу. Тому ці компанії частково повернули монолітний підхід в критичні модулі, де всі виклики відбуваються у межах одного процесу. Це дозволило значно зменшити затримки та спростити архітектуру для певних частин системи.

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

Моноліт не застарів — він еволюціонував. Є сучасні підходи, що поєднують гнучкість мікросервісів із простотою монолітів:

• Модульний моноліт: поділ на незалежні модулі з чіткими API.

  
  

• Моноліт із сервісною архітектурою — всередині моноліту використовують внутрішні сервіси, що імітують мікросервіси.

  
  

• Контейнеризація, що спрощує розгортання та масштабування монолітів.

  
  

• GraphQL та внутрішні API: спрощують взаємодію між модулями.

Цей міф виник тому, що багато класичних монолітів і мали складні, ручні або напівавтоматизовані процеси розгортання. У ті часи DevOps-підходи ще не були сформовані, а оновлення здійснювалися без CI/CD — часто шляхом копіювання файлів на продакшен-сервери вручну або за допомогою простих скриптів. Але це проблема не архітектури, а історичного контексту.

Моноліт, створений із урахуванням сучасних практик, може бути так само DevOps-friendly, як і будь-який мікросервісний проєкт. Ба більше — через цілісність його навіть простіше деплоїти, тому що немає потреби оновлювати десятки сервісів окремо.

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

Сучасні моноліти багато взяли від мікросервісної архітектури, адже в процесі еволюції розробники дивились на підходи до модульності, чіткого розподілу обов'язків. Зараз моноліт – це набір структурованих модулів, які можуть працювати незалежно один від одного. Є концепція  monorepo — монорепозиторію. Вона дозволяє мати розподілені підмодулі в рамках одного репозиторія. Такий підхід суттєво спрощує розробку, деплоймент і навіть масштабування. 

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

Є сенс виносити певний функціонал в окремий мікросервіс, коли навантаження на один модуль не пропорційне навантаженню на інші модулі.

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

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

• вертикального масштабування — додавання ресурсів (CPU, RAM) до одного сервера. Це просте та ефективне рішення на ранніх етапах. Практично кожен продукт, який я розробляв із нуля, стартував як моноліт і спочатку масштабувався саме так;

  
  

• горизонтального масштабування — запуск кількох копій моноліту під балансувальником навантаження. Такий тип підходить для веб-додатків, API-серверів тощо;

  
  

• розділення бази даних — sharding, реплікація, відокремлення read/write-реплік. Це дозволяє зменшити bottlenecks при доступі до даних, навіть у межах моноліту.

  
  

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

Насправді продуктивність залежить не від архітектурного підходу, а від якості реалізації, вибору технологій, структури бази даних, кешування та багатьох інших факторів. У багатьох випадках моноліт працює навіть швидше, ніж мікросервісна система, оскільки:

• Всі виклики між модулями відбуваються всередині одного процесу, без мережевих звернень.

  
  

• Немає оверхеду на серіалізацію/десеріалізацію даних, а також обробку помилок мережі, timeouts, retries тощо.

  
  

• Менше інфраструктурних компонентів = менше точок відмови.

  
  

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

Безумовно, це не так. Якщо в команді є ефективні практики написання коду, якщо ви домовились про стилістику і всі ваші команди її дотримуються, то проблеми з підтримкою не буде. 

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

Але при монолітному підході дійсно легше писати поганий код, ніж при мікросервісному, адже немає гострої необхідності структурувати його по модулях, розбивати на підсервіси тощо, тобто знехтувати найкращими практиками набагато легше.

Насправді все навпаки: добре спроєктована монолітна архітектура зазвичай є простішою для розуміння, розробки та підтримки, особливо на ранніх етапах проєкту. Мікросервіси складніше «за замовчуванням», і їх варто обирати тоді, коли ця складність виправдана перевагами: масштабуванням, незалежністю команд, fault-tolerance. Тому часто моноліт — не складність, а навпаки, спосіб її зменшити.