Camunda 7 End Of Life | Кто виноват и что делать?
1. Для кого эта статья
Эта статья будет полезна тем, кто использует Camunda 7, тем, кто думает о переходе с другой BPMS на Camunda, и тем, кто только выбирает BPM-систему. После прочтения у вас будет полное понимание ситуации вокруг Camunda 7. Эту информацию вы можете рассказать своим руководителям, акционерам или задать уточняющие вопросы вашим техническим специалистам касательно ситуации, связанной с Camunda.
2. Краткая история
Итак, начнем с небольшого экскурса в историю. Camunda BPM появилась на свет в 2013 году как форк Activiti. В 2022 году произошел запуск Camunda 8 с полностью переработанной архитектурой. И спустя три года, в октябре 2025, Camunda, заранее всех информируя, прекратила поддержку версии 7 Community Edition. Однако Camunda 7 Enterprise будет продолжать поддерживаться как минимум до 2030 года.
3. Что означает прекращение поддержки?
Camunda 7 зрелый продукт с более чем десятилетней историей, превосходной имплементацией BPMN-элементов, огромным комьюнити и бесчисленным количеством пользователей. За это время ошибок и багов совсем не осталось, и завершение поддержки в первую очередь означает, что вендор не будет закрывать появляющиеся уязвимости. А уязвимости будут появляться, так как Camunda 7 - это классический IT-продукт, использующий другие библиотеки в качестве зависимостей, и в них тоже могут появляться уязвимости. Кроме этого, технологии и библиотеки имеют свойство морально устаревать, что тоже стоит учитывать.
4. Проблема уязвимостей
После того как мы поняли, что означает C7 End Of Life, давайте порефлексируем на тему уязвимостей в C7. Обычно Camunda это лишь небольшая часть в огромных корпоративных системах. Системах, состоящих из готовых проприетарных решений типа 1C, SAP, Bitrix, Colvir, etc; самописных микросервисов на различных технологиях; фронтальных приложений; внешних интеграций; баз данных; множества других технических решений; а также агентов: людей и ИИ.
Проблемы безопасности Camunda надо рассматривать в комплексе. Совершенно очевидно, что фронт атак на web-приложение системы будет в разы шире, чем на Camunda. Фишинг одного сотрудника может дать больше доступа, чем эксплуатация любой технической уязвимости.
5. Моральное устаревание
Вторая проблема с End Of Life это моральное устаревание технологий. И опять все индивидуально: для кого-то важно проходить аудиты и комплаенсы, а значит, нужно поддерживаемое ПО; у кого-то текучка кадров, и всё сложнее с устаревающей технологией; для кого-то важен time to market, а значит, хорошо бы иметь больший уровень абстракции, low-code/no-code возможности и так далее.
6. Что делать?
Теперь попробуем ответить на вопрос: "Что делать?". В любой непонятной ситуации рекомендуется включать голову и думать. Вариантов не так много, но чтобы принять стратегическое решение, хорошо бы располагать реальными цифрами, которые еще нужно правильно посчитать.
Вариант 1: Не делать ничего
Подходит компаниям с низкими требованиями к безопасности и комплаенсу, где Camunda используется для некритичных процессов. Также разумный выбор, если система планируется к выводу из эксплуатации в ближайшие 1-2 года. Важно понимать, что этот вариант не бесплатный: вы накапливаете технический долг и риски безопасности, которые рано или поздно придется закрывать.
Вариант 2: Сделать свой fork и поддерживать его
Этот путь для крупных компаний с сильной технической командой и критичной зависимостью от Camunda 7. Вам понадобятся ресурсы на анализ уязвимостей, обновление зависимостей, тестирование и поддержку. По сути, вы становитесь собственным вендором со всеми вытекающими затратами на команду разработки и инфраструктуру. Может быть дорого, но у вас будет полный контроль.
Вариант 3: Выбрать готовый fork и следить за комьюнити разработчиков
Компромиссный вариант между независимостью и экономией ресурсов. Подходит компаниям, готовым принять риски зависимости от community-driven проекта. Главный риск заключается в неизвестности. Как долго форк будет активно поддерживаться? Насколько быстро будут закрываться критичные уязвимости? Необходимо тщательно оценить активность комьюнити, количество контрибьюторов и прозрачность процессов разработки.
Вариант 4: Текущую систему оставить как есть, а все новые процессы пилить на Camunda 8
Это классический подход называемый strangler pattern. Идеален для компаний с большим количеством legacy-процессов на C7, которые стабильно работают и не требуют изменений. Новая функциональность разрабатывается на C8, старая постепенно выводится из эксплуатации естественным путем. Позволяет растянуть миграцию во времени, но требует поддержки двух платформ одновременно.
Вариант 5: Мигрировать на Camunda 8 полностью
Радикальное решение для тех, кто хочет получить все преимущества современной архитектуры: cloud-native подход, горизонтальное масштабирование, event-driven возможности, штуки, связанные с AI прямо из коробки, быстрый time to market. Требует значительных инвестиций, так как C7 и C8 принципиально разные продукты с несовместимыми API. Подходит компаниям, у которых процессы активно развиваются и требуют современных возможностей оркестрации.
Вариант 6: Мигрировать на другое BPM-решение
Имеет смысл, если вы недовольны стратегией Camunda или функциональность конкурентов лучше закрывает ваши потребности. Миграция на любую другую платформу это всегда большой проект с рисками.
Вывод
Я постарался подсветить основные моменты, на которые стоит обратить внимание и в общих чертах предложить самые основные варианты будущего. Того, что есть в этой статье, недостаточно, чтобы грамотно принять решение о судьбе вашей Camunda 7. Считайте деньги, человекочасы, исследуйте, а эта статья пусть будет минималистичным путеводителем. Надеюсь мне удалось ответить на вопрос, что значит C7 EOL.
Если что, вы всегда можете обратиться к нам за квалифицированной помощью в оценке вашего случая. Проведем аудит, составим детализированный отчет и поможем выбрать решение, соответствующее вашим требованиям.
Полезные ссылки