Cloud Foundry's embrace of Kubernetes is business as usual, not a "demise"

Cloud Foundry isn't capitulating on its dream by embracing Kubernetes—it's fulfilling that dream.

kubcloud.jpg
Image: buchachon, Getty Images/iStockphoto

Cloud Foundry may have its problems just like any other organization, but arguably, its decision to embrace Kubernetes isn't one of them, despite suggestions to the contrary. In fact, as Cloud Foundry Foundation executive director Abby Kearns put it, "Our vision is to be the best cloud native platform for developers," no matter the underlying technologies.

SEE: Cloud providers 2019: A buyer's guide (free PDF) (TechRepublic)

The death of a disco dancer

Ironically, while criticizing Pivotal for "hyper marketing" the Cloud Foundry platform, Rishidot analyst Krishnan Subramanian does a little hyper marketing himself. On the eve of a well-attended Cloud Foundry event, Subramanian wrote a eulogy "on the 'demise' of Cloud Foundry." I thought I had missed a major announcement—that the project had somehow folded. I scoured the internet, looking for news of this "demise."

To no avail.

Yes, I had friends pinging me to tell me that Pivotal, the company behind Cloud Foundry (now housed in its own foundation), was struggling. I looked at its financials: Narrowing losses and increased revenues. The stock price isn't at its peak, but it has been moving up consistently over the last six months. LinkedIn shows that the total head count has declined 14% over two years, and down 3% over the last six months. Not setting the world on fire, perhaps, but not dead, either. (And, as Begin co-founder Brian Leroux has noted of Pivotal's $5 billion market cap: "Hope I fail our a—— into a $5 billion niche business! lmao.")

And that's Pivotal, not Cloud Foundry. So when did Cloud Foundry die?

Digging into Subramanian's post, it becomes clear that he's using "demise" in a very particular way. Noting that Cloud Foundry's original container format (Garden, most recently) and orchestration engine (Diego) had both been replaced by industry standards (Docker and Kubernetes), he concludes: "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." Or, in his rendering, is dead.

When I asked for clarification, he obliged: "There is no magical experience or efficiency offered by Cloud Foundry which is not already available in Kubernetes ecosystem. This announcement only helps existing Cloud Foundry customers to use Kubernetes instead of Diego. Otherwise, Cloud Foundry as a concept is dead."

Is it, though?

Well, it happens a lot around here

With one caveat (which I'll come back to), for a company like Pivotal (or Red Hat or...name your enterprise vendor) it really (really) doesn't matter what the underlying technologies are. If Red Hat powered OpenShift with magical hamsters but customers got the scale and ease-of-use they require, no one (except maybe PETA) would mind. In like manner, the fact that Cloud Foundry has been changing the technologies that power its platform is immaterial to customer success with that platform.

SEE: Vendor comparison: Microsoft Azure, Amazon AWS, and Google Cloud (Tech Pro Research)

As Kearns put it to me, "For the last couple of days, I've been having conversations with users at our summit, users who are running tens of thousands of applications on Cloud Foundry, and plan to increase those numbers." When Cloud Foundry began, it offered functionality that Kubernetes couldn't match. That has since changed, which is why Pivotal engineer Oleksandr Slynko could write in October 2017 that Kubernetes would never replace Diego and then in May 2018 he reversed his adamant assertion to say "Sure it can." Pivotal, and Cloud Foundry, had to evolve to embrace what the market had chosen.

That decision, however, is driven by customers. As Kearns noted, "Having a stable platform is of the utmost importance. Being right on the technology hype cycle is not of the utmost importance." As Kubernetes matured and solidified industry support, it became the obvious answer to Cloud Foundry's container orchestration needs. Over time, Kearns went on, that might well change, with Cloud Foundry committed to swapping out technologies to keep with its core mission: "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."

Or, as Pivotal vice president Richard Seroter said, "Kubernetes is great. That's why it'll be part of Cloud Foundry, as are a dozen other great open source software projects we've swapped in over time. But the value of automating the path to production in a SINGLE platform is valuable on its own. And people pay for packaging of that, versus DIY."

Which brings us to the caveat I referenced above.

If you think peace is a common goal

There is value in embracing an industry trend first, and helping to shape it, as Pivotal/Cloud Foundry competitor Red Hat/OpenShift has done with Kubernetes. Back in 2015, Red Hat opted to skip joining the Cloud Foundry Foundation, and instead doubled down on Docker and, later, Kubernetes. Writing at the time, Red Hat's Joe Fernandes highlighted the importance of this choice:

With Linux containers at the core of many modern cloud application platforms, we felt it would be a lost opportunity to not embrace an emerging container standard. Red Hat has always worked to drive upstream standards in the Linux community, to help avoid technology fragmentation, and with containers we see the need for a similar approach. Standards for container formats (including packaging, APIs, index metadata) also enable us to collaborate with vendors like Google, Microsoft, IBM and others who have similarly decided to support Docker.

Similar motivations underlined the decision to go with Kubernetes:

Given Google's deep expertise in container technology and managing what is likely the largest containerized datacenter infrastructure in existence, we felt that standardizing on Kubernetes would be the right choice for OpenShift users. Today Red Hat is contributing extensively to Kubernetes, and working with the community to bring these capabilities to [Red Hat] customers.... And unlike Cloud Foundry Diego, we aren't investing in an OpenShift-specific container orchestration solution, but one that is being supported by a number of vendors including Microsoft, IBM, Mesosphere, CoreOS and more.

Cloud Foundry eventually reached the same conclusion, but there is value for Red Hat in having such a deep footprint in the open source communities around Docker and Kubernetes. While Red Hat doesn't control either community, it has "bought" itself influence with the code it has contributed. This puts it in a stronger position to support these still-emerging industry standards.

So, is Cloud Foundry "dead?" Nope. Not even close. But will it be that much more alive if it, in the future, helps to drive industry standards like Kubernetes, as Red Hat has done, rather than come to the party belatedly? Yes. Even so, full credit should be given to Pivotal for reaching the right conclusion at all: It's hard to change technology direction after big investments have been made. They've done this more than once, and that's a credit to its customer focus.

Also see

By Matt Asay

Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.