I am writing blog entries to coincide with my new YouTube videos. I have started a series of videos exploring many of the capabilities of the IBM Cloud. Part 1 focuses on deploying a simple Node.js application to the IBM Cloud using Cloud Foundry. Please watch the video and give me your feedback. CF is still a viable deployment platform and IBM will continue to provide this as a first class citizen.
One thing I didn’t point out in the video. The full Cloud Foundry command line is available as a part of the IBM Cloud CLI. IBM does not force you into a customer flavor of Cloud Foundry in any way.
CF was the foundation of the original IBM Cloud. Everything was built on top of the CF ideas of orgs, spaces, and the Cloud Foundry service broker. IBM was and still is the single largest Cloud Foundry implementation.
But things have changed. The emergence of Kubernetes and the realization that deploying new CF services around the world is not nearly as quick and nimble as necessary. Deploying new cloud services in new regions of the world requires manual work. With the IBM Cloud growing to new regions and data centers every day, having to manually run procedures and configure things is not the fast enough.
So IBM made the choice to change the underpinnings of its cloud. IBM went full in on Kubernetes and Kube is now the foundation of the IBM Cloud. IBM still supports CF but there is now a Kube layer in the middle that allows IBM to create and offer new services in new regions in a fully automated way. This has drastically impacted IBM’s ability to propagate new services around the globe to new regions quickly.
The other challenge that IBM needed to tackle was providing a dedicated Cloud Foundry offering. There is a large set of customers that don’t like the multi-tenant idea when it comes to their cloud platform. They don’t want noisy neighbors and they want some assurance that they are running their workloads on an isolated platform. This posed a problem. Setting up a dedicated Cloud Foundry instance was a very manually intensive process. Dedicated hardware needed to be acquired and then a customer implementation of Cloud Foundry deployed to it. IBM did it and it didn’t scale.
So IBM ventured out to try and containerize Cloud Foundry. This was done a bit ahead of the Cloud Foundry Foundation but has since become embraced as a first class project within the foundation. Read about it here and here. What does this do for me? This now allows one to spin up a new instance of the Cloud Foundry Application Runtime on top of a Kubernetes cluster by simply deploying a Helm chart. Voilà. We now have a way to offer on-demand Cloud Foundry instances using Kubernetes as the underlying platform. Since we can control all types of networking things with Kube clusters, IBM can now offer dedicated and siloed private implementations of Cloud Foundry running in the public cloud. Go get yourself one here.
On-demand Cloud Foundry has been a game changer. My opinion is that this will become the standard way to get Cloud Foundry in the IBM Cloud sometime in the future.
By the way, this has also allowed IBM to provide Cloud Foundry as an offering on top of the IBM Cloud Private solution. Another key advantage of containerized Cloud Foundry.
Cloud Foundry continues to remain popular with developers. And why not, it is simple and easy and removes from developers any reason to think about plumbing. But there is no arguing with the fact that Kubernetes is currently the thing. This explains the Cloud Foundry Organization’s Eirini project which allows you to run Kubernetes instead of Diego as the Cloud Foundry orchestration engine.