The Rules are Changing: Five Things to Know about your Camunda Production Environment

Abstract

Setting up a Camunda production environment can be a very different experience from traditional BPM applications. In this paper, we’ll discuss why and how you can avoid common pitfalls, optimize your environments for your applications, control resource constraints, and why controlled breakage is a great thing.

https://1c6dba4e-4803-4443-a0a9-c9b19dea5066.usrfiles.com/html/db9376e69cfa487ea0fa0b912ae51a4f_v1.html

Background

The single environment approach is pervasive in legacy systems like IBM, Pega, Appian, etc. In these systems, a single environment is used for all of your BPMN applications. There’s a single logging system to maintain, a single integration layer, and single UI layer, etc.

In other words, it’s monolithic. Everything gets deployed there. It’s simpler to deliver to, simpler to maintain, and requires less interdepartmental jujitsu to reach the databases, environments, etc., that you need.

But this sort of thinking doesn’t work with Camunda and can end up painting you into a corner. This article will explain how to break old paradigms in order to unlock new potential.

Problem Statement

It’s difficult to know how the Camunda Production environment should be built. You have two basic options to start with.

1. A single environment for all applications
2. An environment for each BPMN application.

The first one is what this article will refer to as the “Big Machine”: a single environment to house all of your process applications. The second one will be referred to as a “Micro Machine”, which assumes that every Camunda application gets it’s own server. There is also a middle ground, which will be referred to as a “Fractional Big Machine”, which supposes that multiple Applications will share a Camunda Server. For the purposes of this paper, the Fractional Big Machine and the Big Machine have the same challenges.

Problems with the Big Machine

1. The single environment approach poses issues with optimization. It explicitly limits the ability to provide changes to the server without the possibility of significant adverse impacts to other resident applications.
2. You can’t socially distance one application from another. If you do not establish boundaries for the individual applications, you simply cannot systematically develop in a clean environment and force proper integration practices. For example, a BPM application serves different business functions and units, and those business units have other goals, different leadership, different tolerance for risk, and different evolutionary cycles. What happens when one application wants to embrace a change, and another wants stability? They are separate for a reason.
3. Application evolution becomes more difficult in a single server.
4. Fault tolerance is not inherently designed in a single server environment, requiring extensive root cause analysis when issues arise. When a neighboring department’s application has an infinite loop, for example, they won’t bring you to your knees. Using a multi-server approach can reduce risk, increase adaptation, and generally act as a circuit breaker in case disaster strikes.

The Solution, Build Micro Machines

Every Camunda Application should have its own environment, preferably as a Clustered Spring Boot Application. These can be a cluster of one or bigger clusters. Do not build a single monothetic environment. This is not going to solve your legacy BPM problem. At best, it’s going to move your legacy BPM problem into the cloud but leave it essentially unchanged. That is the opposite of what you need.

Camunda’s literature calls this the micromachine, where each node only has one application, but there is a shared database, as in Fig 1.

Fig 1

I’d go a step further and actually give each application its own database, as in Fig 2.

Fig 2

Optimization Each application

Camunda is designed to be optimized per application. For example: by configuring the Job Executor Thread or configuring External Tasks. The problem is, the heuristics for those optimizations have to do with the nature of your process. Elements such as

1. How often does it execute?
2. How many integrations does it have?
3. What’s its average load?
4. What’s the time to live for processes?

When you cram all your processes onto a single-engine; optimization, by nature, focuses on the lowest common denominator, which is the absolute opposite of what optimization is designed for. Worse, you’ll only get slower and less performance over time since the working model requires making a bad situation worse by adding in new models.

Utilizing the single server approach, risk often arises with competing areas. For example, the Invoice Process can’t take advantage of the new features of Camunda 7.15 because the Accounting Department doesn’t want to risk the steady flow of business that they are experiencing. Both have a legitimate, sincere argument, but they are now in conflict because the architecture has been technically structured. This issue is entirely avoidable and should be.

Customize Resource Constraint

Standing up multiple instances may seem daunting with limited resources, but it’s just a different way of doing the same task.

For example, it’s the difference between serving off the countertop or having a bunch of small plates. The surface area is the same.

The net amount of memory, compute, etc., is essentially the same. Scaling a given application horizontally without having to scale *every* application horizontally, so you’re setting yourself up to save resources. We generally recommend having a clustered Spring boot application for each process, even if it’s a cluster of one running on a container, along with a DB clustered to support each one.

Embrace Reusability

When you reuse a process, you’ve reused the BPMN definition: not its instance. So you can have and reuse a library of shared assets that are deployed to each machine so that you still get reuse, but not at the expense of flexibility. This gives you the benefits of reusability without saddling you with its negative side effects.

Conclusion

Camunda BPM applications are meant to be customized, optimized, scaled, and managed on a per-application basis. Any other usage is unnatural and bound to paint you into a corner. When you start hearing people complain about how the multi-tenancy tables aren’t working as expected, or that the performance can’t be boosted with horizontally scaling, you know you’re headed down a dark path. We invite you to step into the light and do it the easy way.