Microservices vs монолит: честный взгляд на 2026 год

Дебаты о microservices vs монолите идут уже десять лет. Их давно следовало закрыть, но инженерные блоги Netflix, Amazon и Uber продолжают их воскрешать — а эти компании не являются вашей компанией. Их архитектурные решения принимались для решения проблем, которых у вас ещё нет, в масштабах, которых вы, возможно, никогда не достигнете, с инженерными командами в двадцать раз больше вашей. Брать архитектурные советы у Netflix, когда у вас 4 бэкенд-инженера, — всё равно что брать рекомендации по управлению трафиком в Токио при планировании дороги в деревне на 3000 человек.

Дальше — что реально работает на разных стадиях.

Как дебаты были искажены

Нарратив шёл примерно так: Amazon декомпозировал монолит на сервисы и вышел на масштаб глобальной торговли. Netflix перешёл на microservices и достиг 99,99% uptime. Следовательно, microservices = хорошо, монолит = легаси.

Что эти посты упустили: у Amazon были сотни инженеров и годы инвестиций в инфраструктуру платформы до того, как этот переход окупился. Netflix создал целую внутреннюю платформу (и позже открыл значительную её часть) для управления обнаружением сервисов, circuit breaking, распределённой трассировкой и откатом. Архитектура, которую они описывают, — это microservices плюс сложная платформа, которая делает microservices управляемыми.

Когда стартап из 10 человек читает эти посты и решает собрать свой MVP как 15 независимых сервисов с кластером Kubernetes — это не следование лучшим практикам. Это косплей архитектуры, которую они не смогут поддержать.

Что microservices на самом деле решают

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

Независимый деплоймент. Когда разные части системы нужно выпускать по разным расписаниям — потому что ими владеют разные команды, или потому что у разных сервисов разные профили риска, — microservices позволяют деплоить изменение одного сервиса, не трогая всё остальное.

Автономия команд. Закон Конвея реален: архитектура системы воспроизведёт структуру коммуникаций команды. Крупные организации с отдельными продуктовыми командами выигрывают от границ сервисов, совпадающих с организационными. Каждая команда владеет сервисом, деплоит независимо и не заблокирована циклом релиза другой команды.

Изоляция сбоев. Если сервис рекомендаций падает, сервис оформления заказов всё равно должен работать. Microservices с правильными bulkhead-паттернами предотвращают каскадирование сбоев одной области через всю систему.

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

Всё это реальные преимущества, но они имеют смысл только тогда, когда у вас есть проблемы, которые они решают.

Что microservices на самом деле стоят

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

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

Накладные расходы на наблюдаемость. Баг в монолите имеет стектрейс. Баг в четырёх сервисах имеет распределённый трейс, который требует correlation ID, структурированного логирования во всех сервисах и системы трассировки (Jaeger, Zipkin или аналога) для восстановления картины. Это решаемо, но требует инструментария и дисциплины для настройки.

Service discovery и сетевое взаимодействие. В монолите функция A, вызывающая функцию B, — это локальный вызов метода. В microservices сервис A, вызывающий сервис B, требует сетевого транспорта, service discovery, балансировки нагрузки, TLS между сервисами и обычно sidecar или service mesh при серьёзном подходе.

Распределённые транзакции. Если нужно атомарно обновить два сервиса — например, провести платёж и обновить статус заказа — больше нельзя использовать транзакцию базы данных. Нужны saga-паттерны, двухфазный commit или паттерны eventual consistency. Это по-настоящему сложно реализовать правильно.

Сложность деплоймента. Вместо деплоя одного артефакта вы управляете 10 или 20 независимыми пайплайнами деплоя, реестрами контейнеров, стратегиями выкатки и матрицами совместимости версий.

Честный аргумент в пользу монолита

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

• Одна транзакция базы данных проще и надёжнее, чем распределённая saga.
• Один пайплайн деплоя быстрее поддерживать, чем 12 отдельных.
• Стектрейс быстрее отлаживать, чем распределённый трейс.
• Нанять инженеров, которые понимают одну кодовую базу, проще, чем объяснять 15 границ сервисов новому сотруднику.
• Локальная разработка — это git clone && npm install, а не поднятие кластера контейнеров.

Для большинства продуктов до определённого масштаба монолит — не узкое место. Узкое место — скорость разработки, скорость отладки и продуктивность команды, и по всем трём монолит конкурентоспособен.

Модульный монолит: срединный путь, на котором должны быть большинство команд

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

Это даёт:

• Простоту деплоймента монолита (один артефакт, одна база данных, один пайплайн)
• Скорость разработки (нет сетевых накладных расходов, пока не нужна распределённая трассировка)
• Соблюдение разделения обязанностей внутри кодовой базы
• Чёткий путь извлечения, когда оно реально понадобится

Большинство команд, утверждающих, что им нужны microservices, на самом деле нуждаются в модульном монолите с более строгой внутренней структурой. У них спагетти-монолит, и они пытаются решить это границами сервисов, тогда как настоящая проблема — слабая внутренняя дисциплина.

Антипаттерн миграции

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

1. Команда решает, что монолит — источник всех проблем.
2. Начинают поочерёдно извлекать сервисы.
3. Каждое извлечение добавляет 2–3 недели накладных расходов (новый репозиторий, новый пайплайн, service discovery, межсервисная auth, интеграционные тесты).
4. Исходный монолит всё ещё существует и в него всё ещё вносятся изменения.
5. Через 12 месяцев у команды 6 сервисов, частично извлечённый монолит и значительно больше сложности, чем в начале.

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

Фреймворк для принятия решения

Фактор	В пользу монолита	В пользу microservices
Размер команды	< 15 инженеров	15+ инженеров, несколько команд
Частота деплоя	Одинаковый ритм для всей системы	Разный ритм для разных доменов
Структура организации	Одна команда	Несколько продуктовых команд
Требования к изоляции сбоев	Не критично	Нужна строгая изоляция
Дифференциал масштабирования	Равномерная нагрузка	Очень разная нагрузка на компоненты
Операционная зрелость	Ограниченные возможности DevOps	Зрелая платформенная команда

Задайте эти вопросы перед принятием решения:

1. Разным частям системы нужен независимый деплой уже сегодня? Если нет — границы сервисов не нужны сегодня.
2. Есть ли отдельные команды, заблокированные общим деплоем? Если нет — автономия команд не ваша проблема.
3. Нужно ли одному компоненту масштабироваться в 100 раз интенсивнее другого? Если нет — независимое масштабирование не нужно.
4. Есть ли инфраструктура наблюдаемости и платформы для надёжной эксплуатации нескольких сервисов? Если нет — вы потеряете недели на отладку проблем распределённых систем до того, как доставите хоть одну фичу.

Если на все четыре вопроса ответ «нет» — стройте монолит. Структурируйте его хорошо внутри. Выделяйте сервисы, когда для этого появится конкретная причина.

Выбираете архитектуру для нового продукта или пытаетесь разобраться, действительно ли текущий монолит — проблема? Напишите нам на hello@cimpleo.com. Дадим честный разбор.