🏗️ Монолит и микросервисы

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

Сравнение

Как это работает

1. Монолит — одна кодовая база и обычно одна база данных. Любое изменение требует релиза всего приложения
2. Микросервисы разделены по бизнес-доменам: заказы, платежи, уведомления. У каждого своя база, чтобы не было скрытых связей
3. Сервисы общаются по HTTP или через брокер сообщений. Сеть ненадёжна, поэтому нужны повторы, таймауты, очереди
4. Для десятков сервисов нужны оркестрация, обычно Kubernetes, централизованные логи, трассировка и метрики

Зачем это менеджеру

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

Пример из жизни

Стартап начал с микросервисов, потому что «так правильно». Три разработчика поддерживали двенадцать сервисов и полдня тратили на инфраструктуру. Через год переехали в монолит с чёткими модулями внутри и стали выпускать вдвое быстрее. Когда команда выросла до четырёх, самый нагруженный модуль вынесли в отдельный сервис. Это и есть здравый путь: монолит с границами, потом выделение по необходимости

Важно запомнить

• Микросервисы решают проблему роста команд, а не производительности как таковой
• Цена микросервисов — инфраструктура, мониторинг, сетевые ошибки, более долгий старт
• Масштабировать микросервис дешевле: копируешь только нагруженную часть

Как ответить на собесе

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