Почему монолит помогает запускать IT-проекты быстрее и дешевле

Я сбился со счета, сколько микросервисных проектов я видел — каждый с гордостью показывает свой «новый, масштабируемый до бесконечности набор микросервисов». И каждый раз я думаю: через полгода все это развалится. Не потому что микросервисы — плохая идея. У них есть свое место. Но это место точно не в команде из трех человек  с полуготовым MVP.

Парадокс? Самые успешные проекты, которые я видел — те, что реально запускались, регулярно релизились и не сливали бюджеты на бесполезную инфраструктуру — работали на монолитах.

Да, на тех самых «динозаврах» программной архитектуры.

Монолит — не враг

В какой-то момент слово «монолит» стало ругательством. Почти как «легаси». Но большинство тех, кто осуждает монолиты — никогда не делали ничего сложнее CRUD-приложения.

А между тем, реальные проекты, которые находят пользователей, генерируют выручку и растут, зачастую пишут целый бизнес в одном репозитории с Postgres на бэке и одной большой папкой services.

И это работает. Великолепно работает.

Монолит — не проблема. Преждевременная сложность — вот настоящая беда.

Миф о «масштабируемости»

Молодые проекты обожают говорить, что «строят под масштаб». Типа:

 А что если нас завтра будет миллион пользователей?

— говорят они, в то время как форма регистрации на сайте не работает.

Реальность такова:

Молодым проектам не нужно масштабироваться. Им нужно выжить.

Им нужно быстро понять, что они вообще делают, и суметь резко сменить курс. Им нужно деплоить каждый день (а лучше каждый час), не разбираясь сутками, почему не работает gRPC между двумя контейнерами на одном и том же сервере.

На раннем этапе гибкость важнее масштабируемости. Простота лучше элегантности.

Рабочий, понятный код > распределенный код, который вызывает слезы.

Быстро. Фокусно. В прод

Знаете, что происходит, когда вы строите монолит?

Вы завершаете задачи.

Вы не тратите три дня, решая, нужно ли выносить авторизацию в отдельный сервис. Вы не пишете YAML ради YAML. Вы не заводите пять репозиториев и не называете это «архитектурой».

Вы просто… делаете фичу.

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

GitHub? Монолит. Amazon? Тоже начал как монолит — до того, как стало ясно, что нужно делить.

Цена микросервисов — не только техническая

Все говорят про границы сервисов и масштабируемость. Никто не говорит про мотивацию команды.

Попробуйте онбордить разработчика в проект с 40 микросервисами, половина из которых без документации и с названиями в стиле `payment-helper-v2-legacy`. Посмотрите, как его душа тихо покидает тело.

А теперь сравните это с аккуратным, читаемым монолитом. Где можно найти нужную функцию и где «запустить проект» — это не три bash-скрипта и ритуал жертвоприношения.

Архитектура напрямую влияет на скорость команды. И микросервисы, если они не являются абсолютно необходимым злом, скорее тормозят, чем помогают. Культурно. Логистически. Ментально.

Монолит легко разбить. А вот микросервисы обратно не собрать

Монолит — обратим. Микросервисы — нет.

Если монолит разрастается — отлично. Выделите часть. Отделите ее, когда она начнет мешать. И делать это нужно только после того, как появятся реальные «швы» в коде, по которым удобно резать.

Хорошая архитектура растет органически, а не рисуется заранее в блокноте.

Вы не защитите свой проект, строя сложную систему. Вы защищаете его, выживая. Быстро. Разумно. И без выгорания.

Итог

Монолиты — не устарели. Они недооценены.

Они не потому что вы ленитесь. А потому что вы умны.

Потому что вы строите успешный проект, а не защищаете диплом по распределенным системам. Потому что вы знаете: технологии — это не про «что модно». Это про что работает.

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

А до тех пор?

Релизьтесь быстро. Проектируйте просто.