The New Stack Podcast

Quarks vs. Eirini: What's the Difference?

Episode Summary

"Cloud Foundry is a project that predates Kubernetes, and as container orchestration has evolved, we have started seeing more microservice components built into Cloud Foundry that were used as a way to containerize to some extent. This speaks to the history of project Eirini and project Quarks," said TNS founder and Editor-in-Chief Alex Williams during a live interview recorded at Cloud Foundry Summit Europe, where he was joined by Jennifer Spinney, Staff Software Engineer at Pivotal, and Vlad Iovanov, Technical Lead at Cloud Foundry SUSE. Spinney went on to explain, "So, Cloud Foundry traditionally has this component called Diego, which is actually a rewrite of the old way that containers used to be run in Cloud Foundry via these DEAs, we replaced that with Diego when we did that we introduced this hard boundary between the API of CF and the back end that schedules containers and schedules your actual app workloads. So then when Kubernetes started picking up steam, because we have this hard boundary now between the Cloud Foundry API and the back end that's actually scheduling jobs, we could look at swapping out Diego with just Kubernetes because it's kind of doing the same thing. Back when we started Diego, Kubernetes wasn't fully there yet, there was still a lot of maturing to do. Now I think we're seeing Kubernetes becoming way more mature, and it's much more possible to just drop in Kubernetes instead of Diego."

Episode Notes

"Cloud Foundry is a project that predates Kubernetes, and as container orchestration has evolved, we have started seeing more microservice components built into Cloud Foundry that were used as a way to containerize to some extent. This speaks to the history of project Eirini and project Quarks," said TNS founder and Editor-in-Chief Alex Williams during a live interview recorded at Cloud Foundry Summit Europe, where he was joined by Jennifer Spinney, Staff Software Engineer at Pivotal, and Vlad Iovanov, Technical Lead at Cloud Foundry SUSE.

Spinney went on to explain, "So, Cloud Foundry traditionally has this component called Diego, which is actually a rewrite of the old way that containers used to be run in Cloud Foundry via these DEAs, we replaced that with Diego when we did that we introduced this hard boundary between the API of CF and the back end that schedules containers and schedules your actual app workloads. So then when Kubernetes started picking up steam, because we have this hard boundary now between the Cloud Foundry API and the back end that's actually scheduling jobs, we could look at swapping out Diego with just Kubernetes because it's kind of doing the same thing. Back when we started Diego, Kubernetes wasn't fully there yet, there was still a lot of maturing to do. Now I think we're seeing Kubernetes becoming way more mature, and it's much more possible to just drop in Kubernetes instead of Diego."