Cloud Foundry’s Eirini and the Commitment to Interoperability
Cloud Foundry sponsored this podcast.
Cloud Foundry Summit’s Theme of Interoperability and Eirini
A major theme at Cloud Foundry Summit North America last week in Philadelphia was interoperability and its importance to Cloud Foundry — as the core functional tests validating Cloud Foundry Application Runtime releases for Project Eirini begin.
Speaking to this during a podcast, hosted by The New Stack’s Alex Williams, founder and editor-in-chief, were:
- Dr. Xiujiao Gao, client lead and cloud engineer at Stark & Wayne;
- Bernd Krannich, technical lead, Cloud Foundry SAP;
- Julian Friedman, Cloud Foundry project lead, IBM.
As part of Cloud Foundry’s continued push to improve interoperability, Eirini was created with this goal in mind for scheduling for the Cloud Foundry Application Runtime. As Cloud Foundry notes, organizations can choose to adopt Diego/Garden or Kubernetes to orchestrate to application container instances.
Previously, container scheduling in Cloud Foundry was limited to Diego. This was the case because Cloud Foundry built Diego before other container schedulers, Friedman said. “So, we had to build our own, right? If you want to build a Cloud Foundry push experience, you’re going to need a container scheduler,” Friedman said. “One didn’t exist, so we built one.”
Today, Cloud Foundry can offer organizations a “Cloud Foundry push user experience whenever they want a Cloud Foundry push user experience,” Friedman said. “And I think that’s the big value — it’s broadening the number of places you can have a CF push and broadening the ecosystem because the Kubernetes ecosystem is so strong,” Friedman said. “Now, being able to take advantage of that is a huge thing.”
The creation of Eirini began as “market realities kicked in” and Kubernetes became the de facto standard for container management these days, Krannich said. “And so, it’s kind of clear for Cloud Foundry to stay relevant — you need to be able to respond to those market realities and the evolution overall,” Krannich said. “The other thing is there’s even more new technologies that are being pushed in the market and like maybe Kubernetes is even one of the more mature parts of that technology stack.”
With Kubernetes, Istio responds to another need in distributed systems, allowing “a big mesh of microservices talking to each other,” Krannich said. “And then I guess, as we all learn in computer science studies, the network not always being reliable, the service you want to talk to is not always being available, etc.,” Krannich said. “So, Istio is a technology that (kind of transparently for the people that are developing those services), deals with a couple of aspects, like how to actually kind of retry a call to another service if that service is not available for the first time,” Krannich said. “How to do that properly like it doesn’t really help to flood that service with request but you need to kind of time that a little bit, try after a second, try after two and then maybe wait a little bit longer. So things like that.”
Istio also serves as a way to secure communication between services, Krannich said. “Traditionally, we’ve asked service developers to deal with things like TLS encryption and all of these technologies themselves,” Krannich said. “And now, we are basically seeing a trend and Istio is one of the technologies that helps there which says, no actually, the people riding those services should be freed from the burden of doing that hard stuff and there should be common underlying technology that would deal with those aspects.”
Today, Kubernetes also obviously dominates container runtimes. “When we talk about in this community, you only really mean Kubernetes. There are other container runtimes but Kubernetes are more popular,” Gao said. “So, we try to see like what your team or your company need, then try to see what’s the better fit for you to requirement, because I see this community is really rich and diverse.”
In this Edition:
1:52: How the Eirini is a step forward.
4:22: Benefits of open source environments.
7:24: Comparison of runtimes.
11:10: Cloud Foundry versus other cloud-native technologies.
15:34: Exploring the graduation of abstractions and ‘leaky abstractions.’
20:26: Evolution of those abstractions.
