The only other reason I can think of to use a service mesh is if you want to restrict which services can talk to each other. That's easier to do when centrally

The only other reason I can think of to use a service mesh is if you want to restrict which services can talk to each other. That's easier to do when centrally deployed via proxy configuration, though the building blocks are the same as what Kubernetes provides out of the box, so you could do that on your own. If you investigate that far, though, you're not installing service meshes due to hype, you're analyzing service meshes as a form of application architecture. Instead of deploying dependencies using language-specific tooling, you can deploy dependencies using Kubernetes and the network, with some overhead of course, and a lot of configuration-as-code. Parallels to "You don't need no service mesh" could also be drawn for things like the OpenTelemetry Collector or maybe projects like OpenPolicyAgent, or "Identity-Aware Proxies" and other cloud services -- including Kubernetes itself. In the end, all of these tools are generic enough that you can use them in many ways to save time -- but you don't have to, as this article points out, and it might not actually save you any time at all if your environment is small enough.