В каких случаях выбирают микросервис

# В каких случаях выбирают микросервисы?

Микросервисы — это архитектурный стиль, где приложение разделено на множество независимых сервисов. Это не всегда правильный выбор.

Когда ВЫБИРАЮТ микросервисы

1. Большая команда разработчиков

Монолит:           Микросервисы:
Вся команда        Team A → User Service
↓                  Team B → Order Service
Один код база      Team C → Payment Service
Конфликты merge    Независимые repo
Медленные release  Быстрые deploy

Критерий: 50+ разработчиков, несколько команд

2. Разные требования к масштабируемости

Монолит:
Всё масштабируется вместе
User Service нужна 10 инстансов
Payment Service нужна 50 инстансов
Деплоим 50 инстансов целого приложения → пустая трата ресурсов

Микросервисы:
Scalable независимо
User Service: 10 инстансов
Payment Service: 50 инстансов
Оптимальное использование ресурсов

Критерий: сервисы имеют разные пиковые нагрузки

3. Разные стеки технологий

Монолит:
Все на Java
Все на PostgreSQL
Не оптимально для всех задач

Микросервисы:
User Service → Java + PostgreSQL
Search Service → Python + Elasticsearch
Notifications → Node.js + Redis
Каждый сервис оптимален для своей задачи

Критерий: разные команды хотят разные технологии

4. Разные скорости обновления

Монолит:
User Service меняется раз в месяц
Payment Service меняется раз в квартал
Делаем deploy → нужно тестировать ВСЁ
Долгий release цикл

Микросервисы:
User Service → deploy раз в день
Payment Service → deploy раз в квартал
Независимые цикл релиза

Критерий: разные скорости итераций

5. Независимое масштабирование команд

"У нас есть 5 команд, каждая должна работать независимо"

Монолит → все тормозят друг друга
Микросервисы → каждая команда независима

Когда НЕ выбирают микросервисы

❌ Стартап с 3-5 разработчиками

Монолит:
- Один код база
- Быстро разрабатываем
- Просто деплоим
- Монолит легче понять новичку

Микросервисы:
- Оверинжиниринг
- Сложная настройка (Docker, K8s, сеть)
- Новичок будет разбираться месяц
- Не нужна независимость команд

❌ MVP или прототип

"Давайте быстро протестируем идею"

Микросервисы = слишком много boilerplate'a
Монолит = быстро до market

❌ Простое приложение

Личный блог, CRUD приложение, админ-панель
Монолит нормально
Микросервисы = лишняя сложность

❌ Нет опыта с распределёнными системами

Микросервисы требуют опыта с:
- Асинхронными операциями
- Распределёнными транзакциями
- Сетевыми проблемами (timeout, retry)
- Логирование и трейсинг
- Docker, K8s

Если команда не готова → боль

Реальные критерии выбора

✅ ИСПОЛЬЗУЙ МИКРОСЕРВИСЫ, ЕСЛИ:

1. Команда 30+ разработчиков
2. Разные требования к масштабируемости
3. Разные стеки технологий
4. Разные скорости обновления
5. Есть опыт с distributed systems
6. Бизнес может себе позволить ops complexity

❌ НЕ ИСПОЛЬЗУЙ МИКРОСЕРВИСЫ, ЕСЛИ:

1. Команда <20 разработчиков
2. Стартап/MVP
3. Один стек технологий работает для всех
4. Одинаковые требования ко всем частям
5. Нет опыта с распределёнными системами
6. Нужна скорость разработки

Проблемы микросервисов

// Сложная отладка
HTTP запрос → Service A → Service B → Service C
Ошибка где-то посередине? Где искать?

// Распределённые транзакции
Service A: создать заказ ✓
Service B: списать деньги ✗ (упал)
// Что делать?

// Сетевые проблемы
try {
    response = serviceB.call();
} catch (TimeoutException e) {
    // нужно retry, exponential backoff, circuit breaker
}

// Operational complexity
M сервисов × N версий = M×N комбинаций
Деплоим Docker → K8s → Istio → Prometheus
Оперс нужно 10 человек

Альтернативы

Модульный монолит

- Одно приложение
- Внутри разные модули (User, Order, Payment)
- Можно разделить по папкам/пакетам
- Потом легче выделить в микросервис

Разделение по БД

Одно приложение, но разные БД
- User Service: PostgreSQL
- Search: Elasticsearch
- Cache: Redis

Так тоже можно масштабировать

Резюме

Микросервисы выбирают когда:

1. Большая распределённая команда
2. Разные требования к разным частям
3. Команда опытная в распределённых системах
4. Бизнес может позволить себе ops complexity

Для стартапа и MVP - монолит лучше. Начни с монолита, потом выделяй микросервисы когда действительно нужны.

Peter Rodgers: "Don't start with microservices. Start with a monolith and split off services as your system grows."