 Hi, this is Yoho Sapin Bhartiya and welcome to another episode of TF4 Newsroom and today we have with us once again Thomas Grapp, co-creator of Cillium Project and co-founder of Isovalent. Thomas, it's great to have you on the show. Thanks all for having me. It's great to be here. It's my pleasure. Today we are mostly going to talk about the need report that you both came out with. But before we go there, let's quickly remind our viewers what is Cillium all about and what is its role in the cloud-reduced space? Cillium is a CNCF project, is best known to be what's called a CNI, a container networking interface plug-in which provides the networking portion of Kubernetes, but we're by now actually much more than just the CNI, we're doing a little balancing, we're doing our policy, we're doing security, we're doing runtime security, we're doing service mesh. So we've quickly grown into a platform, kind of an ecosystem based on EBPF-based tooling that provides a variety of different values around networking security and observability for cloud-native infrastructure. Talk a bit about the role Cillium as well as Isovalent is playing in the space to kind of lower the barrier of entry, make things, because also as you're talking about observability, security, monitoring, these are also a lot of projects with the CNCF, they offer that. So talk a bit about the overall picture there. Yes, I think there's two aspects that matter. First of all, of course, we're not the first projects to provide networking, connectivity, observability, security and all of that. I think what's when we created Cillium itself, it was clear that there is a new team forming a new set of persona forming that will use Kubernetes containers and so on. Back then it didn't have a name, now it seems to be getting a name called Platform Engineering. So everything we build is built for this persona. And then the second aspect that is unique about Cillium is the use of EBPF. So the lower level, magical technology that we use to implement all of this is this EBPF engine, kernel level technology that allows us to do things better, faster and more efficient. So these two components really is what makes Cillium or the entire Cillium ecosystem unique and essentially differentiates to other projects. Let's start with the users, now talk a bit about what kind of users growth you have seen over the years. Yeah, I think we've seen amazing user growth from a perspective that I would say we have not expected even close. When we started out seven years ago, we started out with a team of three engineers working on Cillium and writing code. By now we have over 500 code contributions from different people, not only just counting the people who have actually contributed code, we have end user organizations that have added themselves to what we call a Cillium users file. We have over 14,000 users in Slack chatting about Cillium and EBPF and how they solve networking security challenges and so on. We have grown our Twitter follower base and so on. So on every metric and you can see this in the actual report, we have essentially grown massively beyond every expectation we had. As you were talking, initially the project, most cases projects start with a specific focus with the user, the scope of the project grows. Talk a bit about some of the exciting use cases of users that you have seen and you were like initial days, seven or eight years ago, you would not, hey, nah, they will not be, I mean, this is not our use case. Talk about if anything is there that excites you also. Yeah, this is, to me, this is I've been building products and projects for a long while and this is always the most exciting part because you're often wrong. I remember, obviously, we started out as we're going to be the networking layer. So we provided multi-node networking that containers and pods can talk to each other and that was clearly also an element. Well, this is cloud native, these are microservices, so layer seven matters. Like you just don't want to stop purely on the network level, but we need to do layer seven firewalling. We want to do layer seven load balancing and so on. But then the layer seven firewalling initially was actually not interesting at all to users at all. They wanted observability, they told us. Stop with this next-gen firewall. We really want to see what's going on first. So we have to build Hubble first. An observability layer that gives platform teams and application teams deep insights. What are my apps doing? How is the network happening or is the issue on the network side or isn't the app side? And then I think the wave of DNS issues appeared. So all the platform teams wanted to have dashboards on how is DNS doing? Is DNS the issue? So we literally have a dashboard that is answering the question, is DNS the cause of the issue? And then there is also interesting aspects where we thought that we would properly predict the market when we built multi-cluster connectivity, multi-cluster multi-cluster load balancing. And I remember doing a Kube contact bank in 2018. And it was not really interesting at all yet. People said, yeah, that's cool, but nobody started using it. And now today it is our most frequently used feature. And if I would, I think, list one feature, one aspect that we would have never guessed we would actually cover, it is clearly service mesh. I think when service mesh came around, it was like, yes, that service mesh will run on top of Stilium. Clearly there is a little bit of overlap. We're targeting the same team. I think there is a bit of connectivity overlap. But we're over at what we're kind of operating at different levels. And now we've naturally grown into covering service mesh as well. That's definitely something that we did not think about when we initially started Stilium seven years ago. This is an open source project. So folks can, of course, see how does the pipeline look like. But if I ask you, what are the things that, once again, as you said initially, and then you kind of grew the scope of the project. So talk a bit about what kind of things we should look at for in 2023 in terms of Stilium that, hey, these are the things that you're working on. These are the problems that we are trying to solve for the user community. I think there's three main areas that we really, really focus on. First of all is clearly Tetragon, which we announced last year. Runtime security using eBPF in the Stilium ecosystem. So all the eBPF knowledge that we have, that we've applied to networking, we have brought into Tetragon to solve runtime security from an observability and enforcement perspective. We've announced that at KubeCon Europe last year. We've now have prod users and we're kind of iterating. There's definitely a lot to come in 2023. The second aspect, we're very excited for what is coming with Gateway API on the service mesh side. We've added ingress support to Stilium. And just in 113 that is coming out in a couple of days, supported the first version of Gateway API. And we're looking forward to essentially continue with the upstream community to work on Gateway API to essentially standardize the intent language, the API, how to configure a service mesh. I think that will empower Stilium to become a fully capable service mesh. And I'm really looking forward for an industry wide standard on the service mesh side. And the third part, I think, is definitely listening to our users on the on-prem networking side, all the enterprises out there trying to figure out how to connect their existing infrastructure with this new cloud native world, providing the answer to that. That's the third big focus that we have. And that kind of makes me think that... Can you also talk a bit about, as you were talking earlier about the adoption of Kubernetes, which is great. And also you talk about some of the pain points. What are some of the core pain points that you are seeing, not just as a co-creator of Stilium, but also co-founder of Isobel and that the wider ecosystem, you know, users are feeling there and you're like, hey, this is still some of the challenges that the whole cloud native community has to still solve. So I think in the beginning it was very basic problems, like even just getting the baseline securities in place or migration to Kubernetes essentially resulted in teams losing all of the observability because the existing observability solutions would not have visibility into a cloud native cluster. Now today, the challenges are a bit more nuanced and we see enterprises struggling with, I want to migrate more workloads from my on-prem settings into the cloud, but I cannot do so for all of my apps. I can only, for example, the stateless portions or parts of the apps, but some of the databases need to stay behind, but then that's actually very challenging for enterprise applications that no longer want to be modified. So providing them solutions how they can partially migrate, while for example, preserving the actual network addressing and so on there's a lot, many asked there to help migration into the cloud because it's very desirable, but it's not easy. It's not as easy. It's very simple for let's say the cloud natives that have built their apps in the cloud and have a CI CD pipeline. It's dramatically more complex for enterprises that are not in a position that they can just simply rewrite all of their apps. Now let's talk about this report. Talk a bit about the idea behind the report, how frequent it comes out and what was the methodology that was used for this one? Yeah, so I think from the very beginning, Syllium has been very community focused. When we look at what features we have built, we have always been asking our community, what are you using today? What is blocking you from using Syllium? More what you would like to see in the future. So we've always been interacting with the community of Syllium. And same here in the report, the report really focuses on how the community sees Syllium. How many people are using Syllium? Which features are being used? How many contributors we have? How many different companies are working on Syllium? And so on. So the report really goes into detail how Syllium stands in the ecosystem and how we have evolved solving different use cases for different users. Out of these findings, which were the ones that you saw were, hey, we were not expecting that. Or it's like, hey, this is a trend that you're expecting and it's good to see that it's going in the right direction or like, hey, no, that's not what we're expecting. Anything that caught your attention? Yeah, I think the two aspects. Aspect number one is that the rise of Kubernetes outside of the clouds is going much faster than ever anticipated. I think we've seen like very cloud focused use of Kubernetes and Cloud Native in general. And if we look at Syllium usage now, and I would say like more than 90% of Syllium usage in the beginning was cloud only. And now 70% is including at least an on-prem aspect. And a lot of the focus is actually how do I connect my infrastructure that's not in the cloud yet? How do I connect that with my cloud native workloads? And Syllium is essentially starting to cover that aspect as well very, very quickly. And the second aspect is definitely how quickly we have gained a foothold on the service mesh side. From essentially running an initial survey, hey, we have been hearing that you would like us to cover service mesh with outside cars. Tell us how you want that to a better program to production users in one year that was definitely completely unexpected, but obviously a very pleasant surprise. How is this report going to help the project? Because as you're talking about, to gather a lot of insights from the users, how they're using it, other communities that are there. Because when we talk about community, there is no community, they're communities. They're community of maintainers, they're community of users, they're like peer vendors. So talk a bit about some of the learning, so findings of this project that is going to, sorry, some of the findings from this report that is going to influence the project and which ones are those? So I think out of such reports, in the end, open source projects at this stage is always like a massive, massive effort by a lot of different people. And in the beginning, that's essentially, I'd say a core team and you talk to each other very, very frequently and everybody knows each other. At this point, it's literally hundreds of people coming together and creating psyllium. So I think a big portion of this report is actually to thank the people, to actually list the contributors that are on a daily basing, reviewing code, writing code, bringing in ideas, testing code, like keeping the CI running, all of that. And also, I think, shout out and essentially highlighting the companies, the vendors that are funding these engineers and actually help psyllium get along. So to a large extent, I think, we are also doing this report to essentially list out like who is actually contributing to psyllium, who is building psyllium, to make sure that the people and the companies that are actually doing the contributions see that they're being recognized. And this will, of course, help that the effort continues and that vendors and individual engineers continue to feel comfortable and continue to feel motivated to actually work for psyllium and continue implementing what our users are asking us to do. Thomas, thank you so much for taking time out today and not only talk about psyllium, as well in this report at the larger, you know, challenges for the whole community, but also how you folks are solving it. And it was a great discussion. And as usual, I'll look forward to talking to you again soon. Thank you. Thanks a lot for the time.