Cloud Foundry Embraces Kubernetes Runtime Environment
The Cloud Foundry Foundation (CFF), at a Cloud Foundry Summit Europe conference, announced it will make the Cloud Foundry Container Runtime (CFCR) the default runtime for deploying applications on Kubernetes clusters, using the BOSH lifecycle management tools it developed to manage the components that make up the foundation’s open-source platform-as-a-service (PaaS) environment.
Abby Kearns, executive director of the CFF, says DevOps teams now can choose between CFCR, formerly known as Kubo, to deploy applications on Kubernetes or continue to use Application Runtime, previously Elastic Runtime, which CFF also provides for deploying applications. CFCR is based on a runtime that Google and Pivotal, a unit of Dell Technologies, developed based on the BOSH frameworks for deploying distributed services. That means that whether a DevOps teams opts for CFCR or Application Runtime, it will be employing the same base technology to employ a runtime environment, says Kearns.
The CCF also announced that CFCR can also now claim default support for Istio, an open-source mesh for connecting disparate microservices based on technology jointly developed by Google, IBM and Lyft. In addition, support for storage persistence on Google Cloud Platform (GCP), Amazon Web Services (AWS) and VMware vSphere have been added to CFCR.
Kearns says the CFF expects to see IT organizations that have standardized on CFF to employ both. In fact, she notes that an existing Open Services Broker API developed by The Linux Foundation will also play a pivotal role in integrating applications deployed using multiple runtime environments.
In general, the CFF is positioning Kubernetes as a complementary deployment platform. Kearns says the application runtime the CFF developed is being used to support both legacy and new applications, while support for Kubernetes enables the Cloud Foundry PaaS to also support a new generation of microservices applications based on containers. She notes that while 25 percent of IT organizations today have deployed applications in production based on containers, most application workloads based on a 12-factor methodology for building modern applications continue to be deployed on runtimes such as Application Runtime.
Going forward, DevOps teams will need to support multiple application runtime environments. Kearns says the decision regarding what runtime environment to employ now comes down to determining the right tools for the right job versus being forced to pick one over another. In fact, she says organizations’ biggest challenge has more to do with adopting their internal IT processes and cultures than it does any specific technology platform.
For the better part of the last year CFF has been coming to terms with the rise of container-as-a-service (CaaS) platforms based on Kubernetes that have been positioned as a lighter-weight alternative to a traditional PaaS. Red Hat has even gone so far as to completely rewrite its PaaS environment on top of a Kubernetes foundation. But while a CaaS platform is often chosen by individual developers, the CF PaaS environment requires a major commitment from an IT organization to deploy and maintain. In many cases, developers building applications using containers simply don’t have access to a PaaS at all. As both CaaS and PaaS environments continue to evolve, the CFF is moving to ensure its continued long-term relevance by supporting multiple runtime environments in addition to overseeing the development of Kubernetes technologies such as those from the Cloud Native Computing Foundation (CNCF).
Of course, the line between what the CFF controls and what CNCF, which oversees the development of Kubernetes, is responsible has yet to be drawn. In the meantime, DevOps teams can take some comfort in the fact that ongoing research between the CFF and Kubernetes camps is being increasingly shared.
