Переход на микросервисы часто оборачивается ростом расходов и усложнением релизов — вместо ускорения получаем обратный эффект.
По данным исследования CNCF за 2025 год среди организаций, перешедших на микросервисы, 42% уже вернули часть сервисов обратно в более крупные развёртываемые блоки. Это не единичные случаи — это системная коррекция, которая набирает обороты.
В 2026 году выбор между монолитом и микросервисами перестал быть идеологическим. Данные, стоимость и реальный опыт команд — вот что определяет решение.
Расскажем, что на самом деле стоит за каждой архитектурой, во сколько она обходится в деньгах и времени, и как избежать распространённых ошибок при выборе.
ВАМ ПРИШЛО ПРИГЛАШЕНИЕ 💌
Приходите к нам в соцсети поделиться своим мнением и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
Монолит, микросервисы и что между ними
В спорах об архитектуре часто смешивают четыре разных понятия. Прежде чем двигаться дальше разберёмся с ними.
Монолит — это единица развёртывания. Всё приложение собирается в один артефакт, тестируется и выкатывается целиком. Компоненты работают в одном процессе, общаются через вызовы функций, используют общую базу данных. Код может быть идеально структурированным или полным хаосом — это уже вопрос дисциплины команды.
Микросервисы — это набор независимо развёртываемых сервисов. Каждый сервис отвечает за свою предметную область, владеет собственными данными, общается с другими по сети. Сервисы можно обновлять, масштабировать и переписывать на разных технологиях независимо друг от друга (в теории). У микросервисов есть свои плюсы и минусы, которые стоит изучить заранее.
Модульный монолит — третий вариант, который всё более востребован в 2026 году. Код разложен по модулям с чёткими границами и публичными интерфейсами. Модули общаются через эти интерфейсы, а не напрямую друг с другом. База данных одна, развёртывание тоже единое. Но внутри — строгая дисциплина, как в микросервисах.
Распределённый монолит — то, во что превращаются микросервисы, когда их неправильно спроектировали. Сервисов много, но они жёстко связаны: релиз одного требует релиза других, все ходят в одну базу, падение второстепенного сервиса роняет всю систему. Это худший из миров: платите за распределённость, а выгоды не получаете.
Первые три варианта — осознанный выбор. Четвёртый — ошибка, которую совершают чаще, чем можно ожидать.
Модульный монолит как третий вариант
Большинство обсуждений видов архитектуры ПО до сих пор строятся по схеме «монолит против микросервисов». Но эта дихотомия устарела. Модульный монолит предлагает прагматичный компромисс.
Устройство простое: код разделён на модули по предметным областям — bounded contexts, если говорить языком DDD. Каждый модуль имеет чёткий публичный интерфейс. Обращения между модулями идут только через эти интерфейсы. Внутренняя реализация модуля скрыта. База данных общая, но доступ к ней тоже ограничен — каждый модуль работает со своей схемой или набором таблиц.
Развёртывание одно: собрали весь проект, прогнали тесты, выкатили.
Подход даёт примерно 80% преимуществ микросервисной архитектуры при пятой части операционных издержек. Потому что не нужны сервисная сетка, распределённая трассировка, сложная оркестрация и выделенная платформенная команда. Модули общаются через вызовы методов, а не по сети — быстрее, дешевле, проще отлаживать.
Правила, по которым проводят границы модулей:
- Граница проходит по предметной области. Модули называют по бизнес-сущностям: «заказы», «пользователи», «платежи». Для определения границ не используют технические слои вроде «контроллеров» и «репозиториев».
- Модуль владеет своими данными. Другие модули получают доступ через публичный API, а не через прямое чтение таблиц.
- Между модулями минимум зависимостей. Если для работы модуля А нужен модуль Б — это нормально. Если А тянет Б, В, Г и Д — граница проведена неправильно.
- Модуль теоретически можно вынести в отдельный сервис. Если это потребует полной переработки кода — значит, модуль не изолирован.
Модульный монолит — полноценная архитектура. Многие компании годами работают на таком подходе и не планируют переходить на микросервисы.
Сколько стоит каждая архитектура
Переходим к деньгам, потому что абстрактные рассуждения о «гибкости» и «масштабируемости» заканчиваются там, где приходит счёт за инфраструктуру.
Данные на 2026 год. Ваш конкретный случай может отличаться в зависимости от провайдера, региона и нагрузки.
| Статья расходов | Модульный монолит | Микросервисы |
| Инфраструктура среднего продукта | $1 100–2 300 в месяц | $4 200–8 500 в месяц |
| Инфраструктура крупного продукта | около $15 000 в месяц | $40 000–65 000 в месяц |
| Платформенные инженеры | не требуются отдельно | 1–3 человека, $140 000–360 000 в год |
| Итоговая разница | базовая линия | дороже в 3,75–6 раз |
Цифры наглядно демонстрируют, что инфраструктура микросервисов обходится в 3–6 раз дороже, чем эквивалентный по функциональности монолит. Причём это только инфраструктура — без учёта зарплат платформенных инженеров, которых для микросервисов нужно нанимать отдельно.
Показательный кейс — Amazon Prime Video. В 2023 году команда, отвечающая за мониторинг качества видео, переписала свой пайплайн из распределённой схемы в один процесс. Инфраструктурные расходы сократились примерно на 90%.
Важная оговорка: это кейс конкретного сервиса, а не всей платформы Prime Video. Но он наглядно показывает: распределённая архитектура — не всегда правильный выбор даже для компаний с почти безлимитными ресурсами.
Большая скидка — 16% на все курсы Практикума
Если вы читаете эту статью, тогда вы точно разбираетесь в технологиях. Стать лучше и зарабатывать больше можно после курсов Практикума — по программированию, анализу данных и искусственному интеллекту.
До 17 сентября на все курсы действует скидка 16%, она применится автоматически при оплате. Потом цены станут выше, поэтому не откладывайте!
Ещё пишете первый бэкенд — берите «Python-разработчика»; дошли до разговоров про границы сервисов — «Архитектуру ПО»; уже дробитесь и утонули в эксплуатации — «Микросервисную архитектуру» или «Эксплуатацию и разработку в Kubernetes».
Что меняется в разработке
Архитектура проверяется в ежедневной работе — схемами её не заменишь. Разберём, что меняется для разработчика.
Скорость выкатки
В монолите релиз — это общая очередь. Все изменения собираются вместе, проходят интеграционное тестирование и выкатываются одной версией. Если что-то сломалось — откатывается всё. Когда команда маленькая это работает. Когда разработчиков больше десяти, а фич много очередь становится узким местом.
В микросервисах каждый сервис имеет свой пайплайн и выкатывается независимо. Исправили баг в сервисе заказов — задеплоили только его. Остальные продолжают работать. Это главное преимущество, ради которого и затевают дробление.
Но, по данным DORA, около 90% команд с микросервисами всё равно выкатывают сервисы пакетами. То есть берут на себя всю сложность распределённой системы, но не получают главного бонуса — независимых релизов.
Отладка
Монолит: стек вызовов в одном процессе. Упала ошибка — видно всю цепочку. Можно запустить отладчик, поставить брейкпоинт, пройти шаг за шагом.
Микросервисы: запрос проходит через пять сервисов. Ошибка может возникнуть в любом из них. Чтобы понять, где именно, нужен сквозной идентификатор запроса и распределённая трассировка. Без этого определить источник сбоя почти невозможно.
Исследования показывают, что отладка в распределённых системах занимает примерно на 35% больше времени. И это при условии, что у вас настроена наблюдаемость. Если нет — время увеличивается кратно.
Тестирование
Интеграционные тесты монолита занимают секунды. Всё крутится в одном процессе, база одна, зависимости подняты — поехали. Стабильность прогона — 70–90% в зависимости от качества тестов.
В микросервисной схеме интеграционное тестирование — это поднятие десятка сервисов со своими базами, очередями, кешами. Прогон длится несколько часов. Тесты падают из-за таймаутов, проблем с сетью, несинхронизированных версий сервисов. Стабильность — 40–60% в лучшем случае.
Многие команды просто отказываются от полноценных интеграционных тестов в микросервисной среде, полагаясь на тесты в каждом сервисе по отдельности. И пропускают ошибки интеграции, которые в монолите были бы пойманы на ранней стадии.
Локальная разработка
В монолите: склонировал репозиторий, запустил одну команду — приложение работает. Можно менять код, видеть изменения мгновенно.
В микросервисах: чтобы разрабатывать один сервис, нужно поднять его зависимости. А это может быть пять, десять или двадцать соседних сервисов. Вариантов два: либо поднимать всё локально (и ждать, пока запустится), либо работать против общего тестового контура (и делить его с коллегами). Ни тот, ни другой вариант не делает разработку быстрее и приятнее.
Что меняется в эксплуатации
Эксплуатация распределённой системы создаёт накладные расходы, о которых иногда забывают на этапе проектирования.
Задержки. Внутрипроцессный вызов в монолите укладывается в наносекунды или единицы микросекунд. Сетевой вызов между сервисами добавляет 10–50 миллисекунд. На цепочке из пяти обращений это уже 50–250 мс задержки до того, как сервис вообще начал работать. Для пользователя это ощутимо.
Отказоустойчивость. Если что-то упало в монолите — это значит, упало всё. Минус: нет изоляции отказов. Плюс: понятно, что чинить. В микросервисах отказ одного сервиса может вызвать каскадный сбой. Сервис А вызывает Б, Б вызывает В, В тормозит — и вся цепочка встаёт. Без таймаутов, ретраев с экспоненциальной задержкой и предохранителей (circuit breakers) система будет падать регулярно и непредсказуемо.
Наблюдаемость. В монолите достаточно логов и метрик одного приложения. В микросервисах логи и метрики со всех сервисов нужно собирать в одном месте, коррелировать по сквозному идентификатору, строить дашборды для каждого сервиса и для системы в целом. Объём данных растёт пропорционально числу сервисов — и счёт за наблюдаемость тоже.
Оркестрация. Контейнеры нужно где-то запускать, управлять их жизненным циклом, обеспечивать сетевую связанность, обновлять без даунтайма. Это требует оркестратора — обычно Kubernetes. А Kubernetes — это отдельная сложность и отдельные расходы.
Список обязательных элементов обвязки для микросервисов:
- оркестратор контейнеров (Kubernetes или аналог);
- сервисная сетка или хотя бы API-шлюз для маршрутизации;
- распределённая трассировка для отслеживания запросов;
- централизованный сбор логов и метрик;
- система оповещений и дежурства.
Без перечисленного микросервисы не эксплуатируются. При этом, эксплуатация становится полноценной профессией, требующей выделенных людей.
Данные и транзакции
Самая недооценённая часть выбора архитектуры. И самая болезненная на практике.
В монолите операция над несколькими сущностями укладывается в одну транзакцию базы данных. Начали — обновили таблицу заказов, списали деньги, изменили статус доставки — закоммитили. Либо всё сделано, либо ничего. ACID гарантирует согласованность.
При разделении на сервисы со своими хранилищами эта транзакция распадается. Каждый сервис работает со своей базой. Чтобы выполнить операцию, нужно обновить данные в нескольких сервисах. Транзакция становится распределённой, а распределённых транзакций с ACID не бывает.
Согласованность становится отложенной.
Чем это компенсируют:
- Сага — паттерн, при котором каждая операция в сервисе сопровождается компенсирующим действием на случай отката. Например, оформили заказ — зарезервировали товар. Не смогли списать деньги — отменили заказ и вернули товар. Сага может быть хореографической (сервисы общаются напрямую) или оркестрируемой (центральный координатор управляет шагами).
- Идемпотентные обработчики — один и тот же запрос можно обработать несколько раз без побочных эффектов. Если сообщение потерялось и переотправилось — ничего страшного не произойдёт.
- Исходящий журнал событий — сервис публикует события о своих изменениях, другие сервисы подписываются и обновляют свои данные асинхронно. Это даёт согласованность в конечном счёте.
- Общая база данных на несколько сервисов — признак распределённого монолита. Это одна из самых частых ошибок при переходе на микросервисы. Вы получаете всю сложность распределённой системы, но теряете главное преимущество — изоляцию данных. Так делать не стоит.
Команда и организация
Закон Конвея гласит: архитектура системы повторяет структуру коммуникаций в организации. Если команды общаются через формальные интерфейсы — получаются микросервисы. Если все сидят в одной комнате и говорят напрямую — будет монолит.
Для команд численностью до пятидесяти инженеров модульный монолит предпочтительнее. Такая команда ещё помещается в одно физическое пространство, коммуникации остаются управляемыми, координация релизов не требует сложных процессов. Сложность микросервисов в этих условиях не окупается.
Микросервисы начинают приносить пользу, когда команды распределены географически и им нужна автономия релизов. Или когда разные группы разработчиков не хотят ждать друг друга и готовы нести полную ответственность за свои сервисы.
Но для этого нужна ответственность:
- выделенная платформенная команда, которая строит и поддерживает инфраструктуру;
- дежурства — кто-то должен отвечать за сервисы 24/7;
- владелец у каждого сервиса — человек или команда, которые принимают решения и несут ответственность.
Без этого микросервисы превращаются в распределённый монолит — все сложности, ни одной выгоды.
| Размер команды | Рекомендуемый вариант | Что должно быть в наличии |
| До 10 человек | Модульный монолит | Хорошая дисциплина модульности |
| 10–50 человек | Модульный монолит с возможностью выделения сервисов | Чёткие границы модулей, автоматизация сборки и тестирования |
| 50+ человек, одна локация | Модульный монолит или ограниченное число микросервисов | Платформенная команда, наблюдаемость |
| 50+ человек, распределённые команды | Микросервисы | Платформенная команда, дежурства, владельцы сервисов, зрелый CI/CD |
Признаки, что монолит пора дробить
Есть измеримые сигналы, которые на это указывают:
- Сборка и прогон тестов занимают больше часа. Цикл обратной связи ломается: разработчик не может быстро проверить изменения, теряет контекст, переключается на другие задачи. Измеряйте время от пуша до зелёного билда.
- Релизы блокируют друг друга. Две команды хотят выкатить изменения, но не могут — потому что в очереди на релиз уже стоит третья. Или потому что изменения конфликтуют, и их нужно объединять. Релизы ждут днями и неделями.
- Отдельная часть системы требует в разы больше ресурсов, чем остальные. Один модуль генерирует 80% нагрузки, но масштабировать приходится всё приложение целиком. Платите за ресурсы, которые не используете.
- Разным частям нужны разные требования к доступности. Платёжный модуль должен работать с пятью девятками, а модуль аналитики — с двумя. В монолите они получают одинаковый уровень доступности.
- Команда выросла настолько, что владение кодом размылось. Никто не знает, за что отвечает каждая часть. Изменения ломают неожиданные участки, потому что связи в коде никто не отслеживает.
- Отдельному куску нужен другой стек по объективной причине. Например, вам нужен Python для машинного обучения, а основное приложение на Java. Или нужна особая база данных, которая не сочетается с общей.
Хотя бы два-три сигнала из шести — повод задуматься о дроблении.
Признаки, что микросервисы были ошибкой
Обратная диагностика для тех, кто уже раздробил и теперь сомневается:
- Релиз одного сервиса требует одновременного релиза соседних. Если вы не можете обновить сервис А без обновления Б — значит, границы проведены неправильно. У вас не микросервисы, а распределённый монолит.
- Сервисы ходят в одну базу. Общая база — антипаттерн для микросервисов. Каждый сервис должен владеть своими данными. Если это не так — вы взяли сложность распределённости, но не получили изоляции.
- Падение второстепенного сервиса роняет основной сценарий. Пользователь не может оформить заказ, потому что упал сервис рекомендаций? Это не отказоустойчивость, это хрупкость.
- Счёт за инфраструктуру растёт быстрее нагрузки. Вы добавили два сервиса — счёт вырос на 40%. Нагрузка выросла на 10%. Это значит, что вы платите за сложность, а не за функциональность.
- Половина спринта уходит на обвязку вместо продуктовых задач. Настройка CI/CD, обновление сервисной сетки, перенос логов, дебаг распределённых ошибок — вместо фич для пользователей.
- Воспроизвести баг локально невозможно. Ошибка возникает только в среде с полным набором сервисов и определённой нагрузкой. Вы гадаете, что пошло не так, потому что локально всё работает.
Что делают в такой ситуации — обратную сборку. Несколько сервисов объединяют в один развёртываемый блок, сохраняя модульные границы внутри. Получается модульный монолит. Команды, которые это делают, называют процесс «консолидацией».
Порядок консолидации: определить сервисы с наибольшей связностью, объединить их код в один репозиторий, настроить общую сборку, перенести интеграционные тесты, выключить старые сервисы. Постепенно, по одному сервису за раз.
Матрица выбора
Теперь конкретные сценарии и наши рекомендации к ним:
| Сценарий | Рекомендация | Обоснование |
| Новый продукт с непроверенной гипотезой | Модульный монолит | Неизвестно, что будет востребовано. Менять архитектуру дешевле, чем микросервисы |
| Внутренний сервис для одной компании | Модульный монолит | Нет внешних пользователей, нет потребности в независимом масштабировании |
| Маркетплейс с сезонными пиками нагрузки | Модульный монолит + вынос пиковых модулей | Основная логика — в монолите, пиковый модуль можно вынести и масштабировать отдельно |
| Продукт с командами в разных часовых поясах | Микросервисы | Команды не могут координировать релизы в реальном времени, нужна автономия |
| Система с жёсткими требованиями к отдельному контуру по безопасности | Микросервисы | Платёжный модуль можно изолировать на уровне сети и доступа к данным |
| Обработка тяжёлых потоков данных | Модульный монолит или ограниченное число сервисов | Сетевые накладные расходы при больших объёмах данных бьют по производительности |
| Легаси-система на поддержке | Оставить как есть, если работает | Переписывать работающую систему ради архитектурной чистоты — дорого и рискованно |
Пять вопросов, на которые команда должна ответить до решения:
- Сколько у нас инженеров и как они организованы?
- Как часто мы выкатываем релизы и что нас в этом процессе тормозит?
- Какая часть системы требует независимого масштабирования?
- Готовы ли мы нанять платформенных инженеров и организовать дежурства?
- Что будет, если мы ошибёмся с выбором — и сколько будет стоить переделка?
Как переходить постепенно
Для тех, кто решил дробиться. Порядок действий.
Паттерн душителя
Новая функциональность пишется снаружи монолита, в виде отдельного сервиса. Запросы постепенно перенаправляются на новый сервис через роутер или API-шлюз. Старый код выключается по частям. Монолит не переписывается целиком — он постепенно замещается новыми сервисами.
Выбор первого сервиса
Берут кусок с ясной границей, слабой связностью и собственными данными. Удачные кандидаты: система аутентификации, модуль нотификаций, сервис генерации отчётов. Неудачные: кусок, который тянет за собой половину базы данных, или модуль, от которого зависят все остальные.
Ошибки перехода
Что может пойти не так:
- Дробление по техническим слоям вместо предметных областей. Отдельный сервис для контроллеров, отдельный для репозиториев — худшее из возможных решений.
- Вынос сервиса без выноса его данных. Сервис отдельно, таблицы остались в общей базе — получили распределённый монолит.
- Отсутствие сквозной трассировки с первого дня. Без неё вы не поймёте, что происходит с запросами.
- Миграция всей системы разом. Попытка переписать всё и сразу — гарантированный способ получить долгострой и потерять команду.
- Перенос сроков продуктовых задач ради архитектурной переделки. Бизнес не простит, если вы полгода ничего не выкатываете, потому что «переходим на микросервисы».
Чек-лист перед выделением первого сервиса
Финальная проверка перед тем, как начать дробление:
- Границы предметной области описаны и согласованы с командой.
- У сервиса есть владелец — человек или команда, которая принимает решения.
- Данные выделяются вместе с кодом — у сервиса своё хранилище.
- Контракт между сервисами зафиксирован и версионируется — изменения не ломают потребителей.
- Сквозная трассировка настроена — каждый запрос можно проследить от начала до конца.
- Пайплайн выкатывает сервис независимо — без ручных операций и без зависимостей от других сервисов.
- Дежурство и алерты назначены — есть те, кто отвечает за сервис в нерабочее время.
- Посчитана стоимость эксплуатации на год — инфраструктура, поддержка, доработки.
Если все пункты выполнены — можно начинать.
Частые вопросы
С чего начинать новый проект в 2026 году?
С модульного монолита. Это даёт 80% преимуществ микросервисной архитектуры при 20% издержек. Вы можете быстро стартовать, легко менять границы модулей, пока предметная область ещё не устоялась, и при необходимости выделить сервис, когда для этого появится измеримая причина.
Сколько сервисов считается нормой?
Минимум, который решает ваши проблемы. Netflix работает с сотнями сервисов — у них команда из тысяч инженеров. Для команды из десяти человек три-четыре сервиса уже могут быть перебором. Нормы нет, есть цена, которую вы готовы платить.
Можно ли вернуться с микросервисов на монолит?
Да, и это делает всё больше команд. Процесс называется консолидацией. Сервисы объединяют обратно в один развёртываемый блок, сохраняя модульные границы внутри. Это не откат назад, а переход к модульному монолиту — более зрелой архитектуре.
Обязателен ли Kubernetes для микросервисов?
Нет, но без оркестратора управлять десятками контейнеров вручную невозможно. Kubernetes — самый распространённый вариант, но есть и альтернативы: Nomad, Docker Swarm, управляемые сервисы вроде ECS. Выбор зависит от команды и инфраструктуры.
Чем модульный монолит отличается от обычного?
Обычный монолит — это когда код просто лежит в одном репозитории, и никто не следит за границами. Модульный монолит — когда код разделён на модули с явными контрактами, обращения идут через публичные интерфейсы, а не напрямую, и каждый модуль теоретически можно вынести в отдельный сервис.
В 2026 году правильный старт почти всегда — модульный монолит с возможностью выделить сервис, когда для этого появится измеримая причина. Это не значит, что микросервисы плохие. Просто они дорогие и сложные. И брать на себя эту сложность стоит только тогда, когда выгода от независимых релизов, изоляции команд и точечного масштабирования перевешивает затраты.
Советуем дополнительно почитать
Что такое технический долг — чем оборачивается решение, принятое ради скорости, и как считать его стоимость через год.
Микрофронтенд: что это такое и как работает — та же идея дробления, но на фронтенде: те же плюсы и ровно те же накладные расходы.
Как выбрать базу данных для проекта — второе большое архитектурное решение, которое принимают на старте и потом дорого меняют.
Что такое код-ревью — процесс, который в модульном монолите заменяет сетевые границы: как удерживать модули изолированными без разделения на сервисы.
DevSecOps: что это такое и как работает — как встраивать проверки безопасности в пайплайн, когда сервисов становится больше одного.
Полезный блок со скидкой
Деньги на инфраструктуру, зарплаты инженеров, потерянное время на отладку и тестирование — выбор архитектуры напрямую влияет на бюджет проекта. Если вы хотите глубже разобраться в устройстве современных систем или научиться принимать такие решения осознанно, нужна практика. У Яндекс Практикума есть курсы по бэкенд-разработке и архитектуре с разборкой реальных кейсов. По промокоду KOD вы получите скидку на любой платный курс. Бесплатные вводные части тоже есть — начать можно без привязки карты.
