Микросервисы: что это, зачем это и когда нужно их внедрять

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

Закон Конвея и связь между бизнесом, организацией и информационной системой

Я в очередной раз позволю себе процитировать:

«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
— Melvyn Conway, 1967

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

Бизнес-ориентированность информационных систем

Поясню на примере. Допустим наличие бизнес-возможности по организации бизнеса по продаже пиццы. В V1 версии (назовем ее доинформационной) компания представляла собой пиццерию, кассу, службу доставки. Эта версия была долгоживущей в условиях низкой изменчивости окружающего мира. Затем на смену пришла версия 2 — более продвинутая и умеющая использовать информационную систему в своей основе для бизнеса с монолитной архитектурой. И тут, на мой взгляд возникает вот просто ужасная несправедливость по отношению к монолитам — якобы монолитная архитектура не соответствует доменной модели бизнеса. Да будь это так, система бы не смогла работать вообще -в противоречии с тем же законом Конвея и здравым смыслом. Нет, монолитная архитектура полностью соответствует бизнес-модели на данном этапе развития бизнеса — я конечно имею в виду этап, когда система уже создана и введена в эксплуатацию. Совершенно замечательный факт, что вне зависимости от архитектурного подхода и сервисно-ориентированная архитектура версии 3 и микросервисная архитектура версии N будет работать одинаково хорошо. В чем подвох?

Все течет, все изменяется или микросервисы — средство борьбы со сложностью?

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

Сторонники использования микросервисного подхода часто говорят о том, что разбиение монолита на микросервисы упрощает подход к разработке за счет уменьшения кодовой базы отдельных сервисов. На мой взгляд это утверждение является полнейшим бредом. Серьезно, очевидное взаимодействие в рамках монолита и гомогенного кода кажется сложным? Если бы это действительно было так, все проекты бы изначально строились как микросервисы, в то время как практика показывает, что миграция из монолита в микросервисы является куда более распостраненной. Сложность никуда не исчезает, она просто переходит из отдельных модулей в интерфейсы (будь то шины данных, RPC, API и иные протоколы) и оркестрирующие системы. И это — сложно!

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

Жизненный цикл продукта и жизненный цикл сервиса

Взгляните еще раз на диаграмму выше. Я не случайно отметил уменьшающийся жизненный цикл отдельной версии бизнеса — в современных условиях именно ускорение перехода бизнеса между версиями является определяющим для его успеха. Успешность продукта определяется скоростью проверки бизнес-гипотез в нем. И вот здесь на мой взгляд и закопано ключевое преимущество микросервисной архитектуры. Но пойдем по порядку.

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

Микросервисы как средство борьбы со сложностью… управления конфигурацией

И вот тут мы можем наконец-то перейти к определяющей роли микросервисов — это подход, упрощающий управление конфигурацией продукта. Детальнее говоря, функция каждого микросервиса описывает именно бизнес-функцию внутри продукта согласно доменной модели — а это уже вещи, которые живут не в короткоживущей версии, а в долгоживущей бизнес-возможности. И переход к следующей версии продукта происходит буквальным образом незаметно — вы изменяете/добавляете один микросервис, а возможно и просто схему их взаимодействия и внезапно оказываетесь уже в будущем, оставляя за бортом плачущих конкурентов, продолжающих прыгать между версиями своих монолитов. Теперь представьте себе, что имеется достаточно большой объем микросервисов с заранее определенными интерфейсами и бизнес-возможностями. И вы приходите и строите структуру вашего продукта из готовых микросервисов — просто рисуя диаграмму например. Поздравляю — у вас появилась платформа — и теперь вы можете себе бизнес накликать. Мечты, мечты.

Выводы

• Архитектура системы должна определяться жизненным циклом входящих в нее компонентов. Если компонента живет в рамках версии продукта — нет смысла увеличивать сложность системы, применяя микросервисный подход.
• Микросервисная архитектура должна основываться на доменной модели — по той причине что бизнес-возможность наиболее долгоживущая область
• Практики доставки (практики DevOps) и оркестрации имеют для микросервисной архитектуры одно из важнейших значений — по той причине, что увеличение скорости изменения компонентов предъявляет повышенные требования к скорости и качеству доставки

Источник: habr.com