REST API Notes for 2017/10/10 - Reactive Microservices and Service Meshes
I've talked, at length, about the challenges of microservice development in previous REST API Notes. If there has been an API trend in 2017, it has been techniques to deal with increasing service complexity. Two of the biggest have been reactive microservices and service meshes.
REACTIVE MICROSERVICES
Jonas Bonér has a compact slidedeck available that, despite not having the full text, covers a lot of ground. In his argument for microsystems, he defines Reactive Microservices as services that communicate via asynchronous message passing. Assuming an asynchronous and non-blocking communication model between microservices, rather than a request and response one, means distributed systems can be both elastic and resilient.
There's much more in the deck, including a link to download his O'Reilly "Reactive Microsystems" book for free. However, one of the interesting aspects of the presentation I'd like to further highlight before moving on is event storming.
Event storming is a technique developed by Alberto Brandolini for identifying essential actions (and actors) in a system. Usually, when it comes to decomposition, people are quick to point at domain driven design (DDD). The problem with DDD, however, is that it has a specialized vocabulary and ritual that can be daunting for those who don't regularly practice it. Event storming attempts to have the same effect in a much more approachable manner.
Identifying what goes where, and why, in a microservice architecture is not a trivial thing. I'm excited to give event storming try in our upcoming work.
SERVICE MESHES
I have also been seeing a tremendous amount of effort around service meshes. A key principle of microservices is that they are independently deployable. However, the complexity of distributed systems results in a host of issues - service discovery, circuit breaking, entitlements, etc. - that would benefit from centralized management. But where to put them? Does every microservice replicate those functions within their own code? Or do we revert to the Enterprise Service Bus (ESB) days, where business logic is divided between a runtime deployable and a message broker (the ESB)?
Spoilers - neither solution is great. Both Phil Calcado and Christian Posta do a fantastic job of starting with a historical review of how things evolved to where we are, the benefits of service meshes, and what those architectures look like. It is still an emerging area of focus which is why, as Kasun Indrasiri points out, people are confusing a service mesh with an API Gateway. And no (spoilers, part deux) they aren't the same.
Regardless of whether microservices are part of a service mesh or not, testing remains a challenge. Daniel Bryant has a thorough overview of how to approach these fine grained services. Is anyone else using Toby Clemson's original microservice testing framework? If so, I'd love to hear about your experience.
MILESTONES
Mehdi Medjaoui, founder of the APIDays global conference series and co-founder of Oauth.io, is a member of CA's API Academy. He will be joining other frequent REST API Notes linkees like Matt McLarty, Mike Amundsen, and Erik Wilde as "Lead API Economist".
David Biesack, a fellow API governance aficionado who left SAS in September, has joined Apiture as lead API architect. I look forward to what he does in his new role there.
To end this section, the folks behind Nordic APIs announced that they are now offering API consulting. It is an interesting move as, previously, they were primarily about creating top-notch web content and conferences (their sold out fall event is happening in Stockholm as I write this). I'll be interested in seeing where this goes, but the first byproduct of this new business effort - a case study with CIBC bank on their microservice framework - hints at an exciting future.
WRAPPING UP
I've posted the online version of my API World 2017 talk for those that were interested. It's heavy (coming in at around 4700 words) but the response has been positive thus far. Kin Lane, the API evangelist, got an advanced preview and said:
"API governance is something that I know many API providers are working on, but Capital One was definitely the furthest along in their journey that I have come across to date."
Those are big words to live up to, but when I have more I'll be sure to share it.
Finally, I need to have a pass at webapi.events . What's there is probably out of date. Do you have a conference, meetup, or hackathon that is not listed? Just ping me - I'd be glad to add it.
Til next time,
Matthew