I think that's a fair call. CF is an already assembled kit and we're constantly looking for ways to have better and better fit-and-finish. The whole point is to allow operators and developers to have smooth "Day 0", "Day 1" and "Day 2" experiences.
For those who really want a prebuilt Kubernete PaaS, Red Hat built OpenShift 3.
That said, Diego (our scheduler tech) was deliberately architected to be ignorant of Cloud Foundry. Right now it's pretty much serving the historical bias of Cloud Foundry's initial architecture -- applications -- but as the v3 API arrives we're breaking it down into finer grained concepts, some familiar to Kubernetes folk.
At one point, Diego was extracted out into a Kubernetes-like package with the Lattice project, which Pivotal supported for a while. But once we went and talked to developers, they said "well I don't really trust it because it's not a real Cloud Foundry". Hence we pivoted to PCFDev.
If Docker and Kubernetes or Mesos had emerged earlier, it's likely we'd have used them as our building blocks (as we've adopted other components). But when Cloud Foundry was born, none of these components really existed outside of private systems owned by Google or Facebook, or in some respects at Heroku.
Disclaimer: I was not responsible for any of these decisions, or even near to them, so take it all of the above with a grain of salt.
I am not the people who would make that decision, but nothing is impossible.
Like I said, it's a twist of fate. Red Hat decided to abandon their own effort when Kubernetes first emerged and I think they've done Kubernetes a lot of good in bringing their inhouse systems integration know-how to it.
Diego has a lot of properties that we really like, though. And it's already been proved at larger production scale than Kubernetes. Our next milestone is 250,000 real app containers per install, which is not far off.
Edit: Also I'm not sure how much re-engineering would be required. I kind of expect we'd just teach Diego to drive Kubernetes.
For those who really want a prebuilt Kubernete PaaS, Red Hat built OpenShift 3.
That said, Diego (our scheduler tech) was deliberately architected to be ignorant of Cloud Foundry. Right now it's pretty much serving the historical bias of Cloud Foundry's initial architecture -- applications -- but as the v3 API arrives we're breaking it down into finer grained concepts, some familiar to Kubernetes folk.
At one point, Diego was extracted out into a Kubernetes-like package with the Lattice project, which Pivotal supported for a while. But once we went and talked to developers, they said "well I don't really trust it because it's not a real Cloud Foundry". Hence we pivoted to PCFDev.
If Docker and Kubernetes or Mesos had emerged earlier, it's likely we'd have used them as our building blocks (as we've adopted other components). But when Cloud Foundry was born, none of these components really existed outside of private systems owned by Google or Facebook, or in some respects at Heroku.
Disclaimer: I was not responsible for any of these decisions, or even near to them, so take it all of the above with a grain of salt.