What to know when Choreographing Microservices with Camunda

Although the definition of a microservice has evolved over the last few years, it is generally accepted that Microservices is a software architecture style. It is based on small building blocks that focus on a single responsibility and function and uses a modular approach to become combining into large complex applications. There is no doubt about it; Microservices are the apex of agile software development.

Microservices provide an alternative to software monoliths and solve many of the issues and bottlenecks caused by the limitations of the monolithic architecture. One major differentiator, from monolithic architecture style, with microservice it is possible to make changes to one part of the application without having to upgrade or redeploy the entire suite of application components. Each microservice module has firm boundaries, can be written using a different programming language, and can independently be managed by different teams.

These abilities of microservices, at execution time, also allow them to be choreographed by an overall Business Process that is managed by a BPM platform solution.

What is the problem with trying to choreograph microservices?

One problem with microservice-based systems is that often use peer-to-peer communication between microservices which can cause a lot of signaling, which when trying to manage these communications, we tend to lose sight of the bigger process picture. This becomes especially problematic when the applications and sub-systems change and grow.

Localized changes that support a tactical solution can fall out of the context of the bigger process, causing a lack of visibility. If you miss the big picture because you’re so focused on the details: that big picture can get real ugly, real fast.

What is the “Microservice Death Star”?

It is exactly that….a lack of visibility, no overall “configuration management”. We lose track of application versions and microservice versions. We need a way to manage the changing way we develop, build, and deploy and execute software, especially the execution of microservice-based software.

The Camunda Process Engine

There are ways to walk around this danger. One Elegant solution is to use the Camunda Process Engine, part of the Camunda Platform, with its support for external tasks which can be used to coordinate these microservices. Each microservice executes as it previously did, you use Camunda to choreograph the sequencing, as well as the signaling. This way, you can get a True Picture of what’s actually happening in the live process instances at runtime by examining the history, which is automatic in Camunda but also use the modeling capabilities of Camunda’s BPMN support to make changes to the interplay between those processes. And when you do make changes, those will be tracked, versioned, etc.