,
19 tweets,
4 min read
Read on Twitter
So I've been thinking a bit about Service Meshes, especially with the whole SMI (Service Mesh Interface) thing. (Thread) 1/18
As a tl;dr for what SMI is, it's a set of APIs to allow for common interop with different service meshes. In general, very happy for this, especially when it emerges ground up in the way this seems to have done. 2/18
This post from Microsoft outlines a bit more behind SMI: cloudblogs.microsoft.com/opensource/201…, but raises and challenges a concept, something which I've seen other folks struggling with during the Rise Of The Service Mesh. 3/18
Specifically, the idea of "Keep the endpoints smart, the pipes dumb". This post directly states that Service Meshes are moving away from this idea, and that it is a good thing. 4/18
This is far from the first time I've heard this - that we need "smarts" in the pipes. Enterprise Service Bus anyone? The reality is though that I think the concept is badly understood (or badly explained by people like myself). 5/18
I first heard the phrase "keep your endpoints smart, your pipes dumb" either from @jimwebber or @iansrobinson. It was a reaction to application smarts living in middleware, requiring changes to be made to the middleware to roll out new features. 6/18
The phrase was *never* meant to imply that the pipes themselves shouldn't be good pipes. If you use a message broker, you want it to do things like guaranteed delivery for example. The reaction was regarding *what* smarts you put in there. 7/18
People would do business process orchestration in message broker layers. It's now common to see people doing the same in API gateways, which are fast becoming the Enterprise Service Bus of the microservices generation. 8/18
Putting business logic into middleware is problematic from a view of deployment as you need to coordinate the rollout, but also in terms of control, as the people building the app were often different to the people managing changes in the middleware. 9/18
So, back to the original concept. Keeping endpoints smart and pipes dumb was always about keeping business functionality out of the middleware, ensuring that you could ship software faster. It wasn't about pushing middleware concerns into services. 10/18
Service meshes, as a concept, are a good idea to help solve some of problems we created with microservice architecture. But as a form of middleware they are prone to the same abuse as the ESB was, and the API gateway is now. 11/18
The same orgs who made ESBs and API Gateways quagmires of productivity may well make the same mistakes with service meshes. We can't blame the tool directly for that. 12/18
But people who are pushing service meshes can make sure that they at least are clear about how to use the tool well, so it would be worth making sure that we're talking about the same things. 13/18
If you want the "smarts" related to routing, tracing, traffic shaping, service discovery etc. in your service mesh, then go for it! Those of us rallying against ESBs never had a problem with these things being in message brokers. 14/18
But keep the logic related to your service, the business functionality, inside your service under your control If you start letting this stuff seep into your middleware, you'll be repeating the same mistakes made in the 90s. 15/18
By the way, this idea of separation of concerns between the business functionality and routing/transport concerns is by no means new. I and many others have cited the Ports and Adaptors/Hexagonal architecture ideas from @TotherAlistair as prior art in microservices 16/18
Remember, the core concept of microservice architectures is to enable independent deployability, so we need to find ways to structure our architectures to optimise toward this goal. 17/18
So if you find yourself constantly having to change your middleware, be it an ESB, API Gateway or Service mesh, take a pause for a moment and ask yourself if your architecture is working for you, or are you working for your architecture? 18/18
Hat tip to @fxgai for kicking off this train of thought:
