Is Camunda already “technical debt”?

Organizations that have adopted Camunda are in for a nasty surprise. Camunda, an organization based on a 2013 Activiti fork, has recently raised over $107m from US-based venture capital and Private Equity companies.

The result of this will be a drive toward higher returns and more complex/valuable software. The bad news for customers is that this goes against almost all the reasons why they adopted this component in the first place.

Why organizations choose Camunda

Workflows are hard to visualize, design and implement. The old truism says:

By the time you realise you need a workflow framework, it’s too late…

if-then-else-then-if-then-else handrolled workflow victim

Enter Camunda.

Nice open-source UI for workflows, explainable diagrams, and a pleasant BPMN upgrade process. Architecturally, it’s little-to-no change. Services include some new libraries, make sure there are no version conflicts and you have a nice open-source workflow built in. Developers fight to say they don’t need a workflow engine, then adopt it as it’s not so bad (relatively!).

Camunda makes money by selling additional tooling, consulting, and maintenance. Great, but not a great unicorn business.

Camunda 8 as a platform-centric solution

The direction of travel for Camunda 8 is to move away from the library-based approach of Camunda 7 and towards a remote execution model for workflows. The reasoning is that this enables high scalability for workflows, removing the relational DB bottleneck identified for high throughput services.

The downside is additional complexity around deployment (additional architecture components required) and moving processing outside of microservices.

Existing implementation patterns (JavaDelegate), won’t work anymore. The integration pattern will move to remote execution. This is a major change for microservices as they are now calling out to external services rather than executing in their own context. This could mean multiple Camunda 8 infrastructure deployments if you span multiple security tiers.

We’ve also seen clients integrate directly into the relational database for metrics, this is no longer possible. Again, major software and process changes.

Camunda 8 is looking to simplify connectors, integrations with Lambda functions, and various other quality-of-life tools for workflow modeling. This comes with major additional deployment complexity.

You’re ok for the next 5-ish years

Camunda 7 is going to be supported for at least 5 years as per the organization itself. Companies that have bought into the light-touch workflow approach are inevitably going to be in trouble. There is a ticking technical debt clock that sits in your code that will need to be mitigated. How long you have left until Camunda stops support is down to their own motivations.

Migration mitigations will be:

• All BPMN models need to change to support the Camunda 8 models. The parameters are going to be different and your models are likely to be no longer valid.
• Microservice architectures that use multiple Camunda instances will no longer have the same separation as Camunda 8 is a shared execution model.
• Welcome to the world of gRPC and ElasticSearch. Something you need to fit into your architecture patterns and build knowledge in. Or you could use a cloud offering, not great if your data is highly sensitive.
• Integrations with the REST API need to be migrated. Fundamental changes here will require core changes.
• New additions to your Kubernetes estate, new support, new scaling params, new performance tests…