Recently, Rishidot analyst Krishnan Subramanian proclaimed the Cloud Foundry, Platform-as-a-Service (PaaS) cloud, had met its demise as a standalone platform. Really? That’s news to me, and I cover Cloud Foundry like paint.

What got Subramanian so frazzled was Cloud Foundry started offering Docker in place of its own container runtime, Garden. And at the recent Cloud Foundry Summit in Philadelphia, the Foundation announced it would enable DevOps to replace its orchestration engine, Diego, with the far more popular Kubernetes. The Foundation is doing this with the still baking Project Eirini.

Far from seeing this as the end of Cloud Foundry, I think it just shows the Foundation has good business sense. While Docker container formats may not end up ruling (I like what’s happening with CRI-O, short for Container Runtime Interface – Orchestrator), Kubernetes is the clear cloud container orchestration winner. In short, rather than waste time trying to dictate standards to a market that’s made up its mind, Cloud Foundry is adopting these technologies for its own purposes.

Besides–repeat after me–Cloud Foundry was never a container or container orchestration group. It is a PaaS foundation.

Sure, containers and orchestration are important. But when Subramanian claims, “Once you take the container runtime and container orchestration out of the equation, whatever remains from the original Cloud Foundry platform has very limited relevance,” he goes too far. No. Just, no.

Cloud Foundry executive director Abby Kearns said it best: “Our vision is to be the best cloud-native platform for developers. You should never bank on one specific, tiny technology to be the end game. That’s not the end game. The end game is to have a platform that allows customers to build, run, and scale applications.”

Bing! Bing! Bing! Exactly.

Sure you can do a lot of things with Kubernetes. It’s great, but Cloud Foundry is designed to make “Happy developers,” as Comcast open-source senior director Nithya Ruff put it at the Cloud Foundry Summit.

Cloud Foundry’s audience, as Karl Isenberg, one of its developers, explained on StackOverflow, is “enterprise application devs who want to deploy 12-factor stateless apps using Heroku-style buildpacks.”

In that piece he explains that “the twelve-factor app is a methodology for building software-as-a-service apps that:

“Use declarative formats for setup automation, to minimize time and cost for new developers joining the project

“Have a clean contract with the underlying operating system, offering maximum portability between execution environments

“Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration

“Minimize divergence between development and production, enabling continuous deployment for maximum agility

“And can scale up without significant changes to tooling, architecture, or development practices.”

That’s all good stuff, and it’s in Cloud Foundry by design. Kubernetes? Not so much.

Emphasizing this, Cloud Foundry also recently introduced Cloud Native Buildpacks. These enable you to automate building containers from source code. This is very handy for building any cloud application, but it works hand-in-glove with Kubernetes.

In short, Cloud Foundry is going to do just fine as a PaaS for developers building applications on the web, same as it ever was.