> Why introduce a new concept to solve the problems that have been solved before? Well, let me try and answer that -- I use istio in production and the reason

> Why introduce a new concept to solve the problems that have been solved before? Well, let me try and answer that -- I use istio in production and the reason I use it instead of, for instance, managing 30+ .p12's for each individual java service that needs to talk to an external api via mtls (not to mention all of those plus the 20 or so others which all automatically get mtls 'in-mesh') is because it's an absolute shitload easier to manage. Is it complicated? Yes. Is it more complicated than orcestrating the cfgmgt to achieve the same thing via more traditional methods? No. Don't get me wrong, I have my problems with istio: * Until about 1.5 the docs were at best sparodic. * Finding out how to handle things like talking to an entpoint that does some ssl renegotiation without crapping out is still not easy * The configuration / yaml spec for the various options is not simple to write However, those are really offset by what we get by using it. I have logs of every external api call my entire estate (a big complicated one) makes, I get automatic tracing, I can do some really cool shit like mirror traffic to a standby pod to do a/b testing, none of my serivces need credentials for mtls calls baked into them (they just call http and 'magic' happens on the egress). End of the day, it's a tool. If you don't need it, don't use it. This article comes across like it was written in the same vein as the old man screaming "get off my lawn".