, 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:
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Sam Newman
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!