— Мы пилим монолит на микросервисы!
Часто слышу я от молодых компаний, которые консультирую.
— А зачем? — уточняю я.
Дальше следуют ответы:
- Накопилось легаси, и нам посоветовали переписать.
- Сайт нестабильно работает, решили, что микросервисы надежнее.
- Хотим ускорить сайт, ведь микросервисы быстрее.
- Разработчики хотят новый стек, а с микросервисами проще внедрять другие языки.
- Инфраструктура будет дешвеле, ведь масштабировать можно по-отдельности.
Правильного ответа, как обычно, не существует.
Мне близка точка зрения Криса Ричардсона, с которым я имел честь несколько раз пообедать. Крис — известный эксперт в разработке, специализируется на архитектуре микросервисов, пишет книги на эту тему, много публикует и выступает. Он создал ресурс microservices.io, где собраны ценные материалы по этой архитектуре.
Ключевая ценность микросервисов, по мнению Криса, — это ускорение разработки. А это один важнейших факторов для топ-менеджмента ИТ-компаний.
Разделяя монолит на независимые сервисы, мы:
- Избавляемся от ситуаций, когда одна команда ждет другую, потому что в коде обнаружились баги.
- Получаем возможность быстро вносить изменения в продакшен без зависимости от команд друг от друга.
Это особенно важно для крупных команд: в монолите, с ростом числа разработчиков, скорость работы падает. А микросервисы помогают сохранить темп.
Не менее важно, что сама по себе эта архитектура не даст скорости, если совместно с ней не проработаны процессы CI/CD и орг.структура с небольшыими кросс-функциональными командами. Эта связь приведена на иллюстрации.
К сожалению, поддержка микросервисной архитектуры стоит дороже: оркестрация, нюансы с консистентностью, сетевые задержки, проблемы в тестировании. Эти сложности окупаются только на больших масштабах благодаря сохранению темпа разработки.
Если всё сделать правильно, можно получить и другие плюсы, о которых говорилось выше: масштабируемость, отказоустойчивость, мультистек, переиспользование модулей.
Что значит "правильно"? Ответы в сегодняшней рекомендации: книга "Microservices patterns", Chris Richardson.