IBM Cloud Foundry Enterprise Environment Now Offers a Tech Preview of Project Eirini

5 min read

By: Carl Swanson, Julz Friedman, and Uwe Fassnacht

Project Eirini: Bringing Kubernetes and Cloud Foundry together

The North America Cloud Foundry Summit 2019 is taking place April 2–4, bringing together contributors to the open source Cloud Foundry project, vendors, and end users of the technology.

The cloud-native space had a particularly exciting year in 2018 as Kubernetes continued to grow in popularity, and now, Cloud Foundry is coming together with this industry-leading container orchestration platform.

In this post, we’re going to talk about this merging technology trend and how (and why) IBM is leading an effort—Project Eirini—to combine the benefits of Cloud Foundry and Kubernetes.

Eirini

At first glance, you would think that there is a lot of overlap between Kubernetes and Cloud Foundry. Both have been built to “deploy, scale, and manage applications deployed into containers.” If they both manage container applications, what’s going on? Why was Kubernetes created? What is the difference? Similarities? Which is better? Do they overlap? Can they be used together? What comes next and what is IBM doing to help that happen?

Key questions

There are some important questions to answer, so let’s go through them:

Why was Cloud Foundry created? Cloud Foundry was created with the mission of delivering applications to the cloud quickly, easily, and with the full capabilities of mature “cloud-native” hosting, such as seamless building, rapid deployment, flexible scaling, and important service integration. Created and deployed as containers, applications operate smoothly with cloud-native application development. Applications are stateless, making them dramatically easier to scale, operate, and manage. Applications of this nature are often referred to as 12-factor apps.

Why was Kubernetes created? Open-sourced by Google in 2014, Kubernetes focuses on orchestrating containers by providing primitives such as pods, nodes, statefulsets, replicasets, and deployments. Kubernetes has been described by its founders as a platform for platforms, used to create other delivery platforms, and it is increasingly important for enterprises as they embrace hybrid cloud strategies.

What are the similarities and differences? Both Cloud Foundry and Kubernetes are open source systems with large, healthy ecosystems and passionate users. Kubernetes provides a flexible system and is operator-focused, but it adds complexity in running simple and stateless applications. Cloud Foundry provides a higher-level, developer-focused user experience. The two platforms have overlapping uses, but very different sweet-spots. Kubernetes excels at operating complex, distributed systems, while Cloud Foundry can be significantly simpler and more effective for deploying and managing 12-factor applications. Cloud Foundry explicitly separates the roles of platform operators and developers, with a focus on enhancing developer productivity. More importantly, Cloud Foundry is built as a multi-tenant system, whereas Kubernetes is not currently recommended in multi-tenant contexts. This allows small teams to maintain and provide a single Cloud Foundry cluster for a large number of users.

Which is “better”? The question about “better” really depends on the audience. Is peanut butter or jelly better? It’s not about better, it’s that the target audiences for Kubernetes and Cloud Foundry are different.

Companies building cloud-native applications tend to have users with distinct roles—developers and operators. More often than not, these roles tend to fall in different departments. Both need and use different tools to get their jobs done. Developers are responsible for high-throughput application design and development (not platform and cluster management), so they need a rapid developer experience. Operatorsare responsible for deploying and ensuring the high-availability and resiliency of applications, and they need a flexible platform that allows complex deployments to satisfy HA, DR, and isolation constraints.

Maybe we should take a page from @kelseyhightower, who advocates for Kubernetes at Google:

@kelseyhightower

Or perhaps from Joe Beda, one of the original founders of Kubernetes, who had some excellent points in his great talk at DevOpsDays Seattle 2018: “Kubernetes Is A Platform Platform.

“Kubernetes is not just a platform, but it’s a platform for building platforms . . . It’s not just a great place to run distributed systems, it’s a great pattern for building the control planes for distributed systems . . .”

“In terms of looking at this whole idea of orchestration and containers and cloud-native, I feel like we’re very much at the beginning . . . We’re getting more and more support built in by the various cloud providers, and that’s just the beginning of seeing what we’re gonna be able to do on top of this platform, and I think that there’s a huge amount of room to do really interesting stuff that I think none of us who started the project really foresaw from the start . . .”

So clearly “better” isn’t the question. The real question is: “Who is each technology tool directed toward?”

The merging of technologies

Diego

We agree that Kubernetes should be used to build other platforms.

Some of the leading cloud vendors—including SUSE, SAP, Google, Pivotal, and IBM—are all working together on a Cloud Foundry project called Eirini. It enables pluggable scheduling for the Cloud Foundry Application Runtime. Specifically, it allows operators to choose whether the Cloud Foundry Application Runtime should use Diego (the default scheduler in CFAR) or the Kubernetes Scheduler to orchestrate application container instances. The project’s goal is to provide the option of reusing an existing Kubernetes cluster infrastructure to host applications deployed by CFAR.

Throughout several sessions at the Cloud Foundry Summit 2019—including a keynote demo from Dr. Julian Friedman, Open Source Development Leader at IBM and Project Lead for Eirini—IBM and other cloud vendors will walk through the latest around these efforts, technologies, and results.

On IBM Cloud, IBM Cloud Foundry Enterprise Environment has a new deployment option in “Technology Preview” that uses the Kubernetes scheduler for Cloud Foundry scheduling operations. It is available for self-provisioning today.

As Cloud Foundry and Kubernetes work closely together, everyone wins (but mostly app delivery teams).

Get involved!

If you’re interested in getting the best developer and operator cloud experience, and if you’re looking to learn more, test out new ideas, and generally support the movement forward of this amazing synergy, take a step and jump in!

Cloud Foundry Summit 2019 sessions

See all the great sessions at the CF Summit 2019. You can watch them later on video if you cannot attend in person.

Be the first to hear about news, product updates, and innovation from IBM Cloud