Микросервисы vs монолит: история, сравнение и прагматичный выбор архитектуры

Микросервисы vs монолит — один из самых жарких архитектурных споров последнего десятилетия. В 2015–2018 годах микросервисы считались «единственно правильной» архитектурой для серьёзных проектов, и монолит подавался как устаревший подход. К 2026 году маятник качнулся обратно: индустрия научилась честно сравнивать эти подходы и понимать, в каких случаях каждый из них работает.

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

Что такое монолитная архитектура

Монолит — приложение, развёртываемое как единое целое. Весь код находится в одной кодовой базе, компилируется в один артефакт (jar, бинарник, docker image), запускается как один процесс или несколько идентичных копий за балансировщиком.

Это не значит, что монолит плохо структурирован внутри. Хороший монолит разделён на модули, каждый с чёткими границами и интерфейсами. Модулей могут быть десятки. Но все они работают в одном процессе и развёртываются вместе.

Классические примеры монолитных приложений: WordPress, GitLab (изначально), Stack Overflow, Basecamp. Многие из них обслуживают миллионы пользователей, оставаясь монолитами.

Что такое микросервисная архитектура

Микросервисы — архитектура, в которой приложение разделено на множество мелких сервисов, каждый из которых:

• Развёртывается независимо
• Имеет собственную базу данных
• Общается с другими сервисами через API (HTTP, gRPC, message queues)
• Разрабатывается отдельной командой
• Имеет свой жизненный цикл (релизы, версионирование)

Подход популяризован Netflix, Amazon, Spotify в 2010-х. Идея: разбивая систему на маленькие куски, можно ускорить разработку, упростить масштабирование, изолировать сбои.

На практике границы микросервисов часто размыты. «Микро» — не про размер, а про возможность независимого развёртывания и владения.

Сравнение по ключевым параметрам

Преимущества монолита

• Простота разработки. Один репозиторий, один процесс, одна БД. Новый разработчик стартует за день.
• Простое локальное тестирование. Запустил приложение — работает всё. В микросервисах требуется поднять много зависимых сервисов или их моки.
• Транзакции из коробки. ACID-гарантии БД работают для всех операций.
• Прямые вызовы функций. Без сетевой латентности, без сложной сериализации.
• Меньше инфраструктуры. Одно приложение, одна БД, простой деплой. Не нужны service mesh, API gateway, distributed tracing.
• Дешевле в эксплуатации. Меньше серверов, меньше DevOps, меньше операционных расходов.
• Простой рефакторинг. Переименование функции — одна операция. В микросервисах изменение API требует координации между командами.
• Лучшая performance в простых случаях. Без overhead сетевых вызовов многие операции работают быстрее.

Недостатки монолита

• Сложность роста с командой. 5 разработчиков работают в одном коде легко, 50 — с конфликтами и блокировками.
• Долгий build и deploy. Большой монолит может собираться 30 минут, развёртываться часами.
• Невозможность независимого масштабирования. Если один модуль грузит систему, масштабируется всё приложение.
• Технологическая блокировка. Сложно постепенно мигрировать на другой язык или фреймворк.
• Один сбой — падение всего. Утечка памяти в одном модуле может уронить всё приложение.
• «Спагетти»-зависимости со временем. Без жёсткой дисциплины модули начинают взаимозависеть, и рефакторинг становится болезненным.

Преимущества микросервисов

• Независимое развёртывание. Каждая команда деплоит свой сервис когда хочет, не дожидаясь других.
• Независимое масштабирование. Сервисы с разной нагрузкой масштабируются отдельно.
• Технологическая гибкость. Каждый сервис может использовать свой язык, фреймворк, БД.
• Изоляция сбоев. Падение одного сервиса не валит всю систему (при правильной обработке ошибок).
• Параллельная работа команд. Десятки команд работают независимо, без конфликтов кода.
• Чёткие границы ответственности. Каждая команда владеет своими сервисами end-to-end.
• Возможность постепенной миграции. Старые сервисы можно переписывать постепенно, не трогая остальные.

