Reining in the chaos, or microservices orchestration in business processes

How are microservices different from a monolithic application?

A microservice is a term that refers to an independent application responsible for a specific business function. In order to create a process that entails more or less complex operations, you will need several such apps (sometimes more than ten).

It follows that if your system consists of more than one process, you will probably need quite a lot of these applications. On the one hand, this approach can create certain management difficulties but, on the other, it will give you much more flexibility in terms of app development. Adding new features will be easier than in monolithic apps, allowing you to deliver business value to your clients more quickly and efficiently.

In a microservices architecture your services can be developed independently by a dedicated team of specialists who can freely choose the tools and technologies to match the problem they seek to solve.

Microservices and complex business processes

Further on, we will focus on how you can use independent services to perform complex business processes, what problems you may come across, and how to address them. To better understand the topic, let us focus on a specific example of, e.g. of a company that repairs telecom equipment. The equipment is delivered to the company by a courier service and the image below shows a simplified template of its services and equipment repair process.

Microservices architecture. Direct communication

Microservices do what they are told to do. And for this purpose, they communicate with other services to get the data they need or share their results.

One of the methods is synchronous communication using REST APIs. Most teams use this approach to create a service communication layer, because it is the simplest, the best known and requires the least amount of planning. Unfortunately, the drawback is that it also involves the tight coupling of services, which means that they are heavily interdependent.

And this is where we get to the crux of the issue: whenever you have many services, they form a strong communication network. As a result, to introduce a new microservice, you might need to modify all the other services that it will communicate with. As a result, any business process change may turn out to be very costly, just like with monolithic architecture.

How can you avoid such problems?

Microservices communication. What to pay attention to?

First, you need to focus on:

• Eliminating the tight coupling of microservices to enable a more independent development of each service;
• Ensuring app reliability, or high availability, but also making sure the app can be quickly restored after a failure (with synchronous communication, the risk is that the app will stop working as a result of an error in just one service);
• Providing a clear view of the business process done by specific services;
• Monitoring the system’s operation for quick and efficient problem-solving.

Synchronous communication. Event-driven architecture

Some issues can be solved by changing your approach to the communication between microservices. Instead of creating a network of services that communicate directly and synchronously, you could consider switching to a less rigid form of so-called event-driven communication. What does that mean?

A service that executes a command communicates that fact to other services. However, the communication is not direct (service → service): the event is not sent to each service but to a so-called queue. This helps avoid a rigid connection between services. The main form of communication involves sending and receiving events from the “queue”, and the microservices do not know who exactly receives the message. Enabling or disabling a service in this scenario is much less costly, since you do not need to modify your other services.

Risks of synchronous communication in distributed systems

The responsibility for high effectiveness, availability and reliable communication here is delegated to an external system (the “queue”). The solution, however, also has some drawbacks. The queue becomes the main site where events are exchanged, which means that your system now has a Single Point of Failure. A failure in this one element may make the whole system incapable of supporting your business process. In addition, you need to put more effort into thinking about issues such as eventual consistency or compensation events.

When switching to asynchronous communication, where each service performs its task upon receiving a specific event (but at the right moment), you need to remember that this approach is not risk-free either. It makes it so easy to create new services and add new features that you might feel tempted to add new steps to the process and lose your grasp of the whole. 

What was once a coordinated choreography now begins to look like a performance of strong individualities. It is only a matter of time before one of the microservices refuses to toe the line and begins to harm your process and data. 

The role of orchestrator in microservices architecture

This is where the orchestrator comes in. One of the services may take on the role of an orchestrator and supervise the entire process. Simply put, the orchestrator sends out a command and once it receives a notification that it has been completed, it performs the next task and sends out a new command to the next service. The orchestrator also monitors whether each service performs its task correctly and, if problems occur, performs the necessary cleanup.

The services are still independent and do not know about one another. They send events to the queue and await them there. The main difference is that the commands that initiate functions are sent by one of the microservices. The responsibility for the whole process rests on a single selected microservice.

Orchestration risks

This solution, just like any other, is not ideal. By designating an orchestrator, you create another bottleneck in the system. Paralysis of one microservice may bring the entire process to a halt.

Adding new microservices means they need to be fitted into the process, which means the orchestrator will also require a modification. By choosing this approach, you slowly begin to lose flexibility; having several versions of the same process complicates development and deployment. It is no longer enough to enable or disable a microservice. You will need to remember about implementing several process paths and making sure each works according to plan.

Microservices architecture and workflow engines

Orchestration also needs support, such as workflow engines, which ensure high reliability, allow you to monitor processes and implement new process versions without having to phase out old ones. Business process management tools make it very easy to use a new service; it just needs to be pinned to a process path. You can do so using visual tools and the process as such is often defined in line with BPMN 2.0 standards.

Solutions of this kind allow you to rein in the chaos created by the uncontrollable growth of the business process.

Workflow engine: Zeebe

One such tool is Zeebe, a free, open-code microservices orchestration management engine, which offers:

• Legibility – every process is built using the ISO BPMN 2.0 standard. The solution allows you to observe the process, mean flow time and errors in real time;
• Orchestration – Zeebe works as an orchestrator. It publishes “events” that can be used by one or more microservices, ensuring process flow progress in accordance with process definition;
• Monitoring – Zeebe monitors delays and other process errors and allow you do define error response paths for errors such as execution retry or escalation to team (you can complete the process manually according to plan).

You can also read about Zeebe in our article: 5 things you should know about Camunda 8

Zeebe. Microservices orchestration

Orchestrating microservices and addressing its issues is the goal of Zeebe. It has achieved this goal thanks to:

• High horizontal scalability – the ability to add new nodes to the system makes them capable of processing even higher loads (linear growth);
• Independence of relational databases – Zeebe saves data in the file system of the server on which it is installed;
• Resistance to failure – thanks to data replication, Zeebe can resume working immediately after a failure is removed;
• Event-driven architecture – events can be exported to external systems to ensure system reports;
• Visual process modelling (ISO BPMN 2.0) – allowing technical and non-technical employees to work together on process definition in a shared language.

Integration with Zeebe can be done in any programming language used in the organisation.

Zeebe. Process tracking and monitoring

For very large systems, the migration of an entire architecture to a new solution may prove very costly, or even inviable. In this case, rather than modifying the entire process and generating high costs, you might want to focus on business process monitoring.

Text BoxYou can use Zeebe to easily integrate your services with the workflow engine and monitor your business process “live”. The solution is largely non-invasive and requires little intervention, and the engine cooperates with the “queues” really well.

The events taken by Zeebe from the queue can be used to create heat maps to show the bottlenecks in the system.

Zeebe. Full microservices orchestration

Still, the best effects can be achieved with a solution fully based on Zeebe technologies.

One option is to use the Zeebe engine for microservices orchestration. Apart from monitoring, it also enables visual process flow definition. New features and microservices can be added independently and non-invasively. Their use is defined in a specific process version and if any issues come up, you can restore them to their previous mode. And you can do all this while enjoying a high of level of security and performance.

Takeaway

Microservices management in business processes is a complicated procedure. If not handled properly, it can land you in a lot of trouble, and further app development might ultimately prove cost-ineffective. This is why the easiest and often the best solution is to use a ready-made process management tool, such as the Zeebe engine discussed in the article.