Многие команды верят, что переход на микросервисы — это признак «зрелости» компании. На деле же большинство просто меняет проблемы монолита на «распределенный ад», платя за это огромный налог, который не могут себе позволить.
Если у вас в штате 12 инженеров, а архитектура как у Netflix (где их тысячи), — у вас проблемы. Разбираемся, почему индустрия начала массово возвращаться к монолитам и как не попасть в ловушку хайпа.
1. Распределенный монолит: Худшее из обоих миров
Многие думают, что разделили код, но на самом деле они просто «размазали» бизнес-логику по сети.
- Связанность (Coupling): Если для изменения одного правила вам нужно обновить 5 сервисов, скоординировать 5 релизов и прогнать 5 наборов тестов — это не микросервисы. Это распределенный монолит.
- Ад отладки: Ошибка в сериализации в одном сервисе может потребовать недель поиска через цепочку из 8 вызовов. Физически сервисы разделены, но логически они скованы одной цепью.
2. «Налог» на сеть и железо
Сетевые вызовы не бесплатны — это физика.
- Задержки: Внутрипроцессный вызов функции занимает наносекунды. HTTP-запрос — от 1 до 10 миллисекунд. Цепочка из 5 сервисов дает 50–100 мс задержки еще до того, как выполнится хоть строчка логики.
- Кейс Prime Video: Команда AWS перевела одну из систем с Lambda и микросервисов на монолит (EC2/ECS). Затраты на инфраструктуру упали на 90%, а производительность выросла, так как исчезли лишние прыжки по сети.
- Оверхед: Sidecar-прокси (вроде Istio) могут потреблять до 90% ресурсов CPU и памяти пода. Вы платите за инфраструктуру, а не за работу вашего приложения.
3. Человеческий фактор и SRE-кошмар
Микросервисы требуют огромного штата поддержки:
- В зрелой системе один SRE может тянуть 10–15 сервисов. Если у вас 40 сервисов и 2 DevOps-инженера — вы уже «под водой».
- Для хорошо спроектированного монолита достаточно 1–2 инженеров на все приложение.
- Итог: Вы нанимаете людей не для создания продукта, а для обслуживания сложности, которую сами же создали.
4. Модульный монолит — это не «откат назад»
Данные DORA (2024) показывают: элитные команды достигают одинаковых показателей скорости и надежности как на микросервисах, так и на монолитах. Секрет не в типе деплоя, а в модульности.
Концепция распределительного щита: В здании каждый контур изолирован. Если замкнет розетку, серверная не сгорит. Но вам не нужно строить отдельное здание для каждого электроприбора. Вам нужны чистые границы внутри одной структуры.
Правильный подход:
- Модульный монолит: Единый артефакт, но с жесткими границами внутри (используйте инструменты вроде ArchUnit или Spring Modulith).
- Общая БД с разделением схем: Логическое разделение данных при сохранении простоты транзакций.
- Извлечение сервиса — только при необходимости: Когда конкретному модулю действительно нужно независимое масштабирование или другой стек технологий.
5. ИИ как катализатор хаоса
В 2025 году ИИ увеличил объем генерируемого кода, но производительность доставки (delivery performance) осталась прежней. Почему? В запутанной архитектуре ИИ просто генерирует баги быстрее. Ревьюить код, который влияет на «все и сразу», невозможно. ИИ приносит пользу только там, где архитектура позволяет изолировать радиус поражения (blast radius).
Итог: Архитектура как финансовое решение
В 2026 году CTO всё чаще приходится защищать бюджеты на инфраструктуру перед советом директоров. Архитектура — это не вопрос «красоты», это вопрос Complexity Budget (бюджета сложности).
- Микросервисы оправданы, если у вас 1000+ инженеров, которым нужно работать независимо, не мешая друг другу.
- Для 90% компаний модульный монолит — идеальная точка старта.
Главный совет: Не внедряйте микросервисы, пока не сможете четко назвать организационную или техническую проблему, которую они решают в вашем конкретном случае. В противном случае вы просто платите налог за право казаться «крутыми».