Недостатки микросервисов

• Огромная инфраструктурная сложность. Service discovery, load balancing, API gateway, distributed tracing, observability — всё это нужно построить и поддерживать.
• Distributed системные проблемы. Сетевые задержки, частичные сбои, eventual consistency — классические проблемы распределённых систем.
• Сложность отладки. Ошибка распространяется через несколько сервисов — нужны специализированные инструменты для трассировки.
• Distributed транзакции. Двухфазный коммит сложен и медленен; sagas требуют сложной логики компенсации.
• Высокая стоимость инфраструктуры. Каждый сервис нужно где-то хостить, каждой БД нужно резервирование, мониторинг.
• Тяжёлый локальный development. Запустить всю систему на ноутбуке часто невозможно.
• Координация изменений между сервисами. Изменение контракта API требует согласования между командами.
• Версионирование API. Каждый сервис должен поддерживать старые версии API для backward compatibility.
• Сложный monitoring и debugging. Без хорошей observability приложение становится чёрным ящиком.

История споров: маятник качается

История архитектурных предпочтений индустрии — иллюстрация того, как «единственно правильный путь» меняется десятилетиями.

Известные отказы от микросервисов

Amazon Prime Video

В 2023 году команда Prime Video опубликовала статью о том, как переход от микросервисов обратно к монолиту снизил стоимость инфраструктуры на 90% для одного из сервисов мониторинга качества видео. Решение возникло из конкретных проблем масштабирования: data flow через множество Lambda-функций и Step Functions стало запредельно дорогим.

Segment

Компания Segment вернулась от микросервисной архитектуры к монолитной в 2018 году. Причина: операционная сложность распределённой системы стала больше выгод от разделения. Подробно описано в их inženernom blog’е.

Istio

Service mesh Istio, классический инструмент для микросервисной инфраструктуры, в 2020 году объединил свой control plane (изначально 5+ микросервисов) обратно в один сервис Istiod. Команда обнаружила, что разделение создавало больше операционных проблем, чем решало.

GitLab

GitLab известен как «monolith on Rails» с миллионами пользователей. Команда сознательно избегает микросервисной архитектуры, считая монолит правильным выбором для их кейса.

Эти кейсы не означают, что микросервисы плохи в принципе. Они показывают, что подход не универсален и требует осознанного выбора под задачу.

Modular Monolith: компромисс

Концепция modular monolith стала популярной в 2020-х. Идея: иметь все преимущества монолита (простота развёртывания, отладки) при чёткой модульной структуре, готовой к выделению в микросервисы при необходимости.

Принципы modular monolith:

• Код разделён на чётко определённые модули
• Каждый модуль имеет публичный API (внутренний, в рамках процесса)
• Модули не обращаются к данным друг друга напрямую
• Архитектура «как если бы» каждый модуль был отдельным сервисом
• Возможность мониторить взаимодействия между модулями
• Возможность вынести модуль в отдельный сервис без больших переделок

Такой подход даёт «лучшее из двух миров»: операционная простота монолита и подготовленность к разделению, если оно станет нужным.

Когда выбирать монолит

• Старт проекта или стартап. Сначала найти product-market fit, потом думать об архитектуре.
• Небольшая команда. До 10–20 разработчиков обычно эффективнее работают с монолитом.
• Простой домен. Если бизнес-логика не сложная, не нужно усложнять архитектуру.
• Strict consistency требования. ACID-транзакции проще в монолите.
• Ограниченный бюджет. Монолит дешевле в эксплуатации.
• Отсутствие DevOps-экспертизы. Микросервисы требуют серьёзной операционной зрелости.
• Internal tools. Внутренние корпоративные системы редко нуждаются в микросервисной архитектуре.

Когда выбирать микросервисы

