Unlocking the Potential of Event-Driven Microservices with a Unified Microservices Platform

One of the architects on my team named Jesse Menning just put to paper a concept steeped in a discussion we have with customers all the time; which he wrote up as the “unified microservices platform.”

In this new white paper, Jesse explains why it is important to bridge the divide between synchronous and asynchronous interactions (both of which are valid and necessary!) in a system composed of many microservices. If that sounds good, I’d skip my synopsis and start reading Jesse’s excellent paper now! If you’re not sure whether or not you’ll find that interesting and valuable, I’ll do my best to summarize some of the key points here so you can decide.

In the paper Jesse explains that many IT organizations recognize the value of event-driven architecture and the value of being able to invoke microservices in both a request/reply and event-driven manner, but struggle to do so because their teams and tools have been built up around requirements of synchronous RESTful interactions. This can prevent you from achieving the superior agility and scalability – the reasons you went down “microservices road” in the first place.

He posits that to realize the full power and potential of microservices, architects need to embrace and utilize both asynchronous and synchronous interactions, and give developers the tools they need to be successful. So what are those tools…?

The Building Blocks of a Unified Microservices Platform

Jesse’s not the kind of guy to leave you hanging, and gives a great introduction to the four things it takes to build a unified microservices platform: a management layer, a distribution layer, a service layer and an infrastructure layer.

As you can see here, the two styles of communication require their own tools at the management and distribution layers, but can and therefore should sit atop a common framework consisting of a shared microservice framework and infrastructure.

• The management layer is about giving your team the power to share and reuse microservices: an administrative portal that lets creators of APIs and events register and update them, a gateway that enforces access rights and policy decisions at runtime, and a developer portal where people can find and reuse them.
• The distribution layer is where you enable the movement of information. The pretty well-known “service mesh” uses Kubernetes and a sidecar proxy to intercept and “handle” requests for microservices, and an event mesh performs a similar role by handling all aspects of routing event-driven information between decoupled senders and receivers.
• The service layer provides a consistent way to implementing microservices in the form of the standardized code a code generator cranks out, enforcement of policies, etc.
• The all-important infrastructure layer is about observability, because one of the side-effects of handling business functions with a dozen microservices instead of one monolithic application is you need to be able to troubleshoot not just the microservices but the process by which information and instructions flow between them.

Tying the Elements of a Unified Microservices Platform Together

Jesse then talks about the importance of linking all those layers with standards so you don’t get locked into any one tool, vendor, or environment.

• Defining APIs and events with OpenAPI and AsyncAPI, respectively.
• Runtime distribution of data using REST and HTTP, of course, along with things like AMQP, Kafka, JMS, and MQTT.
• Observability for event tracing and troubleshooting with OpenTelemetry.

What it Takes to Implement a Unified Microservices Platform

Jesse wraps things up by introducing some of the specific tools and vendors you might want to consider for the various pieces of the puzzle, but I won’t summarize that part because if you’ve read this far clearly you’re overdue to read his paper!