Как нередко бывает - новое, это хорошо забытое старое. Эволюция инструментов разработки напоминает колебания маятника от универсального мощного инструмента для написания кода и навигации по проекту до визуального конструирования описания процессов из алгоритмических блоков (начиная от блок-схем и заканчивая executable BPMN). Были и остаются популярными среды разработки, включающие элементы визуального проектирования интерфейсов и быстрого прототипирования с использованием готовых компонентов (например RAD-среды от Embarcadero) и конструкторы и среды выполнения BPMN-процессов (например Activiti Engine, Camunda, jBPM и др.) и это в значительной степени стало основой для создания инструментов для разработки low-code приложений.
В то же время наблюдалось движение и в облачных архитектурах, где hosted-решения последовательно заменялись на внешние облачные решения для типовых задач (аутентификация, логирование, хранилища данных и файлов и др.) с постепенной интеграцией возможностей запуска кода непосредственно внутри инфраструктуры облака (Amazon Lambda, Google Cloud Functions и др.).
В этой статье мы рассмотрим один из возможных вариантов организации архитектуры приложения, сконструированного с использованием подходов low-code и запуска приложения и его компонентов в управляемой инфраструктуре.
Low-code инструменты позволяют (через визуальное проектирование потоков выполнения или данных) создавать приложение с использованием готовых компонентов, предлагаемых системой или внешними поставщиками. Кроме этого среда выполнения предлагает автоматические инструменты мониторинга и оповещений и простые способы для развертывания приложений с использованием Docker-контейнеров и Kubernetes. Среди инструментов для Low-code можно выделить Mendix, Neptun Software, Appsemble, Appian, Hypi, Acceleo от Eclipse Foundation, Microsoft Power Fx, AppSheet от Google, Amazon HoneyCode. Вендорные решения имеют простые способы интеграции с соответствующими облачными сервисами и упрощают развертывания разработанной автоматизации на серверы запущенные в Amazon Cloud Computing Services, Microsoft Azure или Google Compute Cloud.
Строительными блоками при создании приложения могут быть визуальные компоненты (с описанием сценариев переходов при взаимодействии с ними), блоки для извлечения данных из внешнего источника, блоки для визуализации информации, управляющие блоки (ветвления и циклы), а также другие сконструированные компоненты, имеющие входные и/или выходные параметры (значения или потоки объектов). Пример доступных блоков можно посмотреть на странице Appsemble Blockstore. Блоки могут соединяться как по потоку выполнения, так и по передаче данных (отдельных объектов - параметров или потоков/событий, если подразумевается конвейерная обработка, например map-reduce).
При использовании облачных инструментов (например, AWS Step Functions) блоки могут взаимодействовать с предоставляемыми провайдером сервисами (например, DynamoDB, SQS, ECS), реализовать сценарии обработки данных Extract-Transform-Load, а также вызывать функции, развернутые на инфраструктуре облака (в этом Amazon Lambda). Но можно ли реализовать подобное на Open Source-решениях, которые не интегрированы в облачную инфраструктуру?
Одним из вариантов решения является запуск собственного кластера Kubernetes и запуск собранного приложения через механизмы развертывания контейнеров от поставщика Low-code системы, для реализации отдельных блоков можно задействовать функции, запущенные через knative (расширение Kubernetes для управления жизненного циклом функций, запускаемых по запросу). Например, такой сценарий возможен при использовании Appsemble (который также разворачивается в Kubernetes и управляет запуском разработанных приложений при возникновении соответствующих событий).
Альтернативным решением может стать использование Open-source инструмента Kumologica. Ключевой особенностью этого решения является возможность интеграции с существующими облаками и использование сервисных абстракций (например, S3 Listener вместо указания конкретного провайдера). Инструмент включает в себя визуальный редактор для разработки приложений Kumologica Designer и среду выполнения, которая интегрируется с FaaS провайдером и координирует выполнение приложений и запуск отдельных блоков при возникновении подходящих условий. Приложение создается из трех типов узлов - входные (внешние запросы или события), стандартные (используются для обработки данных и управление потоком выполнения), выходные (формируют ответ запроса или исходящий поток данных).
Для взаимодействия с облачным провайдером Kumologica использует плагины (например, для AWS), который может быть разработан самостоятельно при необходимости использования неподдерживаемого провайдера. Применяемый Serverless-плагин задается и настраивается в файле проекта serverless.yaml, для разработки собственного плагина (например, публикации в Knative) можно взять за основу ServerlessPlugin.
Использование Kumologica в сочетании с развернутой FaaS инфраструктурой на основе Kubernetes + Knative может позволить решить задачи автоматизации на собственном кластере, при этом для реализации облачных сервисов хранения объектов и обработки событий можно интегрировать open source-решения (например, RabbitMQ, Apache Kafka, MinIO) через специализированные узлы (например, AMQP) или через разработку адаптера (если есть необходимость мигрировать существующий процесс с узлом, разработанным для конкретного облачного провайдера).
На этом все. Всех, кто дошел до конца, приглашаю на бесплатный урок, в рамках которого рассмотрим понятие "состояние". Посмотрим, как работать с диаграммой состояний и переходов. Проведем обзор конечных автоматов и поймем, как от простой реализации объектов перейти к интерфейсам.
