Businesses operate in real time—unlike many of their applications. In nearly all major industries and verticals, there has been an explosion of interest in microservices. Their promise to enable the rapid delivery of flexible, scalable, and robust applications has proven to be extremely alluring to businesses looking to refactor or add new digital capabilities. But microservices in their traditional sense are not enough. To maximize the impact a microservices approach can have and fulfill their promise of business benefits, organizations need to make use of event-driven architecture. Event-driven microservices enable businesses to transform business processes and customer experience using real-time data and asynchronous interactions.
Microservices architecture is increasingly the technical strategy businesses are using as part of their current transformation projects—breaking down existing monolithic applications into self-contained, independently developed and deployed services. In fact, in a recent O’Reilly study of software engineers and technical professionals, more than three-fifths (61%) of respondents have been using microservices for a year or more. The same report found finance and banking lead the way in using microservices—but many other industries are following suit, including retail/ecommerce, telecom, manufacturing, transportation and logistics, and more.
Not All Microservices Architectures Are Created Equal
The benefits of microservices include enhanced agility, scalability, and resilience. Unfortunately, most organizations saddle their microservices with synchronous exchange patterns and RESTful APIs, making their shiny new microservices architecture a distributed monolith.
The world of microservices can be both full of promise and blunders. The goal should be to avoid the following common pitfalls and make sure your modern microservices architecture fully delivers on its technical, organizational, and business promises.
The Service Decomposition Paradox
Distributed computing is challenging because the networks over which you integrate assets aren’t always reliable, or secure, and they always introduce some amount of latency.
As microservices become smaller and their purposes more singular, the potential for reusability increases, but you need more of them, and they need to be able to communicate over distributed networks. Thus, the question: Do you make your microservices small and purpose-specific to enable organizational efficiencies and reuse, or do you make them larger to minimize the challenges inherent in distributed computing? It’s a nasty set of trade-offs!
So, how can we use microservices to achieve business value without falling back on monolithic architectures? Put events at the center of the business universe.
Until Copernicus proposed that the sun is the center of our solar system, most folks believed the Earth was at its center. Similarly, many architects and technologists see databases and RESTful APIs as the center of microservices strategies. It is, after all, where their data is stored and accessed.
This viewpoint leads to tightly coupled API interfaces and means all data interactions are synchronous. Synchronous interactions require always asking, “Has something changed?” versus event-driven interactions of “Tell me the moment something has changed.” Synchronous interactions are great for bespoke user queries and historical data, but terrible for accessing changes of state as things happen. It’s past-versus-present thinking, and businesses must be in the present.
So, what should be at the center of the microservices universe? Events.
Consider your own body. We constantly react to and act upon events that arrive via our senses of touch, vision, taste, hearing, and smell. These events relay information that is stored in our memory, replayed in our brains for pattern matching, and acted upon, if necessary, in the form of a new action/event. It’s a perfect real-time system.
Organizations that approach things with an event-first mindset are always sensing new information and acting on it as quickly as possible. This is the transformational power that real-time data through event-driven architecture can have upon your business and your interactions with customers.
Make Your Microservices Dance
The first step toward adopting an event-driven mindset is to change the way you think about designing and architecting solutions. There is a tendency to think about all interactions between microservices as a predetermined sequence of request/reply interactions that needs to be tightly controlled or orchestrated. Picture a conductor madly waving the baton to ensure the precise timing and volume of every instrument in the symphony every step of the way.
Many people use terminology such as “invoke,” “request,” or “call” to describe interactions between microservices, which is point-to-point thinking that leads to tight coupling. Multiply this by the fact that each microservice performs a series of steps, with each step possibly performing more request/reply interactions. The service is now responsible for orchestrating all of these service calls and dealing with the complexities of downstream errors and outages. Thus, the realities of distributed computing are coming back to haunt us again and causing chaos.
The alternative is to choreograph your microservices. Consider dancing as an analogy. A choreographer (in our case, the architect) listens to a song and creates a routine based on the beats (events) within the music (use case). The dancers (microservices) may perform completely different moves or steps from each other but, as long as it was choreographed together based on those audio cues (events), the routine will be a success. Even if someone messes up by doing the wrong step (error or outage), the show can continue because each dancer is independently listening to the music, not being told by an orchestrator or another dancer what to do.
To bring it back to microservices, event-driven architecture enables each service to register its interest in an event, or set of events, and wait for them to happen. Once the event of interest occurs, they react by performing their part of the routine, independently from the other services and steps. In fact, each service doesn’t need to know about the existence of other services, making them loosely coupled.
What It Takes to Implement Event-Driven Microservices
Event-driven architecture maximizes the agility of microservices as it liberates data from being “at rest” (for example, stuck in a database behind an API) so it is “in motion” (consumable in real time as events happen). As such, choosing the right event streaming or messaging platform is one of the most important steps in the path to realizing the benefits of microservices.
An eventing platform should be able to be deployed in diverse cloud and on-prem platforms as a service and easily federated across WANs (wide area networks). It should also support DevOps automation for operators and tooling that makes creating event-driven microservices easy for developers to ensure organizational efficiencies. The platform needs to have tooling that lets architects and developers collaborate on the design, implementation, and lifecycle management of microservices.
Realizing the Full Potential
Without a modern platform with these key features, event-driven microservices will provide value but not fully realize their full business potential.
Businesses need to be able to go with the flow in a rapidly evolving and changing world. They can only do this if their business applications enable them to react in real time and be in the present, not the past. That’s the essential role of event-driven microservices.