Привет, Хабр! Мы — бизнес-линия разработки кредитных продуктов для физических лиц в Т. Нам крайне важно использовать актуальное, безопасное и предсказуемое решение в проектировании бизнес-процессов. Для автоматизации выдачи кредитных продуктов мы используем движок бизнес-процессов Camunda.
В прошлом году компания объявила о завершении бесплатной поддержки Camunda 7. Платформа больше не будет получать обновления, включая критические исправления безопасности и уязвимостей. Для нас, как для финансовой организации, где безопасность, стабильность и соответствие стандартам играют ключевую роль, такой поворот стал серьезным сигналом.
Мы решили проанализировать текущее состояние оркестрации бизнес-процессов во всем банке. Хотели собрать потребности команд и найти подходящие решения, которые будут безопасными, масштабируемыми, надежными и готовыми к изменениям. Мы провели многоэтапный анализ существующих решений и сформировали итоговые рекомендации в виде дерева. В статье делимся тем, что получилось.
Поиск потребителей Camunda 7
В рамках поиска альтернатив мы выстроили последовательную методологию оценки. Сначала определили целевую аудиторию и собрали пул текущих потребителей Camunda 7, чтобы зафиксировать реальные сценарии использования.
Далее сформировали набор критериев и сегментов задач, которые решаются с помощью BPM-движка, собрали функциональные и нефункциональные требования. На основе этих требований составили список возможных альтернативных вариантов. Отобранные кандидаты прошли этап PoC, результаты PoC позволили сравнить производительность, стабильность и эксплуатационные характеристики решений.
Отдельное внимание уделили опыту миграции: скорости перехода, сложности и совокупной стоимости владения. Финальным этапом стала проработка стратегии adoption — внедрение выбранных PoC-решений в продуктовую разработку силами команд.
На диаграмме отражены основные этапы методологии, которые последовательно раскрывают наши этапы выбора решения.
На первом этапе мы выгрузили все репозитории из gitlab, в которых использовалась Camunda 7, и получили данные по компании:
74 команды;
больше 170 проектов;
больше 1000 bpmn- и dmn-файлов.
В итоге у нас оказалось множество проектов по всему банку, которые активно используют Camunda 7. Одна из ключевых проблем — масштабная зависимость от устаревающей платформы. Для большинства команд оркестратор стал не просто инструментом, а неотъемлемой частью архитектуры, тесно интегрированной с крупными монолитными системами. Такая связка давно работает, устраивает многих и сопряжена с высокими рисками при попытке замены — как техническими, так и организационными.
Использование оркестратора обусловлено опытом команд в компании и востребованностью функциональности — в первую очередь, поддержки стандарта BPMN, от которого команды не готовы отказываться. Camunda 7 проста в освоении и гибка в разработке, что позволяет ускорять доставку продуктовых фич в прод, — в этом и заключается ценность, которая сделала ее популярной. Но у платформы есть и существенные недостатки — о них расскажем чуть позже.
Опросы и CustDev-встречи: точка старта для формирования требований
Анализируя масштаб использования Camunda 7 в банке, мы обнаружили, что потребность в оркестрации и автоматизации бизнес-процессов значительно шире, чем предполагали. Это стало поводом расширить исследование и выйти за рамки технического аудита, углубившись в реальные потребности команд.
Наша цель — понять не только что сейчас используется, но и зачем, какие задачи решаются с помощью оркестраторов, и какие инструменты применяются помимо Camunda 7. Особое внимание мы уделили классификации сценариев использования, чтобы отделить критичные процессы от второстепенных и выявить общие паттерны.
Сбор обратной связи проходил в два этапа:
Опросы по всем командам, задействованным в автоматизации процессов.
CustDev-встречи с ключевыми стейкхолдерами для глубинного понимания болей, ограничений и ожиданий.
Наш подход к сбору обратной связи позволил сформировать полную картину — от текущей технической базы до реальных бизнес-потребностей.
Опросы среди команд. Несмотря на солидное преобладание решений на Camunda 7 (87,6%), уже сейчас в Т-Команде есть вариативность использования движков бизнес-процессов.
Внешние решения | Внутренние решения |
Camunda 7 Temporal Camunda 8+ | WFE XBPM CAEN TTM/JES Candy Fork WorkflowCore Shakotis |
Многие из решений — небольшие оркестраторы для локальных командных задач, когда использование полнофункциональных избыточно. Некоторые оркестраторы закрывают ряд проблем оригинальных движков, например самописный TTM/JES, построенный на концепции Temporal, но при этом решающий его проблему с мульти-DC репликацией.
Результаты опроса показали, что наиболее востребованы сценарии с последовательностью из 10 и более шагов, включая делегаты, задачи, активности и точки интеграции. Это подтверждает целевое использование инструмента для управления сложными, многоэтапными бизнес-процессами.
Больше половины команд поддерживает более 10 схем, что говорит о сложности и тяжеловесности бизнес-контекста, который автоматизируется.
Количество созданных процессов в сутки (для основной схемы, без учета подпроцессов) говорит о том, что процессы на Camunda имеют низкую нагрузку — 79,3%. Хотя есть и исключения.
Средний срок жизни основного процесса — дни и недели, что говорит о длительном выполнении внешних задач, таких как ожидание действий клиента, выполнение интеграций госсервисов и партнеров. А более чем у половины процессов срок жизни доходит до месяцев.
Результаты опроса подтверждают: потребность в надежном движке для оркестрации бизнес-процессов у команд есть, но требования к производительности не носят критического характера. Camunda 7 по-прежнему устраивает большинство инженеров из-за простоты и опыта внутри команд.
Отказоустойчивость, восстановление после сбоев, безопасность и работа с историей требуют значительных дополнительных усилий. Это подтверждается количеством инцидентов и объемом кастомных доработок, необходимых для стабильной эксплуатации в продакшен-среде.
CustDev-встречи. Более половины команд стремятся снизить затраты на поддержку и считают важной задачей платформизацию движка: переход от embedded-интеграции Camunda 7 к ее развертыванию как управляемого сервиса (aaS). Такой подход позволяет вынести эксплуатацию за рамки проектных команд, централизовать мониторинг, обновления и бэкапы, сократив операционную нагрузку и снизив риски, связанные с ошибками конфигурации.
Цель — превратить движок в стабильный, предсказуемый инструмент, а не часть прикладного кода.
Многие команды при выборе движка полагаются на заявленные производителем метрики — пропускную способность или время отклика — без проведения собственного нагрузочного тестирования. Они опираются на цифры из документации или презентаций, не учитывая свои потребности в нагрузке, структуре процессов или инфраструктуре. В результате в продакшене возникают узкие места: деградация при росте истории, нехватка IOPS, перегрузка экспортеров. Отсутствие предварительной проверки превращает миграцию или внедрение в серию сюрпризов, которые сложно устранять в эксплуатации.
Статистика показала, что embedded-использование остается доминирующим более чем в 90% команд. Решение хорошо справляется с текущей нагрузкой, которая в большинстве случаев низкая. В таких условиях миграция на Camunda 8 или Temporal выглядит избыточной: экономически выгоднее усилить мониторинг, бэкапы и отказоустойчивость текущей системы.
Ключевым требованием остается поддержка BPMN: стандарт глубоко укоренился в процессах, особенно у аналитиков. BPMN не просто нотация, а единый источник истины в командах, добавляющей прозрачности для инвестигирования проблем в проде. Любое новое решение должно обеспечить перенос существующих схем без потерь.
Опыт других компаний подтверждает сложность миграции. Платформа Flow V от Сбера изначально была построена на Camunda 8. Теперь она развивается как low-code-платформа и минимизирует вмешательство разработчиков, где вся обработка данных, включая маппинги и интерпретацию контекста, реализуется в визуальном редакторе BPMN. Движок отказывается от персистентности в пользу потоковой выгрузки в Kafka. Такой подход обеспечивает удобную интеграцию с аналитическими и ETL-системами, но требует дополнительных решений для восстановления состояния инстансов в случае сбоев.
При выборе движка критичны не только архитектура и производительность, но и практическая реальность: опыт разработки и поддержки, BPMN, нагрузка, операционная сложность.
Клиентские потребности как основа бизнес-требований
В ходе исследования мы собрали более 50 требований от команд и выделили 20 ключевых, сгруппированных по основным аспектам. Категории отражают реальные вызовы при разработке и эксплуатации систем на основе движков бизнес-процессов. Вот их краткая характеристика.
Обработка и оркестрация. Процессы в банке длятся от секунд до года. Движок должен надежно хранить состояние, обеспечивать приостановку, восстановление и консистентность — как для краткосрочных, так и для долгоживущих сценариев.
История и мониторинг. Командам нужен доступ к истории выполнения — для диагностики, аудита и работы дежурных. Желательно, чтобы движок либо хранил историю, либо экспортировал ее, например в Kafka. Отсутствие централизованной трассировки осложняет сопровождение в распределенной среде.
Версионирование. Критично управлять изменениями без потерь. В Temporal разработчик вручную контролирует совместимость, в Camunda можно запускать несколько версий схем одновременно. Это делает Camunda удобнее для команд с активной эволюцией процессов.
Надежность и отказоустойчивость. Важна возможность восстановления без дублирования шагов. Встроенные retry, блокировки и идемпотентность снижают операционную сложность. При этом большинство процессов — низконагруженные, поэтому решения вроде Camunda 8 или Temporal могут быть избыточными. Embedded-подходы зачастую эффективнее и проще в эксплуатации.
Безопасность в современных системах все чаще основывается на принципе zero trust — подходе, при котором ни один запрос не считается доверенным по умолчанию. Camunda 8 поддерживает OAuth2/OpenID Connect, интеграцию с IAM, шифрование, детальный аудит и гибкую авторизацию. Она готова к эксплуатации в защищенных и регуляторных средах.
Camunda 7, напротив, лишена встроенной поддержки современных протоколов, полагается на упрощенную аутентификацию, не шифрует данные по умолчанию и не обеспечивает сквозного аудита. Она становится уязвимым звеном в архитектуре, ориентированной на безопасност��.
Лицензирование и доступность, техническая поддержка и совместимость.
Выбор движка — это не только техническое, но и организационное решение. Важно понимать:
Совместима ли лицензия с нашими требованиями к модификации и развертыванию?
Поддерживается ли движок на текущей инфраструктуре (включая on-premise)?
Есть ли уязвимости в используемых зависимостях?
Кто будет отвечать за мониторинг, обновления и сопровождение — платформа, вендор или сами команды?
Особое внимание стоит уделить долгосрочной поддержке: что произойдет через год-два после внедрения?
Будет ли доступна техническая помощь?
Поддерживается ли обратная совместимость между версиями?
Для ответов на эти вопросы мы сформировали эталонный набор требований, которым должна удовлетворять система.
Функциональные требования — что система должна уметь делать:
Быть готовой к внешним событиям. Например, к ответу от системы или к подтверждению пользователя.
Сохранять контекст между шагами, включая долгосрочные паузы.
Восстанавливаться после ошибок с возможностью продолжения с последнего сохраненного состояния.
Поддерживать проектирование в нотации BPMN как единого языка для бизнеса и ИТ.
Хранить детализированную историю выполнения каждого экземпляра процесса.
Real-time-мониторинг с визуализацией текущего состояния на диаграмме.
Предоставлять UI для управления процессами в рантайме: запуск, остановка, просмотр и модификация.
Поддерживать версионирование бизнес-процессов и плавные переходы между версиями.
Иметь полноценное API для интеграции с другими системами.
Перечисленные функции позволяют строить гибкие, прозрачные и управляемые процессы, понятные как техническим, так и бизнес-специалистам.
Нефункциональные требования — как система должна работать:
Восстанавливаться после сбоев и иметь встроенную поддержку ретраев.
Быть высокодоступной — не ниже 99,8%.
Иметь механизмы аутентификации и авторизации для всех внешних и внутренних запросов.
Поддерживать технологические стеки: Java и .NET.
Быть совместимой с инфраструктурой банка и иметь возможность on-premise-развертывания.
Обеспечивать устойчивую обработку входящей нагрузки, превышающей возможности синхронной обработки на имеющемся аппаратном обеспечении.
Быть масштабируемой при росте нагрузки — как по количеству, так и по сложности процессов.
Активно поддерживаться и развиваться — решение должно быть актуальным.
Иметь качественную документацию и активное сообщество.
Иметь подтвержденный опыт использования в финтехе.
Распространяться под открытой лицензией, пригодной для корпоративного использования.
Перечисленные нефункциональные критерии обеспечивают надежность, безопасность и долгосрочную поддержку решения в реальных условиях банка.
Мы выделили ключевые требования, отражающие реальные нужды команд. Но даже при их наличии единообразного ответа на вопрос «Какой движок выбрать?» пока нет. Каждое решение — это компромисс между гибкостью, сложностью, зрелостью экосистемы и контекстом использования.
Главный вопрос остается открытым: как помочь команде самостоятельно принять обоснованное решение? Мы вернемся к нему после анализа доступных альтернатив и их соответствия функциональным и нефункциональным критериям.
Классификация движков бизнес-процессов
После сбора требований мы классифицировали движки бизнес-процессов по сегменту решаемых задач, чтобы сделать более прозрачным процесс принятия решения по выбору подходящего инструмента.
Существуют различные типы процессинговых систем, различающиеся по сложности, продолжительности жизни процессов и задачам.
Полноценные процессинговые системы — ядро бизнес-логики продукта: сложные, долгоживущие процессы, которые охватывают ключевые сценарии взаимодействия с клиентом. Их особенности:
Высокая сложность (десятки и сотни узлов на схеме).
Длительный жизненный цикл (от нескольких дней до нескольких лет).
Много интеграций (10+ внешних систем).
Большой объем трафика, особенно в критически важных сервисах.
Необходимость гибкого управления состоянием, обработки событий и реакции на внешние триггеры.
Полноценные процессинговые системы составляют 55% от общего количества в Т. Такие процессы требуют максимального уровня наблюдаемости: визуализации прогресса, детального мониторинга, API для управления инстансами и диагностики.
Для их реализации наиболее подходят движки бизнес-процессов (например, Camunda) или гибридные оркестраторы, способные сочетать визуальное моделирование с надежным управлением состоянием и масштабированием.
Легковесные процессы — экспериментальные или MVP-сценарии, создаваемые для быстрой проверки гипотез, пилотирования новых фич или внутренних сервисов.
Они характеризуются:
низким трафиком;
минимальной критичностью (BO/OP-уровень);
потребностью в быстрой итерации и визуальном редактировании.
Легковесные процессинговые системы составляют 15% от общего количества. Их ключевая цель — ускорить delivery и вовлечь нетехнических участников (аналитиков, продукт-менеджеров) в проектирование.
Для них уместны low-code-платформы или легкие embedded-движки, позволяющие конструировать процессы через UI, без глубокого погружения в код. Главное — удобство, скорость и доступность.
Высоконагруженные микропроцессы — технические оркестраторы с высокой пропускной способностью: например, обработка событий, расчеты, синхронизация или триггерные цепочки, выполняемые миллионами раз в сутки.
Особенности:
Короткий жизненный цикл (секунды и минуты).
Минимальная изменяемость после запуска.
Требования к производительности, отказоустойчивости и масштабируемости на первом плане.
Высоконагруженные микропроцессы составляют 10% и редко нуждаются в BPMN-визуализации или сложном управлении версиями. Вместо этого важны предсказуемая задержка, эффективное использование ресурсов и устойчивость к пикам. Для них оптимальны технические оркестраторы, ориентированные на производительность, а не на low-code.
Вспомогательные технические процессы — узкоспециализированные функции, не являющиеся основным флоу продукта. Такие процессы занимают 15% от общего количества, требуют компактности и быстрого запуска и завершения.
Могут включать работу с бизнес-правилами, шедуллинг задач или реализацию паттерна state machine. Часто они реализуются через Task Processors, state machines или BRMS. Их объединяет то, что они не нуждаются в оркестрации на уровне BPMN, но требуют точности и предсказуемости.
Low-code-решения — 5% процессов. Они подходят для небольших команд или новых продуктов с низким трафиком, используемых для тестирования продуктовых теорий, требующих визуализации, удобства изменения, быстрого конструирования процессов через UI и наличия готовых функциональных блоков.
Анализ показывает: единый «универсальный» движок для всех типов процессов — миф. 55% процессов требуют полноценного BPM-движка, но оставшиеся 45% — разнородные сценарии, где более уместны специализированные инструменты: от технических оркестраторов до BRMS- и low-code-платформ.
На этом этапе мы трансформировали свою конечную цель. Теперь наша цель не в том, чтобы выбрать лучший движок, а в том, чтобы сформировать экосистему инструментов, где каждый решает свою задачу эффективно, без избыточности и компромиссов в надежности.
Сбор и анализ решений
После систематизации потребностей команд и типологизации решаемых задач мы перешли к следующему этапу — поиску и оценке доступных движков бизнес-процессов. Цель — не просто составить список альтернатив, а сформировать объективную картину возможных решений, способных закрыть широкий спектр сценариев: от долгоживущих бизнес-процессов до высоконагруженных технических оркестраций.
Мы рассматривали внешние решения, включая open-source и коммерческие платформы, и внутренние разработки, уже используемые в экосистеме Т. Такой подход позволил учесть не только рыночные тренды, но и существующий командный опыт, инфраструктурные ограничения и особенности банковской среды.
В результате первичного сбора мы выявили 33 потенциальных кандидата. Каждое решение прошло четырехэтапную процедуру отбора:
Первичный фильтр по стеку, применимости и совместимости с инфраструктурой.
Предварительную оценку по ключевым must-have-требованиям.
Детальный анализ по полному набору функциональных и нефункциональных критериев.
Практическую проверку (PoC) на реальном фрагменте бизнес-процесса.
В финале отбора осталось пять решений, наиболее полно охватывающих спектр задач, с которыми сталкиваются команды. Они стали основой для дальнейшего сравнительного анализа, стратегического позиционирования и формирования рекомендаций.
Этап 1 — первичный отсев по требованиям:
Стек: необходимо иметь поддержку Java, NET.
Назначение инструмента. Решение должно подходить под определение движка бизнес-процессов или оркестратора.
Возможность применения решения у нас в Т-Команде.
Совместимость с нашей инфраструктурой — насколько возможно и просто можно развернуть решение у нас.
Этап 2 — преданализ по основным 20 must-have-требованиям (масштабируемость, отказоустойчивость, работы с инструментом и другие).
Этап 3 — подробный анализ решений на соответствие всем собранным требованиям. Определяем, какой объем требований закрывают решения.
На третьем этапе проводится анализ по всем требованиям, обязательно предъявляемым к рекомендуемым решениям. Остальные требования являются специфичными для команд, их важность может варьироваться, поэтому они не рассматривались на данном этапе и ушли в рекомендации.
Этап 4 — на основе реального куска бизнес-процесса мы подготовили PoC. Определили реальные, а не заявленные возможности решений удовлетворить требования. Это позволило сравнить решения в одинаковых условиях.
В рамках PoC хотели:
Понять реальную производительность и то, как решения ложатся в нашу инфраструктуру.
Собрать подводные камни и особенности.
Найти точки отказа и масштабирования.
Оценить сложность переноса с Camunda 7.
Миграция на Camunda 8.6 оказалась наиболее простым и плавным вариантом благодаря сохранению знакомого UI и API, поддержке BPMN схем бизнес-процессов. Несмотря на урезание некоторых BPMN-функций (event subprocess, conditional start events, signal events и retryTimeCycle) платформа обеспечивает прозрачность процессов, облегчает онбординг и дежурство, позволяя бизнес-пользователям самостоятельно контролировать процессы.
Кроме того, миграция на Camunda 8.6 позволяет сохранить опыт специалистов по системному анализу при переходе на другую позицию и характеризуется легкостью реализации.
Миграция на Temporal сопряжена с трудностями:
UI кардинально отличается от Camunda 7.
Функциональность UI ограничена, особенно в части редактирования переменных.
В UI отсутствует возможность перемещения токенов.
Нет визуального представления схемы бизнес-процесса.
Логику необходимо описывать в императивном стиле.
Temporal предоставляет готовые решения для обработки ретраев и исключений. Процесс миграции представляется сложным и потребует значительных усилий по переосмыслению и переработке существующих процессов.
Кроме того, в рамках PоC мы провели нагрузочное тестирование многих движков, в том числе Camunda 7, Camunda 8, Temporal, о чем расскажем в отдельных статьях.
Как команде самостоятельно выбрать движок
Рекомендуемые решения закрывают потребности кластеров команд, собранные на основе глобального ресерча по банку. Каждое решение имеет свою роль и нацелено на закрытие конкретной потребности.
В рекомендации попало два типа решений на основе классификации движков выше:
Решения, не являющиеся движками бизнес-процессов или оркестраторами, — субпродукт исследования, не является основной целью рекомендаций.
Движки бизнес-процессов или оркестраторы — несколько решений, каждое из которых закрывает свою нишу.
Мы подготовили дерево принятия решений, которое состоит из двух частей, работа с каждой частью происходит по разным правилам. Существует три компоненты, чтобы выбрать подходящее решение: вопросы анкеты, рекомендуемые решения и группа решений.
Выбор группы подходящего решения. При выборе группы решений нужно пройти по ряду вопросов и понять, действительно ли нужен движок бизнес-процессов.
Выбор движка бизнес-процессов. Здесь происходит самое интересное: выбирается движок бизнес-процессов, который удовлетворяет потребностям и прошел предыдущие этапы. На диаграмме изображена лишь часть этих требований к системе, но большинство их них мы уже обсуждали.
Помимо того, что мы просто отвечаем на вопросы, еще заполняем чек-лист специфических требований: например, производительность, отказоустойчивость, доступность. Получается таблица из ряда требований для каждого движка.
В результате второго этапа получается чек-лист с отмеченными в таблице критериями, наиболее важными для команды. Когда рекомендации сформированы, нужно изучить таблицу и выбрать наиболее подходящее решение.
Где один движок, который сразу закроет все мои требования, и я пойду счастливый пить кофе с печеньками и завозить движок в свою инфраструктуру без лишних хлопот? Ответ: мы собрали рекомендации, которые позволят командам подобрать движок бизнес-процессов под их потребности и самим решить, какой продукт больше подходит, исходя из требований.
Определение и классификация требований — одна из важных задач в процессе выбора движка, и командам нужно самим понимать: нужен BPMN или нужна система, которая обрабатывает миллионы процессов в день, или нужна система, способная выдерживать 99% отказов? Возможно, нужна небольшая библиотечка для запуска 10—20 процессов в день — тогда, может, и оркестратор не нужен? Насколько длительны и сложны процессы или они отрабатывают парой команд? Может, подойдет TaskProcessor или достаточно скриптом раз в день вызывать процесс кроном?
Нельзя навязывать один инструмент командам, если только нет строгих требований от компании по использованию чего-то конкретного. Мы планируем развить тему автоматизации и сделать выбор движка бизнес-процессов более прозрачным. Есть планы по написанию бота в корпоративном мессенджере на основе RAG, который у нас сейчас активно популяризируется.
Стратегия. Форк и платформизация
Мы говорили о том, как систематизировали требования и отбирали решения. В финале остановились на трех ключевых кандидатах: Camunda 7, Camunda 8 и Temporal. Давайте поймем, почему они рассматриваются, какие преимущества и риски несет каждый путь и как они соотносятся с нашим контекстом.
Camunda 7: зрелость, но EOL на горизонте. На сегодняшний день Camunda 7 остается инструментом, покрывающим большинство потребностей команд. По нашим оценкам, она удовлетворяет около 99% функциональных и нефункциональных требований. Это не случайно: за годы использования получен большой опыт, разработаны внутренние библиотеки, практики и low-code-подходы, которые делают его не просто движком, а целой экосистемой.
Ключевой факт: Camunda 7 объявлен устаревшим (EOL). Поддержка прекращается, обновления безопасности больше не выходят, а развитие функционала остановлено. Это создает критический технологический долг и повышает риски эксплуатации в продакшене.
Решение: форк Camunda 7. Один из возможных путей — создание внутреннего форка. Это не новаторская идея: на GitHub уже существует более 1700 форков Camunda 7, что говорит о востребованности такого подхода в индустрии.
Но вопрос не в технической возможности, а в сопровождении. Кто будет поддерживать этот форк? Кто будет вносить исправления, обновлять зависимости, патчить уязвимости? И главное — нужно ли изобретать велосипед, если можно использовать open-source-альтернативы?
В условиях текущих потребностей команд мы выбрали путь создания собственного контролируемого форка Camunda 7, развиваемого платформенной командой. Цель — не просто «продлить жизнь» движка, а вынести его в open source, сформировать прозрачный процесс развития и при необходимости позволить другим командам участвовать в его эволюции. Это не отказ от миграции на другие решения, а стратегический буфер, дающий время для плавного перехода, не принуждая команды к резким изменениям. Решение обусловлено тем, что:
Наша экосистема Camunda не просто использование движка, а сложная сеть кастомных решений, встроенных в процессы, CI/CD, мониторинг и безопасность. Интеграция с внешним форком потребует переписать или адаптировать весь стек, что дороже, чем развитие собственного.
Мы не можем зависеть от чужой дорожной карты. Наш бизнес-ритм, приоритеты и SLA требуют полного контроля над темпом, содержанием и стабильностью изменений.
Только собственный форк позволяет гарантировать, что каждая зависимость прошла внутренний security review, соответствует политике compliance и может быть аудирован в любой момент.
Мы рассматриваем форк не как временное решение, а как основу для будущей внутренней workflow-платформы, которая может вырасти в независимый продукт с уникальными возможностями, недоступными в Camunda 7/8 или любых сторонних форк’ах.
Избежание vendor lock-in и лицензионных рисков. Любой внешний форк — это новый вендор. Мы не хотим новой зависимости.
Мы не просто выбираем форк — мы выбираем независимость. Внешний форк — это иллюзия экономии. На самом деле он создает новую зависимость, риски и технический долг. Наш собственный форк — инвестиция в контроль, безопасность, предсказуемость и будущее.
Camunda 8 и Temporal: путь к PaaS. В параллель с поддержкой Camunda 7 мы развиваем стратегию платформы как сервиса (PaaS) на базе двух современных решений: Camunda 8 и Temporal.
Цель — не просто внедрить движки, а предоставить командам готовую, масштабируемую, надежную и легко сопровождаемую платформу, включающую:
автоматизированное развертывание;
централизованный мониторинг и алертинг;
управление версиями и безопасностью;
поддержку кросс-датацентровой отказоустойчивости;
инструменты для диагностики и дежурства.
Camunda 8 — логичное развитие экосистемы Camunda. Она предлагает:
современную архитектуру на базе Zeebe;
поддержку BPMN с визуальным моделированием;
прозрачность процессов для бизнеса и аналитиков.
У нее есть ограничения: некоторые BPMN-конструкции больше не поддерживаются, а коммерческая лицензия накладывает ограничения на возможность распространения внутреннего форка.
Решение — использовать компоненты Zeebe и собственный control plane, оставаясь в рамках разрешенного использования, но реализуя PaaS-подход самостоятельно. При проектировании фасада между потребителем и BPM as a Serviсe в рамках платформизации Camunda 7 можно закладывать бесшовную миграцию для пользователей восьмой версии.
Temporal — мощный инструмент для технической оркестрации. Его сильные стороны:
встроенная отказоустойчивость;
гарантированное выполнение;
поддержка долгоживущих workflow;
отличная производительность.
Его известная проблема — ограниченная поддержка мульти-DC-репликации. Кроме того, для решения некоторых потребностей он излишне дорог с точки зрения инфраструктуры (ее стоимости и сложности). Это критично для нас, так как требует высокой доступности и сложного DRP.
Развитие Temporal как PaaS позволяет решить эту проблему на уровне платформы — за счет интеграции с внутренними механизмами репликации, бэкапов и управления конфигурацией. То есть мы берем сильный инструмент, дорабатываем и делаем его enterprise-ready.
Риски & открытые вопросы
Выбор стратегии, основанной на поддержке нескольких решений, включая форки, внутренние платформы и коммерческие продукты, неизбежно влечет за собой сложные архитектурные и правовые вопросы. Одним из ключевых становится лицензирование: оно уже не просто юридическая формальность, а фактор, напрямую влияющий на стратегию развития, эксплуатацию и коммерциализацию.
Разберемся, как лицензионные модели Camunda 7, Camunda 8 и Temporal влияют на наши возможности — от форков до создания платформы как сервиса (PaaS).
Начнем с Camunda 7. Как мы выяснили, сейчас довольно много форков этого движка, но что самое важное — лицензия. Недавно рекламировали очередной форк Camunda 7, но ситуация на рынке только набирает обороты после EOL Camunda 7 и дает нам шанс задуматься насколько хорош этот форк и есть ли альтернативные варианты, которые распространяются свободно? Не проще ли компании поддерживать свой форк, нежели платить за решение, которое будет редко дорабатываться, но приносить убытки?
Camunda 7 действительно очень хороший продукт и подходит многим командам. За более чем десятилетний опыт в этом движке многое доработано и переработано, уязвимостей стало меньше и сами разработчики платформы не просто так создали новую версию Camunda 8. Инженеры осознали, что есть текущие проблемы в архитектуре «семерки» и стараются идти в ногу со временем, изобретая новые велосипеды инструменты для устранения предыдущих проблем архитектуры.
В отличие от Camunda 7, новые версии Camunda ( > 8.5) не позволяют форкнуть и продавать решение как aaS без ограничений. Начиная с версии 8.6 сам движок Zeebe стал платным. Отметим, что под лицензию попало именно ядро камунды — сам движок Zeebe, остальные компоненты и ранее были платные (например, Operate, TaskList и т. д.).
Исходный код Zeebe 8.5 распространяется под двумя основными лицензиями.
Лицензия Zeebe Community License Version 1.1 применяется к большинству компонентов движка.
Лицензия Apache License, Version 2.0 используется для списка компонентов:
Java Client (clients/java);
Go Client (clients/go);
Exporter API (exporter-api);
Protocol (protocol);
Gateway Protocol Implementation (gateway-protocol-impl);
BPMN Model API (bpmn-model).
Перечисленные компоненты полностью открыты, в то время как остальная часть кодовой базы Zeebe 8.5 регулируется условиями Zeebe Community License.
Развеим мифы о Camunda License 1.0. Несмотря на то, что при беглом взгляде на основную ветку репозитория (main) и документацию может сложиться впечатление о применении Camunda License 1.0 к Zeebe 8.5, это не соответствует действительности.
Camunda License 1.0 вступила в силу только с версии Camunda 8.6, выпущенной в октябре 2024 года. Zeebe 8.5, релиз которой состоялся в апреле 2024, распространяется под Zeebe Community License Version 1.1. Это подтверждается:
Официальной документацией Camunda, указывающей, что информация о лицензировании относится к версиям 8.6 и выше.
Содержимым ветки release-8.5, где явно указана Zeebe Community License Version 1.1.
Основная ветка репозитория (main) обычно содержит последнюю актуальную версию, а здесь мы видим снепшот для 8.9.
Подтверждением от Camunda AI.
Лицензия Zeebe Community License Version 1.1 предоставляет широкие возможности использования и модификации программного обеспечения:
Использование, копирование, модификация, объединение, публикация и распространение.
Сублицензирование и продажа копий.
Создание производных работ.
Распространение как в виде исходного кода, так и в скомпилированном виде.
Использование в коммерческих целях.
Основное ограничение Zeebe Community License Version 1.1 касается коммерческого использования:
Запрещена продажа Zeebe как сервиса (aaS) или облачного решения (SaaS).
Разрешена продажа форка в виде self-managed-решения (например, on-premise).
При форке Zeebe 8.5 необходимо учитывать лицензионные ограничения. Можно форкать и распространять только компоненты, лицензированные под Apache License 2.0. Использование компонентов, регулируемых Zeebe Community License Version 1.1, в SaaS-решениях запрещено.
Почему не стоит сразу переходить на Camunda 8.6+. Версии Camunda 8.6 и выше предлагают ряд улучшений, которые могут повысить производительность и надежность движка, особенно в контексте self-managed-решений:
Long pooling на стороне сервера для улучшения отзывчивости и снижения нагрузки на кластер.
Elasticsearch в режиме HA, который обеспечивает высокую доступность с тремя репликами по умолчанию в Helm-чарте.
Flow Control с backpressure для повышения стабильности при высоких нагрузках.
Улучшенные RTO/RPO, которые служат для отказоустойчивости и повышения скорости восстановления (актуально для SaaS).
Из-за более строгой лицензии Camunda License 1.0 использование версий 8.6+ для форка и последующего распространения может быть затруднено.
Zeebe 8.5 представляет собой жизнеспособную основу для форка, особенно для создания self-managed-решений. Важно тщательно учитывать лицензионные ограничения и сосредоточиться на компонентах, лицензированных под Apache License 2.0. Хотя более новые версии Camunda предлагают интересные улучшения, их лицензионные условия требуют дополнительного анализа перед принятием решения о переходе.
Temporal приносит немного свободы в плане лицензирования, так как открыт для модификации и расширения, но есть риск (как и у любого продукта), что появится лицензия.
Помимо рисков есть ряд открытых вопросов на обсуждении.
Будущее BPMN: необходимость или наследие? Один из самых дискуссионных вопросов — роль BPMN в современной оркестрации.
С одной стороны, BPMN остается ключевым инструментом для системных аналитиков, QA и бизнеса: он обеспечивает визуальную прозрачность, упрощает согласование логики и становится единым источником истины для нетехнических ролей.
С другой — многие современные решения (включая Temporal и ряд внутренних разработок) отказываются от BPMN в пользу кода. Разработчики ценят императивный подход: он дает полный контроль, упрощает тестирование и интеграцию с CI/CD.
Отказ от BPMN не просто техническое решение, а смена парадигмы: от визуальной моделировки к code-first. Это открывает путь к более гибким и производительным инструментам, но ставит под вопрос вовлеченность бизнес-участников процесса.
Можем ли мы позволить себе потерять коммуникационный мост между бизнесом и разработкой? Или стоит развивать гибридный подход — например, генерацию кода из схем или обратную визуализацию workflow?
Безопасность: рост зрелости платформы от вендора. С точки зрения безопасности Camunda 8 предлагает более современную и защищенную архитектуру, чем Camunda 7. У нее есть централизованное управление доступом, поддержка OIDC и интеграция с IAM-системами, более строгая изоляция компонентов и гибкие политики аудита и логирования.
В условиях строгих требований банковской сферы все эти механизмы безопасности, которые поддерживает Camunda 8, — значительное преимущество. Оно должно быть сопоставлено с ограничениями лицензии и возможностью кастомизации.
Лицензионная модель: свобода против контроля. Еще один важный аспект — лицензирование движков. Camunda 7.23 доступна под Apache 2.0, что позволяет свободно модифицировать, развертывать и даже распространять ее — в том числе в составе собственных продуктов.
В то же время Zeebe (ядро Camunda 8) распространяется под ограничительной лицензией, запрещающей использование в open-source-проектах и продажу решений как сервиса (aaS). Это создает барьеры для внутреннего open-source-движения и построения независимых экосистем вокруг решения. А еще лишает перспектив коммерциализации платформы.
Вопрос: готовы ли мы мириться с vendor lock-in ради удобства и зрелости платформы? Или стоит инвестировать в альтернативы с открытыми лицензиями?
Выводы
В ходе масштабного исследования мы пришли к одному ключевому пониманию: единое «правильное» решение для всех команд — это иллюзия.
Вместо того, чтобы навязывать единый стандарт, мы сформулировали рекомендательный подход, который позволяет каждой команде сделать осознанный выбор исходя из контекста: типа процессов, уровня зрелости, состава участников и долгосрочных целей.
Мы не можем и не должны запрещать использование Temporal, если команда работает с высоконагруженными техническими микропроцессами и не нуждается в BPMN. А когда у продуктовой команды фокус на скорости доставки ценности в прод, продумывание обратной совместимости при доработке каждого шага выглядит как дополнительная нагрузка на этом пути.
Подавление инициативы и блокировка альтернатив приводят к застою. Наша задача — не ограничивать, а направлять, вдохновлять и обеспечивать поддержку.
Что мы сделали:
Провели всесторонний анализ более чем 30 решений — от open-source-движков до коммерческих платформ и внутренних разработок.
Оценили их по функциональным, операционным и организационным критериям, выделив сильные стороны, ограничения и точки роста.
Сформировали карту соответствия решений типам процессов, чтобы помочь командам выбирать осознанно.
Выявили малоизвестные, но перспективные инструменты, ранее не рассматривавшиеся в банке, и дали командам повод задуматься: а что, если попробовать?
Провели ревью внутренних решений, оценив их зрелость и потенциал для масштабирования.
Мы определили для себя стратегические векторы развития:
Оценка и развитие форка Camunda 7 как первый шаг к платформизации BPM as a Service,тем самым предлагаем стабильное решение командам, не готовым к миграции.
Формирование PaaS-платформ на базе Camunda 8 и Temporal — с акцентом на удобство, отказоустойчивость и централизованное сопровождение.
Поддержка экспериментов с альтернативными и внутренними решениями, чтобы не терять инновационный импульс.
Представленные рекомендации — не окончательный приговор, а точка входа, отправная платформа для диалога. Они призваны помочь командам:
Понять, что есть за пределами привычного стека.
Оценить архитектурные trade-off.
Принять обоснованное решение, а не действовать по шаблону.
Мы не диктуем путь — мы помогаем его найти. А какой путь выбрали вы? Оставляйте вопросы и фидбэк, будем рады услышать мнение и интересные идеи.