Deploying software on single machines was too risky, because all of the operations and configurations had to happen in one place, and if that system went down,

Deploying software on single machines was too risky, because all of the operations and configurations had to happen in one place, and if that system went down, you'd be offline, so we built specialized hardware and VM platforms to allow each piece of the service to be deployed on a specialized platform that could be run by dedicated experts. But deploying systems to specialized VMs and load balancers and networking devices had too many disparate pieces and was impossible to unify, and developers didn't want to have to talk to all of those experts to get the configurations they needed, and anyway, resources were wasted on all these specialized pieces of hardware, so the Kubernetes API was created to encapsulate all the pieces into straightforward and consistent APIs any developer could understand that allowed services to be binpacked to achieve maximum efficiency. But the Kubernetes API was too complicated with so many complicated interrelated concepts in one big monolith of an API, and developers did not want to have to think about how to configure all the individual pieces and dependencies, so people created Helm charts to allow that one dude on the team who understood the infrastructure to hide the complexity. But Helm charts were too obfuscated, and no one could tell what was going on inside them, and reliability suffered and it became too risky to use black boxes to configure your deployment, so now there's a universal chart that exposes every Kubernetes API option for easy visibility. But obviously, this new universal chart has far too many options, when all I want to do is deploy my application without having to think about every detail. So I'm looking forward to the upcoming packaging system that wraps this universal chart into something with less visible complexity.