• Большая команда. 50+ разработчиков с несколькими командами.
• Разные части системы с очень разной нагрузкой. Сервис обработки изображений и сервис уведомлений имеют разные паттерны масштабирования.
• Требования к независимой разработке. Команды должны деплоить независимо друг от друга.
• Технологическая гетерогенность. Разные части системы лучше реализуются на разных стеках.
• Зрелая DevOps-культура. Команда умеет с микросервисами работать.
• Сложный домен с чёткими границами. Domain-Driven Design выявляет естественные bounded contexts.
• Регуляторные требования к изоляции. Например, отделение PII-данных от остальных.

Эволюционный подход

Самая практичная стратегия — не выбирать архитектуру навсегда, а эволюционировать:

1. Стартап-стадия. Простой монолит, фокус на product-market fit.
2. Рост. Modular monolith с чёткими границами модулей.
3. Когда модуль становится узким местом. Выделяется в отдельный сервис.
4. Зрелая стадия. Естественная микросервисная архитектура там, где она оправдана.

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

Типичные ошибки

• Микросервисы с первого дня. До product-market fit вы ещё не знаете, какие границы нужны. Извлекаемые сервисы окажутся не там, где должны быть.
• «Микро»-микросервисы. Сервис из 50 строк кода — слишком мелкое разделение. Operational overhead превышает выгоды.
• Распределённый монолит. Микросервисы, которые жёстко связаны и должны деплоиться вместе — худшее из обоих миров.
• Общая БД для микросервисов. Если несколько сервисов работают с одной БД, это не микросервисы.
• Игнорирование observability. Микросервисы без distributed tracing и centralized logging — debugging-ад.
• Отсутствие API contract management. Когда нет версионирования API, любое изменение ломает зависимые сервисы.
• Синхронные коммуникации везде. Цепочки HTTP-вызовов между микросервисами создают распределённую хрупкость. Где возможно — async через message queues.
• Игнорирование границ доменов. Разделение по техническим слоям (DB-сервис, API-сервис) вместо бизнес-доменов — антипаттерн.
• Преждевременная оптимизация в монолите. Когда модули искусственно сделаны «готовыми к выделению» в момент, когда выделение не нужно.
• Копирование Netflix. Netflix построил микросервисы для решения своих проблем масштаба. У вас, скорее всего, другие проблемы.

Часто задаваемые вопросы

Сколько микросервисов — это микросервисная архитектура?

Не существует магического числа. Архитектура — микросервисная, если её сервисы независимо развёртываются, имеют свои БД, разрабатываются отдельными командами. Это может быть 5 сервисов или 500.

Можно ли начать с микросервисов и перейти к монолиту?

Технически да, но болезненно. Извлечение общей логики, объединение БД, перенос инфраструктуры — серьёзный проект. Обратный путь (от монолита к микросервисам) обычно проще, если монолит был модульным.

Что лучше для AI/ML-приложений?

Часто сочетание: основное приложение как монолит, отдельные ML-сервисы (inference, training pipelines) как микросервисы из-за разных требований к ресурсам и масштабированию.

Влияет ли выбор на стоимость найма?

Да. Микросервисы требуют DevOps-инженеров, специалистов по distributed systems, observability. Это дорогие специалисты. Монолит можно поддерживать меньшей командой.

Подходит ли serverless для микросервисов?

Подходит, и часто оптимально. Serverless-функции (Lambda, Cloud Run) — это микросервисы с минимальными операционными расходами. Многие современные системы строятся на serverless как разновидности микросервисной архитектуры.

Что выбрать для проекта на 5–10 разработчиков?

Почти всегда — монолит или modular monolith. Микросервисы для команды этого размера обычно создают больше проблем, чем решают.

Заключение

Спор «микросервисы vs монолит» — ложная дихотомия. Это не вопрос «что лучше», а вопрос «что подходит под конкретный контекст». Маятник индустрии качнулся обратно к более прагматичному подходу: монолит — нормальная архитектура для большинства проектов, микросервисы — специализированный инструмент для конкретных задач масштаба и организационной структуры. Команды, которые понимают это, экономят годы работы и десятки тысяч долларов. Команды, которые слепо следуют моде на «правильную архитектуру», часто год спустя возвращаются к более простым решениям.