I find these articles to be gibberish, because they so heavily use acronyms and jargon specific to massive containerized installations, which i don't use in my line of work. In my company we use a OpenVZ which is a lower overhead virtualization than VMware, and it is simple to administer. But i can imagine when you have hundreds of thousands of containers to manage you have to use more complex stuff. I wonder sometimes why people need to use so many servers; an individual server is incredibly fast, and can handle a huge number of requests if they are efficiently presented. It seems like in terms of amount of data being pushed around, many systems are incredibly verbose and downloading way too much stuff for what they are doing. I am at the moment studying the McDonalds' food ordering app; it is 130 MB and that doesn't include the artwork for the menu. It's all code from frameworks, and crap that got pulled in due to dependencies. My mind rebels at learning these hypercomplex toolchains that keep getting invented and promoted by the big companies.

Thanks that is great feedback. There are actually some really great ideas underlying the article, but I agree, the way they are explained is total gibberish

This article isn’t gibberish, it’s a rather straightforward collection of common patterns - we see this usage a lot in our public kubernetes service, particularly in our advanced customer base. It’s smart to enforce cloud native base usage and then extend it ways that can’t break basic uptime guarantees.

Yeah I guess I mean it is gibberish to everyone outside of our kubernetes preist hood of which i kind of belong to

I read through it. I'm kind of indifferent. It's probably a better way to interface with certain 3rd party code bases, but I don't see it being universally better than using libraries. I think this sidecar pattern is trying to make a certain class of dependencies a configuration problem instead of a coding problem, but I'm not convinced it's going to work. Its too easy to imagine someone bumping a sidecar version, then needing to update their business logic to account for some minor breaking change in the sidecar's API. The thing that seems really cool to me is that you can have dedicated UIs for each sidecar. That seems like the killer feature that makes the whole thing worth while. There's no reason you couldn't do the same thing with an in-process dependency, but the fact that this is a real think that's working now is very cool.

It's not massively different than libraries, but it is much more hook-based and out of primary threads - I had the same doubts initially, it also sounded like a performance drain - but it turns out to have enabled a vast new ecosystem, permitting a lot more independence of approach for different shops, while still contributing a lot of new behavior back to the community