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