[kevan]

>slightly easier

As a company grows sooner or later most of these features become pretty desirable from an operations perspective. Feature developers likely don't and shouldn't need to care. It probably starts with things like Auth and basic load balancing. As the company grows to dozens of teams and services then you'll start feeling pain around service discovery and wish you didn't need to implement yet another custom auth scheme to integrate with another department's service.

After a few retry storm outages people will start paying more attention to load shedding, autoscaling, circuit breakers, rate limiting.

More mature companies or ones with compliance obligations start thinking about zero-trust, TLS everywhere, auditing, and centralized telemetry.

Is there complexity? Absolutely. Is it worth it? That depends where your company is in its lifecycle. Sometimes yes, other times you're probably better off just building things and living with the fact that your load shedding strategy is "just tip over".

[davewritescode]

We’re the process of moving all of our services over to a service mesh and while the growing pains are definitely there, the payoff is huge.

Even aside from a lot of the more hyped up features of service mesh, the biggest thing Istio solves is tls everywhere and cloud agnostic workload identity. All of our pods get new tls certs every 24 hours and nobody needs an API key to call anything.

Our security team is thrilled that applications running with an Istio sidecar literally have way to leak credentials. There’s no API keys to accidentally log. Once we have databases setup to support mTLS authentication, we won’t need database passwords anymore.

[bushbaba]

Some of the functionality you mentioned above is possible without a service mesh.

[thinkmassive]

All of the functionality of kubernetes can be implemented independently. It’s still a useful set of abstractions, therefore/because it’s understood by a large portion of the industry.