It’s an open secret that microservices architecture is dominating today’s application development. Businesses are using microservices architecture 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 promise of enhanced agility, scalability, resilience, and speed to deploy and maintain components, is what attracts many to microservices, including the Government Technology Agency of Singapore (GovTech).

However, not all microservices architectures will be able to unlock these values. The real-world implementation of microservices is more complicated than first thought, and not all microservices architectures are created equal. Unfortunately, most organisations saddle their microservices with synchronous exchange patterns and RESTful APIs, making that shiny new, modern microservices architecture a distributed monolith.

The goal should be to avoid the following common pitfalls and ensure that the implemented microservices architecture fully delivers on its technical, organisational, and business promises.

The service decomposition paradox

Distributed computing is challenging because the networks over which you integrate assets always introduce some amount of latency, and aren’t necessarily always reliable or secure.

As microservices become smaller and their purposes more singular, the potential for reusability increases, but you’ll need more of them, and they need to be able to communicate over distributed networks.

Thus, the paradox: do you make your microservices small and purpose-specific to enable organisational efficiencies and reuse, or do you make them larger to minimise 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 centre of your business universe

Until Copernicus proposed that the Sun is the centre of our solar system, most folks believed the Earth was at its centre. Similarly, many architects and technologists see databases and RESTful APIs as the centre 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?” vs event-driven interactions of “Tell me the moment something changes.”

Synchronous interactions are great for bespoke user queries and historical data, but terrible for reacting to changes of state as things happen. It’s past vs present thinking, and businesses must be in the present.

So, what should be at the centre 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.

Organisations that approach things with a similar event-first mindset are always sensing for new information and acting on it as quickly as possible. This is the transformational power that real-time data can bring to businesses and customer interactions through event-driven architecture.

Make your microservices dance 

The first step towards adopting an event-driven mindset is to change the way we think about designing and architecting solutions. There is a tendency to view all interactions between microservices as a predetermined sequence of request/reply interactions that needs to be tightly controlled or orchestrated.

The alternative is to choreograph microservices. Consider the analogy to dancing: 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 their 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.

The future of microservices is event-driven

In almost all major industries, there is a fast-growing interest in microservices to allow rapid, regular, and reliable delivery of complex applications. But microservices alone are not enough. They need to be underpinned by event-driven architecture to take data from being simply “at rest” (for example, stuck in a database behind an API) to being fully “in motion” (consumable in real time as events happen) to increase application performance.

As such, choosing the right event streaming and messaging platform is also one of the most important steps in the path to realising the benefits of microservices.

Businesses need to be able to go with the flow in a rapidly evolving and changing world. They can do this only 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.