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

Скрытые проблемы микросервисов: когда монолитные архитектуры экономят время и деньги

Стартап серии B — 23 микросервиса. 10 000 активных юзеров в день. Счет от AWS: $47 000 в месяц.

После объединения в 4 сервиса: счет сократился до $18 000 в месяц.
Итого: $348 000 экономии в год. Никакой магии, оптимизации кода или кэширования.

Просто признание факта: микросервисы им были не нужны.

Ложь, в которую мы верим

Ложь №1: Нам нужны микросервисы для масштабирования

Netflix обрабатывает 100 000 запросов в секунду. Вы обрабатываете 100.

Вы парадируете Netflix, имея 0.1% их трафика. И платите энтерпрайз-цену за проблемы стартапа.

Вот правда: один инстанс EC2 m5.xlarge может вывозить 10 000 запросов в секунду на типичных CRUD-операциях. Цена: $140 в месяц.

Ваши 23 микросервиса на инстансах t3.medium? $1150 в месяц. За те же 100 запросов в секунду.

Ложь №2: Микросервисы ускоряют разработку

20 репозиториев. 20 CI/CD пайплайнов. 20 наборов зависимостей.

Одна фича затрагивает 5 сервисов. Это 5 пул-реквестов, 5 код-ревью, 5 деплоев и 5 мест, где что-то может сломаться.

Ваша задача на два дня превратилась в двухнедельную сессию отладки распределенных систем.

Ложь №3: Это общепринятая практика

Лучшая практика для кого? Для Amazon с 10 000 инженеров? Или для вашего стартапа из 15 человек?

Amazon создал микросервисы, потому что сотни команд мешали друг другу. Вы создали микросервисы, потому что так было написано в статье на Medium.

Скрытый счет

Открой свой AWS Cost Explorer. Я подожду.

А теперь давай найдем расходы, которые ты не замечаешь:

Передача данных: Тихий убийца

Каждый API-вызов между твоими сервисами стоит денег. AWS берет $0.01/ГБ за передачу данных между зонами доступности (cross-AZ).

Давай посчитаем на пальцах:

  • Запрос пользователя —> API Gateway —> Сервис A —> Сервис B —> Сервис C —> База данных
  • Каждый прыжок: ~10КБ запрос + 50КБ ответ = 60КБ
  • 1 миллион запросов в день × 60КБ × 5 прыжков = 300ГБ в день
  • Ущерб за месяц: $900 просто за игру в «горячую картошку» твоими же собственными данными.
  • Ваш монолит? Ноль затрат на внутреннюю передачу. Ноль.

Стомость Load Balancer

Каждому микросервису нужен Application Load Balancer. AWS берет за это $0.025 в час + плата за обработку данных.

20 сервисов × $18 в месяц = $360 в месяц.

Плюс $0.008 за каждый обработанный ГБ. При 1 ТБ трафика на сервис в месяц: еще $160.

Итого: $520 в месяц просто за привилегию иметь пачку сервисов.

Одному монолиту нужен один лоад-балансер. $18 в месяц. И точка.

Observability — черная дыра

DataDog берет плату за хост. CloudWatch — за лог-группу. New Relic — за каждый сервис.

Реальные цифры из реального стартапа:

  • DataDog: 20 хостов × $100 в месяц = $2 000.
  • Логи CloudWatch: 20 лог-групп × 50 ГБ каждая = $500.
  • Метрики CloudWatch: 200 кастомных метрик × $0.30 = $60.
  • X-Ray трейсинг: 10 миллионов трейсов × $0.000005 = $50.

Итого: $2610 в месяц просто за то, чтобы наблюдать, как твои 20 сервисов не делают ничего особенного.

То же приложение в виде монолита: $300 в месяц.

Болезнь разрастания баз данных

Учебник по микросервисам говорит: у каждого сервиса должна быть своя база данных.

  • 20 сервисов × RDS t3.small ($35 в месяц) = $700 в месяц.
  • Плюс хранилище бэкапов, плюс снапшоты, плюс рид-реплики для самых важных.
  • Реальный итог: $1 400 в месяц.

Один RDS t3.xlarge, который тянет всё: $280 в месяц. С более высокой производительностью.

Развод с NAT Gateway

Твоим приватным микросервисам нужен доступ в интернет.

NAT Gateway: $45 в месяц + $0.045 за ГБ.

20 сервисов, которые качают пакеты, тянут образы и шлют вебхуки = 2 ТБ в месяц.

Счет за NAT Gateway: $135 в месяц.

Монолит в публичной подсети с правильно настроенными security groups: $0 в месяц.

