One of the most common questions being asked at the Cloud Foundry Summit last week – in my appearance on The Cube here, for example – was a predictable one: what about Kubernetes? The seriousness and intent of the question varied: some were genuinely curious as to how the two projects conflict and coexist. Others used the question as a rhetorical mechanism – a dig, in most cases.
Before we get to that, it’s worth revisiting the history of the projects briefly. Cloud Foundry, first released publicly in 2011, was a project that served a functional role similar to traditional middleware. Where the former served as an abstraction layer in between Java applications and the underlying hardware and operating system they ran on, Cloud Foundry was a multi-runtime bridge to and between on and off premise cloud environments.
Significantly, it predated the explosion in popularity of an older virtualization-like technology, which arrived in 2013 with the emergence of a developer-friendly package of container technologies in Docker.
Docker, as RedMonk has observed previously, was a technology that grew at a rate we hadn’t seen before. Within a year of its release it was showing up regularly in briefings; within two, it was in most briefings, even those whose connection to container technologies was tenuous at best. We call this practice “Docker-washing.”
While Cloud Foundry has a much broader functional mandate than a standard Docker container, questions about the relationship between the two were immediately raised. Docker was an immensely popular technology amongst developers, while Cloud Foundry’s strength historically has been more towards the operations end of the spectrum. And like employees that want to bring their iPhones to work, developers increasingly sought a means for bringing their containers from their workstation through to production.
Cloud Foundry’s messaging around containers was less than clear and at times contradictory, but via projects like Diego it was clearly responding to accelerating demand for containers in a Cloud Foundry context. It took a few years, however, for that to become the default approach. In the meantime, other players were targeting that same demand, the most notable of which was Google.
In June of 2014, the search giant and would-be cloud provider made Kubernetes available. Google was at the time, and likely still is, the largest container-based environment in the world. At Google, containers were managed by an internal management system called Borg. This was unique to Google’s environment, however, so rather than try and adapt it to make it more generic some of its authors created a new container orchestration platform. Like many later popular technologies – VMware comes to mind – it was frequently dismissed as “a toy” and, on one occasion, “a watered down version of a real container management system.”
In the last eighteen months, due to a number of factors, Kubernetes has exploded as a project; here are some numbers from my colleague on the subject. Kubernetes was a project with an interesting pedigree but uncertain future two years ago; today its path is clear. It’s becoming the default for container-centric workloads for many vendors we speak with, and is seeing a commensurate spike in commercialization (e.g. Heptio), governance (CNCF) and investment (Istio). Gone are the claims, in other words, that Kubernetes is a toy.
Which brings us back to the original question from the Summit: what about Kubernetes?
There are many potential answers to this question, but in the short to medium term it seems probable that the best is: different tools for different jobs. It’s true that Cloud Foundry and Kubernetes have substantial functional overlap. It’s also true that that this is likely to increase rather than decrease. But they remain differentiated in approach, audience and opinons.
Kubernetes is, by design and definition, container-centric in its approach. It is described by one of its founders as “fundamentally a tool box.” Cloud Foundry, by contrast, container abilities like Diego notwihstanding, is application-centric. It is more production line than toolbox, in a sense. These approaches are neither mutually exclusive or inclusive, and indeed can and often are leveraged by different business units within the same organization depending on need.
The problem with the Cloud Foundry and Kubernetes conversation, then, isn’t the question of how the projects compare to one another. It’s the common and reductive assumption that there can be only one. The implicit assertion that Cloud Foundry and Kubernetes are the only two variables in a zero sum equation ignores both the differences between the two projects and the wider market context. Even if we assumed, counterfactually at present, that one of the two approaches could satisfy both projects’ audiences, there remains a large and growing number of other options which are neither app nor container-centric, with the function-centric serverless being perhaps the most obvious.
Seven years ago, in a presentation to Java advocates at the wonderful FOSDEM conference in Brussels, I told Java advocates that their favorite language was unlikely to ever be as popular as it once had been on a percentage of share basis. Also, that this was not particularly relevant, because its marketshare had been artificially inflated by an absence of competition. Where once enterprises would sanction only Java or .NET apps, even seven years ago they were increasingly open to JavaScript, Python and a host of others. Once the dominant player, Java was now merely a dominant player. All these years later, what is the quantitative impact on Java’s share? Java is so dead that it remains number two on our rankings.
It’s difficult to compare programming languages and platforms, of course, but this was the analogy that most frequently came to mind last week. Cloud Foundry is unlikely to be as popular as it was shortly after it launched, when it was the only open source PaaS platform available. But this says little about Cloud Foundry, and more about the platform market which – like every other infrastructure market – is exploding with choice to the point of being problematic. It also ignores the ability for the Cloud Foundry foundation to actively embrace this choice via the addition of Kubo.
Kubernetes advocates should be rightfully proud of their project’s trajectory. But if that success means that Cloud Foundry’s dead, it’s dead the same way that Java is dead.
Disclosure: The Cloud Foundry Foundation, GE, IBM and Pivotal (CF) are all RedMonk clients, as are CoreOS, Google and IBM (k8s).
