Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.

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

Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.

«Микро» — это не «нано», микро-сервисы устроены иначе. Не скажу, что знаю рецепт хорошего микро-сервиса. Но я постараюсь показать, каким он точно не должен быть.

Историческая потребность в микро-сервисах.

Разберемся, для чего появились микро-сервисы. Это поможет понять, где «что-то пошло не так», и как это исправить. Обрисуем широкими мазками, с чего все начиналось.

Вначале были монолиты.

Потребности бизнеса росли, монолиты становились всё сложнее. Как следствие — росли и команды.

Когда команда разрастается до десятков разработчиков, поставка ценности практически останавливается. Деление команды на группы помогает не сильно. Координация разработки, тестирования и выкладки монолита — сущий ад. Даже трудности масштабирования самого монолита отходят на второй план. Основная сложность — масштабирование разработки.

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

SOA как ответ на проблему монолита.

В теории SOA — это независимые специализированные сервисы, масштабируемые и управляемые.

На практике же это сервисы, ведущие беспорядочные связи либо напрямую друг с другом, либо через корпоративную шину (ESB). Либо и так и этак. Да ещё в довесок часть бизнес-логики размазана по ESB.

По кулинарной аналогии, SOA превращается в развал разных продуктов. Всё перемешано, где что лежит — не понятно. Чтобы добраться до некоторых продуктов, приходится переворошить всю кучу.

Владеть развалом — дорого. Поддерживать его работу — трудно. Если, к примеру, виноград скиснет, он испортит окружающие продукты. Тогда придется перебирать и перемывать все вокруг.

SOA, которая казалась спасением от монолита, сама имеет ряд критических недостатков. У нее сложные связи: тронете один сервис — придется менять окружающие. Бизнес-логика размазана как по сервисам, так и по шине. Её трудно тестировать, и не менее трудно разворачивать. Все это привело к изобретению нового лекарства: микро-сервисной архитектуры (MSA).

Микро-сервисы — ответ на проблемы SOA.

Микро-сервис — это некий независимо разрабатываемый и развертываемый сервис. Он изолированный и масштабируемый. Он решает конкретную бизнес-задачу. Каждый микро-сервис имеет свой ограниченный контекст и общается через стандартизированный API.

Возможно, ваше определение микро-сервиса будет иным. Это весьма «холиварная» тема. К примеру, в этой статье приведен целый спектр определений от уважаемых людей.

Давайте дадим определение микро-сервису через аналогию: микро-сервис — как блюдо. Про него можно сказать следующее:

• Блюдо изолировано: каждое находится в свой тарелке. Или, если хотите, в контейнере.

• Блюда имеют ограниченный контекст. Плов — это плов, его не мешают с фруктами. Потребитель получает то, за что платит по меню.

• Блюда слабо связаны между собой. После тарелки любого супа можно взять любой гарнир. А можно и не брать. Бывают, конечно, ограничения: не стоит запивать селедку молоком. Но это — исключение.

• Блюда масштабируются. Мало одной котлеты — можно съесть две.

• Блюда легко тестируются. Их можно дегустировать по-отдельности.

• Блюда индивидуально конфигурируются. Можно взять борщ с пампушкой, можно — без.

По описанию получилось вполне съедобно, не так ли? Так почему же внедрение микро-сервисов так редко заканчивается успехом? Я не буду разглагольствовать про неверное разграничение контекста и другие пороки. Про них и так много сказано. Сфокусируюсь на одном.

Корень проблемы — неверная область использования микро-сервисов.

Микро-сервисы применяются не там и не так.

Микро-сервисы задумывались как альтернатива монолиту, который пилят десятки разработчиков. А сейчас все работают по Agile, команды маленькие. Работают или над своим небольшим продуктом, или над частью общего продукта компании.

Продукт (часть продукта) уже имеет изолированный контекст и слабые зависимости. С другими продуктами (частями) общается по API. Имеет свой технологический стек. Владеет отдельным хранилищем (базой). Независимо разворачивается. И даже имеет свою команду «на две пиццы».

По совокупности признаков, он уже микро-сервис! Продукт является готовым блюдом для потребителей. Так же, как этот салатик:

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

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

Если вам вместо трех блюд подадут тридцать ингредиентов в отдельных тарелочках, думаю, вы вряд ли посчитаете это хорошим обслуживанием.

Допустим, вы хозяин ресторана. Хорошее обслуживание может получиться, если

• Каждое блюдо — это блюдо, а не набор ингредиентов в контейнерах. То есть — микро-сервис, а не куча нано-сервисов.

• Есть еще общая солонка, перечница и салфетница. Это — инфраструктурные микро-сервисы. Солонка в тарелке — так себе решение. Не надо их тащить в свой продукт.

• У каждого гостя есть свой стул, место за столом, приборы, и несколько блюд. Получаются железо плюс софт, составляющие информационную систему (ИС).

• У компании гостей есть свой стол, за которым они сидят и едят. Все это образует домен.

• Ну а все, что находится внутри ресторана, то есть совокупность всех этих доменов, формирует корпоративный IT-ландшафт.

Да простят меня корпоративные архитекторы за такую интерпретацию!

Готовьте микро-сервисы правильно.

Многие компании целиком поражены болезнью чрезмерной декомпозиции. То и дело говорят: «у нас 30 команд и 1500+ микро-сервисов». И ведь искренне еще гордятся этим! Забывая рассказать про свои затраты на инфраструктуру. Рассказать, что новый разработчик до полугода погружается в эти сервисы. Что локализация обычного бага занимает у него неделю.

После всего сказанного позволю себе один совет:

Не дробите ваш маленький продукт на нано-сервисы. Это его убьёт.

Он хороший. Дайте ему шанс повзрослеть.