When contemplating software architecture, you have probably come across and have experienced microservices within process orchestration which has become the default method for building applications.
The microservices architectural style focuses on developing singular applications to operate as a suite of “microservices”, each running its own processes and communicating with mechanisms such as an HTTP resource API. The applications are built to be deployed independently and designed around business capabilities with automated execution. Centralized management is a component, but only needed minimally.
When referring to microservices, it helps to compare it to the monolithic style of application development where there is a client-side user interface, a database, and the server-side application. From the server side, the application manages HTTP requests, deploys domain logic, receives and updates information from the database, and then selects and displays HTML views through the browser. As a monolith, it is a single executable. If any changes are required then a new version of the server-side application must be built.
The monolithic style has been the “traditional” approach to application development. The application handles requests via a single process and utilizes basic features to divy the app into classes, functions, and namespaces. If you wanted to run multiple instances, you could scale the monolith horizontally behind a load-balancer.
While the monolithic style of application development can garner success, it can also induce obstacles for deploying larger numbers of apps to the cloud. For instance, since change cycles are linked together, any application modification requires a complete rebuild and re-deployment. In time, keeping an organized modular structure becomes much more complex and time-consuming. If your organization wanted to scale business apps, you would have to scale each application – one by one instead of just a single component that needs more resources.
From monolith to microservice
Microservice popularity is due in part to the frustrations associated with the monolith style. Not to mention the microservice style ensures services are independently scalable and deployable with the ability to write different services in different languages. It can also be managed by varying teams. The roots of the microservice style go back to Unix design principles, and are much more efficient in the cloud age.
Product ownership over its entire lifecycle
In the monolith style, once an app is developed it is considered completed. The next step is to transfer ownership to the maintenance team. In contrast, the microservice style encompasses lifetime ownership from the project team who developed it. Think of Amazon’s mantra of, “you build it, you run it.” As a result, the development team has daily management over how their application behaves and handles some of the support tasks. The idea is there is a continuous relationship with the application to ensure it consistently delivers on its intended business capabilities.
In fact, microservice teams often balk at strictly enforced standards. Although it may also depend on how standards are set and enforced. For example, in the corporate world, standards are often developed by teams with little-if-any programming experience. One way to think of this is through the lens of the Domain-Driven Design of Bounded Context. DDD compartmentalizes a complex domain into multiple bounded contexts with a map linking the relationships. The DDD process is beneficial in both monolithic and microservice architectures since it helps to clarify and reinforce separations. However, microservices decentralizes decisions around data storage where each service can manage its own database even if there are different instances. This approach is referred to as Polyglot Persistence. Each service has a specific function and uses a medium for interaction and sharing of data. How? Either through orchestration or choreography.
What is process orchestration?
Much like an orchestra relies on the “conductor” or “orchestrator,” a microservice interaction uses “Process Orchestration” to manage all interactions waiting on a response before requesting the next service. Orchestration follows a request/response paradigm. Here are several benefits with orchestration:
- Easy to manage by centralizing business processes
- Application flow is efficiently coordinated using synchronous processing
What are the limitations? Well, orchestration also creates a type of dependency since it couples services. If service A experiences a failure then service B will not be called. Moreover, if the orchestrator goes down, all processing stops and visibility is lost.
What is choreography?
If your objective is to avoid dependencies and allow each service to work independently, then choreography would be the optimal method. With this approach, services don’t have to wait on instructions – it acts independently. Taking the asynchronous approach, services know what-and-how to react to events. Here are a few benefits:
- Quick processing since services aren’t waiting on an orchestrator.
- Simple to add services or update from the event stream.
- Removes any single points of failure.
- Aligns with an agile delivery model where teams can focus on specific services instead of the entire application.
Choreography seems the logical choice for a microservices infrastructure but there are some limitations including the fact that processes are spread out making it more difficult to manage the entire process. As a result, complexity is a resounding issue.
If you want to understand choreography vs. orchestration, it might help to compare them to real-life examples first. For instance, think about buying a chocolate bar from a vending machine. A basic workflow would involve the following:
- Put money into the machine
- Select your item
- Cabinet emits the candy
- Retrieve your sweet treat
- Take any change (if available)
You can break this down further into three distinct components:
- Payment
- Placing your order
- Item dispatch
Now, let’s imagine the aspects of a garage band – there wouldn’t be a conductor. With the vending machine, every event triggers another action primed for execution. When you insert your money, it activates the machine to allow a selection of snack options. Once you press the button of your choice, the disbursement begins. Each component only works based on the event that has occurred previously.
Unlike a garage band, a conductor is required when an orchestra is involved. Every note played, and how they are played, are guided by the conductor. For this illustration, you may call it orchestration with a conductor or process manager who sequences every event. Therefore, the conductor is aware of the entire workflow. Since the conductor knows all, this individual can also offer status updates – the music always happens on cue.
As in the example of a garage band, many of the members improvise; they work independently and don’t know what will happen next. So, if you’re a business that requires continuous updates, then orchestration would fit the bill. On the other hand, if your organization changes continuously, then choreography would make more sense. Still, they don’t have to be mutually exclusive as they can work together throughout various aspects of different workflows.
Process Orchestration vs Choreography: What are their two modes of interaction?
When a workflow follows a pattern of process orchestration, there is always a point-to-point connection between events – it would be challenging to remove required events because every link is noted. In contrast, the choreography approach means that the events do not “talk” to each other but instead act autonomously. Orchestration requires active control, whereas choreography does not.
When you get to the range of managing hundreds or thousands of processes, it becomes overwhelming to “choreograph.” On a large scale, orchestration makes it easier to monitor all processes at once. Further, human interactions can be inserted easily and quickly.
Imagine a team of dancers performing at an event. They already know their choreography, so they can dance without anyone telling them where to go when to turn, or when to dip. They take the right steps and don’t miss a beat. The performance is asynchronous – when they’re on stage in front of their intended audience, they are no longer waiting on the choreographer. Choreography is the logical choice when tasks do not require synchronous responses and requests.
So then, compare the dance team to processes. Even if one event fails, every other action can continue to proceed as designed. If one dancer misses a jump in the same context, the other dancers can still go on with the performance as if it never happened. As a result, there is much less flux and churn. Each task is connected but also acts independently, which enhances time savings and reduces manual labor requirements. Processes execute faster because they have already been programmed and don’t need active management. The performance is proven and reliable. In essence, orchestration works best in a bounded context where choreography works best in between bounded contexts.
Since services can fail at any given moment, it’s crucial to have procedures in place to determine failures quickly and automate service restoration. It takes real-time application monitoring along with semantic monitoring to receive early warning alerts if anything goes wrong. Further, it’s significantly more important within a microservices architecture since microservice implicitly favors the choreography approach.
Let’s dance: Choreography or Orchestration?
Our answer is both. Utilizing a hybrid of synchronous and asynchronous blocks of processes – orchestration and choreography combined means that the flow is distributed and protected against a single point of failure. Services can be decoupled, to an extent. Blending orchestration with choreography gives you the opportunity to obtain optimized results and tailor each approach to meet the needs of your architecture.
Want to learn more about how a balanced approach can work for your organization? Contact Processmaker today to determine how to dynamically integrate your processes so that you can quickly meet your business objectives.
