With Project Eirini, Cloud Foundry Adapts to a New Open Source Ecosystem
The days of Cloud Foundry’s youth are behind us. That much is apparent at the Cloud Foundry Summit in Philadelphia this week. Now comes the continuing transition from an open source platform for launching 12-factor apps to one that respects its roots but continues to expand with Project Eirini, a Kubernetes backend for Cloud Foundry that deploys Cloud Foundry apps to a Kubernetes backend, using OCI images and Kubernetes deployments.
Described on GitHub as an “Orchestrator Provider Interface” (OPI), Eirini can be used to translate run-time instructions written for Diego, the scheduler built for Cloud Foundry, so they can be understood by Kubernetes. Eirini is built as a backend scheduler with an API that abstracts away orchestration from Cloud Foundry’s control plane. It can work with any scheduler, be it Diego, Kubernetes or Docker Swarm. At its core, OCI embraces the concepts of Long Running Processes (LRPs) and Tasks that maps to orchestrators. Currently, this means support for Kubernetes. Other orchestrators may be integrated as long as there is an implementation of the OPI layer for the target platform.
Eirini was originally developed by IBM, which showed a use case in a Cloud Foundry Summit keynote by Jason McGee and Briana Frank.
IBM developed #ProjectEirini to manage and extend #CloudFoundry services within #Kubernetes environments. Now supported in @IBM's enterprise @cloudfoundry distro. — @jrmcgee, @FranklyBriana #CFSummit pic.twitter.com/BUBxZ8ZpK5
— The New Stack (@thenewstack) April 4, 2019
At the Cloud Foundry Summit, Eirini is the center of attention. It reflects the change and adaptation that has come as member organizations mature and develop their developer teams. Vendors are adapting to the changes that have come as open source communities have become the epicenter of application development. The change is an external one for all involved. The communities develop the technologies that developers then use to build modern applications that use multiple services in what we generally know as a microservices approach.
Cloud Foundry Building the Future
The Cloud Foundry Foundation has had to adapt over the years, especially as open source technologies such as Kubernetes have received such attention. Cloud Foundry leaders will often like to talk about how Kubernetes is hyped. They make their point that it’s not always new and shiny that’s needed. Customers at Fortune 500 companies need the basics for their growing developer teams. A 12-factor app is still complicated enough for organizations new to continuous integration and continuous delivery. The antidote has historically been to provide professional services to help members build out their teams and begin the process of at scale development, deployment and management.
Pivotal, the leading CF provider, has built a platform that uses a pair programming model to help organizations build developer teams. The company’s approach is popular with customers such as Comcast, which have used the model to move beyond its scope as a cable television provider to multichannel entertainment provider.
The Comcast story: Making the transition from a telecom operations company to a technology and a product organization and now a company focusing on the customer experience. Customer experience stems from “happy developers” who build the technology and the products. #CFSummit pic.twitter.com/g6Eg8sOgH5
— alexander hazard williams iv (@alexwilliams) April 2, 2019
And so the discussion continues over the future of Cloud Foundry. And its direction. But it’s not just about Cloud Foundry any more, It’s how Cloud Foundry interoperates with different runtimes, cloud services, schedulers and orchestration engines. Kubernetes may get a lot of attention but its future is also questioned, enough so that even with Kubernetes enjoying such wild popularity, customers still want Diego to be alive and well.
Cloud Foundry is used by about half of the Fortune 500 companies such as Comcast, Liberty Mutual and Home Depot. It is alive and well even if it is not the “one” platform that it used to be.
It’s absurd to believe that there is just one platform anymore. It’s also absurd to focus on the hype of one platform when there are so many other services that are dependent upon each other. CF had to adapt to this new world and so have its customers who have long depended on Diego as their scheduler of choice. But Diego is tightly bound to CF and the shift, as it has been for years, is for more loosely coupled architectures across distributed systems.
Still, the concern about shifting away from Diego is real. Developers have traditionally used the Cloud Foundry API (CAPI) to push their code to their apps. Further, Diego is critical to platform operators who use Diego to monitor the application, its resiliency and a host of other factors.
But the reality is that economics are deep at play. No one company can develop the software. They just don’t have the manpower to build, deploy and support a technology stack and then sell it for hundreds of thousands of dollars. It’s too expensive for them and developers have too many options available.
For open source communities, it’s also a matter of economics. Organizations like Cloud Foundry have to adapt to meet the needs of their community and large vendors such as Pivotal that are dedicating engineers to the project.
And the users themselves? For the sponsors of The Cloud Foundry Foundation, such as Comcast, the focus on developer tooling has brought upside.
Cloud Foundry and Pivotal are sponsors of The New Stack.
