Мистер Монолит vs банда микросервисов 🥊

Объявим участников. В правом углу — бывший чемпион в супертяжелом весе, грозный и опытный Мистер Монолит. В левом — молодая и дерзкая банда микросервисов, лёгкая на подъем, но со своим характером.

Я видел в жизни несколько настоящих монстров. Один монолит, например, собирался больше пяти часов, и компания построила свой собственный CI, чтобы просто не стоять на месте. С другой стороны, видел и микросервисную архитектуру, в которой для запуска требовалось 11 балансировщиков. Просто представьте себе делать это руками.

Если бы вас поймали лет пять назад, вы бы с энтузиазмом заявил, что монолит — это зло, а микросервисы — светлое будущее. И процитировали бы весь учебник. Но, как это часто бывает, жизнь вносит правки. И теперь я знаю: путь микросервисов может быть не менее опасным, чем путь монолита.

Монолитная архитектура — это подход к построению приложений, где весь функционал концентрируется в одном приложении или модуле. Все компоненты, такие как пользовательский интерфейс, бизнес-логика и база данных, находятся внутри одной кодовой базы.

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

💀 Позвольте мне пропустить рассказ о проблемах монолитов — нет смысла пинать мёртвую лошадь. Вместо этого давайте на минуту задержим взгляд на микросервисах.

Проблема в том, что кроме написания кода есть ещё куча всего: сборка, тесты, деплой, мониторинг, масштабирование… и всё это надо проделывать не один раз, а столько раз, сколько у вас микросервисов. Причём, если вы решили делать всё на разных технологиях (а это случается чаще, чем хочется), то забудьте о переиспользовании решений — вы в аду. В худшем случае, каждый микросервис будет как капризный ребёнок со своим характером.

Дежурства становятся весёлыми. В два часа ночи кто-то из микросервисов «чуть-чуть подустал» — и просыпается именно тот, кто знает, где у этого сервиса находится печень. А если он в отпуске и без связи? Ну, держитесь. Монолит, при всех его грехах, даёт хотя бы общее понимание происходящего.

Изменения в коде? В монолите — поправил в одном месте. В микросервисах — вноси изменения в интерфейсы, поддерживай обратную совместимость, обновляй документацию. К тому моменту, как ты закончишь, можно и бизнес переписать.

И тут открывается главный риск: стартапы с большими амбициями. Они начинают с микросервисов, будто уже завтра выйдут на IPO. А в итоге — лишняя сложность, медленная разработка и операционные риски, потому что «архитектура как у Netflix» — это не волшебная таблетка, а огромная ответственность.

🎭 А ведь и с монолитом не всё так просто. Он растёт, толстеет, становится всё более громоздким, и в какой-то момент вы понимаете, что разделить его теперь — это как распилить самолёт на ходу.

Всё упирается в масштаб. Смотря под каким углом смотришь — любой монолит на самом деле уже состоит из микросервисов, просто не таких формализованных. А в микросервисах, если честно, часто обнаруживается пара жирных монолитов, которые спрятались под капотом и делают вид, что они «микро».

Что же выбрать? Позвольте открыть портал в ад и сказать: я за здравый смысл. Большинству проектов отлично подойдёт разумно устроенный монолит, один или два сервиса, ничего сверхъестественного. А дальше — наблюдать. Как только вы начинаете тратить 5% времени на борьбу с архитектурой — самое время подумать о разделении.

Например, на том же любимом всеми Битриксе, первым делом начинает хромать обмен с 1С. И это как раз тот случай, когда стоит выделить отдельный сервис, прокинуть шину — и вздохнуть спокойно.

В реальности почти не бывает чистых монолитов или идеальных микросервисов. Всё вокруг — гибрид, компромисс, эволюция. Главное — понимать, во сколько обойдётся трансформация и насколько больно её будет делать. Всё остальное — детали.