The alternative is writing more code in our applications.

As soon as we make any request that goes over a network, we need to make sure that connectivity cannot be disrupted and that observability is in place. LinkedIn famously wrote a "smart" client to do that in Java, that every team must use and they keep maintaining over time but that limits them in adopting non-JVM technology in the organization and creates technical debt over time.

You might be thinking of Netflix, who developed Hystrix and Ribbon.

These are being slowly replaced with other components from Spring Cloud or Resilience4J: https://medium.com/netflix-techblog/netflix-oss-and-spring-b...

Disclosure: I work for Pivotal, but not on Spring.

Are you saying my application doesn't need to have any logic for handling network connectivity problems once I have a service mesh? That sounds hard to believe. Maybe I don't understand what code I wouldn't need any more.

You won’t need code for mutual TLS, certificate rotation, routing, canary load balancing, tracing, logging, service ACL, retries, circuit breakers, cross-region failovers and so on. The out of process proxy model makes these features portable across multiple stacks and programming languages too, which is a nice benefit.

Oh. Well, I hate managing many of those things, so maybe I am sold on the idea at this point. The key for me would be to find some case study of converting a traditional setup to use one of these so that I could get a grasp on where you actually start for wiring it up.

I have Consul going, and making decent use of it for discovery, and have a feeling that Consul Connect may be a half-assed version of what you're describing; but I don't hear of many people using it.

More complex end applications / Products require more complex infrastructure. Just as true with physical world as with digital.