Привет, форумчане. За последние три года я дважды участвовал в проектах, где команда всерьёз решала, распиливать монолит на микросервисы или нет. В первый раз мы распилили и почти пожалели, во второй раз сознательно остались монолитом и не пожалели ни разу. Расскажу на цифрах, потому что разговоры про гибкость и независимые деплои без цифр быстро превращаются в религию.
Проект номер один: интернет-магазин, монолит на PHP, около 400 тысяч строк кода, команда из шести разработчиков. Метрики на старте выглядели так. Полная сборка с прогоном тестов занимала 14 минут, релиз выкатывали раз в две недели, новый разработчик входил в контекст примерно три недели, инфраструктура стоила около 1 200 долларов в месяц. Казалось, что микросервисы нас точно спасут.
Триггером стал пик перед Новым годом. Монолит лёг на четыре часа, потому что один медленный запрос в блоке рекомендаций забил пул соединений к базе. Мы потеряли примерно 8 процентов дневной выручки и две ночи сна. После этого решение о разделении приняли практически без обсуждения, и вот тут начинается самое интересное.
Распил занял восемь месяцев силами тех же шести человек, из которых двое последние месяцы поддерживали старый монолит. Получилось пять сервисов, отдельная база для двух из них, очередь сообщений и собственный сервис аутентификации. Что мы получили в цифрах. Релизы стали ежедневными, сборка сократилась до четырёх минут, восстановление после сбоя упало с четырёх часов до двадцати пяти минут, вход нового разработчика в контекст занял десять дней. Инфраструктура при этом подорожала с 1 200 до 3 400 долларов в месяц, а на подготовку окружений и согласование контрактов API уходило около 30 процентов времени команды.
Считаем честно. Экономия на скорости релизов и на простоях окупала новые расходы только потому, что выручка росла, а цена часа простоя была высокой. Если бы магазин приносил вдвое меньше, переход не окупился бы никогда. И ещё одна деталь, о которой в презентациях не говорят: полгода ушло просто на то, чтобы догнать по скорости разработки тот уровень, с которого мы начинали. Это огромные скрытые инвестиции, которые не видно в красивом графике после релиза.
Теперь вывод, подкреплённый вторым проектом. Внутренняя система для логистики, десять разработчиков, монолит на Java, разделённый на модули по доменам. Мы выделили всего два сервиса: интеграцию с внешним провайдером и тяжёлый расчёт тарифов. Всё остальное осталось в модульном монолите. Итог за полтора года: релизы дважды в день, инфраструктура 900 долларов в месяц, критичных инцидентов три, и все закрывались в пределах сорока минут.
Отсюда моя главная рекомендация. Считайте не моду, а стоимость координации. Микросервисы окупаются, когда у вас несколько команд по шесть-восемь человек, устоявшиеся границы домена, зрелая наблюдаемость и нормальная автоматизация развёртывания. Если команда меньше десяти человек, если нет отдельного человека на инфраструктуру и если домен ещё меняется каждую неделю, распил почти гарантированно превратится в распределённый монолит с лишними сетевыми вызовами. Начинайте с модульного монолита, где границы модулей совпадают с будущими сервисами, и выделяйте сервис только под конкретную боль, а не под красивую идею из доклада.
И вопрос к вам, форумчане: а какой опыт был у вас? Случались ли проекты, где переход на микросервисы реально отбил вложения, и на каких цифрах это стало видно? Делитесь историями, вместе мы соберём куда более честную картину, чем любая конференция.
Проект номер один: интернет-магазин, монолит на PHP, около 400 тысяч строк кода, команда из шести разработчиков. Метрики на старте выглядели так. Полная сборка с прогоном тестов занимала 14 минут, релиз выкатывали раз в две недели, новый разработчик входил в контекст примерно три недели, инфраструктура стоила около 1 200 долларов в месяц. Казалось, что микросервисы нас точно спасут.
Триггером стал пик перед Новым годом. Монолит лёг на четыре часа, потому что один медленный запрос в блоке рекомендаций забил пул соединений к базе. Мы потеряли примерно 8 процентов дневной выручки и две ночи сна. После этого решение о разделении приняли практически без обсуждения, и вот тут начинается самое интересное.
Распил занял восемь месяцев силами тех же шести человек, из которых двое последние месяцы поддерживали старый монолит. Получилось пять сервисов, отдельная база для двух из них, очередь сообщений и собственный сервис аутентификации. Что мы получили в цифрах. Релизы стали ежедневными, сборка сократилась до четырёх минут, восстановление после сбоя упало с четырёх часов до двадцати пяти минут, вход нового разработчика в контекст занял десять дней. Инфраструктура при этом подорожала с 1 200 до 3 400 долларов в месяц, а на подготовку окружений и согласование контрактов API уходило около 30 процентов времени команды.
Считаем честно. Экономия на скорости релизов и на простоях окупала новые расходы только потому, что выручка росла, а цена часа простоя была высокой. Если бы магазин приносил вдвое меньше, переход не окупился бы никогда. И ещё одна деталь, о которой в презентациях не говорят: полгода ушло просто на то, чтобы догнать по скорости разработки тот уровень, с которого мы начинали. Это огромные скрытые инвестиции, которые не видно в красивом графике после релиза.
Теперь вывод, подкреплённый вторым проектом. Внутренняя система для логистики, десять разработчиков, монолит на Java, разделённый на модули по доменам. Мы выделили всего два сервиса: интеграцию с внешним провайдером и тяжёлый расчёт тарифов. Всё остальное осталось в модульном монолите. Итог за полтора года: релизы дважды в день, инфраструктура 900 долларов в месяц, критичных инцидентов три, и все закрывались в пределах сорока минут.
Отсюда моя главная рекомендация. Считайте не моду, а стоимость координации. Микросервисы окупаются, когда у вас несколько команд по шесть-восемь человек, устоявшиеся границы домена, зрелая наблюдаемость и нормальная автоматизация развёртывания. Если команда меньше десяти человек, если нет отдельного человека на инфраструктуру и если домен ещё меняется каждую неделю, распил почти гарантированно превратится в распределённый монолит с лишними сетевыми вызовами. Начинайте с модульного монолита, где границы модулей совпадают с будущими сервисами, и выделяйте сервис только под конкретную боль, а не под красивую идею из доклада.
И вопрос к вам, форумчане: а какой опыт был у вас? Случались ли проекты, где переход на микросервисы реально отбил вложения, и на каких цифрах это стало видно? Делитесь историями, вместе мы соберём куда более честную картину, чем любая конференция.