"You'll see that Kubernetes doesn't provide all these things," said Red Hat's Gracely. "They're all areas where the community is, through different vendors, through open source add-on projects, giving the marketplace a lot of options, giving them choice, giving them pluggability for these different elements, and allowing companies to ultimately decide, within this broader framework, how do I build the best platform for what we want to do, pick the best pieces that make sense for us, but still have it all be interoperable and supportable?" Yet as Gracely's comment itself demonstrates, since the product of any of these collections is indisputably a platform, and Kubernetes is the facilitator at the center of it, then all of these results should be "Kubernetes platforms." Red Hat's OpenShift is one prominent example, as well as the latest 2.0 edition of Rancher. Whether Kubernetes is perceived by data center managers and CIOs as a platform or as an engine is not an esoteric or trivial matter. If the orchestrator is to continue to make headway in the enterprise, it can't afford to be treated as a lab experiment, or one of those crazy tools the developers love but no one else understands. "Engine" implies the need for a complete chassis (or, to borrow a phrase from my other gig, a "new stack"), and thus gives some evaluators the impression that it's incomplete by design. A platform must provide the enterprise with the hope that it could soon host all of its applications, not just the funky ones with the curly-Q's and the microservices. For this reason, the CNCF has been presenting Kubernetes as a platform capable of hosting both old and new applications by way of containerization, even when the benefits of transferring old applications from virtual machines to containers have yet to be assessed.
Jul-11-2018, 18:42:40 GMT