Camunda 8 as a revolution in developer-friendly BPM. What does it entail?

Over the years, Camunda has attracted a large number of users because of its flexibility, extensibility and, last but not least, its open source version, thanks to which everyone can obtain the full-fledged process platform. Its motto is to be “developer-friendly” and this approach, imprinted in its architecture, has proven to be a great way to go. The significantly reduced development effort required with its help will reward the organization with long-term cost savings. The use of BPMN and DMN standards as a modelling language then brings good clarity to different roles across the organization, from business to analysts to developers.

Over time, it has become a full-fledged competitor to historically established BPM solutions and indeed a new standard for many enterprises. With the advent and ever-increasing use of cloud services, Camunda says it's time for a change. After several years of development, they have come up with a new version 8, completely redesigned from scratch, which brings with it a number of changes. In short - everything has changed and the service is no longer free.

New architecture - long live the cloud

To understand the basic differences between the older version (7) and the latest version (8), we first need to understand how Camunda actually works. Let's start with a brief summary of version 7.

Camunda up to and including version 7 is provided as a standard Java application. Its core comprises a powerful process engine that communicates with the outside world through a rich REST API layer. Web applications such as Tasklist and Cockpit (management of running processes) are built on top of it. The engine can then either be embedded directly into your application or you can run Camunda as a standalone service and communicate with it via the REST API. The second option may limit your flexibility at first glance, but the provided API is so rich that in our experience you can always get by with it. The advantage is that you have a standard interface for standalone distribution and Camunda itself provides pre-made distributions, for example in the form of a Docker image.

For version 8, deciding whether to go with the embedded or standalone route is easier - the new version can now be run only as the standalone platform with no options to interfere with the application itself. This brings with it certain advantages and disadvantages. An indisputable advantage is the standardization of working with the platform. Where a programmer could do anything in the past, there is now only a universal interface, so the learning curve is shorter in teams working with the platform, and staff rotation and changes are smoother. From the perspective of Camunda, you get simplicity and easy scalability. On the other hand, there is a need to change the mindset where it is not currently customary to operate a process platform in this way.

But that’s not all. Do you have someone who knows Camunda's background, can deploy and edit it? Unless they have already requalified, they don't know version 8 at all. With version 8 comes a new architecture and, most importantly, a move to the cloud. Where in the past, the core was a process engine with a broad REST API over which service applications were built, today’s Camunda is divided more into logical components. The new core - the Zeebe process engine - provides only a narrowly focused gRPC API for general management of process instances and jobs. Events from the engine are stored in internal storage on the filesystem and in Elastic Search in a way known to event brokers (e.g. Kafka).

All of this improves the performance of the platform as such many times over and, thanks to its own protocols, allows for easy performance scaling (performance increases linearly with the number of instances). At the same time, this removes the dependency on relational databases, which were a performance throttle and a source of all sorts of other problems in the older versions. The Tasklist (for task handling) and Operate (for running process management) applications work directly with data from Elastic in the new version and provide APIs (REST, GraphQL) for use in third-party applications, which older versions had directly over the central engine.

What else does the move to the cloud bring?

The transition to the cloud then means that it only makes sense to run the new version in a container platforms environment (Kubernetes, Openshift) or to pay for Camunda Cloud as SaaS. The classic deployment to application servers is no longer applicable for the new platform.

Another point is the process modelling itself - this is simplified on the new platform. More advanced template creation options for process modelers make the job easier and eliminate many potential errors. Add to that the fact that model creation is standardized in the web application, so not on each modeler's local station separately, and you have a more versatile and simpler solution. The enhanced capabilities of forms are then the “icing on the cake” that helps maintain best practices and enterprise standards when the platform is widely deployed. The downside is the lack of ability to create listeners and more complex scripts directly in the process model, which many advanced modelers certainly used in older versions. They now have to do without this and thus create models that are more explicit and easier to read for the layman.

To make it easier to work with the new version, Camunda has also prepared several out-of-the-box connectors that make it easier to integrate with today’s commonly used systems and interfaces (Kafka, REST-API and others). The work of the programmer is then limited only to the so-called Connectors and Job Workers. Simply put, it is software that processes the tasks created by Camunda, which thus becomes a universal orchestrator.

So which version to choose?

If you're not using Camunda yet, or if you're starting a brand new initiative, taking advantage of the latest version is a good first step. However, there will be some “buts”. If you already have an older version and are thinking of migrating, there will be even more.

The new version still lacks something to the maturity of the previous version. Some features are different, others are completely missing and we may see them in the future. On the other hand - some features are new. In some cases, it is certainly possible to use version eight just like seven. If you're primarily looking for a system orchestrator, 8 is ready for you. However, if you are building mainly on human-oriented processes and would like to use the out-of-the-box Tasklist, version seven is the better option for now. However, Camunda is doing their best and is enriching and expanding version 8 at a rapid pace, so this may soon cease to be the case.

However, you may stumble during migration if you “played” with the previous version too much. As already mentioned, version eight relies on simplicity and standardization. So if you've altered your Camunda too much for your specific needs, you'll have to redo everything. If you have your standalone Camunda “as-is” and you have been using the “external task pattern”, you won’t avoid redoing it either, but the situation will be easier. There are also tools for partial migrations, but these cannot be recommended. Experience with similar tools shows that it is always necessary to check the result in detail, which in this case will probably cost you more trouble than redoing everything from the bottom.

The greatest obstacle to the new version? Surprisingly, the price tag.

Version seven offers everything you need for a common process platform for free. Its enterprise version brings added value, mainly in the form of quality of life upgrades, which facilitate long-term operation, but it is possible to do without them. Version eight is simply paid. While there are options to run it without paying, you will only get the platform core as such, without any accompanying apps. Anyone who has ever worked with a process platform knows that without the ability to view the status of a process, for example, it is virtually impossible. Add to that the fact that you'll also be deprived of much of the interface, which will make it necessary to employ developers to program all the necessary additions, which will further require adaptation to each new version. We wouldn't go down that road - there is a reason why the developers at Camunda have been programming all the apps for several years.

The price itself is based on a pay-as-you-grow model and depends on how much you actually want to use Camunda. The important parameters include the number of processes, process instances and users. Individual calculations are available for higher volumes.

Are you considering Camunda? We can help you – including individual pricing

If you are considering the platform, or thinking about migration, we are happy to share our extensive experience in deploying and operating the platform for smaller and larger projects, including complex E2E processes running across many departments. We consider Camunda to be an excellent process engine that, thanks to the BPMN and DMN standards, allows people from business to analysis to development to speak and model in a common language and to connect different departments working on a single common process. We will be happy to help you choose the most suitable option for your processes and needs, and if you opt for the paid platform, we can then provide you with the individual pricing that necessarily comes from the pay-as-you-grow model. Just e-mail jkosina@thetrask.com and open the door to a powerful platform that will save you a lot of work.

Author

Jan Kosina
Head of Intelligent Automation
jkosina@thetrask.com