Привет, коллеги. Хочу рассказать историю, за которую мне до сих пор немного стыдно, но она того стоит. Три года назад мы с двумя партнёрами запускали сервис для автоматизации записи в небольшие клиники. На второй месяц я, как самый «прокачанный» технически, убедил команду, что писать монолит — это прошлый век. Мы разбили будущий продукт на двенадцать микросервисов ещё до того, как у нас появился первый платящий клиент. Итог: семь месяцев работы, две тысячи строк инфраструктурного кода на каждую строку бизнес-логики и выгоревшая команда, которая разошлась по другим проектам. Продукт так и не вышел. Сегодня я хочу разобрать пять ошибок, которые нас убили, — возможно, кому-то это сэкономит полгода жизни.
Ошибка первая — микросервисы ради моды. Мы выбрали архитектуру не потому, что она решала нашу проблему, а потому что о ней говорили на конференциях. У нас не было нагрузки, не было десятков команд, не было требований к независимому деплою. Мы лечили болезнь, которой у нас не было, и платили за это временем, которого у стартапа всегда в обрез. Микросервисы — это инструмент для масштабирования организации, а не для поиска product-market fit.
Ошибка вторая — инфраструктура сжирает продукт. Вместо того чтобы разговаривать с клиентами, мы настраивали оркестратор, писали пайплайны сборки, поднимали сервис-дискавери, разбирались с сетевой политикой и секретами. Каждая новая фича требовала правок в трёх-четырёх репозиториях и согласованного релиза. Мы фактически построили маленькую платформенную команду внутри стартапа из четырёх человек, и эта платформа не приносила ни рубля выручки.
Ошибка третья — данные и согласованность. В монолите мы бы сделали одну транзакцию и забыли. В микросервисах пришлось городить саги, компенсирующие операции, идемпотентность и очереди. Мы ловили баги, когда запись создана в одном сервисе, а слот в расписании не забронирован в другом, и это выглядело для клиники как потерянный пациент. Отладка таких сценариев занимала дни, а уверенности в корректности данных не было вообще.
Ошибка четвёртая — команда меньше, чем сервисов. Каждому сервису нужен владелец, который понимает его код, деплой и метрики. По закону Конвея архитектура начинает отражать структуру коммуникаций, и у нас она отражала хаос: три разработчика на двенадцать сервисов означали, что никто не отвечает ни за что по-настоящему. Любой отпуск или больничный превращался в остановку релизов.
Ошибка пятая — наблюдаемость и локальная разработка. Поднять весь зоопарк на своей машине было невозможно, поэтому мы тестировали прямо в общем окружении и постоянно мешали друг другу. Логи размазаны по десятку источников, трейсинг мы подключили поздно, а алерты приходили уже после того, как клиент звонил и ругался. Диагностика одной ошибки занимала в разы больше времени, чем её исправление.
Что бы я сделал иначе и что советую вам. Начинайте с модульного монолита: один код, один деплой, чёткие границы модулей внутри. Держите одну базу данных, пока это возможно, и не стыдитесь этого. Выделяйте сервис только тогда, когда у него есть реальная причина — независимое масштабирование, отдельная команда или изоляция сбоев, подтверждённая метриками. Инвестируйте в мониторинг и тесты на монолите, а не в оркестрацию. Архитектура — это следствие ваших ограничений, а не самоцель, и менять её нужно тогда, когда боль становится измеримой.
Мы, кстати, потом переписали всё в один сервис за пять недель и наконец начали общаться с клиентами. Так что история со счастливым концом, просто дорогим. А как у вас? Расскажите, приходилось ли вам откатываться от микросервисов обратно к монолиту или вы сразу пошли по простому пути и ни разу не пожалели?
Ошибка первая — микросервисы ради моды. Мы выбрали архитектуру не потому, что она решала нашу проблему, а потому что о ней говорили на конференциях. У нас не было нагрузки, не было десятков команд, не было требований к независимому деплою. Мы лечили болезнь, которой у нас не было, и платили за это временем, которого у стартапа всегда в обрез. Микросервисы — это инструмент для масштабирования организации, а не для поиска product-market fit.
Ошибка вторая — инфраструктура сжирает продукт. Вместо того чтобы разговаривать с клиентами, мы настраивали оркестратор, писали пайплайны сборки, поднимали сервис-дискавери, разбирались с сетевой политикой и секретами. Каждая новая фича требовала правок в трёх-четырёх репозиториях и согласованного релиза. Мы фактически построили маленькую платформенную команду внутри стартапа из четырёх человек, и эта платформа не приносила ни рубля выручки.
Ошибка третья — данные и согласованность. В монолите мы бы сделали одну транзакцию и забыли. В микросервисах пришлось городить саги, компенсирующие операции, идемпотентность и очереди. Мы ловили баги, когда запись создана в одном сервисе, а слот в расписании не забронирован в другом, и это выглядело для клиники как потерянный пациент. Отладка таких сценариев занимала дни, а уверенности в корректности данных не было вообще.
Ошибка четвёртая — команда меньше, чем сервисов. Каждому сервису нужен владелец, который понимает его код, деплой и метрики. По закону Конвея архитектура начинает отражать структуру коммуникаций, и у нас она отражала хаос: три разработчика на двенадцать сервисов означали, что никто не отвечает ни за что по-настоящему. Любой отпуск или больничный превращался в остановку релизов.
Ошибка пятая — наблюдаемость и локальная разработка. Поднять весь зоопарк на своей машине было невозможно, поэтому мы тестировали прямо в общем окружении и постоянно мешали друг другу. Логи размазаны по десятку источников, трейсинг мы подключили поздно, а алерты приходили уже после того, как клиент звонил и ругался. Диагностика одной ошибки занимала в разы больше времени, чем её исправление.
Что бы я сделал иначе и что советую вам. Начинайте с модульного монолита: один код, один деплой, чёткие границы модулей внутри. Держите одну базу данных, пока это возможно, и не стыдитесь этого. Выделяйте сервис только тогда, когда у него есть реальная причина — независимое масштабирование, отдельная команда или изоляция сбоев, подтверждённая метриками. Инвестируйте в мониторинг и тесты на монолите, а не в оркестрацию. Архитектура — это следствие ваших ограничений, а не самоцель, и менять её нужно тогда, когда боль становится измеримой.
Мы, кстати, потом переписали всё в один сервис за пять недель и наконец начали общаться с клиентами. Так что история со счастливым концом, просто дорогим. А как у вас? Расскажите, приходилось ли вам откатываться от микросервисов обратно к монолиту или вы сразу пошли по простому пути и ни разу не пожалели?