Hacker News new | ask | show | jobs
by yoz 803 days ago
Serious question: If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off?

Am I (and Betty Junod, and Seth Vargo) wrong about the desirability of Heroku's interface? Was Cloud Foundry far worse than Kubernetes, or did it just not get traction?

I admit that's a pretty loaded question, so I should give context: I dealt with Cloud Foundry from the user side, not the admin side. This was around 2016, and I had very little exposure to what else was going on with it. But I was impressed that they some key elements of Heroku-style PaaS seemingly working fine.

So if it was far harder to get going than Kubernetes, that's a good explanation. But I'm guessing there's much more to it than that.

3 comments

Afaik cluster administration is pretty complicated. They had a pretty big internal deploy at JP Morgan Chase and I was under the impression other Fortune 50s had internal deployments but it takes a dedicated team to run.

I think nowadays building on top of Kubernetes has completely eclipsed the CF stack. There's a buildpacks CNCF incubator and you can get k8s pretty close with different tools/abstractions.

Google App Engine was ahead of its time, but it's still quite a successful product. I think it didn't get traction back then because it was too different from the status quo for developers to want to invest in it. The other thing is vendor lock-in and costs. If you're all in on Heroku (or AWS or GCP or...) you have no recourse if they decide to raise prices on you. Even though that's never really happened other than the ipv4 AWS thing for developers, (ie DocuSign doesn't count) the mere possibility that you could get hosed by your vendor scared enough people off that it failed to get the traction it deserved, imo.
> If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off?

Cloud Foundry isn't like Heroku, it's more like "build your own AWS" or maybe "build against this shim layer so you can make a credible threat to migrate when your cloud provider jacks up their prices".

The target audience isn't application developers, it's CTOs and CFOs.

I mean.. from the user side (aka the developers deploying applications within the org) Cloud Foundry was a lot like Heroku. I think the Buildpack concept (incepted at Heroku) was picked up by the Cloud Foundry Foundation and developed in lockstep with Heroku. For a while there was a lot of pollination between both projects.

The reason IMO that Cloud Foundry didn't catch on is that from the admin side, deployment of vanilla CF was a nightmare, and maintenance could be challenging.

You could pay for an Cloud Foundry distribution with guardrails, but that ended up being $$$ and still required having employees with systems/ops knowledge if you weren't just deploying to the cloud provider du jour anyway.

I think CF had its golden years before k8s really started to catch on. Then there was a push by a lot of companies to bring CF to k8s (I was working at one such company as it went from the Cloud Foundry Distribution -> Cloud Foundry Distribution on K8s journey). I think these could have caught on if someone could have made it work in a truly seamless way, but unfortunately all the abstractions for bridging CF concepts to a K8s world developed in pursuit of this goal ended up being leaky, and requiring your customers to have CF domain knowledge atop K8s domain knowledge to successfully deploy and maintain their in-house CF, which proved to be too tall an order.

Unfortunately, CF seems to have fallen by the wayside now (though I'm sure there will still be companies running it for 20 years if their needs don't outgrow the capabilities of their mostly-working deployments) and AFAIK nothing has really taken its place.

I haven't had the opportunity to try this yet, but Kubevela (https://www.cncf.io/projects/kubevela/) looks like it could be the closest thing to a modernized CF-like experience on top of K8s that should (hopefully) be more sensible to deploy and manage. Would really love to hear thoughts from people who have used both though.