hyperbola :: Service meshes are organization tools, not technical ones

Why should we do a service mesh?

A service mesh is great for injecting policy in a way that makes it difficult for folks to do the wrong thing: connection pooling and keep alive, retries, timeouts, enforcing data locality constraints, AZ-local routing, etc, etc.

A 3D isometric illustration of nostalgic toys on a white background. The image features a rainbow-colored plastic slinky arched in the center, a group of four silver jacks with a cream-colored rubber ball, and three fuzzy pipe cleaners (two red and one green) standing upright in a small beige cup. The design has a soft handcrafted realism and a premium, emoji-like aesthetic.

To a certain extent, product engineering wanting to move quickly is at odds with reliability and a service mesh is difficult to subvert. Services meshes make sure the right thing happens by default.

This is probably the most succinct reason for deploying one. It allows separation of responsibilities in ways that don’t add extra steps product teams have to remember to do.