IBM Experiments with Cloud Foundry on Kubernetes
IBM is moving to make an experimental instance of the Cloud Foundry platform-as-a-service (PaaS) environment available on the IBM Cloud Private that runs on top of Kubernetes.
Cloud Foundry already has its own container orchestration engine known as Diego. By deploying it on Kubernetes, IBM is effectively giving customers the option of using what is rapidly emerging as a de facto container orchestration standard, says Don Boullia, says general manager for Cloud Developer Services at IBM.
IBM is making Cloud Foundry running on Kubernetes available on hypervisors. But Boulia says IBM will also make it available running on Kubernetes on bare-metal servers. IBM just made available an instance of Kubernetes running on bare-metal servers on its cloud last month. Customers should expect to be able to deploy Cloud Foundry on Kubernetes on-premises as well, says Boullia.
Cloud Foundry has committed to eventually converging Kubernetes and its PaaS environment. But IBM is clearly moving ahead on its own. The ability to deploy Cloud Foundry on Kubernetes is enabled by an open source Fissle tool developed by SUSE, a unit of Micro Focus.
One of the most immediate benefits of that approach is it immediately reduces the number of hypervisors required to stand up Cloud Foundry. Today a base level implementation of Cloud Foundry requires a dozen or more virtual machines to stand up. Boullia says that same base level implementation running on Kubernetes can be stood up using as few as three virtual machines.
Shrinking that base is also key to expanding the base of customers that can deploy Cloud Foundry. A PaaS environment requiring anywhere from a dozen to 40 virtual machines to support is a large-scale IT effort that outside of the Fortune 500 few organizations can afford.
At present, the Cloud Foundry Foundation (CFF) is trying to work through all the political issues associated with embracing Kubernetes for container orchestration. Boulia says in time the CFF may elevate Kubernetes to be a peer of Diego or replace Diego with Kubernetes altogether. Longer term, it’s questionable how much Diego will be supported given the size of the community now contributing to the Kubernetes. That issue may also become more pressing as Red Hat presses forward with a rival PaaS environment that has already integrated Kubernetes.
At the same time, rivals such as Docker Inc. continue to aggressively make the case for a lighter-weight container-as-a-service (CaaS) environment running on Docker Swarm or Kubernetes that can be employed more broadly than PaaS environments such as Cloud Foundry that focus mainly on 12-factor applications.
It’s pretty clear the rise of container orchestration platforms is driving a massive wave of transformation across application development platforms. For example, it’s not clear that going forward there is a need for hypervisors to run a PaaS or CaaS environment. Long term, most large organizations will wind up supporting multiple classes of application development platforms, all of which would be much easier to support if they shared a common container orchestration engine.
