Как выбрать движок бизнес-процессов после EOL Camunda 7?

В прошлом году прекратилась бесплатная поддержка Camunda 7, платформа больше не будет получать обновления, включая критические исправления безопасности и уязвимостей.

Мы провели масштабное исследование: опросили 74 команды, проанализировали 170+ проектов более чем с 1 000 BPMN-схем и оценили 33 альтернативы.

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

Первым делом мы выгрузили все репозитории и оценили масштаб: Camunda 7 использовали 74 команды более чем в 170 проектах, всего — свыше 1 000 BPMN- и DMN-файлов. Оркестратор стал не просто инструментом, а неотъемлемой частью архитектуры, тесно вплетенной в монолитные системы. Ценность Camunda 7 — в простоте освоения, гибкости и ускорении доставки фич. Но привязанность к существующей платформе создает высокие риски, особенно после прекращения поддержки.

Результаты опроса показали интересную картину. 79,3% процессов на Camunda 7 имеют низкую нагрузку: создаются реже 1 000 инстансов в сутки. При этом средний срок жизни основного процесса — дни и недели, а у более чем половины доходит до месяцев. Это говорит о долгоживущих сценариях: ожидании действий клиента, интеграциях с госсервисами, асинхронных взаимодействиях. Потребность в движке есть, но требования к пиковой производительности не критические.

На основе кастдевов мы выделили 20 ключевых требований. На первом месте — поддержка BPMN как единого языка для бизнеса и ИТ. Также критичны:

• Детальная история выполнения для аудита и диагностики.
• Встроенные механизмы ретраев и отказоустойчивости.
• Версионирование схем без потерь данных.
• Централизованный мониторинг.
• Платформизация — переход от embedded-решений к управляемому сервису (BPMaaS) для снижения операционной нагрузки на команды.

Мы разделили все процессинговые системы на типы:

• Полноценные процессинговые системы (55%) — долгоживущие процессы, требующие полноценного BPM-движка с визуализацией.
• Высоконагруженные микропроцессы (10%) — техническая оркестрация с миллионами исполнений в сутки. Важна производительность, а не BPMN.
• Легковесные и вспомогательные процессы (30%) — MVP или внутренние задачи, где достаточно state machine или легкого оркестратора.
• Low-code-решения (5%) — подходят для небольших команд или новых продуктов с низким трафиком.

Мы рассмотрели 33 решения — внешние (open-source и коммерческие) и внутренние. Отбор шел в 4 этапа: первичный фильтр по стеку, оценка по must-have-требованиям, детальный анализ и PoC на реальном фрагменте процесса. В финале остались три ключевых кандидата: Camunda 8, Temporal и Camunda 7. Также в рекомендации попали узкоспециализированные инструменты для своих ниш.

Мы выбрали многоходовую стратегию:

1. Собственный форк Camunda 7 как буфер для команд, не готовых к немедленной миграции. Позволяет контролировать безопасность, зависимости и дает время на плавный переход.
2. PaaS на базе Camunda 8 и Temporal. Развитие платформы как сервиса с централизованным развертыванием, мониторингом и отказоустойчивостью.
3. Рекомендательный, а не императивный подход. Мы предоставляем командам чек-листы и дерево решений, чтобы они сами выбирали инструмент под свои процессы и требования.

Лицензирование стало ключевым фактором. Zeebe 8.5 распространяется под Zeebe Community License 1.1, которая запрещает продажу как SaaS, но позволяет форк и распространение как self-managed-решение. Начиная с Camunda 8.6, действует более строгая Camunda License 1.0, затрудняющая форки. Temporal пока остается с открытой лицензией. Этот аспект критичен при планировании долгосрочной стратегии и возможной коммерциализации платформы.

Чтобы помочь командам, мы создали двухэтапный механизм. Сначала нужно пройти по вопросам и определить, действительно нужен тяжелый BPM-движок или достаточно state machine или task processor. Затем — выбрать конкретный движок, используя чек-лист со специфическими требованиями (производительность, BPMN, отказоустойчивость). В итоге команда получает сравнительную таблицу и может принять взвешенное решение, а не следовать общему предписанию.

Главный итог исследования — отказ от поиска «серебряной пули». Вместо навязывания единого стандарта мы сформировали экосистему рекомендаций и стратегию платформизации. Это дает командам время на адаптацию, сохраняет гибкость и позволяет выбрать инструмент, который лучше всего решает их конкретные задачи, будь то миграция на Camunda 8, эксперименты с Temporal или поддержка на форке Camunda 7. Часто оптимальное решение — не замена, а эволюция существующего стека.