SUSE’s Bridge Between Kubernetes & Cloud Foundry: Thomas Di Giacomo

Yeah, you're right. So it started at SUSE quite a while ago, actually, since the acquisition of some of the HPE assets back in 2017-2018. We started to work with the team coming also from ActiveState, and from the very beginning we wanted to provide the Cloud Foundry developer experience, the cf push experience, to Kubernetes clusters and Kubernetes infrastructure. So it was there from the beginning, and it was not that easy because Cloud Foundry was designed as a platform including container orchestration. So we had to make some tricks so that both things would also be certified. We didn't want to have a non-certified Cloud Foundry distribution, but we wanted to make it more Kubernetes-native from day one. And so we've done that for a couple of years, improving the technology, containerizing Cloud Foundry, working with the Cloud Foundry community, because at the same time Cloud Foundry was evolving and having more features and capabilities. And along the way we started to work with partners, with IBM, with SAP. We also started to work on and having an alternative to the Kubernetes container infrastructure called Eirini. So that's the project Eirini. And for us at SUSE, it's always better to work inside a community than outside. So SUSE Cloud Foundry was already open source, it was already on GitHub, we were already working with partners, but it's a lot better when you're part of the foundation, for the community, for the governance, to get more contributions and more interactions with other partners and other Cloud Foundry technologies. So I think the technology has been mature for a while, and it was time to do that and get some inputs and contributions from other people. Traditionally, some people would look at Cloud Foundry and Kubernetes as a competing platform, but the fact is a lot of users use both.

There are different use cases. Sometimes you need Cloud Foundry for 12-factor applications and cloud-native applications. Sometimes you just need a container infrastructure, but most companies need both. And what was happening, or what is still happening most of the time, is that they have two different platforms that are not directly connected to each other. They have to operate two different platforms, or applications and data are running on two different platforms. And that's what we wanted to avoid, providing the two technologies together so that you could run and develop some of the applications with Cloud Foundry, or you could run some of the containerized applications directly on Kubernetes. Do some migration over time potentially as well, but with the same platform, the same operational processes, the same dashboard, the same monitoring. It's also why we are spending a lot of time and work on Stratos, which is a Cloud Foundry user interface but which can also monitor and manage Kubernetes clusters now, so that you provide the same experience for that platform irrespective of whether you're doing only Kubernetes or Kubernetes and Cloud Foundry together. And it makes things a lot simpler, actually.

Yeah, that's extremely important. That's one of the benefits of open source projects, to make sure that when you go from one platform to another from a different vendor, you don't have to redo everything. And so from the very beginning, when we started to containerize Cloud Foundry, we wanted to make sure that it was platform-certified, that we were providing the same functionality, the same compatibility, the same interfaces that traditional upstream Cloud Foundry would do. And actually we did from the very beginning. Now, same with the Kubernetes aspect. So those two things have to be interoperable. And on the SUSE side, the container model makes it a little bit easier as well to have compatibility at the application level, because by nature containers are interoperable and can run on different platforms. Cloud Foundry was already OCI-compatible or runC-compliant. It was actually the first platform to be runC-compliant when the Linux Foundation, SUSE, and a few others started the Open Container Initiative a few years ago. So that's actually a key part of the job of contributions to open source, to make sure that you don't break that, because otherwise it's not helping anybody, it's not helping users. We're doing the same with Stratos, for instance. So Stratos is the SUSE Cloud Foundry and Kubernetes dashboard, but it's also working with upstream Cloud Foundry, upstream Kubernetes, and actually we see some other companies outside of SUSE using some pieces of technology that SUSE initiated with their own offering. And that's also one of the benefits of open source, that not everybody has to redo the entire thing. We contribute, which accelerates products, and that's key. So the certification program of the Cloud Foundry Foundation has to be met. To me that's a prerequisite. I don't want to ship any SUSE product if it's not certified by the open-source foundation that it chooses.

Well, a lot of them have been working with us for a while, actually. Atos, Engineering, and Stakeme, we've been working with them. They've been working with us on training materials, so they have huge knowledge about the Cloud Foundry technology and how it's used by real-life companies, and that is also directly applicable to what we are doing. They have a lot of knowledge around Kubernetes, so it's just a matter of bridging the gaps and a different way to deliver Cloud Foundry and to manage Cloud Foundry than in the past. But they've been with us from the very beginning as well. Actually, some of our training materials are being done by them. They are training our customers, our partners, they are training the community. They are a very important part of the Cloud Foundry ecosystem because it's not only about the technology and the platform, it's also about adapting processes for enterprise software development, some best practices, some integration with CI/CD or DevOps tools. So that's key, because you cannot really adopt just the technology without having some help and guidance from service companies like the ones you mentioned.

Yeah, so the way the foundation is working is that we have incubation projects, extension projects, and CF Core. And most of the time, what's in incubation is early stage. But in that case, KubeCF has been mature for a couple of years already, and it's being used in commercial products. I mean, the predecessor of KubeCF was Eirini, and it's been around for many years. What we are doing now with KubeCF is improving it, modernizing it, but the core of the technology has been really mature, using Helm charts, using CF Operators now as well, and it's already part of some commercial products. So I believe it will move very soon from incubation to core. Now, we also have to make sure that, back to the discussion about certification and interoperability, we don't want to break that by forcing KubeCF to be the de facto way to deploy Cloud Foundry, because there are also distributions of Cloud Foundry not using it. And so that's mostly why it's in incubation today and it's not really part of the core. It's to have a transition from the previous ways of developing and deploying Cloud Foundry to the Kubernetes-native way.

So I think it's a good start. And there's not only KubeCF. We mentioned Eirini too, able to plug Kubernetes natively as the container orchestrator for Cloud Foundry. There is Quarks, we have extensions to Eirini as well. And Kubernetes is not standing still, Cloud Foundry is not standing still. You can think about also event-driven or serverless frameworks. So things will keep moving, and there's still work to be done in KubeCF today. And there will still be work to be done to bring Kubernetes and Cloud Foundry even better together in the future, like in terms of sharing services, maybe sharing the same service mesh solution and serverless framework potentially in the future as well. Some of the things that are sitting on top of Kubernetes today, I'm thinking about KubeFlow or other things, would also be part of the ecosystem. And there will always be better ways to improve these integrations. There's one piece of technology that I'm thinking about as well, which is all the work that CDF is doing for CI/CD with Jenkins, Tekton, that are also very closely integrated with Kubernetes. And bridging that with KubeCF or other technologies together with the Cloud Foundry features for developers is going to be very important. So I think it will keep on being developed and improved, and also extended to adopt those new things that are coming in the cloud-native space.