Я сбился со счёта, сколько микросервисных проектов я видел — каждый с гордостью показывает свой “новый, масштабируемый до бесконечности набор микросервисов”. И каждый раз я думаю: через полгода всё это развалится. Не потому что микросервисы — плохая идея. У них есть своё место. Но это место точно не в команде из трёх человек с полуготовым MVP.
Парадокс? Самые успешные проекты, которые я видел — те, что реально запускались, регулярно релизились и не сливали бюджеты на бесполезную инфраструктуру — работали на монолитах.
Да, на тех самых “динозаврах” программной архитектуры.
Монолит — не враг
В какой-то момент слово “монолит” стало ругательством. Почти как “легаси”. Но большинство тех, кто осуждает монолиты — никогда не делали ничего сложнее CRUD-приложения.
А между тем, реальные проекты, которые находят пользователей, генерируют выручку и растут, зачастую пишут целый бизнес в одном репозитории с Postgres на бэке и одной большой папкой services.
И это работает. Великолепно работает.
Монолит — не проблема. Преждевременная сложность — вот настоящая беда.
Миф о “масштабируемости”
Молодые проекты обожают говорить, что “строят под масштаб”. Типа: “А что если нас завтра будет миллион пользователей?” — говорят они, в то время как форма регистрации на сайте не работает.
Реальность такова:
Молодым проектам не нужно масштабироваться. Им нужно выжить.
Им нужно быстро понять, что они вообще делают, и суметь резко сменить курс. Им нужно деплоить каждый день (а лучше каждый час), не разбираясь сутками, почему не работает gRPC между двумя контейнерами на одном и том же сервере.
На раннем этапе гибкость важнее масштабируемости. Простота лучше элегантности.
Рабочий, понятный код > распределённый код, который вызывает слёзы.
Быстро. Сфокусированно. В прод.
Знаете, что происходит, когда вы строите монолит?
Вы завершаете задачи.
Вы не тратите три дня, решая, нужно ли выносить авторизацию в отдельный сервис. Вы не пишете YAML ради YAML. Вы не заводите пять репозиториев и не называете это “архитектурой”.
Вы просто… делаете фичу.
Именно поэтому опытные команды чаще выбирают монолит. Потому что они уже прошли через весь этот микросервисный ад и знают цену вопроса. И знают, что это оправдано только при настоящей нагрузке.
Facebook в начале? Монолит.
GitHub? Монолит.
Amazon? Тоже начал как монолит — до того, как стало ясно, что нужно делить.
Цена микросервисов — не только техническая
Все говорят про границы сервисов и масштабируемость. Никто не говорит про мотивацию команды.
Попробуйте онбордить разработчика в проект с 40 микросервисами, половина из которых без документации и с названиями в стиле payment-helper-v2-legacy. Посмотрите, как его душа тихо покидает тело.
А теперь сравните это с аккуратным, читаемым монолитом. Где можно найти нужную функцию и где “запустить проект” — это не три bash-скрипта и ритуал жертвоприношения.
Архитектура напрямую влияет на скорость команды. И микросервисы, если они не являются абсолютно необходимым злом, скорее тормозят, чем помогают. Культурно. Логистически. Ментально.
Монолит легко разбить. А вот микросервисы обратно не собрать.
Монолит — обратим. Микросервисы — нет.
Если монолит разрастается — отлично. Выделите часть. Отделите её, когда она начнёт мешать. И делать это нужно только после того, как появятся реальные “швы” в коде, по которым удобно резать.
Хорошая архитектура растёт органически, а не рисуется заранее в блокноте.
Вы не защитите свой проект, строя сложную систему. Вы защищаете его, выживая. Быстро. Разумно. И без выгорания.
Итог
Монолиты — не устарели. Они недооценены.
Они не потому что вы ленитесь. А потому что вы умны.
Потому что вы строите успешный проект, а не защищаете диплом по распределённым системам.
Потому что вы знаете: технологии — это не про “что модно”. Это про что работает.
А когда вы действительно достигнете той самой мифической “нагрузки” — у вас уже будут и деньги, и команда, и понимание, как и зачем всё разносить.
А до тех пор?
Релизьтесь быстро. Проектируйте просто. Да здравствует монолит!