От монолита к микросервисам и обратно: чему индустрию научили 20 лет экспериментов
Двадцать лет между монолитом и микросервисами: почему компании возвращаются обратно и как маятник качнулся к прагматизму.
Как архитектурный маятник в 2025 году качнулся к прагматизму
В середине 2020-х в индустрии разработки произошло то, что ещё несколько лет назад казалось невозможным: микросервисы — архитектурный стиль, долгое время считавшийся безальтернативным будущим, — начали массово пересматриваться. Компании, прошедшие путь от монолитов к тотальной сервисной декомпозиции, всё чаще говорят не о масштабируемости и гибкости, а о сложности, стоимости и потере управляемости.
Архитектурный маятник качнулся обратно. Но не к старым монолитам, а к более зрелым, прагматичным решениям.
Эпоха монолита: просто, пока не стало слишком сложно
В начале 2000-х монолитная архитектура была стандартом индустрии. Одно приложение, единый код, общая база данных — всё находилось в одном процессе. Такой подход позволял быстро стартовать и был понятен большинству команд.
Проблемы начинались по мере роста системы. Любое изменение несло риск затронуть неожиданные части приложения. Развёртывание новой версии превращалось в стрессовую операцию, а масштабирование означало увеличение всего приложения целиком — независимо от того, какая часть испытывала нагрузку.
Тем не менее долгие годы это считалось неизбежным компромиссом. Пока несколько компаний не решили, что можно иначе.
Появление сервисной архитектуры и обещание нового будущего
Одним из переломных моментов стала внутренняя трансформация Amazon в конце 1990-х — начале 2000-х. Компания отказалась от прямых связей между компонентами и потребовала, чтобы все взаимодействия происходили исключительно через сервисные интерфейсы. Так появилась сервис-ориентированная архитектура (SOA).
Другой знаковый кейс — Netflix. После серьёзного сбоя в 2008 году компания полностью пересобрала систему: переехала в облако и разделила функциональность на множество независимых сервисов. Это дало возможность масштабировать отдельные части системы, ускорить разработку и повысить отказоустойчивость.
Эти примеры быстро стали эталоном. Индустрия сделала вывод: микросервисы — это ответ на все проблемы роста.
Микросервисы как догма — и первые трещины
Микросервисная архитектура обещала многое:
— независимые команды;
— частые деплои;
— гибкое масштабирование;
— технологическую свободу.
Компании начали активно дробить системы, иногда без чёткого понимания, зачем именно тот или иной компонент должен быть отдельным сервисом. В результате вместо одного сложного приложения появлялись десятки, а затем сотни автономных частей.
Со временем стало очевидно: проблемы никуда не исчезли — они просто сменили форму.
Вызовы функций превратились в сетевые запросы. Появились задержки, сериализация данных, необходимость поддерживать совместимость API. Мониторинг и логирование стали распределёнными. Отладка — сложной и медленной. Локальный запуск всей системы на рабочем компьютере оказался практически невозможным.
То, что раньше было внутренней реализацией, стало инфраструктурной проблемой.
Когда сервисов становится слишком много
Наиболее наглядно издержки микросервисного экстремизма проявились у крупных компаний.
Uber и «Звезда смерти»
Uber, быстро масштабируясь, разделил систему на тысячи микросервисов. Архитектура стала настолько сложной, что её визуализацию прозвали Death Star Diagram — из-за огромного количества узлов и связей.
Одно пользовательское действие — например, заказ поездки — требовало согласованной работы десятков сервисов: геолокация, тарифы, подбор водителя, уведомления. Любой сбой мгновенно отражался на пользовательском опыте.
В ответ Uber перешёл к подходу Domain-Oriented Microservice Architecture: сервисы начали группировать в домены — логические блоки, отвечающие за конкретные бизнес-функции. По сути, это стало попыткой вернуть управляемость и сократить количество точек взаимодействия.
Twitter и попытка «резко упростить»
Twitter тоже пришёл к пределу. К началу 2020-х система состояла из множества энд-сервисов, обслуживающих отдельные функции. Попытка резко сократить их количество привела к временным сбоям критически важных возможностей, включая двухфакторную аутентификацию.
Этот эпизод показал сразу две вещи: архитектура стала слишком сложной для понимания даже внутри компании, а резкий откат без глубокого анализа — опасен. Тем не менее сам факт необходимости упрощения стал симптоматичным.
Возвращение монолита — но уже другого
Постепенно в индустрии начал формироваться компромиссный подход — модульный монолит.
Это не возврат к неструктурированным системам прошлого. Модульный монолит — это одно или несколько крупных приложений, внутри которых код чётко разделён на независимые модули с ясными границами ответственности. Они разворачиваются вместе, но проектируются так, чтобы при необходимости их можно было выделить в отдельные сервисы.
Идея проста: если части системы меняются и масштабируются вместе — нет смысла искусственно разделять их сетевыми границами.
Экономика сильнее идеологии
Один из самых показательных кейсов — Amazon Prime Video. Команда построила систему мониторинга качества видео на базе серверлесс-архитектуры с большим количеством мелких функций.
При масштабировании выяснилось, что значительная часть затрат уходит не на вычисления, а на коммуникацию между компонентами. После анализа систему переписали в монолитное приложение.
Результат оказался неожиданным: инфраструктурные расходы сократились более чем на 90%, а масштабируемость улучшилась. Этот кейс стал редким примером публичного признания того, что микросервисы — не универсальное решение.
Похожие выводы сделали Dropbox и Shopify, сознательно выбрав модульный монолит как основу своей архитектуры.
Как выбирать архитектуру в 2025 году
Современный подход всё меньше опирается на моду и всё больше — на контекст.
Ключевые вопросы выглядят так:
- Размер команды. Небольшие команды редко выигрывают от микросервисов.
- Характер нагрузки. Есть ли части системы, которые действительно нужно масштабировать независимо?
- Нефункциональные требования. Критична ли задержка? Нужна ли строгая консистентность данных?
- Бюджет и экспертиза. Готова ли команда поддерживать сложную инфраструктуру?
Для стартапов и небольших продуктов монолит часто остаётся оптимальным выбором: быстрее, дешевле, понятнее. Микросервисы оправданы там, где они решают конкретную, измеримую проблему.
Важно и то, что архитектура — не окончательное решение. Начать можно с монолита и постепенно выделять сервисы по мере роста. Обратный путь возможен, но значительно сложнее и дороже.
Вместо вывода: маятник остановился в точке баланса
История архитектурных подходов показала, что крайности редко работают долго. Монолиты стали слишком тяжёлыми, микросервисы — слишком сложными. В результате индустрия пришла к более зрелому и прагматичному взгляду.
Сегодня архитектура — это не вопрос веры и не следование трендам. Это инженерный расчёт и честный ответ на вопрос: какую проблему мы решаем прямо сейчас.
И именно этот подход, а не очередная модная аббревиатура, определяет архитектуру систем в 2025 году.
