Микросервисы и монолиты
Коллега написал отличную статью, на тему микросервисов, к которой я написал обширный камент. Возьму на себя смелость расширить и дополнить мой камент, преобразовав его в полноценную статью.
Полностью согласен с тезисами из упомянутой статьи про то что 90% типичных аргументов про преимущества микросервисов не имеют никакого отношения к микросервисам:
Возможность писать на разных языках — уже лет 50 сотни монолитов пишут на разных языках.
Говнокод в микросервисе не перестанет быть говнокодом.
Стейтлес монолиты масштабируются так же хорошо как и микросервисы
и так далее.
Так же полностью соглашусь что микросервисы привносят достаточное количество стандартных сложностей:
Распределенное изменение данных зачастую без ACID гарантий
Более сложная отладка
Проседание перфоманса
и так далее
Но у микросервисов есть одно ключевое преимущество — deploy fast за счет уменьшения единицы деплоймента. Давайте разбираться.
Возьмем классический монолит, которому уже лет 20. Допустим он написан на дотнете и это один солюшн с сотней проектов, которые на выходе собирается в один большой контейнер (докер 5 лет назад прикрутили). Над этим солюшном работают 5–7 команд, у каждой из которых есть манагер, беклог и бизнес заказчик. Все это лежит в одной репе и используется какая то разновидность фичер бранчинга: каждая юзер сторя делается в отдельном бранче которая мержится в девелоп, в котором тагятся релизы.
Для таких проектов, релизный цикл в полгода — это еще хорошо. И главная сложность здесь — это процесс, а не технологии. Во первых надо синхронизировать все команды, чтобы к дате релиза код был стабилен. Во вторых надо сделать полную регрессию такого монолита —, а это код фриз, несколько недель упорной работы QA инженеров, фиксов и тд.
Теперь давайте просмотрим на это глазами бизнеса. Бизнес обычно хочет чтобы его запросы были сделаны вчера. А тут получается что реализацию минимального запроса надо ждать полгода. Естественно это вызывает недовольство.
Как можно оптимизировать процесс. Очевидно, уменьшая единицу деплоймента. Релизный цикл маленькой единицы деплоймента можно резко сократить, минимизируя количество привлеченных людей, объёмы тестирования и т. д. До тех пор пока изменения инкапсулированы в единице деплоймента.
И вот приходят микросервисы. Минимальная единица деплоймента. Микросервис разрабатывает одна команда. Никаких согласований для выкатки. Регресионное тестирование делается за полдня. И как следствие — релиз каждые 2 недели. Бизнес видит результат вот уже сразу.
Но как обычно, за это надо платить. Плата за быстрый релиз каждого отдельного микросервиса — огромный геморрой при изменении контракта. Если мы возьмем описанный монолит, то все контракты у него внутри одного солюшна. Инструменты авторефакторинга позволяют менять контракты как угодно в течении одной минуты. Если контракты где‑то не доменялись корректно — билд солюшна свалится.
В случае с микросервисами это мягко говоря не так. У каждого микросервиса свой релизный цикл. И если команда микросервиса А поменяла контракт, то у команды микросервиса Б (который вызывает микросервис А), свои планы, свои задачи и т. д. У команды В, которая тоже дергает микросервис команды А — своя история. И на практике микросервису А надо поддерживать 2 версии контракта, старую и новую, пока клиенты не перейдут на новую. Это может занять месяцы, и новое, третье изменение контракта уже в планах микросервиса А. Поддержка 3х версий контракта — так себе идея. В реальных больших бизнесах (нетфликс к примеру) — сотни микросервисов, которые вызывают друг друга как угодно. И опять таки приходится всем договариваться при любом изменении в контрактах, писать письма что «через 3 месяца мы перестанем поддерживать версию контракта 1, кто не успел перейти на версию 2 — мы не виноваты».
Из чего следует, что стабильность контрактов — основа успеха проекта с микросервисами. А стабильность контракта достигается правильным разбиением бизнес домена на микросервисы. Правильное разбиение бизнес домена на микросервисы достигается опытом работы в бизнес домене.
Как то так, итоги подведем.
Микросервисы нужны для ускорения релиз цикла в больших и неповоротливых системах. Из чего следует, что если нет и не планируется проблем в длинных релиз циклах — оно вам не надо. Разбив домен на микросервисы неправильно, гарантированно будет много боли с кооперацией микросервисов. Стартуйте с монолита. Там гораздо дешевле экспериментировать с ответственностями модулей и рефакторингов контрактов между ними. Если вы уже в точке, когда релизный цикл не вкладывается в ожидания бизнеса — хорошо структурированный монолит, в котором уже обкатали разбиение ответственности между модулями и их коммуникацию, элементарно бьется на микросевисы.
И да, микросервисы — это про процесс и deploy fast, и только во вторую очередь про технологии.
