Заказчики приходят с одинаковой болью: монолит, который пять лет рос вместе с бизнесом, теперь тормозит сам бизнес. Любая правка тянет регрессию во всей системе, релиз готовят неделями, а команда боится трогать ядро. Микросервисы и контейнеры обещают вылечить это. Обещание реальное, но цена ошибки высока – поэтому интегратор не «модернизирует ради моды», а считает, что именно даёт распил монолита конкретному заказчику.
Когда монолит пора резать
Монолит – не диагноз. Небольшая система с одной командой и редкими релизами в монолите живёт прекрасно, и трогать её незачем. Резать стоит, когда совпадают три условия: разные части приложения меняются с разной скоростью, нагрузка на модули неравномерна, а одна команда уже не вмещает всю кодовую базу в голову.
Прежде чем рисовать границы сервисов, мы проводим аудит ИТ-ландшафта. Без честной карты зависимостей декомпозиция превращается в гадание: вы вытаскиваете «сервис», а он тянет за собой половину базы данных и три чужих таблицы. Границы микросервисов должны идти по швам бизнес-доменов, а не по слоям кода. Биллинг, каталог, личный кабинет – это кандидаты. «Слой работы с БД» – нет.
Что реально дают контейнеры
Docker за последние пару лет превратился из инструмента энтузиастов в производственный стандарт. Для интегратора ценность контейнеров не в хайпе, а в трёх вещах.
Во-первых, повторяемость. Образ, собранный на ноутбуке разработчика, едет на тестовый стенд и в продакшн без сюрпризов «у меня же работало». Для госзаказчика с жёсткими регламентами приёмки это означает предсказуемую сдачу работ.
Во-вторых, изоляция. Каждый сервис несёт свои зависимости и версии библиотек. Обновление одного компонента не ломает соседей – критично, когда часть системы должна работать на сертифицированных версиях ПО, а часть требует свежих библиотек.
В-третьих, плотность. На том же железе размещается больше сервисов, чем при модели «одна виртуалка – одно приложение». В импортозамещении и при ограниченных бюджетах на инфраструктуру это прямая экономия.
Оркестрация в России пока в начале пути: команды осторожно смотрят на Kubernetes, многие держат контейнеры под Docker Compose или простыми скриптами. Мы не навязываем тяжёлый стек там, где хватает легкого, – выбор зависит от зрелости команды заказчика и требований к отказоустойчивости.
Чем платят за распределённость
Микросервисы переносят сложность из кода в сеть. Вместо одного вызова функции – вызов по HTTP, который может отвалиться, зависнуть или вернуть мусор. Появляются распределённые транзакции, версионирование контрактов, рассинхрон данных между сервисами.
Главная плата – наблюдаемость. В монолите вы читаете один лог. В системе из двадцати сервисов вы не понимаете, где умер запрос, пока не настроите сквозную трассировку. Без неё инцидент превращается в часы догадок. Поэтому трассировку, централизованные логи и метрики мы закладываем не «потом», а сразу в архитектуру.
Этот баланс – сервисы и их зависимости, версии образов, точки отказа – должен быть зафиксирован. Мы ведём его в реестре, первые записи которого появляются ещё на этапе проектирования, а не после первого падения в проде.
Вывод
Микросервисы и контейнеры – инструмент, а не цель. Они окупаются, когда монолит действительно мешает бизнесу меняться, и становятся обузой, когда их внедряют ради галочки. Интегратор обязан считать обе чаши весов. Распил монолита окупается только тогда, когда за ним стоит трезвая оценка ландшафта и поэтапный план перехода на новую инфраструктуру.