Monolithic architecture, once heralded as the best (and only) path forward for building an IT infrastructure, has lost its place at the top.
The cloud computing revolution came with its approaches to development and that led to development by way of microservices. Much like a tiger team of specialized developers, each microservice plays a unique part yet works in harmony to produce an end product of efficiency and resilience.
Applications built upon this monolithic architecture found themselves struggling to keep up with the pace, unable to adapt swiftly to changes. There’s a solid reason that makes microservices the most popular choice for development and it comes down to one word: communication.
Let’s delve into the world of microservices to find out how flexibility in communication is transforming the development landscape and forming a critical backbone for an efficient process automation system.
The importance of communication between microservices
Monolithic architecture might offer simplicity and efficiency but it can, and likely will, present many challenges in terms of scalability, limited technology diversity, and deployment/maintenance.
Take, for example, a web application. Imagine having the backend business logic and frontend code inside the same project. Now, within a monolithic architecture, these two very distinct parts are housed within the same project, operating as part of the same process.
This might seem like a good idea initially. After all, everything is in one place, right? However, in reality this is far from ideal.
As your application grows, so does the complexity of managing this intertwined code. Imagine trying to untangle a ball of yarn that’s been mixed up with different colors—that’s what you’re dealing with.
In comparison, microservices seem perfectly designed to tackle many of the issues presented in monolithic architectures. They are scalable, give developers the freedom to use whatever technology or programming language they wish to code the service, and they are easy to deploy and redeploy. However, microservices can only do these things if service-to-service communication is handled correctly.
In a monolithic architecture, all parts participating in the application service are tightly interconnected, leading to a complex web of interactions. However, with microservices, each service communicates with other individual services internally through APIs. If this isn’t handled properly, it can cause just as much trouble as a monolith if not more so.
Understanding different types of microservices communication
The biggest hurdle in transitioning from a monolithic architecture to microservices is communication. In a monolithic structure, communication is straightforward. But with microservices, it requires careful planning, inter-service communication, message communication, and understanding.
Imagine your platform as a pizza shop. In a monolithic setup, there’s just one employee responsible for everything. In a microservices environment, you have different people handling different tasks (the chef, the server, and the manager), and they all need to communicate effectively to keep the pizza place running smoothly.
There are two main types of communication in microservices: synchronous and asynchronous messaging.
Synchronous communication between microservices
In synchronous communication, a service sends a request to another service and waits on one or more services for a response before continuing with its tasks.
It’s much like a conversational call-and-response. After the “call”, you’re waiting for the other person to answer before you continue speaking. A service sends a request to another service and waits for a response before it can make a client request and continue with its tasks.
This method ensures that all processes are completed in order, but it can slow down operations, especially when dealing with multiple microservices with complex requests. Until there’s an answer, with synchronous communication your microservice is essentially left twiddling its thumbs, unable to move forward until it receives a response. When you have multiple services just sitting there waiting it can get even worse. Poor microservices communication can lead to bottlenecks, slowing communication patterns, down business processes, and reducing efficiency.
Asynchronous communication between microservices
The other type of microservice communication, asynchronous, allows a service to continue with its tasks after sending a request, without waiting for a response.
It’s like dropping a letter in the mail—the message sender isn’t standing at the mailbox waiting for a reply; you continue with your day. This method allows your services to multitask effectively, improving efficiency and scalability. Going back to our pizza shop example, instead of having one person do everything, you’ve got a team where each member can concentrate on their single, focused task without getting bogged down.
But, dropping a letter in the mail or working in a pizza shop requires trust that the tasks outside of your purview will get done. The pizza will get made, the letter will reach its destination. Asynchronous communication requires similarly careful planning and management.
You need to ensure that your requests are being received and processed and that responses are being sent and received appropriately. If not managed correctly, asynchronous communication can lead to missed messages or responses, leading to errors and inconsistencies in your operations.
This requires an understanding of orchestration and choreography.
Understanding microservice choreography and orchestration
When it comes to distributed systems, two microservice communication patterns stand out—choreography and orchestration. But what exactly do they mean, and how do they differ? Let’s dive into the details.
Choreography and Microservice Communication
Have you ever watched a flock of birds moving in the sky? Each bird knows when to turn, dive, or climb, creating a mesmerizing dance in the air. That’s choreography in nature—no central authority, just seamless synchronization.
Now, let’s bring this concept into the realm of IT architecture where microservices communicate. Here, choreography microservice architecture is about different software components interacting with services to communicate with each other seamlessly without needing a central conductor. Each component knows its role and how to respond to specific events.
Consider this: an e-commerce website receives an order (an event). This triggers the inventory system to check if the item is in stock, the payment gateway to process the transaction, and the shipping service to prepare for delivery. None of these systems need to wait for instructions from a central authority. They react autonomously to the event, like birds in a flock.
Orchestration and microservice communication
Remember when you were in school and your teacher coordinated a class project? They assigned roles, set deadlines, and managed the overall progress. That’s orchestration in a nutshell—a central authority directing the actions of different participants.
In IT architecture, orchestration follows a similar pattern. A central coordinator manages and controls the interactions between different software components.
Imagine a hotel booking platform. When a user makes a booking, the orchestration service springs into action. It sends a command to the reservation system to reserve the room, instructs the payment system to process the payment, and prompts the email service to send a confirmation email to the user.
All these actions are centrally coordinated, ensuring a smooth flow of operations.
Both have their strengths and weaknesses. Which should you use?
Choosing the right microservice communication method for your needs is vital
Choosing between synchronous and asynchronous communication and which approach you should take depends on your specific needs and circumstances. Take the story of Goldman Sachs story for example.
Goldman Sachs is a leading global investment banking, securities, and investment management firm, and has been leveraging Camunda for microservices orchestration since 2015. This platform was integral to delivering financial automation at an enterprise scale, with over 60,000 unique users annually and approximately six million tasks executed weekly.
However, as the landscape evolved in 2020, so did Goldman Sachs’ priorities (check out the full story in a Camunda Community Summit session). The need for enhanced throughput, scalability, and resilience became more apparent. Additionally, the internal payments team recognized a growing requirement for heightened security, rapid disaster recovery without data loss, and a smoother payment handling process.
In response to these evolving needs of microservices communications, Goldman Sachs embarked on the development of a new microservices orchestration platform. This platform was designed using asynchronous messaging so they could not only meet the changing demands of internal communication in microservices but also offer the flexibility to adapt to future use cases.
The result was a robust and scalable platform capable of adapting to the increasing demands. With enhanced security measures, Goldman Sachs could now handle payments more smoothly and recover from disruptive incidents in just minutes, without any data loss.
This platform’s success underscores the importance of adaptability in technology solutions. As business needs evolve, so too should the tools and platforms that support them. Goldman Sachs’s original monolith was incapable of any sort of rapid change.
By shifting to a microservices architecture they were able to deconstruct the monolith and become a far more nimble organization through the use of a distributed system. With the creation of their Enterprise Automation Platform, they’ve managed to take their ability to adapt using microservices even further.
Microservices offer a powerful solution to the challenges of monolithic architecture.
By understanding and effectively managing communication between different web services together, you can harness this power to drive your business forward.
Developer’s Guide to Microservices
Learn how to overcome microservices challenges by following some best practices