KateThomas
New member
Лет пять назад я был из тех, кто на любом созвоне бодро повторял: монолит — это наследие прошлого, а будущее за микросервисами. Красивые доклады, независимые деплои, команды по пять человек на сервис, и вот уже кажется, что ты построил неубиваемую систему. Сегодня, за спиной три проекта и два болезненных переписывания, я готов честно рассказать, как распределённая архитектура тихо съедает маржинальность, и как я теперь считаю её реальную стоимость.
Первый проект был B2B-платформой на монолите. Команда из шести человек, один сервер приложений, одна база, деплой раз в день, и всё это жило припеваючи с маржинальностью около сорока процентов. Нам казалось, что мы упираемся в потолок: релизы мешают друг другу, база становится узким горлышком, а любая правка в биллинге требовала полного прогона тестов. Мы разбили систему на четырнадцать сервисов, поставили Kubernetes, сервисную сетку, отдельный стек трассировки и централизованные логи. Через год маржинальность упала до восемнадцати процентов. Код мы писали больше, релизов делали чаще, а зарабатывать стали меньше.
Куда ушли деньги, я понял только когда сел и расписал всё по строчкам. Кластер с резервированием, сервисная сетка, распределённый трейсинг, хранилище логов, которое за год выросло в десять раз, отдельная инфраструктура под очереди и кэши, плюс лицензии на всё это. Дальше — люди: дежурства, разбор инцидентов, где причина теряется между сервисами, поддержка контрактов API, миграции схем в трёх базах одновременно, ручная возня с идемпотентностью и ретраями. И самая дорогая статья — координация. Каждый новый разработчик первые два месяца не пишет код, а изучает карту сервисов. Каждая фича вместо одной правки превращается в согласование трёх команд и пять пул-реквестов.
Теперь про TCO, то есть совокупную стоимость владения. Я делю её на пять частей и считаю честно, без самообмана. Первая — прямые инфраструктурные расходы, включая трафик между зонами и хранение логов. Вторая — фонд оплаты труда, умноженный на коэффициент координации, который для десяти сервисов я беру не меньше единицы трёх десятых. Третья — стоимость времени до рынка: сколько дней проходит от идеи до продакшена, и сколько из них тратится на интеграцию, а не на ценность. Четвёртая — цена инцидентов: среднее время восстановления, умноженное на стоимость часа простоя и на частоту сбоев. Пятая — стоимость выхода: насколько дорого заменить один сервис или, не дай бог, выключить всю систему целиком.
Методика расчёта простая и довольно отрезвляющая. Я беру конкретный сервис и спрашиваю: сколько человеко-часов в месяц он требует только на то, чтобы оставаться живым, без единой новой фичи. Потом добавляю накладные расходы на деплой, мониторинг, алерты, ротацию дежурств и обновление зависимостей. Дальше считаю стоимость одной бизнес-транзакции и сравниваю с монолитной версией. Если микросервис не даёт измеримого выигрыша в скорости изменений или в устойчивости под нагрузкой, он у меня попадает в красную зону. Отдельно я всегда оцениваю когнитивную нагрузку: если инженер не может удержать в голове путь запроса через систему, вы уже платите за это временем и качеством.
При этом я не стал апологетом монолита. Микросервисы действительно окупаются, но при конкретных условиях. Когда у вас больше пятидесяти инженеров и команды упираются друг в друга в одном репозитории. Когда части системы требуют принципиально разного масштабирования — например, видеообработка и биллинг. Когда есть регуляторные требования изолировать данные. Когда скорость релиза одного домена критична для бизнеса, а остальные домены стабильны. В этих случаях распределённая архитектура не роскошь, а инструмент выживания. Но если у вас двадцать человек и один продукт, вы, скорее всего, просто покупаете себе вторую работу.
Мои рекомендации звучат скучно, зато они сэкономят вам год жизни. Начинайте с модульного монолита и сначала наведите порядок в границах доменов, а не в инфраструктуре. Выделяйте сервис только тогда, когда боль от его совместного существования измерена в деньгах и часах. Считайте стоимость каждого сервиса как отдельный центр затрат и раз в квартал смотрите, что он приносит. Закладывайте бюджет на наблюдаемость с первого дня, иначе будете платить за инциденты втройне. И держите правило: одна команда — не больше двух сервисов в полной ответственности, иначе дежурства превратятся в каторгу.
А теперь мне интересно услышать вас. Был ли у вас проект, где микросервисы окупились с лихвой и цифры это подтвердили, и если да, то какой именно показатель стал для вас главным аргументом — скорость релизов, устойчивость под нагрузкой или что-то совсем неожиданное?
Первый проект был B2B-платформой на монолите. Команда из шести человек, один сервер приложений, одна база, деплой раз в день, и всё это жило припеваючи с маржинальностью около сорока процентов. Нам казалось, что мы упираемся в потолок: релизы мешают друг другу, база становится узким горлышком, а любая правка в биллинге требовала полного прогона тестов. Мы разбили систему на четырнадцать сервисов, поставили Kubernetes, сервисную сетку, отдельный стек трассировки и централизованные логи. Через год маржинальность упала до восемнадцати процентов. Код мы писали больше, релизов делали чаще, а зарабатывать стали меньше.
Куда ушли деньги, я понял только когда сел и расписал всё по строчкам. Кластер с резервированием, сервисная сетка, распределённый трейсинг, хранилище логов, которое за год выросло в десять раз, отдельная инфраструктура под очереди и кэши, плюс лицензии на всё это. Дальше — люди: дежурства, разбор инцидентов, где причина теряется между сервисами, поддержка контрактов API, миграции схем в трёх базах одновременно, ручная возня с идемпотентностью и ретраями. И самая дорогая статья — координация. Каждый новый разработчик первые два месяца не пишет код, а изучает карту сервисов. Каждая фича вместо одной правки превращается в согласование трёх команд и пять пул-реквестов.
Теперь про TCO, то есть совокупную стоимость владения. Я делю её на пять частей и считаю честно, без самообмана. Первая — прямые инфраструктурные расходы, включая трафик между зонами и хранение логов. Вторая — фонд оплаты труда, умноженный на коэффициент координации, который для десяти сервисов я беру не меньше единицы трёх десятых. Третья — стоимость времени до рынка: сколько дней проходит от идеи до продакшена, и сколько из них тратится на интеграцию, а не на ценность. Четвёртая — цена инцидентов: среднее время восстановления, умноженное на стоимость часа простоя и на частоту сбоев. Пятая — стоимость выхода: насколько дорого заменить один сервис или, не дай бог, выключить всю систему целиком.
Методика расчёта простая и довольно отрезвляющая. Я беру конкретный сервис и спрашиваю: сколько человеко-часов в месяц он требует только на то, чтобы оставаться живым, без единой новой фичи. Потом добавляю накладные расходы на деплой, мониторинг, алерты, ротацию дежурств и обновление зависимостей. Дальше считаю стоимость одной бизнес-транзакции и сравниваю с монолитной версией. Если микросервис не даёт измеримого выигрыша в скорости изменений или в устойчивости под нагрузкой, он у меня попадает в красную зону. Отдельно я всегда оцениваю когнитивную нагрузку: если инженер не может удержать в голове путь запроса через систему, вы уже платите за это временем и качеством.
При этом я не стал апологетом монолита. Микросервисы действительно окупаются, но при конкретных условиях. Когда у вас больше пятидесяти инженеров и команды упираются друг в друга в одном репозитории. Когда части системы требуют принципиально разного масштабирования — например, видеообработка и биллинг. Когда есть регуляторные требования изолировать данные. Когда скорость релиза одного домена критична для бизнеса, а остальные домены стабильны. В этих случаях распределённая архитектура не роскошь, а инструмент выживания. Но если у вас двадцать человек и один продукт, вы, скорее всего, просто покупаете себе вторую работу.
Мои рекомендации звучат скучно, зато они сэкономят вам год жизни. Начинайте с модульного монолита и сначала наведите порядок в границах доменов, а не в инфраструктуре. Выделяйте сервис только тогда, когда боль от его совместного существования измерена в деньгах и часах. Считайте стоимость каждого сервиса как отдельный центр затрат и раз в квартал смотрите, что он приносит. Закладывайте бюджет на наблюдаемость с первого дня, иначе будете платить за инциденты втройне. И держите правило: одна команда — не больше двух сервисов в полной ответственности, иначе дежурства превратятся в каторгу.
А теперь мне интересно услышать вас. Был ли у вас проект, где микросервисы окупились с лихвой и цифры это подтвердили, и если да, то какой именно показатель стал для вас главным аргументом — скорость релизов, устойчивость под нагрузкой или что-то совсем неожиданное?