Back in the deep recesses of history (and, given that this is technology, history is a fluid term. I’m speaking here of five years ago), Cloud Foundry was incubated within VMware as an answer to the pretty obvious market requirement for a platform that went beyond servers (be they virtual or physical) and which automated more of the operational aspects of infrastructure.

This is pretty much the definition of Platform as a Service (PaaS), a term which has become very much passé these days but which was coined to explain the solution in between infrastructure and software (bonus below for those who want a primer on the cloud stack, a video I made many years ago).

At the time, the two big PaaS solutions were Heroku and Engineyard. Heroku was famously acquired by Salesforce for a pretty impressive (at the time) price and Engineyard… well, their container platform Deis was acquired by Microsoft last year and the shell of the company, inasmuch as there was anything left, was acquired by Crossover.

Time, and technology, don’t stand still

Back then, the idea of automating virtual servers was at the leading edge of infrastructure innovation and these PaaS offerings undeniably did a good job of making infrastructure more efficient. But things change, and a little-known Linux technology, containerization, was brought to the masses by Docker, the company that popularized the eponymously-named container offering. The concept of containerization grew like weeds and all of a sudden any platform that wasn’t container-ready was seriously on the back foot.

Bing, Bang, BOSH

Luckily, back in 2010, the smart people at VMware (the original home, remember, of Cloud Foundry) created a tool in order to deploy the then-nascent Cloud Foundry. BOSH was designed to manage the lifecycle of large distributed systems. Fortunately (or presciently) when BOSH was created, it wasn’t built to deploy virtual machines only, rather it was indifferent to the deployment of VMs or containers. As such, BOSH was, fortuitously future-proofing itself for the rise of containers.

PaaS in a container world

It was fortunate that BOSH gave Cloud Foundry a container-management story because, at least when it comes to mindshare and thought-leadership, containers have replaced VMs as the shiny new things. Now that’s not to say, for a minute, that VMs are no longer relevant. What it does mean, however, is that organizations looking to adopt platforms and approaches into the future will have “container support” in their due diligence checklist. BOSH helps Cloud Foundry tick that box.

Playing in the sandpit alongside Kubernetes

Of course, there are other container management offerings – Docker Swarm and Kubernetes, for example. And of those two, one remains relevant. Kubernetes seems to have won the container management battle and virtually all vendors and platform (even, ironically, Docker itself) have settled on Kubernetes for container management. This has created something of a conundrum for Cloud Foundry – if Kubernetes is the generally accepted container management platform, what does this mean for Cloud Foundry which also offers this service?

In a move to retain container relevance, Cloud Foundry last year announced the Cloud Foundry Container Runtime, an offering that helps those organizations who run both virtualized and containerized applications do so in parallel. At the time there was a bit of a kerfuffle, and Cloud Foundry executive director Abby Kearns spent a lot of time explaining the move and justifying Cloud Foundry’s existence in a container-heavy world.

The container runtime works within the context of Diego, Cloud Foundry’s own container service. But what if Kubernetes is your container service of choice? What options do you have? Two projects that were launched by the foundation at their recent summit help to answer that question.

Eerily Eirini

Project Eirini is the first of the new projects that more tightly tie Cloud Foundry to Kubernetes. Eirini, which was originally launched by IBM, before Suse and SAP jumped on board, allows operators to chose between using the existing Diego container orchestrator or, you guessed it, Kubernetes. It’s a move similar to that which Docker recently made when it announced that users could choose between Docker Swarm or Kubernetes – it’s also a pragmatic capitulation and acceptance that, when it comes to container management, Kubernetes has won.

While Cloud Foundry leadership spent time explaining particular use-cases where Diego is a better option (Windows support and high-requirement multitenancy situations being two examples), I suspect that most of the talk around container management in the Cloud Foundry community will, in the future, revolve around Kubernetes.

ContainerizedCF CF Containerization

The second new project announced is ContainerizedCF CF Containerization, an offering initially developed by Suse (historical note, Suse acquired Hewlett Packard Enterprise’s Cloud Foundry business and is now trying to make a go of it where HPE failed abysmally.) ContainerizedCF CF Containerization allows users to package the core Cloud Foundry Application Runtime and deploy it to Kubernetes clusters. If that sounds like the IT cliché of “turtles all the way down,” you’d be right. But Suse is adamant there is a use case for deploying Cloud Foundry on top of Kubernetes – indeed, this is what Suse is using internally to ship its own Cloud Foundry distro.

So, is Cloud Foundry still relevant?

A fair question, given all this Kubernetes love, is whether Cloud Foundry is even still relevant. It’s a question eerily similar to one asked over and over again in relation to OpenStack, the cloud operating system that launched to massive excitement and promise, only to miss delivering on its promise of allowing cloud vendors to go head-to-head with AWS (OpenStack is still a thing, and has been successful in some sectors, though not the ones promised).

So is Cloud Foundry superfluous? Itself destined to wither on the vine? Certainly not if a large number of enterprise users I spoke to at the event have anything to do with it. These users – from Boeing to Fidelity, from Volkswagen to Rabobank – see Cloud Foundry as a core part of how they deliver upon their digital ambitions. Cloud Foundry is, for these organizations, the key enabler for developer agility and efficiency.

Indeed, sitting in the NDA analyst session during the event, there were a number of raised eyebrows when one executive whose company has built much of their digital innovation strategy on top of Cloud Foundry articulated the view that Cloud Foundry as a platform will remain within his organization for a lifetime. Anyone who has spent any time around the technology industry will know that trends and technologies change and suggesting that anything will be in place many decades into the future is likely overstating the situation. That said, it is rare to hear that degree of bullishness from large enterprises and the message, while likely to prove inaccurate, bodes well for the Cloud Foundry project generally.

MyPOV

Cloud Foundry has deftly managed to avoid the fate that OpenStack has suffered. There are many reasons for that, not least of all the more measured amount of investment that came into the Cloud Foundry ecosystem at its beginnings. But the creation of BOSH, and the fact that Cloud Foundry’s container story is plausible, also helps. And if the customers who were attending the summit are anything to go by, Cloud Foundry is integral to their vision for the future. That’s a strong situation for a project to be in.

And whereas OpenStack was all about cloud infrastructure, since its inception, Cloud Foundry has been more about a developer experience and DevOps lifecycle management story. While OpenStack spent its early years telling anyone who would listen that it enabled users to compete with AWS, Cloud Foundry simply focused on its core message of developer agility – smart strategy, it seems.

Crystal ball gazing

I fully intend to be at next year’s Cloud Foundry summit and I very much suspect that we’ll be hearing the leadership announce the acceptance of an open source serverless initiative as part of the foundation. In its newfound quest to be the developer platform that covers all clouds, deployment models and platforms, serverless is the next tick box the foundation will need to cover – mark my words that they’ll do so

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

2 Comments
  • Zeeshan Bhatti |

    Hi Ben, long time follower and admirer. Excelent prespective! Where do you see the future of storage in a containerized world? The challenges that large amount of data and object “storage” are different from “compute”. Mounted volumes in containers cause more problems than it solves. The stateful nature of storage services makes it tough to implement “scalability-via-respawn”. Looking forward to read more from you on cloud storage solutions.

    • Hi Zeeshan, nice to hear from you. I was a (very) early investor in the company that went on to become CLusterHQ. It ultimately failed, but it was trying to solve the issues around storage with containers. Portworx is trying to do similarly…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.