4 ms·

One of the things I liked about CF was how it encoded application dependencies into the app package. Chef has just recently announced Habitat, which apparently

by hosh 10y ago

One of the things I liked about CF was how it encoded application dependencies into the app package. Chef has just recently announced Habitat, which apparently brings that kind of an idea into play. The thing is though, Kubernetes is a set of lego blocks from which you can compose into CF, but you couldn't create Kubernetes from CF. That makes Kubernetes more interesting to me.

jacques_chester 10y ago
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.
- hosh 10y ago
  Yep, I remember when CF first came out. It was really interesting tech.
  - jacques_chester 10y ago
    It still is! :)
- wstrange 10y ago
  Strategically I think it would make a ton of sense for CF to rehost on Kubernetes. There is a bunch of infrastructure that becomes someone else's problem - letting CF focus on higher level PaaS primitives. Just my 2 cents ;-)
  - jacques_chester 10y ago
    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.
smarterclayton 10y ago
That mindset - being able to build all types of application on top of the "platform" - is why OpenShift rehosted itself on top of Kubernetes. Being able to compose building blocks and run higher level services (batch, application, clustered pets, 12-factor, legacy, etc) means you're much closer to the Goldilocks zone of Datacenter infra. I.e. avoiding needing to deploy multiple application stack platforms. Disclaimer - I work on OpenShift and Kubernetes
- jacques_chester 10y ago
  We saw the same gaps with Cloud Foundry -- the CF v2 API is resolutely about apps, the whole app and nothing but the app. That's one of the reasons that the Diego effort was launched and it's why the v3 API is under development. Red Hat has rebased on Kubernetes, but at the time we launched Diego, there was no alternative to building it ourselves. I note that the workloads you mentioned are all supported or supportable by Diego and we're building out the missing ones very rapidly. Disclaimer: I work for Pivotal, we donate the majority of engineering on Cloud Foundry. I am not near the Diego or core runtime teams, so my version of events may be hilariously inaccurate.

by hosh 10y ago

jacques_chester 10y ago

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.

hosh 10y ago
Yep, I remember when CF first came out. It was really interesting tech.
- jacques_chester 10y ago
  It still is! :)
wstrange 10y ago
Strategically I think it would make a ton of sense for CF to rehost on Kubernetes. There is a bunch of infrastructure that becomes someone else's problem - letting CF focus on higher level PaaS primitives. Just my 2 cents ;-)
- jacques_chester 10y ago
  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.

smarterclayton 10y ago

That mindset - being able to build all types of application on top of the "platform" - is why OpenShift rehosted itself on top of Kubernetes. Being able to compose building blocks and run higher level services (batch, application, clustered pets, 12-factor, legacy, etc) means you're much closer to the Goldilocks zone of Datacenter infra. I.e. avoiding needing to deploy multiple application stack platforms. Disclaimer - I work on OpenShift and Kubernetes

jacques_chester 10y ago
We saw the same gaps with Cloud Foundry -- the CF v2 API is resolutely about apps, the whole app and nothing but the app. That's one of the reasons that the Diego effort was launched and it's why the v3 API is under development. Red Hat has rebased on Kubernetes, but at the time we launched Diego, there was no alternative to building it ourselves. I note that the workloads you mentioned are all supported or supportable by Diego and we're building out the missing ones very rapidly. Disclaimer: I work for Pivotal, we donate the majority of engineering on Cloud Foundry. I am not near the Diego or core runtime teams, so my version of events may be hilariously inaccurate.