Монолит vs Микросервисы

2006 год: Amazon завершает многолетний переход с монолита на микросервисы. 2020 год: Stack Overflow обслуживает 50 миллионов пользователей в месяц с монолитом на 9 серверах. Оба решения работают в production у успешных компаний. Вопрос не 'монолит или микросервисы', а 'когда что'. И ответ зависит от организации, не от технологии.

• **Stack Overflow**: один ASP.NET монолит, 9 серверов, 50M пользователей/месяц - доказательство что монолит масштабируется при правильной архитектуре
• **Airbnb**: переход от монолита к микросервисам занял 5+ лет через Strangler Fig. Сейчас Service-Oriented Architecture с 2000+ сервисами
• **Shopify**: критичный для бизнеса e-commerce код до сих пор в большом Rails монолите с модульными границами - осознанное решение, не legacy

Modular Monolith

Модульный монолит - архитектура где весь код деплоится как одно приложение, но внутри чётко разделён на изолированные модули с явными границами. Stack Overflow в 2022 году: один ASP.NET монолит обслуживает 50 миллионов пользователей ежемесячно на 9 серверах. Basecamp, GitHub в ранние годы, Shopify - компании выбрали продуманный монолит вместо преждевременных микросервисов.

Преимущества монолита: простота деплоя (один артефакт), нет network latency между компонентами, ACID транзакции без distributed transactions overhead, единый codebase проще отлаживать. Modular Monolith добавляет структуру: строгие module boundaries (нельзя обращаться напрямую к internal package другого модуля), explicit interfaces между модулями, одна база данных со схемой разделённой по namespace (orders.*, payments.*, catalog.*). Это готовит почву для разбивки на сервисы при необходимости.

Миграция: монолит к сервисам

Миграция монолита к микросервисам - эволюционный процесс, не революция. Amazon перешёл с монолита на микросервисы за несколько лет через постепенное выделение сервисов. Правило: никогда не переписывать всё с нуля одновременно (Second System Effect). Каждый выделенный сервис должен работать в production до перехода к следующему.

Критерии выбора первого сервиса для выделения: чётко определённые границы (низкий coupling с остальным кодом), высокая частота изменений (команда хочет деплоить независимо), разные требования к масштабированию (нужен отдельный scaling), специализированные технологии (ML модели на Python в Java монолите). Антипаттерн: начинать с самого сложного и связанного куска системы.

Strangler Fig Pattern

Strangler Fig - паттерн постепенной замены монолита, названный по виду растения-паразита, которое обволакивает дерево и постепенно его замещает. Martin Fowler описал паттерн в 2004 году. Новая функциональность строится как отдельные сервисы рядом с монолитом. Трафик постепенно перенаправляется с монолита на новые сервисы через facade (API Gateway или nginx). Монолит 'задыхается' по мере того как его функциональность мигрирует.

Реализация: перед монолитом ставится proxy/facade. Все новые запросы проходят через него. Facade может направить запрос в монолит (старый путь) или в новый сервис (новый путь). Постепенно больше маршрутов переключается на новые сервисы. Когда монолит обрабатывает 0% трафика - его можно удалить. Amazon, Airbnb, Etsy использовали этот паттерн для постепенной декомпозиции.

Trade-offs: когда что выбирать

Микросервисы решают organizational scaling проблему, а не техническую. Если команда небольшая и когнитивная нагрузка позволяет держать весь контекст системы в голове - монолит проще. Если команда выросла до 50+ человек и deployment coordination стал bottleneck - микросервисы дают autonomy. Правило Амазон 'Two-Pizza Team': каждый сервис поддерживается командой, которую можно накормить двумя пиццами (5-8 человек).

Реальные costs микросервисов: distributed transactions (Saga complexity), network latency (каждый вызов - сеть), observability (трейсинг через 10 сервисов), operational overhead (деплой, мониторинг, service discovery для каждого), data consistency (eventual consistency вместо ACID). Эти costs оправданы когда organizational benefits (автономия команд, независимый деплой) перевешивают. Преждевременные микросервисы - распределённый монолит: все costs без benefits.

Связанные темы

Выбор архитектуры определяет весь дальнейший стек решений:

• Микросервисы: паттерны — API Gateway, Circuit Breaker, Saga - паттерны которые нужны после перехода на микросервисы
• Domain-Driven Design — Bounded Context из DDD - правильная единица декомпозиции для микросервисов и модулей в монолите

Вопросы для размышления

• Когда 'distributed monolith' (микросервисы с сильной связанностью) хуже чем обычный монолит?
• Strangler Fig требует proxy перед монолитом - какие риски это создаёт и как их митигировать?
• Как Conway's Law ('структура системы отражает структуру организации') влияет на выбор монолит vs микросервисы?

Связанные уроки

• sd-10-microservices