I agree that Service Meshes should be easier to use and configure both statically and dynamically. The cost of running them is also a con. Those extra sidecars

I agree that Service Meshes should be easier to use and configure both statically and dynamically. The cost of running them is also a con. Those extra sidecars make your pod heavier and slower to start. I disagree that they should fade out of sight. This sentiment is to a larger extent applicable to reverse proxies too. My experience debugging problems when the service mesh is not accounted for can be painful. For example, setting keepalive parameters and max connection age parameters for gRPC clients and servers. If the intermediary proxies and sidecar components are not accounted for, connections may close sooner than configured on the server but still be open on the client. Similar permutations of this abound. Another example is retry logic. If retry mechanisms are configured between client and server, there can be a multiplicative blowup of connections established/dropped to/from servers due to intermediate proxies retrying. I think hiding the service mesh will end up with complications similar to "dll hell".