За последние годы я наблюдал десятки команд, которые выбирали микросервисную архитектуру. Почти всегда обоснование звучало одинаково: «Netflix так делает», «это industry standard», «монолит не масштабируется». Почти никогда обоснование не звучало так: «у нас 200 разработчиков и 50 000 RPS, и мы не можем деплоить независимо».
Проблема не в микросервисах как таковых. Проблема в том, что инженеры часто строят то, что хотят построить, а не то, что нужно бизнесу. Разница между этими двумя вещами — сотни тысяч рублей в месяц на инфраструктуру, месяцы потраченного времени и команда, которая поддерживает платформу вместо того, чтобы создавать продукт.
Эта статья — попытка систематизировать то, что я вижу снова и снова. Архитектуру должны определять цифры: количество пользователей, объём трафика, размер данных, количество разработчиков и стадия бизнеса. Не модные тренды. Не конференции. Не желание добавить строчку в резюме.
Resume-Driven Development: строим то, что хорошо смотрится в резюме
Есть феномен, который в индустрии называют Resume-Driven Development (RDD). Суть проста: инженеры выбирают технологии и архитектурные решения не потому, что они лучше всего решают задачу, а потому что их хочется добавить в резюме.
Kelsey Hightower однажды точно заметил:
Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality.
Я видел это множество раз. Kubernetes разворачивают для трёх сервисов с суммарным трафиком в 100 запросов в минуту. Event sourcing внедряют для CRUD-приложения, где нет ни одного бизнес-требования к восстановлению истории изменений. Микросервисы проектируют в команде из пяти человек, где каждый разработчик отвечает за два-три сервиса и половину времени тратит на починку межсервисного взаимодействия.
Последствия RDD предсказуемы и всегда одни и те же:
- Рост сложности. Вместо одного приложения, которое можно запустить одной командой, появляется зоопарк сервисов, каждый со своим деплоем, мониторингом и конфигурацией.
- Замедление разработки. Фича, которая в монолите укладывается в один PR, в микросервисах превращается в координацию изменений в трёх-четырёх репозиториях.
- Удорожание инфраструктуры. Каждый сервис — это отдельный контейнер, балансировщик, логирование, трейсинг. Стоимость растёт линейно, а чаще суперлинейно.
- Размытие ответственности. Когда что-то ломается, дебаг распределённой системы превращается в детектив с distributed tracing, где никто не может быстро найти корневую причину.
Если вы выбираете технологию, спросите себя честно: «Я это делаю, потому что так лучше для продукта, или потому что хочу написать это в резюме?»
Что такое монолит и почему это не плохое слово
В какой-то момент слово «монолит» стало ругательством. Монолит ассоциируется с legacy, с огромным комом грязи, с кодом, который невозможно поддерживать. Но это не свойство монолита как архитектуры — это свойство плохо написанного кода.
DHH, создатель Ruby on Rails, ввёл термин «Majestic Monolith» — величественный монолит. Его тезис: монолит — это не наследие прошлого, а осознанный архитектурный выбор. Basecamp и HEY обслуживают миллионы пользователей на монолитной архитектуре, и у них нет планов переходить на микросервисы. Потому что им это не нужно.
Между чистым монолитом и микросервисами есть промежуточный вариант — модульный монолит. Это единое приложение, но с чёткими границами между модулями. Каждый модуль отвечает за свой домен, имеет определённый публичный API и минимальные зависимости от других модулей. Деплоится как единое целое, но внутри структурирован так, что модуль можно относительно легко выделить в отдельный сервис, если в этом появится реальная необходимость.
Один из самых ярких примеров — Shopify. 2.8 миллиона строк кода на Ruby, более 500 000 коммитов, обработка 30 ТБ исходящего трафика в минуту во время пиковых распродаж вроде Чёрной Пятницы или Кибер Понедельника. И это модульный монолит. Shopify сознательно выбрали эту архитектуру и инвестировали в инструменты, которые позволяют сотням разработчиков работать в одной кодовой базе, не мешая друг другу.
Преимущества монолита часто недооценивают:
- Простота деплоя. Один артефакт, один пайплайн, один процесс.
- Простота отладки. Stack trace показывает всю цепочку вызовов. Не нужен distributed tracing.
- Вызовы методов вместо сетевых запросов. Вызов метода занимает наносекунды. HTTP-запрос занимает миллисекунды. Разница в порядки.
- Транзакционная целостность. ACID-транзакции в одной базе данных просты. Распределённые транзакции (саги, двухфазный коммит) сложны и ненадёжны.
Микросервисы: реальная цена, которую не показывают на конференциях
На конференциях микросервисы выглядят красиво. Аккуратные диаграммы с прямоугольниками и стрелочками. Независимый деплой. Масштабирование отдельных компонентов. Свобода выбора технологий для каждого сервиса.
В реальности за каждым из этих преимуществ стоит цена, о которой докладчики предпочитают не говорить.
Инфраструктурные расходы. По различным оценкам, инфраструктура для микросервисов обходится в 3.75-6 раз дороже, чем для аналогичного монолита. Каждому сервису нужен свой контейнер (а часто — несколько реплик), свой сетевой endpoint, свой health check. Плюс сервисная инфраструктура: service mesh, API gateway, message broker, distributed tracing, centralized logging.
Операционная сложность. Без зрелой платформенной команды рекомендуемое соотношение — 1 SRE на 5-10 сервисов. Если у вас 30 микросервисов и нет платформенной команды, кто-то из разработчиков будет тратить существенную часть времени на операционные задачи вместо разработки продукта.
Сетевые вызовы вместо вызовов методов. Каждый межсервисный вызов — это сетевой запрос с задержкой, возможностью таймаута и отказа. Для каждого вызова нужны: retry с backoff, circuit breaker, timeout, обработка частичных отказов. Один запрос пользователя, который в монолите проходит через 5 вызовов методов за микросекунды, в микросервисах может породить цепочку из 5 сетевых вызовов, каждый из которых добавляет 5-50 мс латентности.
«Microservices tax». Это совокупная стоимость поддержки микросервисной архитектуры: мониторинг, алертинг, деплой пайплайны, сервис-каталоги, документация API, контрактное тестирование, управление версиями. По разным оценкам, этот «налог» составляет до 40% инженерного бюджета команды.
Вот грубая оценка ежемесячной стоимости для типичного B2B сервиса с 10 000 пользователей по моей оценке:
| Категория | Монолит | Микросервисы (15-20 сервисов) |
|---|---|---|
| Вычислительные ресурсы | 200-300 тыс. ₽ | 750 тыс. — 1.1 млн ₽ |
| Базы данных | 100-200 тыс. ₽ | 300-450 тыс. ₽ |
| Очереди/брокеры | — | 100-300 тыс. ₽ |
| Мониторинг/трейсинг | 50-100 тыс. ₽ | 300-450 тыс. ₽ |
| Service mesh / API GW | — | 100-200 тыс. ₽ |
| CI/CD | 50-100 тыс. ₽ | 200-350 тыс. ₽ |
| Инженерное время на инфраструктуру | ~10% | ~30-40% |
| Итого (инфраструктура) | ~500-750 тыс. ₽/мес | ~1.7-2.8 млн ₽/мес |
Эти цифры приблизительные, но порядок верный. Для стартапа или небольшого бизнеса разница между 500 тысячами и 2.5 миллионами рублей в месяц — это один-два разработчика, которых можно было нанять вместо того, чтобы кормить инфраструктуру.
Конкретные метрики: когда микросервисы оправданы
Вместо абстрактных рассуждений давайте определим конкретные пороговые значения. Они не абсолютны — каждая ситуация уникальна — но дают хорошую отправную точку.
Размер команды. Это, пожалуй, самый важный фактор. Микросервисы решают прежде всего организационную проблему: как дать многим командам работать независимо. Закон Конвея никто не отменял — структура системы отражает структуру организации.
- Менее 10 разработчиков: монолит. У вас физически не хватит людей, чтобы поддерживать несколько сервисов и платформу. Каждый человек будет отвечать за несколько сервисов, координация съест весь выигрыш от независимости.
- 10-50 разработчиков: модульный монолит. Инвестируйте в чёткие границы модулей, контракты между командами, общие стандарты. Если какой-то модуль становится узким местом — выделите его в отдельный сервис.
- 50+ разработчиков: можно думать о микросервисах. У вас достаточно людей, чтобы сформировать платформенную команду, и организационная потребность в независимом деплое становится реальной.
Трафик. Горизонтальное масштабирование монолита — это просто. Ставите несколько инстансов за балансировщиком. Для подавляющего большинства приложений этого достаточно. Один инстанс Go-приложения может обработать десятки тысяч RPS. Четыре инстанса — сотни тысяч. Микросервисы для масштабирования нужны тогда, когда у вас есть компоненты с принципиально разными профилями нагрузки: например, обработка изображений (CPU-bound) и API-запросы (I/O-bound), и вам нужно масштабировать их независимо.
Объём данных. Одна база данных PostgreSQL на современном железе может хранить терабайты данных и обрабатывать тысячи транзакций в секунду. Декомпозиция данных нужна, когда: разные части данных имеют принципиально разные паттерны доступа (OLTP vs OLAP), объём превышает возможности одного сервера, или регуляторные требования диктуют изоляцию (PCI DSS, GDPR).
Бизнес-процесс. Если ваши доменные области тесно связаны (например, заказ, оплата и доставка в e-commerce), разделение их на сервисы создаст распределённый монолит — худший из миров. Микросервисы имеют смысл, когда домены действительно независимы: система уведомлений, аналитика, генерация отчётов — вещи, которые могут жить и развиваться отдельно.
Выручка и стадия бизнеса. Микросервисы — это инвестиция. Как любая инвестиция, она должна окупаться. По разным оценкам, вложение в микросервисную архитектуру оправдано при годовой выручке более ~1 млрд ₽ или при наличии более 50 разработчиков. До этого порога монолит почти всегда выгоднее — и по стоимости, и по скорости разработки. Если вы стартап, то ваш выбор монолит.
Главный вопрос, который должен задавать каждый инженер и каждый менеджер перед выбором архитектуры: «Какую конкретную проблему мы решаем?» Если ответ — «ну, для масштабирования на будущее» или «так принято» — это не проблема, это фантазия.
Те, кто попробовал и вернулся
Самые убедительные аргументы — это не теория, а реальный опыт компаний, которые попробовали микросервисы и приняли осознанное решение вернуться к монолиту.
Amazon Prime Video. В 2023 году команда Amazon Prime Video опубликовала статью о том, как они перевели свой сервис мониторинга качества видео с микросервисной архитектуры (serverless, Step Functions, Lambda) на монолит. Результат: снижение затрат на 90%. Микросервисная архитектура создавала огромный overhead на межсервисную коммуникацию, а масштабирование отдельных компонентов не давало преимуществ, потому что нагрузка была равномерной.
Twilio Segment. Один из самых показательных примеров. Segment начинал как монолит, затем перешёл на микросервисы — больше 140 сервисов. Три инженера обслуживали всю эту инфраструктуру. Проблемы с надёжностью росли, а продуктивность разработки падала. В итоге команда консолидировала 140 микросервисов обратно в один монолит. Продуктивность выросла на 44%, стабильность системы значительно улучшилась. Три человека, которые раньше тратили всё время на поддержку инфраструктуры, вернулись к разработке продукта.
Istio. Даже проект, который является сервис-мешем для микросервисов, отказался от собственной микросервисной архитектуры. В 2020 году Istio консолидировал свои компоненты (Pilot, Mixer, Citadel, Galley) в единый бинарник istiod. Причина: сложность деплоя, конфигурации и отладки при микросервисной архитектуре перевешивала преимущества.
Martin Fowler, который много писал о микросервисах, резюмировал это так:
- Almost all the successful microservice stories have started with a monolith that got too big and was broken up.
- Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
Правильный подход: начни с монолита
Martin Fowler предложил подход «Monolith First»: начинай с монолита, даже если уверен, что в будущем перейдёшь на микросервисы. Монолит позволяет быстро итерировать, менять границы между модулями, пока ты ещё не понял домен до конца.
Когда монолит перерастает свои возможности, есть три стратегии:
- Постепенная декомпозиция. Выделяете один модуль в отдельный сервис, стабилизируете, выделяете следующий. Самый безопасный путь, но медленный.
- Strangler Fig Pattern. Новая функциональность пишется как отдельный сервис, старая постепенно мигрирует. Монолит «задушивается» новой системой, как дерево — лианой.
- Крупноблочные сервисы. Вместо дробления на десятки микросервисов выделяете 3-5 крупных сервисов по основным доменам. Это даёт организационную независимость без операционного кошмара.
Консенсус 2026 года, который я вижу в индустрии, выглядит так: модульный монолит + 2-5 выделенных сервисов для горячих путей. Основное приложение — монолит с чёткими модулями. Компоненты с особыми требованиями (обработка медиа, real-time уведомления, аналитика) выносятся в отдельные сервисы. Этот подход даёт 80% преимуществ микросервисов при 20% их сложности.
Для 80% бизнесов — стартапов, малого и среднего бизнеса, внутренних корпоративных систем — монолит является самой выгодной архитектурой. Не потому, что микросервисы плохие, а потому, что они решают проблемы, которых у этих бизнесов нет.
Чек-лист: вопросы перед выбором архитектуры
Прежде чем принимать архитектурное решение, пройдитесь по этому списку вопросов. Честные ответы на них сэкономят месяцы работы и миллионы рублей.
Сколько у вас разработчиков? Если меньше 10 — монолит. Если 10-50 — модульный монолит. Больше 50 — у вас есть основания рассматривать микросервисы, но это всё равно не автоматический выбор.
Сколько у вас пользователей и какой RPS? Если меньше 10 000 RPS — горизонтально масштабированный монолит справится. Если у вас несколько миллионов пользователей и сотни тысяч RPS с разными профилями нагрузки — стоит подумать о выделении горячих путей.
Какой объём данных вы храните и обрабатываете? Один PostgreSQL справляется с терабайтами. Если у вас принципиально разные паттерны доступа к разным частям данных (OLTP и OLAP одновременно) — это аргумент за выделение, но не обязательно за микросервисы. Отдельная аналитическая БД — не микросервис.
Есть ли у вас DevOps/SRE команда? Микросервисы без платформенной команды — это разработчики, которые 40% времени занимаются инфраструктурой вместо продукта. Если нет выделенных SRE — монолит.
Решает ли разделение на сервисы конкретную проблему? Не «потенциально может помочь в будущем», а решает проблему, которая существует сейчас. Время деплоя стало слишком большим? Одна часть системы требует принципиально другого стека? Команды блокируют друг друга при релизах? Если да — выделяйте. Если нет — не выделяйте.
Можно ли то же самое решить модульным монолитом? В 90% случаев ответ — да. Чёткие границы модулей, определённые интерфейсы, внутренние контракты — всё это можно сделать в рамках одного приложения. А если потребуется выделить модуль — у вас уже есть чёткие границы.
Если на большинство этих вопросов вы ответили «у нас пока немного» — выбирайте монолит. Вы всегда сможете выделить сервисы позже, когда в этом появится реальная потребность. Обратный путь (собрать микросервисы обратно в монолит) значительно сложнее и дороже.
Заключение
Микросервисы — это инструмент. Хороший инструмент, который решает реальные проблемы масштабирования организаций и систем. Но, как любой инструмент, он имеет свою область применения. Забивать гвозди микроскопом можно, но зачем?
Лучшая архитектура — не самая модная и не самая сложная. Лучшая архитектура — та, которая решает задачи бизнеса при минимальной сложности. Для большинства компаний это монолит или модульный монолит с парой выделенных сервисов. И в этом нет ничего стыдного — это зрелое инженерное решение.
Перед следующим архитектурным решением откройте не статью про Netflix, а таблицу с цифрами. Посчитайте пользователей, трафик, размер команды и бюджет. Пусть архитектуру определяют данные, а не мода.
Теги: