Camunda 7 или Camunda 8 – что выбрать?

Перед архитектором, решившим использовать Camunda в качестве BPM-системы или как средство оркестрации микросервисов, неизбежно встаёт вопрос – какую версию выбрать?

По состоянию на середину 2024 года, параллельно существуют две отличающиеся друг от друга системы – Camunda Platform 7 и Camunda 8. Рассмотрим каждую из них поближе.

Дисклеймер 

• При подготовке настоящей статьи использовались диаграммы из документации Camunda и Zeebe! 

• Рекомендации в статье основаны на обобщённом опыте специалистов компании и могут не учитывать частные случаи!

• Нетерпеливые читатели могут сразу переходить к сравнению и выводам!

Camunda Platform 7

История появления

Появившись в марте 2013 как форк BPM-движка Activiti, Camunda BPM быстро завоевала популярность среди разработчиков и инженеров. Не последнюю роль в этом сыграли открытость исходного кода, наличие REST API, а также поддержка сообщества специалистов со стороны вендора – компании Camunda.

Постепенно проект стал более «‎живым» и динамически развивающимся, чем Activity.

Росло число клиентов, появились поддержка DMN и Camunda Modeler, были предложены новые способы внедрения системы в ИТ-ландшафт.

Архитектура

С точки зрения архитектуры Camunda является stateless-сервисом, написанным на Java, хранящим свои данные (как рантайм, так и историю) в реляционной базе (PostgreSQL, Oracle, MySQL, etc). 

Camunda может исполняться как часть Java-приложения, так и отдельно: в виде сервиса операционной системы, Docker-контейнера или пода (pod) Kubernetes, что позволяет использовать её как в системах начального уровня (с низким входным порогом экспертизы), так и в высоконагруженных решениях, требующих знания специфических технологий.

Взаимодействие с внешним миром (читай – бизнес-сервисами) происходит через Java API или REST API. Stateless-архитектура приложения позволяет организовать кластер Camunda 7, запуская дополнительные ноды (1+N) и увеличивая таким образом производительность и отказоустойчивость вашего решения. Ноды могут иметь общие (гомогенный кластер) или собственные (гетерогенный кластер) описания процессов. При этом, все ноды будут использовать общую базу данных.

Помимо собственно процессного движка, поставляются также несколько веб-приложений:

• REST API – удалённое взаимодействие с Camunda посредством HTTP-вызовов. Практически все методы, доступные в Java API, доступны и в REST API, что, помимо всего прочего, позволяет автоматизированно тестировать процессы;

• Tasklist – интерфейс для выполнения пользовательских задач (User Tasks), написанный на angular.js (!!!). Несколько архаичный, но достаточно функциональный. Есть богатый выбор технологий для реализации экранных форм пользовательских задач;

• Cockpit – средство мониторинга состояний процессов и обработки инцидентов, возникающих в ходе выполнения процессов;

• Admin – аскетичный интерфейс администратора – управление пользователями, группами, тенантами и авторизациями в веб-приложениях.

Способы внедрения в ИТ-ландшафт

Существуют два основных подхода к встраиванию Camunda 7 в ИТ-ландшафт (опустим Shared Engine как редко используемый).

Только для Java-приложений. Camunda добавляется в приложение в виде зависимости или библиотеки. Для взаимодействия с процессным движком (старт процесса, получение списка задач, завершение задачи) используется Java API. Бизнес-сервисы вызываются через делегаты (Java Delegates), листнеры (Listners), External Task или коннекторы (что менее желательно). Camunda является вызывающей стороной (инициатором).

Делегатный код пишется на Java, может выполняться как синхронно, так и в асинхронно (в фоне), при помощи компонента под названием Job Executor.

Особое удовольствие от использования Embedded Engine получат пользователи Spring Boot – Camunda имеет готовые starter’ы, Camunda Initialzr и предоставляет широкие возможности для интеграции со Spring Framework.

Преимущества: 

• BPM-движок и приложение будут иметь общий жизненный цикл – можно выкатывать одним релизом все обновления (сервисы, Camunda, описания процессов, делегатный код);   

• При использовании микросервисной архитектуры, встроенная в микросервис Camunda позволяет организовать хореографию сервисов – каждый BPM-сервис хранит в себе информацию о том, с кем и в какой последовательности он взаимодействует (в виде описания процесса в нотации BPMN).

Недостатки: 

• Невозможность масштабировать BPM-движок отдельно от сервиса. При росте нагрузки приходится поднимать новые экземпляры, содержащие в себе как бизнес-логику, так и Camunda;

• Разработчики злоупотребляют доступностью Java API, неправильно понимают суть делегатного кода, что, в свою очередь, может привести к деградации производительности;

• Подход Embedded Engine способен затруднить дальнейший переход на Camunda 8 – потребуется менять архитектуру сервисов, избавляться от делегатного кода и листнеров.

Этот паттерн годится для любого техстека: .NET, Java, JS, Python, etc. Данный подход рассматривает Camunda в роли отдельно стоящего сервиса (или кластера сервисов), взаимодействие с которым происходит через сеть, посредством REST API. Camunda является вызываемой стороной.

Используя REST API, внешние приложения и сервисы могут запускать процессы, получать задачи на исполнение, завершать их или сообщать о сбое, получать/устанавливать значения переменных процессов и многое другое. 

Роль делегатного кода здесь выполняют так называемые внешние задачи (External Tasks). Если процесс в ходе своего исполнения встречает задачу, реализованную как External Task, он приостанавливает свое исполнение и создает запись в специальной таблице (act_ru_ext_task).

Воркер (External Task Worker) осуществляет периодический поллинг REST API на предмет появления новых задач нужного типа (топика). При появлении новой задачи воркер помечает её как заблокированную и начинает исполнение.

Принципы работы External Task в целом схожи с Java Delegate – получить задачу и нужные переменные процесса, вызвать сервис или отправить сообщение, после чего – завершить задачу, при необходимости установив значения переменных процесса.

Для того, чтобы максимально упростить внедрение, предоставляется сборка Camunda Run, представляющая собой готовый к использованию дистрибутив или Docker-образ.

Преимущества:

• Асинхронное выполнение задач;

• Сервисы масштабируются независимо от процессного движка (зачастую именно медленный сервис оказывается «‎слабым звеном» процесса);

• Архитектура решения, в случае использования External Task, в целом аналогична Camunda 8, что снизит трудозатраты при переходе на неё.

Недостатки:

• Поскольку Camunda в данном случае является вызывающей стороной, исполнителям-воркерам необходимо осуществлять периодический поллинг REST API. Это может быть неприменимо для коротких процессов, живущих несколько секунд. А сокращение интервала между попытками поллинга неизбежно ведёт к росту нагрузки на процессный движок.

Строго говоря, грань между Embedded Engine и Remote Engine достаточно условная. Можно комбинировать подходы, встраивая движок в сервисы и при этом, исполнять задачи при помощи External Task.

Производительность

Camunda 7 показывает отличную производительность, имеются примеры решений, обеспечивающих одновременное выполнение порядка 1 млн экземпляров процессов и 500 тыс фоновых задач Job Executor.

Ключевым фактором, оказывающим негативное влияние на производительность Camunda 7 (помимо ошибок проектирования) является хранение данных в реляционной базе.

По мере роста числа активных экземпляров процессов растет размер рантайма. Это приводит к увеличению времени выполнения запросов и как следствие – падению производительности. И если проблема роста исторических данных более менее решаема (очистка, запись в Elasticsearch), то бороться с раздуванием рантайма не так просто.

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

Лицензирование

Независимо от подхода к внедрению, Camunda 7 имеет огромное преимущество в виде открытого исходного кода и лицензии Apache 2.0, которая не накладывает практически никаких ограничений на использование. Корпоративные клиенты могут приобрести Enterprise подписку, получив поддержку от вендора, улучшенную версию Cockpit и дополнительное BI-решение для анализа бизнес-процессов (Camunda Optimize).

Поддержка и выход новых версий

Community-версия Camunda 7 поставляется AS IS и пользователи используют её самостоятельно, на свой страх и риск. Исходный код процессного движка доступен на GitHub, новые сборки регулярно публикуются на camunda.com. 

К сожалению, Camunda 7 имеет ограниченный срок жизни:

• Выход новых версий прекращается в октябре 2025 г. – последней версией станет 7.24;

• Далее (вплоть до 2030 г.) предполагается выпуск security-патчей, сначала в рамках полной, затем расширенной поддержек, доступных только Enterprise-клиентам.

Camunda 8, она же Zeebe

История появления

В 2016 году, небольшой командой внутри компании Camunda был начат проект, целью которого была разработка принципиально нового BPM-решения, не завязанного на реляционную базу и обеспечивающего неограниченный уровень горизонтального масштабирования. Так появился Zeebe, долгое время развивавшийся параллельно Camunda 7. Первоначально рассматриваемый как средство окестрации микросервисов, Zeebe был использован в качестве ядра для Camunda 8, представленной в 2022 году.

Архитектура

Ценой высокой отказоустойчивости Camunda 8 стало усложнение архитектуры. 

«‎Сердцем» системы является кластер Zeebe, состоящий из набора реплицирующихся между собой брокеров (Brokers). Каждый брокер хранит описания процессов и исполняющиеся экземпляры в распределенной СУБД RocksDB, представляющей собой хранилище типа ключ-значение (LST-tree). Взаимодействие с внешним миром осуществляется через шлюзы (Gateways) которые могут быть как встроены в брокер, так и работать в виде независимых узлов.

При первом подключении брокер получает информацию о топологии сети и начинает обмен с другими узлами. Данные рантайма шардированы – разделены на заданное настройками число партиций (Partitions). Для каждой из партиций существует 1 лидер (Leader) и N последователей (Followers), которые получают данные от лидера и помещают их в локальные реплики партиции. ​​Каждый брокер кластера является лидером одной партиции и последователем для других. Если по каким-то причинам лидер становится недоступен, происходят выборы и новым лидером становится один из последователей (протокол Raft).

Запуск процессов, получение и завершение задач, отправка сообщений выполняются клиентом (Zeebe Client), компонентом воркера (Job Workers). Воркер, в свою очередь является аналогом External Task Worker в Camunda 7. Взаимодействие клиента-воркера с кластером Zeebe происходит по протоколу gRPC.

Когда клиент-воркер выполняет операцию, информация о ней дописывается в партицию и становится доступна последователям, далее передается экспортеру (Streaming Exporter), после чего клиенту возвращается ответ. Этот же принцип применяет брокер сообщений Apache Kafka – данные дописываются в конец партиции, что обеспечивает высокую скорость операций записи. По-умолчанию Camunda 8 предлагает экспортер в хранилище Elasticsearch, однако, существуют расширения, позволяющие экспортировать поток операций в Kafka, Hazelcast и другие системы.

В качестве отдельных приложений поставляются:

• Operate – его роль в целом аналогична Camunda 7 Cockpit;

• Tasklist – исполнение пользовательских задач;

• Optimize – приложение для анализа бизнес-процессов, теперь входит в стандартную поставку;

• Camunda Identity – управление API, ролями, группами и авторизациями. Использует Keycloak или иной провайдер OIDC;

• Web Modeler – веб-версия Camunda Modeler, обеспечивающая совместную работу над моделями процессов.

Данные приложений (за исключением Web Modeler) хранятся в индексах Elasticsearch.

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

Способы внедрения в ИТ-ландшафт

Единственный способ связывания Camunda 8 с вашими сервисами и системами – использование Zeebe Client. Может использоваться как «‎голый» Zeebe Client (существуют готовые клиенты для C#, Java, JS, Go), так и SDK, представляющие собой удобную обёртку, облегчающую использование клиента (например Spring Zeebe и Node.JS SDK). Если для используемого вами языка отсутствует клиент, он легко может быть разработан самостоятельно.

Клиент может быть встроен в ваше приложение, но чаще используется в виде отдельного сервиса – адаптера к бизнес-системе или консьюмера/провайдера шины событий.

Производительность

При равных условиях, после запуска в эксплуатацию производительность Camunda 8 ниже производительности Camunda 7 с отключенной историей. Однако, по мере роста базы, производительность Camunda 7 начинает деградировать, чего не происходит с Camunda 8 – движок Zeebe практически не имеет пределов масштабирования.

Кроме того, поскольку у разработчика нет доступа к внутреннему API и возможности писать кривой делегатный код – минимизированы ошибки проектирования, часто встречающиеся в решениях на Camunda 7.

Лицензирование

Изначально Zeebe позиционировался как BPM-движок с открытым исходным кодом, единственным ограничением использования которого было условие не создавать облачных BPM-решений, способных конкурировать с Camunda SaaS. Приложения Tasklist, Operate и Optimize могли использоваться бесплатно для non-production стендов, для промышленного использования необходимо было приобретать лицензию.

Начиная с версии 8.6 Camunda меняет лицензионную политику, делая условия лицензирования общими для всех компонентов. Теперь для промышленного использования и веб-приложений и Zeebe необходимо приобретать Enterprise лицензию. 

Non-production использование допускается без ограничений.

Поддержка и выход новых версий

Поскольку Camunda 8 является флагманским продуктом компании, новые версии платформы выходят регулярно. Поддержка Enterprise пользователей осуществляется без ограничений. Zeebe (вне подписки Enterprise) поставляется AS IS как и большинство других open-source продуктов.

Короткое сравнение

Для удобства критерии сравнения сведены в табличку.

Критерий	Camunda 7	Camunda 8
Входной порог и необходимая экспертиза	Достаточно знания BPMN и умения развернуть дистрибутив в нужной исполняемой среде (VM, Docker, etc)	Входной порог достаточно высокий. Требуется опыт экспертиза в части Kubernetes, Helm, Elasticsearch, Keycloak
Архитектура	Исполняемое stateless-приложение (JVM) + реляционная БД (рантайм, история)	Кластер Zeebe (рантайм – распределенная СУБД RocksDB, история – Elasticsearch)
Функциональность	Практически полное покрытие BPMN, кроме редко используемых элементов типа Ad Hoc, Multiple Events, Complex Gateways	Не поддерживаются Conditional Events, Inclusive Gateway (Merging), Transactional Subprocess, Cancel Events, Compensation Start Event
Версионирование и миграция	Система позволяет запускать нужные версии BPMN и DMN, использовать описания форм, разворачиваемых вместе с процессов. Миграция процессов на новую версию может выполняться при помощи Cockpit (только Enterprise), Java API и REST API.	Call Actitivy, Business Rule Task всегда будут вызывать последнюю развернутую модель. А миграция в Camunda 8 пока не реализована. Переносить процессы можно путем создания новых и удаления старых экзмепляров.
Способы внедрения в ИТ-ландшафт	Remote Engine, Embedded Engine, Shared Engine	Только Remote Engine
Масштабирование и производительность	Ограничены, приложение масштабируется путем добавления новых узлов 1+N, при росте рантайма производительность постепенно деградирует	Без ограничений, добавляются экземпляры брокеров, партиции, увеличивается фактор репликации. Нет автоматического масштабирования.
Ошибки проектирования	Часто, из-за злоупотребления Java API и делегатным кодом	Средне
Лицензирование	Apache 2.0 License	Бесплатно только для non-production использования, ПЭ = Enterprise License
Поддержка и выход новых версий	Oct 2025 (v.7.24) – EOL Security patches – Apr 2030 (только Enterprise)	Флагманский продукт Camunda

Выводы

Итак, что же выбрать? 

Вендор предлагает начинать все новые проекты исключительно на Camunda 8 (SaaS  или Self-Managed). 

Наши экспертные рекомендация выглядят следующим образом:

Новые проекты (Greenfield) 

• Небольшая организация или стартап, не имеете собственной инфраструктуры и специалистов, обладающих нужной экспертизой (Kubernetes, Elastic), при этом готовы нести расходы на Enterprise-подписку – выбирайте Camunda SaaS. Это позволит вам эффективно управлять стоимостью владения, при необходимости увеличивая потребляемые мощности.

• Крупное предприятие, имеющее собственную инфраструктуру и специалистов, обладающих нужной экспертизой (Kubernetes, Elastic), предполагается высокая растущая нагрузка (от 1 млн и более активных процессов), есть возможность приобретения Enterprise лицензии – Camunda 8 / Zeebe.

• Не готовы в настоящее время приобретать лицензию или SaaS подписку? Критично использование решения со свободной лицензией? Используйте Camunda 7 Run + External Task (Remote Engine). Это позволит в дальнейшем с минимальными затратами мигрировать на Camunda 8.

• Если три вышестоящих пункта неприменимы, разработка ведётся исключительно в техстеке JVM, требуется хореографировать сервисы – Camunda Embedded Engine. При этом, при написании делегатного кода надлежит следовать лучшим практикам, не перегружая делегаты бизнес-логикой и избыточными обращениями к контексту процесса.

Существующие решения (Brownfield) 

Универсальных решений нет. Критерии, которые следует учитывать, в целом аналогичны критериям для новых проектов. 

Архитектуру необходимо постепенно готовить к Camunda 8 (Java Delegates -> External Task).

Кроме того, стоит принимать во внимание факторы:

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

• Какие усилия были затрачены для разработки решений для мониторинга и отчетности? Все это придется переписывать под Camunda 8.

• Zeebe требует дополнительных приемов для обслуживания (технологические окна либо хитрости для обновления кластера, увеличения числа брокеров, партиций, фактора репликации). Кроме того, кластер Zeebe при росте нагрузки не масштабируется автоматически. Готовы ли вы к этому?

• Затраты на переподготовку и обучение команды.

• Затраты на миграцию (конвертация моделей, перенос экземпляров процессов, переписывание воркеров).

Благодарим за внимание и надеемся, что данная статья была для вас полезна!

А получить нашу помощь по Camunda можно, если воспользоваться формой обратной связи.