Do You Have a Deployment Strategy for Your Microservices Architecture?

This article was originally published as a blog post on solace.com: https://solace.com/blog/automating-microservices-deployment-strategy-eda-rest/

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.

Adopt a Microservices Deployment Strategy: EDA vs. REST

An important factor in your enterprise’s ability to adopt a deployment 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.

Standardize Interaction Between Microservices

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:

• REST (synchronous, one-to-one interaction),
• Event-driven architecture (asynchronous, one-to-many interaction), or
• A hybrid approach with multiple interaction styles.

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.

Read: REST vs Messaging for Microservices – Which One is Best?

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).

How REST Hinders a Microservices Deployment Strategy

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.

Implications for Code

The use of synchronous REST for interaction between microservices creates several challenges when adding the new email microservice:

• The account opening web service requires code changes in order to call the birthday email microservice instead of the card mailing microservice
• The birthday email microservice in turn needs to have code that explicitly calls the card mailing service
• Both the account opening and birthday email microservices need to have error handling code in case downstream microservices encounter an error.

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.

Implications for Microservice Deployment Strategy Automation

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:

Automated and comprehensive unit testing, including error scenarios

• Given that the error handling code has changed in the account opening microservice, you need to test both components, rather than exercising the single new component that is the focus of the enhancement.
• Given that the state passed to the birthday microservice is controlled by the account opening microservice, choosing where to inject data for a unit test is more complex

Automated build of container images

• The distribution of routing logic and error handling across multiple microservices means there is a need to simultaneously generate multiple containers, which slows down the build process and increases the need for logic in the CI/CD toolset.

Automated deployment of container images

• The dependencies between the generated containers need to be considered as they move through environments to production. This would be the case even when deploying updates to microservices. Gartner calls this the “release train” model of release management: “The planning and delivery of different pieces of functionality are linked and delivered in specific, scheduled time intervals, much like regularly scheduled trains.” Even when release trains run on time, which they frequently do not, they can prevent one enhancement from reaching customers before a whole slew of other dependent projects are ready to roll.

Take the Express Lane to Deployment with EDA

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.

Implications for Code

• The account opening web service continues to publish messages to the event broker. No changes are needed in order to call the birthday email microservice and the card mailing microservice
• The birthday email microservice does not need code that explicitly calls the card mailing service. In fact, the birthday email doesn’t even need to know which other services exist, let alone add code to call it.
• All error handling code is contained within the microservices themselves. If there is a need for retry, the persistence provided by the event broker ensures that messages are not lost in the process.

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.

Implications for Microservice Deployment Strategy Automation

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:

Automated and comprehensive unit testing, including error scenarios

• Code changes are isolated to only the new birthday email microservice. Error handling code is self-contained within the birthday microservice, likely leveraging the persistence that event brokers can provide. As a result, automated unit testing only needs to exercise one component in isolation.
• Message routing is handled by the event broker and can be excluded from microservice unit tests.
• Choosing where and how to inject data for a unit test is simplified, given that all information will be contained in the asynchronous message received by the birthday email service.

Automated build of container images

• The isolation of routing logic to the event broker and self-contained error handling within a single microservice means that there is only a need to generate a single container for the solution. This in turn, speeds up the build process and decreases the need for logic in the CI/CD toolset.

Automated deployment of container images

• The independence between generated containers increases the agility of individual enhancements movements through environments toward production. Gartner calls this the “release taxi” model of release management, where developers move code enhancements at their own pace and are “…less likely to rush deliverables out the door to make a scheduled release. When developers are forced to rush, quality and discipline are inevitably compromise — much like a passenger might accidentally leave a bag on the station platform in the rush to make a train.”

Fueling Automation in Your Microservices Deployment Strategy

The decoupling present in event-driven architecture allows for increased automation within your 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.

Other resources you might find useful:

• Why RESTful APIs Can’t Compete with the Event-Driven Approach to Microservices
• Messaging Patterns for Event-Driven Microservices
• Eventual Consistency in Microservices and My Front Yard: Event-Driven Architecture vs. REST
• Solace Microservices Resource Hub: https://solace.com/resources/solace-microservices-resources

?