Microservices architecture breaks up monolithic applications into independent, isolated services. With that freedom comes the need to have a microservices deployment strategy to manage the resulting microservices. As part of that strategy, Gartner urges enterprises to “Automate repetitive deployment processes to make them predictable and repeatable. CI/CD tools, processes, and disciplines are critical to both initiating and sustaining an MSA.”
These tools and processes include:
An important factor in your enterprise’s ability to adopt a deployment automation strategy is how your microservices interact with each other. Microservices implemented using synchronous technologies like REST bind long chains of microservices together. The resulting structure looks a lot like an old-school distributed monolithic application — including complex dependencies between components. In other words, you’ve missed the goal of improving agility, simplifying your system, and increasing performance.
In contrast, event-driven architecture enables a modular structure in which components can be independently deployed in a decoupled manner that simplifies your microservices deployment strategy and makes it easier to use standardized automation toolsets for testing, building containers, and deploying solutions.
Decomposing code into atomic pieces during a transition to microservices architecture can enable more rapid adoption of updates. Since the code is self-contained, if the interface of a microservice is well-defined, well-understood, and does not change, developers can enhance its inner workings without worrying about breaking another component, thereby quickly making the new functionality available to customers. This means developers can mix and match microservices to build innovative solutions, and create new microservices when they need to, which can be further leveraged by additional solutions.
Given the emphasis on mixing and matching, it’s important for architects to standardize how their microservices will interact with each other. Architects can consider options like:
The developer community has widely accepted REST for interaction between microservices. It has an extensive ecosystem that includes frameworks, governance and discovery solutions, code generators, and industry standard schema definitions. However, REST promotes tight coupling between components and makes one-to-many distribution of data difficult.
While currently not as widely used, there is an increasing movement towards using asynchronous event-driven architecture for the interaction between microservices. This shift is being accelerated by the emergence of ecosystem of tools that parallels REST support – including industry API standards that reduce lock-in risk from selecting a particular event broker. Event-driven architecture decouples microservices from each other, with an event-broker playing middleman so providers and consumers are not dependent on each other, and new consumers can be added without affecting existing interactions. As a result, applications are coupled only through the data model of events being passed through the system (which is unavoidable).The Complete Guide to Event-Driven ArchitectureA guide to the benefits, uses, and examples of event-driven architecture in modern business.
To illustrate the increased automation, let’s head to the supermarket. Imagine the Shop-A-Lot grocery store encourages shoppers to sign up for a loyalty card through a new website. The initial solution consists of two microservices: one which opens the account and the other which mails out the physical loyalty card. The microservices use synchronous REST for communication.
Later, Shop-A-Lot decides to increase their engagement by sending an email to shoppers on their birthday. A developer creates a third microservice that formulates and sends the email, inserting it in the chain between the account opening and the card mailing.
The use of synchronous REST for interaction between microservices creates several challenges when adding the new email microservice:
The tight coupling forces developers to modify and change behavior of an existing service just to add a new service. Despite having microservices-level granularity, the tightly coupled components are not agile.
In addition to making life more complicated for the developer, this tight coupling also makes it hard to automate Shop-A-Lot’s microservice deployment strategy. Consider the three aspects of deployment mentioned earlier:
Let’s head back to the supermarket and see how event-driven architecture can help automate Shop-A-Lot’s microservice deployment strategy. The initial solution with event-driven architecture still consists of two microservices, one which opens the account and the other which mails out the physical loyalty card. The account opening microservice, however, now interacts with the card mailing microservice through an asynchronous message, instead of directly communicating via REST.
To add the birthday email service, one still needs to create a third microservice that formulates and sends the email, but implementing it no longer involves changing existing code. Instead, the new service subscribes to events coming from the event broker, so both the card mailing microservice and the birthday email microservice both get the event and do their work in parallel.
The loose coupling fostered by the event broker allows developers to modify and change behavior of an existing microservice or add an entirely new microservice with fewer concerns about the impact to existing services. In addition to having microservices-level granularity, the loosely coupled components maintain their atomic nature.
Asynchronous communication between microservices makes it easier to develop useful code by reducing its complexity. But there are also positive implications for Shop-A-Lot’s microservice deployment strategy. Consider the three aspects of deployment mentioned earlier:
The decoupling present in event-driven architecture allows for increased automation within a microservices deployment strategy. This, in turn, allows for innovative features to be deployed quickly and accurately, giving developers the freedom to explore new possibilities and enhance existing functionality. That agility can give your business a competitive advantage when serving your customers.
Finally, I’ll invite you to download my latest white paper introducing the concept of the unified microservices platform.
 Source: Gartner “How to Succeed With Microservices Architecture Using DevOps Practices”, 22 January 2019, Gary Olliffe, Kevin Matheny