Почему микро-сервисы редко взлетают?

Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.
Маленькими, изолированными сервисами под конкретную маленькую задачу. Они любят полакомиться чужими событиями. Но они не жадные: поймают одно событие, кинут три. Поодиночке они почти бесполезны. Про них можно слагать анекдоты: «Сколько надо сервисов, чтобы напечатать Hello World?». Поэтому нано-сервисов много, они плодятся как зайчики. Или как маленькие паучки, которые затягивают организацию своей паутинкой.
Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.
«Микро» — это не «нано», микро-сервисы устроены иначе. Не скажу, что знаю рецепт хорошего микро-сервиса. Но я постараюсь показать, каким он точно не должен быть.
Историческая потребность в микро-сервисах.
Разберемся, для чего появились микро-сервисы. Это поможет понять, где «что-то пошло не так», и как это исправить. Обрисуем широкими мазками, с чего все начиналось.
Вначале были монолиты.
Потребности бизнеса росли, монолиты становились всё сложнее. Как следствие — росли и команды.

Когда команда разрастается до десятков разработчиков, поставка ценности практически останавливается. Деление команды на группы помогает не сильно. Координация разработки, тестирования и выкладки монолита — сущий ад. Даже трудности масштабирования самого монолита отходят на второй план. Основная сложность — масштабирование разработки.
По кулинарной аналогии, если вас пятеро — вы еще сможете пообедать из одного котла. А вот когда вас пятьдесят… Для того, чтобы решить проблему «одного котла», была придумана cервис-ориентированная архитектура (SOA)
SOA как ответ на проблему монолита.
В теории SOA — это независимые специализированные сервисы, масштабируемые и управляемые.
На практике же это сервисы, ведущие беспорядочные связи либо напрямую друг с другом, либо через корпоративную шину (ESB). Либо и так и этак. Да ещё в довесок часть бизнес-логики размазана по ESB.

По кулинарной аналогии, SOA превращается в развал разных продуктов. Всё перемешано, где что лежит — не понятно. Чтобы добраться до некоторых продуктов, приходится переворошить всю кучу.
Владеть развалом — дорого. Поддерживать его работу — трудно. Если, к примеру, виноград скиснет, он испортит окружающие продукты. Тогда придется перебирать и перемывать все вокруг.
Пример связи сервисов (очень скучный)
-
Сервис вызывает хранимую процедуру в базе MS SQL.
-
Процедура выполняет некоторые действия и через linked server вызывает другую процедуру на другом сервере.
-
Другая процедура через SOAP (!) дергает ESB.
-
ESB обрабатывает данные, и отправляет сообщение другому сервису.
-
Другой сервис вызывает хранимую процедуру в первоначальной базе для выполнения бизнес-логики.
Только представьте себе удовольствие разбирать инциденты в такой системе.
SOA, которая казалась спасением от монолита, сама имеет ряд критических недостатков. У нее сложные связи: тронете один сервис — придется менять окружающие. Бизнес-логика размазана как по сервисам, так и по шине. Её трудно тестировать, и не менее трудно разворачивать. Все это привело к изобретению нового лекарства: микро-сервисной архитектуры (MSA).
Микро-сервисы — ответ на проблемы SOA.
Микро-сервис — это некий независимо разрабатываемый и развертываемый сервис. Он изолированный и масштабируемый. Он решает конкретную бизнес-задачу. Каждый микро-сервис имеет свой ограниченный контекст и общается через стандартизированный API.
Возможно, ваше определение микро-сервиса будет иным. Это весьма «холиварная» тема. К примеру, в этой статье приведен целый спектр определений от уважаемых людей.

Давайте дадим определение микро-сервису через аналогию: микро-сервис — как блюдо. Про него можно сказать следующее:
-
Блюдо изолировано: каждое находится в свой тарелке. Или, если хотите, в контейнере.
-
Блюда имеют ограниченный контекст. Плов — это плов, его не мешают с фруктами. Потребитель получает то, за что платит по меню.
-
Блюда слабо связаны между собой. После тарелки любого супа можно взять любой гарнир. А можно и не брать. Бывают, конечно, ограничения: не стоит запивать селедку молоком. Но это — исключение.
-
Блюда масштабируются. Мало одной котлеты — можно съесть две.
-
Блюда легко тестируются. Их можно дегустировать по-отдельности.
-
Блюда индивидуально конфигурируются. Можно взять борщ с пампушкой, можно — без.
По описанию получилось вполне съедобно, не так ли? Так почему же внедрение микро-сервисов так редко заканчивается успехом? Я не буду разглагольствовать про неверное разграничение контекста и другие пороки. Про них и так много сказано. Сфокусируюсь на одном.
Корень проблемы — неверная область использования микро-сервисов.
Микро-сервисы применяются не там и не так.
Микро-сервисы задумывались как альтернатива монолиту, который пилят десятки разработчиков. А сейчас все работают по Agile, команды маленькие. Работают или над своим небольшим продуктом, или над частью общего продукта компании.
Продукт (часть продукта) уже имеет изолированный контекст и слабые зависимости. С другими продуктами (частями) общается по API. Имеет свой технологический стек. Владеет отдельным хранилищем (базой). Независимо разворачивается. И даже имеет свою команду «на две пиццы».
По совокупности признаков, он уже микро-сервис! Продукт является готовым блюдом для потребителей. Так же, как этот салатик:

Но нет! Каждая команда считает свой салатик монолитом. И поэтому берет, и делит на микро-сервисы. Что же у нее получается в итоге? Правильно: нано-сервисы!
Вместо того чтобы смешать все ингредиенты и приготовить блюдо, команда любовно расфасовывает ингредиенты по контейнерам. Но все-таки салат — это не то же самое, что запчасти для салата.

Если вам вместо трех блюд подадут тридцать ингредиентов в отдельных тарелочках, думаю, вы вряд ли посчитаете это хорошим обслуживанием.
Допустим, вы хозяин ресторана. Хорошее обслуживание может получиться, если
-
Каждое блюдо — это блюдо, а не набор ингредиентов в контейнерах. То есть — микро-сервис, а не куча нано-сервисов.
-
Есть еще общая солонка, перечница и салфетница. Это — инфраструктурные микро-сервисы. Солонка в тарелке — так себе решение. Не надо их тащить в свой продукт.
-
У каждого гостя есть свой стул, место за столом, приборы, и несколько блюд. Получаются железо плюс софт, составляющие информационную систему (ИС).
-
У компании гостей есть свой стол, за которым они сидят и едят. Все это образует домен.
-
Ну а все, что находится внутри ресторана, то есть совокупность всех этих доменов, формирует корпоративный IT-ландшафт.
Да простят меня корпоративные архитекторы за такую интерпретацию!
Готовьте микро-сервисы правильно.
Многие компании целиком поражены болезнью чрезмерной декомпозиции. То и дело говорят: «у нас 30 команд и 1500+ микро-сервисов». И ведь искренне еще гордятся этим! Забывая рассказать про свои затраты на инфраструктуру. Рассказать, что новый разработчик до полугода погружается в эти сервисы. Что локализация обычного бага занимает у него неделю.
После всего сказанного позволю себе один совет:
Не дробите ваш маленький продукт на нано-сервисы. Это его убьёт.
Он хороший. Дайте ему шанс повзрослеть.
Автор: Gradiens