Net API Notes for 2019/11/21 - The Service Mesh One - Issue 115

I had a delightful time in Minneapolis, MN last weekend. However, while I was traveling for fun, there seemed to be a fair amount of social chatter about service meshes. What are service meshes, why would you use them, and where can you find out more? Read on.



William Morgan had a problem. He was deeply passionate about service meshes but was increasingly frustrated by all the hyperbole and confusion around them. So he launched, a site dedicated to clearly explaining the compelling bits that developers and software architects need to know.

"If you're encountering the idea of service mesh for the first time, you can be forgiven if your first reaction is mild horror. The design of the service mesh means that not only does it add latency to your application, it also consumes resources and also introduces a whole bunch of machinery. One minute you're installing a service mesh, the next you're suddenly on the hook for operating hundreds or thousands of proxies. Why would anyone want to do this?"

William goes on to describe that people use service meshes for two reasons:

  • Reducing the cost of deploying proxies
  • Introducing additional logic to a system without muddling application code

As microservice architecture increases, I've seen the shift from answer "why" to one's about how to manage all the various infrastructure. This piece is epistemological salt for people looking to get started.

The site pairs nicely with a new INNOQ site that recently launched: It attempts to comprehensively compare, feature by feature, the various service mesh options available.

Finally, if you want even more on service meshes, I've been testing the LED lifetime warranties while spelunking for better archived notes retrieval methods. When it comes to service meshes some of the best, and previously highlighted, pieces that I recommend include:


Of course, if you're going to build service meshes, you have to have services to put into them.

As I've covered in many prior notes, microservice architecture is akin to teenage sex; all the popular kids brag about how they're successfully doing it, but most people's first time is awkward, maybe even weird. Overwhelmed by the complexity, some have even reverted back to service celibacy.

Nicki Watt has taken a different approach. Both in her slides and in a recorded video presentation, Nicki posits that microservice anti-patterns can be detected via graph theory.

This is exciting stuff. I would love to see more teams applying this higher-level analysis to their architectures or even their microservice death star diagrams. If you're doing something similar, let me know; I'd love to chat.



The number of conferences for 2020 continue to trickle in. Check out for upcoming, in-person API events near you. If you know of a meetup, hackathon, or conference that should be added, let me know.

As always, I want to mention the generous Patreons who continue to support this work. It isn't about the sum of money, but you clearly signaling that this is something that you value. Thank you.

Till next time,

Matthew @libel_vox and

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.