Когда микросервисы на самом деле имеют смысл

Перестань оправдывать свою архитектуру. Ответь честно на эти вопросы:

У вас есть команды, которые ФИЗИЧЕСКИ НЕ МОГУТ координировать релизы?
Не «предпочитают не делать этого». Не «это раздражает».
А именно НЕ МОГУТ.
Если ваши команды могут поместиться в один звонок в Zoom, вам не нужны микросервисы.

Разные части системы масштабируются с разницей в 100 раз? Не в 2 раза. Не в 10. В СТО РАЗ. Ваш сервис пользователей получает 1000 запросов в секунду, а генератор PDF — всего 10? Это разница в 100 раз. Вы победили. Выносите его.

Вам РЕАЛЬНО НУЖНЫ разные языки программирования? Не «хочется попробовать». А НУЖНЫ. Машинное обучение на Python, когда все остальное на Java? Ладно. Выносите только эту часть.

Если на все три вопроса ответ «нет» — вы сжигаете $30 000 в месяц ради архитектурной чистоты.

Паттерн «Умный монолит»

Одна кодовая база. Несколько модулей. Четкие границы. Никаких сетевых вызовов.

app/
├── billing/        # Domain logic
├── users/          # Domain logic  
├── notifications/  # Domain logic
├── api/               # HTTP layer
└── shared/        # Common utilities

У каждого модуля есть свои:

  • Доменные модели
  • Бизнес-логика
  • Схема базы данных (одна база, разные схемы)
  • Тесты

Чего нет у модуля:

  • Отдельного репозитория
  • Отдельного CI/CD пайплайна
  • Отдельного мониторинга
  • Отдельного деплоя
  • Сетевых вызовов к другим модулям

Когда вы достигнете 10 000 запросов в секунду (а вы не достигнете), границы для разделения будут готовы по доменной области.
Выделяйте сервис тогда. Не сейчас.

Порог выделения сервиса

1. Это стоит вам клиентов

Монолит буквально не справляется с нагрузкой. Не «может не справиться» в будущем. А не справляется сегодня. Клиенты уходят, потому что все тормозит и падает.

2. Это стоит вам инженеров

Команды блокируются еженедельно из-за конфликтов при деплое. Не «иногда раздражаются», а именно блокируются. Каждую неделю. Продуктивность измеримо умирает в очередях на слияние веток.

3. Это стоит вам соответствия стандартам (Compliance)

PCI DSS требует изоляции обработки платежей. HIPAA требует разделения медицинских данных. Аудитор говорит «отдельная система» и имеет это в виду.

Все остальное — это разработка ради резюме (Resume-Driven Development).

Математика миграции

Твоя текущая ситуация:

  • 20 микросервисов
  • Команда из 5 инженеров
  • 100 запросов в секунду (пиковая нагрузка)
  • $15 000 в месяц на инфраструктуру

После объединения в 3 сервиса:

  • API Монолит (95% твоей логики)
  • Фоновые задачи (то, что реально требует другого масштабирования)
  • Уведомления (то, что взлетает в 10 раз во время маркетинговых акций)

Новые расходы:

  • Инфраструктура: $4 000 в месяц
  • Экономия: $11 000 в месяц
  • Годовая экономия: $132 000

Это зарплаты двух инженеров. Или продление жизни стартапа на посевной стадии. Или реальные фичи вместо бесконечного исправления багов распределенных систем.

Твои задачи прямо сейчас

  1. Запусти запрос в CloudWatch Insights: Узнай, сколько внутренних API-вызовов ты совершаешь. Умножь объем данных на $0.01/ГБ. Поплачь.
  2. Посчитай свои Load Balancers: Зайди в EC2 —> Load Balancers. Посчитай их. Умножь на $18. Это твой налог на ALB.
  3. Проверь счет в DataDog: Settings —> Usage —> Hosts. Сколько из них — это просто одно и то же приложение, порезанное на куски?
  4. Составь список сервисов по владельцам: Если одни и те же люди владеют несколькими сервисами, почему они разделены?

Правда, которую никто не хочет слышать:

  • Твоему стартапу не нужны микросервисы.
  • Тебе нужен работающий продукт, платящие клиенты и деньги в банке.

Полезные ссылки


Андрей Писаревский

Автор: Андрей Писаревский — Team Lead

Коммерческий опыт в программировании с 2010 года и экспертиза в полном цикле веб разработки: Frontend, Backend, QA, CI/CD, управление крупными командами и Enterprise проектами.

А так-же открыт к предложениям о работе со стеком PHP/Golang.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *