Summary: IBM’s Eirini Project allows Cloud Foundry’s runtime component to be replaced with Kubernetes. Combining these two technologies enables both operators and developers to be more productive.
Technology executives and managers at large enterprises have a tough job in 2019 because the landscape of enterprise cloud IT is complex and rapidly changing. Deciding which technologies are right for your business’s needs is a daunting task.
One of these decisions is that of which platform will run your organization’s apps. Kubernetes and Cloud Foundry are the two main players in this space and deciding between them can be daunting. Each comes with its own set of strengths and weaknesses for operators and developers alike.
Cloud Foundry’s biggest strength is its developer experience: A simple cf push transforms a developer’s source code into a running, routable container.
Kubernetes’ biggest strengths are running containers and its massive, Google-backed community.
IBM’s Eirini project allows its users to take advantage of both of these strengths in a single platform by allowing Cloud Foundry to run its apps on a Kubernetes cluster. In other words, Eirini replaces CF’s Diego runtime component with Kubernetes.
With this configuration, Cloud Foundry’s developer experience remains unchanged. However, an operations team deploying and operating CF no longer needs to learn how to network, debug, and scale containers running on a niche, CF-dedicated runtime like Diego. They can instead use their existing Kubernetes knowledge and expertise to support both the apps that are running on Cloud Foundry and any other services running directly on Kubernetes that apps consume.
Things get really interesting when Eirini is combined with SuseCF, which is a distribution of Cloud Foundry in which each component of the platform runs inside of a container instead of a bosh-deployed VM. SuseCF can run on a Kubernetes cluster and use Eirini to push its apps to that same Kubernetes cluster. This way, platform operators don’t have to spend their time learning Bosh and Diego just to deploy CF. They can instead spend all of their time making your organization better at running Kubernetes.
Behind the scenes, Eirini accomplishes its runtime-switching-magic via a construct called the Orchestration Provider Interface (OPI). This interface is inspired by Bosh’s Cloud Provider Interface (CPI). In the same way that the CPI allows Bosh’s user experience to remain the same regardless of the cloud provider (AWS, GCP, Azure) that infrastructure is being provisioned on, Eirini’s OPI concept allows the CF developer experience to remain the same regardless of which container runtime the apps actually end up running on.
Eirini takes the CF commands given to the OPI and turns them into runtime-specific commands that result in your app running on Kubernetes as a StatefulSet.
The Eirini Project’s vision is a bit bigger than just integrating Cloud Foundry with Kubernetes, though. The OPI provides the foundation for Cloud Foundry to act as a developer’s front-end to any container runtime. This will allow developers to keep using the same cf push experience that they love, even as the world of container runtimes continues to change and develop.
Eirini’s development can be followed on the project’s github, and instructions for deploying to an existing Kubernetes cluster can be found here. These deployment instructions use the SuseCF + Eirini configuration that was mentioned above in order to deploy CF to Kubernetes and deploy CF’s apps to the same Kubernetes.
Spread the word
