Чому команди повертаються від мікросервісів до модульних монолітів

Поділ на сервіси не скасовує складності системи

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

Мережа додає власний клас відмов

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

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

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

Рішення залежить від масштабу команди, а не моди

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