Containers are eating the software world — and Kubernetes is the king of containers. So if you are working on any major software project, especially in the enterprise, you will run into it sooner or later. Cloud Foundry, which hosted its semi-annual developer conference in Boston this week, is an interesting example for this.
Outside of the world of enterprise developers, Cloud Foundry remains a bit of an unknown entity, despite having users in at least half of the Fortune 500 companies (though in the startup world, it has almost no traction). If you are unfamiliar with Cloud Foundry, you can think of it as somewhat similar to Heroku, but as an open-source project with a large commercial ecosystem and the ability to run it at scale on any cloud or on-premises installation. Developers write their code (following the twelve-factor methodology), define what it needs to run and Cloud Foundry handles all of the underlying infrastructure and — if necessary — scaling. Ideally, that frees up the developer from having to think about where their applications will run and lets them work more efficiently.
To enable all of this, the Cloud Foundry Foundation made a very early bet on containers, even before Docker was a thing. Since Kubernetes wasn’t around at the time, the various companies involved in Cloud Foundry came together to build their own container orchestration system, which still underpins much of the service today. As it took off, though, the pressure to bring support for Kubernetes grew inside of the Cloud Foundry ecosystem. Last year, the Foundation announced its first major move in this direction by launching its Kubernetes-based Container Runtime for managing containers, which sits next to the existing Application Runtime. With this, developers can use Cloud Foundry to run and manage their new (and existing) monolithic apps and run them in parallel with the new services they develop.
But remember how Cloud Foundry also still uses its own container service for the Application Runtime? There is really no reason to do that now that Kubernetes (and the various other projects in its ecosystem) have become the default of handling containers. It’s maybe no surprise then that there is now a Cloud Foundry project that aims to rip out the old container management systems and replace them with Kubernetes. The container management piece isn’t what differentiates Cloud Foundry, after all. Instead, it’s the developer experience — and at the end of the day, the whole point of Cloud Foundry is that developers shouldn’t have to care about the internal plumbing of the infrastructure.
There is another aspect to how the Cloud Foundry ecosystem is embracing Kubernetes, too. Since Cloud Foundry is also just software, there’s nothing stopping you from running it on top of Kubernetes, too. And with that, it’s no surprise that some of the largest Cloud Foundry vendors, including SUSE and IBM, are doing exactly that.
The SUSE Cloud Application Platform, which is a certified Cloud Foundry distribution, can run on any public cloud Kubernetes infrastructure, including the Microsoft Azure Container service. As the SUSE team told me, that means it’s not just easier to deploy, but also far less resource-intensive to run.
Similarly, IBM is now offering Cloud Foundry on top of Kubernetes for its customers, though it’s only calling this an experimental product for now. IBM’s GM of Cloud Developer Services Don Boulia stressed that IBM’s customers were mostly looking for ways to run their workloads in an isolated environment that isn’t shared with other IBM customers.
Boulia also stressed that for most customers, it’s not about Kubernetes versus Cloud Foundry. For most of his customers, using Kubernetes by itself is very much about moving their existing applications to the cloud. And for new applications, those customers are then opting to run Cloud Foundry.
That’s something the SUSE team also stressed. One pattern SUSE has seen is that potential customers come to it with the idea of setting up a container environment and then, over the course of the conversation, decide to implement Cloud Foundry as well.
Indeed, the message of this week’s event was very much that Kubernetes and Cloud Foundry are complementary technologies. That’s something Chen Goldberg, Google’s Director of Engineering for Container Engine and Kubernetes, also stressed during a panel discussion at the event.
Both the Cloud Foundry Foundation and the Cloud Native Computing Foundation (CNCF), the home of Kubernetes, are under the umbrella of the Linux Foundation. They take somewhat different approaches to their communities, with Cloud Foundry stressing enterprise users far more than the CNCF. There are probably some politics at play here, but for the most part, the two organizations seem friendly enough — and they do share a number of members. “We are part of CNCF and part of Cloud Foundry foundation,” Pivotal CEO Rob Mee told our own Ron Miller. “Those communities are increasingly sharing tech back and forth and evolving together. Not entirely independent and not competitive either. Lot of complexity and subtlety. CNCF and Cloud Foundry are part of a larger ecosystem with complimentary and converging tech.”
We’ll likely see more of this technology sharing — and maybe collaboration — between the CNCF and Cloud Foundry going forward. The CNCF is, after all, the home of a number of very interesting projects for building cloud-native applications that do have their fair share of use cases in Cloud Foundry, too.
No comments:
Post a Comment