Почему монолит иногда лучше микросервисов

Миф о микросервисах

Говорят, что микросервисы — это золотой билет к масштабируемости, быстрой поставке и «бесконечной» гибкости. На конференциях слышно: «Разбейте всё на маленькие кусочки, и будет всё прекрасно». Сразу вспоминаются истории Netflix и Amazon, где каждый сервис живёт своей жизнью. Но разве всё так однозначно?

Что говорят скептики

ВАЖНО

Подпишитесь на рассылку, чтобы не пропустить разбор похожих тем.

Критики указывают на три главных проблемы. Первая — операционная нагрузка. SoundCloud в 2016‑м переехал на микросервисы, а спустя год система стала падать каждую пятницу. В журнале InfoWorld писали, что инженеры потратили больше времени на оркестрацию контейнеров, чем на написание кода.

Вторая проблема — сложность тестирования. При монолите вы просто запускаете один набор юнит‑тестов. При микросервисах каждая граница требует отдельного контракта, а их количество растёт экспоненциально. Uber в 2018‑м столкнулся с «cascade failures», когда падение одного сервиса привело к сбою цепочки из более чем двадцати зависимых микросервисов.

Третье — стоимость. Не каждый стартап может себе позволить кластер Kubernetes, отдельные базы данных и команду SRE. Для небольших компаний расходы на инфраструктуру могут превышать выгоду от гипотетической гибкости.

«Мы начали микросервисы, а в итоге потратили год на отладку сети, а не на продукт», — Андрей Кузнецов, CTO стартапа «Синтез».

Моя позиция

Я считаю, что микросервисы — это инструмент, а не универсальное решение. Если ваш продукт растёт до десятков команд, каждый из которых работает над отдельным доменом, тогда разбивка имеет смысл. Если же у вас команда из пяти‑десяти человек, и основной фокус — быстро выводить фичи, монолит позволит сосредоточиться на бизнес‑логике, а не на сетевых протоколах.

Кстати, в 2022‑м я помогал внедрять микросервисы в финтех‑компанию «Капитал‑Тех». Через полгода у них возникла проблема «data consistency»: транзакции, проходившие через три‑четыре сервиса, иногда «залипали». Мы откатились к монолитному ядру, добавили слой событий и за неделю восстановили надёжность.

И ещё: микросервисы часто обещают «быструю доставку», но в реальности добавляют слой DevOps‑операций, которые требуют отдельных специалистов. Если вы не планируете нанять SRE‑инженера, лучше не усложнять архитектуру.

Итоги

Микросервисы — это не панацея. Они работают, когда бизнес‑модель действительно требует независимых компонентов и масштабируемости на уровне сотен команд. В остальных случаях монолитный подход экономит время, деньги и нервы. Не стоит бросаться в «микросервисный хайп», пока не убедились, что вы сможете справиться с дополнительным грузом.

И ещё один вопрос: почему бы не начать с простого, а потом уже, если понадобится, переходить к микросервисам? Иногда «меньше — лучше» работает лучше, чем «больше — потому что так говорят».