Идея микросервисов не нова. Те, кто постарше, возможно, работали еще с EJB в эпоху их расцвета. Да что там, уже Сэмюэль Кольт использовал модульный подход для производства своих револьверов. Стандартные, прецизионно изготовленные детали его пистолетов были взаимозаменяемы, что существенно упрощало как производство, так и обслуживание. Так почему бы и инфраструктуре не быть модульной?

Принципиальных возражений тому нет, да и сама идея лежит на поверхности. Но популярной тема микросервисов стала сравнительно недавно. И тому есть причина.

Достаточно долго обслуживание инфраструктуры оставалось трудоемкой и достаточно специализированной задачей. Только умельцы-админы могли развернуть в инфраструктуре какой-нибудь кэш или очередь. О том, чтобы у каждой части приложения была собственная инфраструктура, и речи не шло – кто же весь этот зоопарк будет обслуживать?!

Но технологии виртуализации, контейнеров и инструментов управления конфигурацией инфраструктуры шагнули далеко вперед. И сейчас развернуть независимую инфраструктуру под отдельный сервис приложения стало даже проще и дешевле, чем толкаться всеми сервисами в инфраструктуре общей. Прогресс!

Приложение удобно делить на независимые части, в том числе по организационным причинам. При этом взаимодействие между частями осуществляется через тот или иной API. Суть — сервис. Отсюда начинается процесс деления приложения на макросервисы, метросервисы, микросервисы, наносервисы, пикосервисы и однострочные лямбда функции в амазоне.

Казалось бы, что здесь может пойти не так?

Увы, разделение приложение на части – не бесплатно. Прежде всего, возрастает стоимость поддержки API внутри инфраструктуры.

Предположим, в приложении есть необходимость работать с файлами. Типичная задача. Выделяется микросервис, реализующий инфраструктуру файлового хранилища, он предоставляет две операции: чтение и запись. И без существенных изменений в API такой сервис может разрастись от интерфейса к папке на локальном диске до географически распределенной инфраструктуры дата центров. Идеальный сценарий.

Но что если приложение разделить на сервисы таким образом, что нечетные строки бизнес логики окажутся в одном сервисе, а четные в другом? Мало того, что такое разделение сильно замедлит работу приложения, поскольку теперь вместо прямого вызова метода будет происходить сетевая коммуникация, так еще и API между сервисами будет меняться настолько часто, что впору будет выделять long под номер версии API.

Это все, конечно, преувеличение. Однако, оно дает наглядную картину возможных негативных последствий. Приложение, построенное подобным образом, чрезвычайно дорого развивать.

Прежде, чем разделять приложение на части, следует учесть два аспекта

Первый. Как часто эти компоненты будут взаимодействовать в рамках одной операции? Не получится ли так, что на каждое действие придется выполнить сотни, если не тысячи сетевых вызовов. Это может убить производительность приложения.

Второй. Как часто будет меняться API между компонентами? Если история git покажет, что API будет меняться каждый день, стоимость его поддержки, вероятно, окажется запредельной. Это может убить производительность разработки.

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