McLuckie has explained that with containerised applications running on an Infrastructure-as-a-Service (IaaS) model, code could be written in a hermetically-sealed unit, from which it could be deployed, whole, into disparate environments — a test cloud and a production cloud, for instance.
So far, this standardization of packaging and app architecture looks like one of the most useful effects of kubernetes. Using kubernetes comes with an implicit architecture model, a way of instrumenting applications (making them observable and manageable in production), and a defined life-cycle. It’s not perfectly clear-cut, but there are enough constraints in how you package up, deploy, and run apps in kubernetes that you don’t have many options.
This gives you an architecture you can just accept and start using: you don’t need to spend months – years, often – debating an enterprise architecture in your organization, coming up with many competing stacks, and then 3 or 4 years later sort of deciding on one but having to live with all that variation (e.g., the state we’re currently in).
Less grandiose, it means less architectural position papers you have to write, less meetings to go to, less arguments with rival ideas, and less time spent building and enforcing the policy of your enterprise architecture. Instead, you can spend all that time making the application better, and, thus, the business better. No CEO ever cared which kubernetes distro you ran, how much you paid to build or licenses it, or if it’s multi-cloud. They care if it helped them make money.
The same applies to ops: there’s now one way (sort of) to understand and manage it all. In contrast, we current have many different ways and tools, often customized within large organizations. That much variety ends up costing too much, and slowing things down more than you’d think.
Original source: VMware VP: Kubernetes as the ‘new IaaS normal’