Start your project with Spark
Find a solution that's right for your business, on your terms.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
There's a reason that microservices are a hot topic amongst developers and businesses right now. By using microservices architecture, developers can create a robust application by using separate, smaller, micro components that each do their jobs exceptionally well. Each service is built individually and deployed separately. They run their own processes smoothly and communicate using lightweight, agile APIs. Microservices architecture systems can make these apps extremely versatile and scalable. They're easier to test, understand, and maintain than older, heavier applications where an error in one sector resulted in a domino effect of problems. Building an app out of microservices means that workflows and productivity can continue, even if one microservice runs into difficulties. Moreover, distributed teams can easily create new and stunning applications to facilitate business objectives using the right microservices architecture.
As rosy as that all sounds, however, there will always be problems that need solutions, even with microservices. You can think of many microservices coming together like puzzle pieces to create a wonderful picture; you still need to connect the right parts, in the right order, in the correct direction. Although there is no one perfect solution that's right for every application, you'll definitely know if you've picked the wrong architecture when things start to go awry, and the puzzle falls apart too easily. So, developers and stakeholders need to hash out how to approach the collaboration between a host of microservices. One way to think of this is by comparing how an orchestra works to how a dance company works; hence, the question: how do you choose between orchestration or choreography when formulating microservices architecture?
Putting the Microservices Puzzle Pieces Together Perfectly
Naturally, even great systems have their weak points. Making a microservice application lightweight, agile and efficient means that structure and cooperation between the puzzle pieces are extremely important. Finding the right way to do it requires some thinking through first. That's why you need to understand the differences between the orchestration model and the choreography model. And, as with most things, there are also hybrid models that blend the two ideas. First, let's discuss orchestration.
Imagine yourself on a wonderful night out to hear your favorite orchestra. You watch as all of the musicians settle in, tune their instruments, arrange their sheet music, and prepare for the concert to begin. These are all consummate musicians who know their parts well, but they sit quietly in their chairs, waiting for the conductor. As the lights dim, a hush settles over the crowd for just a moment until the conductor enters the stage to a round of applause. And you understand this: you will not hear one note of the symphony until the conductor gives the signal. He is in charge, and all the musicians must follow his lead and take his directions.
That's how an orchestration approach works with microservices architecture too. This centralized approach requires a hub or "watching point" (a conductor, if you will) for all of the different microservices and their processes. The conductor calls on each microservice to perform a specific action, the results of which are collected. At this point, the conductor calls upon another microservice for another action or requires a rollback. The system is transparent, yes. All of the microservices' separate actions are monitored and "orchestrated" by the hub or conductor.
This tower of strength is also the critical weak point in the system, however. If the orchestra conductor suffers a coughing fit in the middle of the symphony, the music gets muddled. If the controlling point in this microservices architecture hiccups, the entire system will crash and stop working, even if the individual microservices are still intact and functional—just like the excellent musicians, capable of playing their instruments beautifully; they still can't come together to produce the symphony without the guidance of the conductor. The music stops. The application suffers a critical fail.
Of course, orchestras work very well, with a host of expert musicians and a fantastic conductor. The orchestration version of microservices architecture also works very well. It is easy to manage because all business processes are unified and centralized through that central controlling point, or conductor. When the controlling point is well maintained and processing synchronously, the application workflow is efficient, manageable, and stable.
Dependency, however, is the main limitation of an orchestration approach. An orchestrated symphony is a wall of beautiful, intricately layered sound. A well-orchestrated microservices architecture can hum along very effectively, or it can become a monolithic, inflexible structure. When coupled services are dependent upon each other or on the direction from the hub, processes can get gummed up pretty quickly. If service A is down, service B will never be called, and things crash.
In short, there is a lot of pressure on the conductor or the centrally controlled hub point. If that central controlling point fails, everything else fails in return, and the application goes down. Visibility is lost because it's now impossible to track the target business process that the application was supposed to be working on. The symphony grinds to a halt.
Microservices Architecture: Choreography
Now imagine going to the ballet. The music starts (a business process begins), and the highly-trained individual dancers step, twirl, leap, and lift in time to the music and cues they observe from the other dancers. There is no conductor whom they all have to watch for instructions. They just dance. They know what to do if they see a cue from another dancer or hear a specific beat in the music. Still, the incredible dance depends on each dancer's skill and responsibility. It's a decentralized approach.
Likewise, a choreography approach to microservices architecture relies on cues and events that coordinate microservices with each other. Naturally, rehearsal is needed, and cues and events must be defined in advance to get the "dance," or workflow, just right. Instead of requesting actions from other services, each service observes its environment and acts on beats, cues, or events autonomously.
Microservices in the choreography approach are tightly coupled, and they are aware of the other microservices' actions in advance. There are only a limited number of labels or known actions for each microservice to cooperate with, so they each act independently until they detect the defined action.
A choreography approach to microservices architecture accelerates processing because there's no dependency on a central controller. This makes it easy to add, remove, or update microservices without stopping the entire event stream. Because control is evenly distributed, there is no single failure point vulnerability. If one piece fails, the other parts can continue anyway.
This type of architecture works well with an agile delivery model and distributed teams because different teams can work on their microservices (their dance steps) without worrying about the entire application all at once. Teams can try several different architecture patterns. For example, new solutions for event sourcing, where events are stored and event replay, can be tested quite easily. Command-query responsibility segregation (CQRS) can separate read and write activities.
With a choreography approach, complexity is the most pressing issue. You can imagine just how complex it is to coordinate all of the dancers coming together to create the Nutcracker ballet's perfect performance. With each service independently identifying the logic and reacting based on the event stream's definitions, this also requires planning and rehearsal. It takes work to choreograph all of the different microservices efficiently.
In addition, the business process is spread out across multiple players in the system, so it can be challenging to manage and maintain the "big picture" processes. With that in mind, this approach also requires a significant mindset change for many stakeholders who have become accustomed to the orchestration architecture process. Going from a synchronous approach to an asynchronous approach can take some getting used to and might be harder to implement for that reason.
Keeping all of that in mind, there are cases where orchestration is the smartest approach and other instances where choreography is better. Yet, other cases exist where a hybrid approach can be a successful option.
Even though the single-point-of-failure weakness can cause significant problems with microservices, creating a less agile, more monolithic structure, there are some situations in which it makes the most sense. For example, if the system requires up-front validation, along with synchronous requests and responses, orchestration works well. In cases where stakeholders need to see how the business process flows from one end to the other, then orchestration can make it happen. This is especially true when your systems require client blocking behavior. Developers still need to be careful to avoid the brittle "monolith" structure as a result.
If you are building a system that does not require upfront validation for synchronous requests and responses and don't require client blocking, you can consider the choreography approach. Keep in mind that it can be hard to see the entire process from end-to-end in choreography because transactions between microservices are more granular and decentralized. But in many cases, that may be just what you need. Suppose agility and plug-and-play functionality is your central requirement. In that case, leaning toward choreography makes sense, particularly if teams work together upfront to ensure that the microservices respond well to each other's cues.
Creating Microservices: A Hybrid Approach
The hybrid approach to coordinating microservices systems recognizes that you need a well-orchestrated orchestra in the pit to make music for the choreographed dancers on the stage. There are complexities, problems, and benefits for each side, but combining them can create a stunning show or an incredibly useful overall system. In other words, the hybrid model combines a centralized controlling service that manages business processes, while communication between other microservices occurs through events or cues.
A hybrid microservices architecture is easier to manage if the core business process logic is maintained and run from a central location. The process is transparent, so it is easier to see the end-to-end scope of events. That centrality makes it easier to manage, maintain, and monitor. Services that are called up don't require decision logic, so they'll be able to perform an action and return the required response. Processes that require human interactions can easily be supported, as well as can ACID, SAGA, and CRUD.
As you probably guessed, a hybrid solution is far more complex, which means it will probably cost more and take more time to create and implement effectively. Again, you run the risk of the orchestration side, having that single point of failure that can shut the whole system down. On the choreography side, the plug-and-play benefits are real, but seeing and managing the overall process presents challenges and requires that difficult mindset change that comes with teams used to a more centralized system having to adopt a more decentralized approach.
Which Microservices Architecture Approach is Right for Your Project?
The good news is that the approach you choose is independent of your business' size. All three of these approaches have the ability to accommodate very complex projects with the potential for scalability, growth, and increasing complexity. However, you must answer some key questions to arrive at the optimal architecture or combination of architectures. First, ask yourself about the complexity of interactions between the microservices:
As you map the blueprints to build your system, remember that microservices give you the flexibility to choose between which architecture models will best achieve your goals—and you can even mix orchestration and choreography to create a hybrid all your own. A more agile, decentralized system calls for choreography while a centralized, transparent system reaches out for orchestration. Your business processes are unique, so it's essential to get microservices experts devoted to your needs on board from the start. Let's discuss your needs and strategic goals today.
.png)