Микросервисы и оркестратор бизнес-процессов побеждают сложность
Микросервисная архитектура
Эффективность продуктового подхода напрямую зависит от скорости проверки бизнес-гипотез и внесения изменений в бизнес-процессы. Выдерживать такую скорость — непростая задача в том числе и для ИТ-отдела, занимающегося автоматизацией. Ведь в большинстве случаев требуется разработка не запланированных и учтённых в многолетнем плане частей системы, а постоянное изменение вектора разработки, то есть помимо скорости нужна ещё и гибкость. Причём гибкость и самого программного обеспечения, и процессов его создания и поставки.
Грамотно спроектированная микросервисная архитектура позволяет обеспечить требуемую гибкость, готовность к изменениям и скорость поставки в том числе и за счёт борьбы со сложностью. В случае с микросервисами сложность уже не удаётся «замести под ковёр» в больших объёмах кода, с ходу непонятных даже разработчикам — каждый из микросервисов реализует небольшой кусочек функциональности, а значит, содержит минимум кода бизнес-логики. Вся сложность при этом переходит на уровень выше — на уровень архитектуры микросервисов, где её можно визуализировать и работать с ней при помощи паттернов проектирования.
Подробнее о визуализации архитектуры и паттернах:
Подробнее о паттернах проектирования архитектуры:
Для борьбы со сложностью (а значит, для высокой и стабильной скорости поставки изменений) работа системы должна быть визуализирована на всех уровнях — начиная с инфраструктуры серверов и каждого конкретного микросервиса и заканчивая движением доменных сущностей по статусной модели и бизнес-процессам. На каждом из уровней есть практики и инструменты, позволяющие этого достичь. Задача ИТ-команд — собрать всё воедино и учесть специфику конкретного технологического стека, бизнес-стратегии и ИТ-ландшафта конкретного предприятия. Для уровней:
- инфраструктуры — это задача devops-команды и системного архитектора;
- реализации микросервисов — техлида и платформенной команды разработчиков;
- реализации продуктов — solution-архитекторов и кросс-функциональных команд;
- на уровне всего предприятия — enterprise-архитектора.
Подробнее о практиках и требованиях к инфраструктуре и микросервисам:
При успешном внедрении и реализации практик мы получаем, что на каждом уровне есть набор условных «кубиков», из которых легко и быстро можно собирать следующий уровень, не изобретая раз за разом велосипедов и не повторяя уже проделанную ранее работу. Примерами таких «кубиков» на разных уровнях могут быть библиотеки сбора метрик и трассировок, шаблонные репозитории микросервисов, мастер-системы доменных сущностей и шина данных с бизнес-событиями в продуктах.
Если говорить про визуализацию для каждого из уровней:
- инфраструктуры — это трассировки движения данных, графики технических метрик и системная архитектура;
- реализации продуктов — это графики продуктовых бизнес-метрик, solution-архитектура и визуализация бизнес-процессов продукта (например, в BPMN-оркестраторе);
- всей компании — графики метрик целей бизнеса, enterprise-архитектура предприятия и визуализация межпродуктовых процессов в оркестраторах.
Оркестраторы бизнес-процессов
Отдельную роль в борьбе со сложностью выполняет визуализация бизнес-процессов в уже упомянутых оркестраторах бизнес-процессов. Если, к примеру, описать бизнес-процессы BPMN-нотацией и окружить оркестраторы функциональными блоками в виде микросервисов (или целых систем-продуктов, если мы говорим об уровне предприятия) — мы получим визуальное представление работы наших бизнес-процессов. Такое представление будет всегда актуальным, так как код исполняется ровно по представленным схемам. Более того, на схемах мы в режиме реального времени всегда можем отследить каждый конкретный экземпляр объекта бизнес-процесса. К примеру, в каком статусе сейчас какая поставка, где она находится на схеме и чего ждёт по процессу, чтобы двинуться дальше.
Также на BPMN-диаграмму можно нанести тепловую карту нагруженности тех или иных блоков в бизнес-процессах.
Кейс: создание WMS с нуля
BPMN-схемы бизнес-процессов могут быть и весьма объёмными, вложенными и сложными на первый взгляд, особенно для развесистых операционных процессов, таких как, к примеру, автоматизация работы складов, сортировочных и распределительных центров. Такие визуализированные схемы зачастую впервые позволяют объять весь спектр операционных процессов, а их автоматическая генерация в исполняемый код связывает понимание и анализ с тем, как на самом деле на практике работает автоматизация и маршрутизирование бизнес-объектов.
BPMN-схемы из реализованного кейса с WMS для крупного ретейлера
В кейсе с автоматизацией дарксторов, сортировочных и распределительных центров как раз и были реализованы все описанные выше подходы — от создания инфраструктуры и «кубиков» до проектирования микросервисной архитектуры и оркестраторов бизнес-процессов.
Защита архитектуры кейса:
Выделение компонентов и визуализация на всех уровнях — залог гибкости и победы над сложностью
Разделение на части и выделение самостоятельных функциональных блоков позволяет гибко работать с автоматизацией со всех сторон. К примеру:
- В плане безопасности микросервисная архитектура позволяет разделить систему на несколько периметров и контуров, рисками которых можно управлять независимо друг от друга различными стратегиями, соответствующими уровню критичности очерченного контекста сервисов.
- В плане финансовых затрат на облачную инфраструктуру микросервисы позволяют применять FinOps-практики.
- В плане масштабируемости и отказоустойчивости разработчики также вольны применять различные стратегии и подходы к разным частям системы.
Таким образом, микросервисная архитектура способствует гибкой подстройке и поддержке бизнеса со стороны автоматизации. А применение оркестраторов бизнес-процессов усиливает основные плюсы микросервисного подхода и позволяет бороться со сложностью за счёт прозрачности и визуализации не только на технических уровнях, но и на уровне бизнес-процессов конкретных продуктов и всей компании в целом.
Ссылки по теме
- Насколько мелким должен быть микросервис?
- Развитие ИТ-архитектур
От микросервисного монолита к оркестратору
Linux с его ядром и сервисной обвязкой на сегодняшний день одна из самых стабильных OS.
Что нового предложено в подходе с оркестратором?
А НИ-ЧЕ-ГО!