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…?
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.
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.
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!