В этой статье я расскажу о карго-культе "микросервисов" в большом кровавом энтерпрайзе. От упоминания оверкильности микросервисов меня всегда передергивает. Потому что используют их в половине энтерпрайзов так же, как Scrum (без ретроспективы) и DevOps (без CI/CD).
Почему так грубо?
Микросервисы - это один из лучших архитектурных паттернов для своих целей. Благодаря им мы можем легко масштабироваться, быстро разрабатывать и крепко держать "шесть девяток". Такие системы работают на передовой банков, телекомов, заводов и прочих пароходов.
Но у компании есть еще огромная прослойка для автоматизации внутренних процессов. В них, обычно, работает пара сотен человек и делает с тысячу транзакций в день. Только CTO таких проектов хочется получить премию за внедрение, архитектору - строчку в резюме, а разработчикам - доклад на хайлоаде. Таким образом рождаются "микросервисы". Произойти это может еще потому что микросервисы внедряют во всей компании и проект просто под руку попался (см. Массовое Внедрение SAFe в сжатые сраоки). Результат один - куча необученных этому подходу архитекторов и разработчиков лепят распределенный монолит на докер-контейнерах и кубернетесе и портят имидж прекрасному подходу.
Все ничего, но продукт в этом случает становится менее надежным, разрабатывается медленней и стоит дороже в обслуживании.
Но у компании есть еще огромная прослойка для автоматизации внутренних процессов. В них, обычно, работает пара сотен человек и делает с тысячу транзакций в день. Только CTO таких проектов хочется получить премию за внедрение, архитектору - строчку в резюме, а разработчикам - доклад на хайлоаде. Таким образом рождаются "микросервисы". Произойти это может еще потому что микросервисы внедряют во всей компании и проект просто под руку попался (см. Массовое Внедрение SAFe в сжатые сраоки). Результат один - куча необученных этому подходу архитекторов и разработчиков лепят распределенный монолит на докер-контейнерах и кубернетесе и портят имидж прекрасному подходу.
Все ничего, но продукт в этом случает становится менее надежным, разрабатывается медленней и стоит дороже в обслуживании.
Пример такого карго-культа
Покажу на примере. Это был давний кейс компании, которая начала микросервисопереход. Там не было ни инфраструктуры, ни комплаенсов, ни экспертизы. Задача как раз стояла в обкатке подхода. Но выбрали для этого самый неподходящий кейс.
Итак, задача на продукт была проста: написать новый бек для регистрации нового товара взамен старого и интегрировать со сторонним фронтом.
Бизнес-процесс был банальней некуда:
- Оператор вводит данные.
- Проходит валидация данных локально и в сторонних системах.
- Данные сохраняются.
- PROFIT
Количество пользователей: до 500 с прогнозом роста до 1000.
Количество запросов: ~50 RPM
Количество данных: 2 ГБ, рост на 2 ГБ/год.
Требования к надежности: 99%
Количество запросов: ~50 RPM
Количество данных: 2 ГБ, рост на 2 ГБ/год.
Требования к надежности: 99%
Классическое решение проблемы
Если бы вопрос стоял о написании продукта, под эти требования я бы выбрал такой подход.
Если бы вопрос стоял о написании продукта, под эти требования я бы выбрал такой подход.
Для этих требований хватило бы за глаза обычной классики. Бекенд может быть обычным или модульным монолитом, с масштабированием все решаемо и вертикально и горизонтально. При наличии грамотного архитектора приложений, система будет радовать разработчиков и пользователей до скончании веков.
А если начнется бурный рост функционала, то можно уйти в SOA архитектуру, разделив модули или начать делать микросервисы рядом, но уже с полным пониманием доменной области.
А если начнется бурный рост функционала, то можно уйти в SOA архитектуру, разделив модули или начать делать микросервисы рядом, но уже с полным пониманием доменной области.
“Микросервисное решение”
Но мы же не хотим писать на всяком старье, давайте сразу сделаем нормально и будем писать микросервисы.
Напомню, что бизнес-процесс остался таким же и для него требуется участие ВСЕХ микросервисов для его завершения. Такой подзод называется распределенным монолитом и она не имеет ничего общего с настоящими микросервисами. К сожалению, я виду такую картинку в каждом втором энтерпрайзе.
Стоимость разработки
Разберем на примере часть бизнес-функции. Для регистрации продукта, надо получить штрих-код. В обычном монолите мы просто открываем транзакцию и делаем блокировку номера. Если что-то случилось с бизнес-логикой, то мы транзакцию откатываем.
В случае карго-микросервисов нам надо пройти вот такой квест:
Мы получили вдвое больше точек отказа, нам нужно:
- обрабатывать недоступность микросервисов
- откат распределенной транзакции (использовать event store и прочие саги)
- соблюдение контрактов
- под каждый микросервис нужно сделать IAAC или какой-нибудь HELM.
- в бизнес-процессах учитывать отказы
Добавление функционала
В такого рода решениях, для добавления одного поля в запрос, придется сделать изменения во всех компонентах. Допустим, у нас появилось новое поле в продукте. Значит, в выделенных цветом сущностях нужно:
1. Поменять контракты между микросервисами
2. Добавить функционал.
3. Смигрировать три базы.
4. Выкатить это все одновременно и попытаться интегрировать.
2. Добавить функционал.
3. Смигрировать три базы.
4. Выкатить это все одновременно и попытаться интегрировать.
Послесловие
Может показаться, что я выступаю за использование монолитного подхода (см. Микросервисный баттл). Нет, я люблю микросервисы, но еще больше я люблю здравый смысл. Не надо использовать Микросервисы (Agile, DevOps, Монолиты,) как серебрянную пулю!
Банальный анализ нефункциональных требований вроде количества пользователей, планируемой нагрузки или планируемого развития системы, поможет принять правильное решение или убедить вашего архитектора. Или хотя бы снизить ущерб :-)
В следующих выпусках я расскажу, как решить, нужны ли вам вообще микросервисы.
