I think where service mesh goes wrong is when the design is monolithic or proprietary, where your whole cluster usually needs to use one particular set of compatible products.<p>At its core, a service mesh is just a complicated, multi-tier, higher-level router and VPN. For TCP/IP routing there's lots of protocols, from the local level to LAN to WAN and beyond. Many of them are designed for specific use cases. But even so, traditional routers aren't centralized, they don't care what other routers they connect to, and they all speak common languages, transfer information, make independent decisions, and act in isolation. This is a really good design that I think service mesh should utilize.<p>I think what we really want from a service mesh is a router for applications with a standard protocol that doesn't share state (or at least, state is asynchronous and non-consistent, and only verified at the end of an operation, similar to IP routing). Additional features are needed, and those can be codified into the protocol. That would make the system more resilient to change and compatible with different products, rather than now where each service mesh software is basically a unique incompatible router and protocol.