Take Kubernetes, and bish bash BOSH, you've got Container Runtime
Cloud Foundry project aims to make containers manageable
Announcing its updated and renamed Kubernetes and BOSH (Kubo) project as Container Runtime (CFCR) last month, Cloud Foundry said the project would give users greater "choice".
CFCR became Cloud Foundry's preferred method for deploying containers using Kubo, donated to the Cloud Foundry Foundation by Pivotal Software and Google in June.
But this it not simply a renaming of Kubo, according to Cloud Foundry Foundation CTO Chip Childers. "The project continues to progress in myriad ways on the technical side, has taken on new contributors and is moving forward as a clear way for Kubernetes to be delivered in an enterprise-grade fashion," he said.
Those new contributors have helped add a number of new feature releases to CFCR, he added. Changes include support for persistent volumes for various IaaS providers, compatibility testing with the Istio service mesh project, cluster self-healing, an update of the included Kubernetes version to 1.8.1, and the integration of the BOSH DNS and CredHub projects into the deployed environment.
Childers said, however, that it's not just the technical changes that boosted the acceptance of the new service. The biggest change was the increased support from the Cloud Foundry community.
A meeting of minds
He said that the new name was more than just a cosmetic change but an indication of its importance. "With a membership base of more than 40 per cent users and more than half of the Fortune 500 using Cloud Foundry Application Runtime today – by putting Container Runtime on parity, we're increasing the velocity with which Kubernetes is entering the enterprise by pairing it with Application Runtime."
The goal is to ensure that clusters using Kubernetes, from Google and stewarded by the Cloud Native Computing Foundation (CNCF), could be deployed either on-premises or in the public. You can now use CFCR to deploy either Kubernetes or the Foundry's Application Runtime.
BOSH, first released in 2010, is the open-source DevOps tool originally from VMware now with Cloud Foundry. It's important because it can be used to deploy, control and manage virtual workloads. It is particularly good at providing the type of monitoring capabilities that Kubernetes is lacking.
So, why are we suddenly interested in this notion of choice? Why is Cloud Foundry working with a core technology from a different group? Look to the uptake numbers.
For all the industry talk about containers, they're only being deployed in production in about 25 per cent of enterprises, according to a foundation survey – up from just 3 per cent last year.
Organisations are, meanwhile, going through tech changes – going, dare we say it, "digital".
Childers told The Reg: "An enormous number of customers are large enterprises going through this transformation processes, and it's going to be even larger as SUSE brings out their product and SAP cloud platform come onto the market."
This is about improving uptake of container technology, by making it easier to use outside the commonly accepted notion of the public cloud.
The group wants remove barriers to further adoption.
"It's not just about containers: this is a fundamental shift of thinking," Childers said. "If you think of the organisation as an organism, it's not to change its entire outlook."
If you build it, they will come
According to Childers, focus is on "creating an actual platform, not on creating a series of tools that can create the platform".
So how exactly is CFCR supposed to provide real choice? By targeting the independent software vendors (ISV).
"We know that there are a number of cases where you want to deploy a container and use some of the abstractions that the Kubernetes community has built. Some of the use cases I've seen include ISVs who want to distribute software as an OCI image or as a Docker image," Childers said.
"These are different types of systems to the ones deployed within Cloud Foundry. These are technologies that are often best packaged as a container and shipped to you that you want to include in your applications' overall architecture.
"The developer experience that we see evolving is one where you have unified identity across these two abstraction types that you can work well together, where you can host Kubernetes to work with a lot of backing services that you want to consume from your custom code."
How this might work in practice is if you have an older, monolithic application that you want to wrap as a Linux container. It may work quite well in Application Runtime but it may not – depending on its attributes. "We don't require that you follow all 12 factors in Application Runtime – we know a lot of apps don't fit those 12 factors. So, we may decide that to deploy that in the same environment, it's going to be wrapped in a container and then deployed in Container Runtime – we've given the users the choice," Childers said.
There's a recognition at Cloud Foundry Foundation that container must become more accessible and more manageable. There is hope, it seems, in its work with CNCF. ?