Thomas Graf is the co-founder and CTO of Isovalent, and the creator of a widely used open source (and cloud native) networking technology named Cilium. Cilium is built on top of a kernel-level Linux technology called eBPF.
In this interview, Graf talks about the roles Cilium and eBPF have in the expanding cloud-native networking ecosystem, along with broader shifts in Kubernetes adoption and development. He describes who is using and purchasing Kubernetes in large enterprises, where cloud native infrastructure still has room to improve, and how the push for standardization is fueling innovation.
eBPF and Cilium
How should we understand eBPF and Cilium in the broader context of computing and networking, and then specifically within the cloud native ecosystem?
THOMAS GRAF: At a high level, eBPF is the technology, and it operates at a very low level. It was built for kernel developers, and my own background is in kernel development. eBPF is to the kernel, to the operating system, what JavaScript is to a browser. It turns the operating system into something programmable, just as JavaScript makes the browser programmable. In the past, we had to move up to newer browser versions before we could use certain websites. Then JavaScript arrived, and suddenly application teams and developers could create huge applications — so much so that the most popular word-processing application was eventually displaced by an in-browser one. It sparked a massive wave of innovation.
The same thing is taking place with eBPF, though at the operating system layer, because suddenly we can do things at the kernel or OS level where we can observe everything and govern everything — which is very important for security — without needing to modify kernel source code. We can essentially load programs into the kernel to extend what it can do and add new capabilities. That has also unlocked a huge wave of innovation. Hyperscalers like Facebook, Google, and Netflix are using this themselves, directly, with their own kernel teams.
What Cilium contributes is that it takes this low-level eBPF technology and uses it to deliver a new wave of software infrastructure, especially for the cloud native wave. Think of it as software-defined networking and what Nicira, later VMware NSX, did for the virtualization industry. We are doing the same for cloud native, where there is a combination of cloud provider or public cloud infrastructure and on-premises infrastructure. And we are addressing networking, security, and observability use cases at the infrastructure layer with it.
And the Cilium Service Mesh, which was just released, is an extension of these capabilities?
What is happening now, since around a year ago, is that the two worlds are colliding. What Cilium has been focused on up to now is networking, virtualized networking, and then cloud native networking — but still networking. But then, from the top down, application teams at Twitter and Google were doing service mesh work — in the application first, and then the sidecar-based model, the proxy-based model, which is what projects like Istio provide. And now these two layers are moving closer together because traditional enterprises are entering the cloud native world, and they have enterprise networking requirements, but their application teams also want a service mesh.
Gartner is referring to this new layer as “service connectivity” — we’ll see whether that term sticks — but it is basically a layer that combines the enterprise networking element and the service mesh element that is coming from application teams. And since that is what customers are asking for, we have built the capabilities into Cilium itself. So, in effect, Cilium is moving upward from the enterprise networking side and the service meshes are moving downward into more of the networking side.
Service mesh
Per Wikipedia: A service mesh is a dedicated infrastructure layer for enabling service-to-service communication between services or microservices, using a proxy. A dedicated communication layer can offer a number of benefits, such as giving observability into communications, providing secure connections, or automating retries and backoff for failed requests.
Why is there so much attention on the networking and service mesh layer of the Kubernetes stack?
Because with the push to run across multiple clouds and to break applications into containers, the connectivity layer has become central. What used to be perhaps inter-process communication and middleware is now the network, so the network is becoming absolutely essential for applications to communicate with one another and for data to move.
And in cloud native, specifically, multi-cloud is becoming absolutely essential. All the cloud providers have their own networking layers, but, naturally, they are built for their own clouds. They do offer on-prem products, but they are not truly multi-cloud. Cilium and eBPF bring that multi-cloud, agnostic layer to the table. It works exactly the same on-premises as it does in the public cloud. Several public cloud providers are using Cilium beneath the surface for their managed Kubernetes offerings, and telcos are using it for on-prem 5G infrastructure. It is about speaking both languages and linking these worlds together.
That is why there is so much attention on this: because one of the simplest ways for cloud providers to lock customers in is to control that connectivity layer. I think from a strategic infrastructure standpoint, just as the virtualization layer was important, now the connectivity and network layer is absolutely critical.
The source of [future] innovation will be open-source, and the customers and users driving demand will be companies one tier below the hyperscalers — already substantial companies that are still highly disruptive.
Kubernetes adoption and evolution
Kubernetes is fairly broadly accepted and deployed at this point, but there is still discussion in some circles that it is overkill. Who do you think Kubernetes, and the cloud native ecosystem overall, is for?
It is for modern application teams. I think the realization has set in that if you want to attract modern application teams, and be able to move quickly to market, you need to offer them cloud native infrastructure. We often see prototyping — initial work, pre-MVP, even proving the idea or selling it internally — on serverless, something like Lambda. And then on Kubernetes, because the app teams can own the infrastructure directly. And then, as it goes into production, they move to enterprise, on-prem Kubernetes distributions. But that is actually a relatively small slice of the whole infrastructure, maybe a single or low double-digit percentage.
It will clearly become the new standard, though. Just as virtualization adoption was very slow at first and people said it was overkill — but over time, of course, it began replacing the majority of things — we will see the same here. Or just like with modern languages. People said Java was overkill, and it probably still is for many applications, but there was a time when it became very difficult to do any application development outside Java because that is what most application developers could write in. The same will hold true for modern application teams: they will expect Kubernetes to be available in order to develop more flexibly and bring the product to market quickly.
On the infrastructure side, it may be somewhat overkill, but if the alternative is rewriting an application from serverless into on-prem, that is a huge undertaking. So Kubernetes is the middle ground there, which is very appealing.
What about the view that Kubernetes still needs a better developer experience?
If we look at the original OpenShift, before it rebased onto Kubernetes, it was this. It was even closer to the application team and offered an even better application developer experience. You could push to Git and it would deploy automatically. Heroku also pursued this, but in a SaaS-based form.
Kubernetes took a step back and said, “We need to retain some operational pieces in it and make it a little more like what a sysadmin would anticipate, too. We cannot be only designed around applications.” It sits in the middle: It has to be appealing enough for application teams, but it still must be usable to run that app outside a particular environment, and to have it managed by people other than application developers.
I would say the biggest leap from Docker to Kubernetes was that Docker was centered on developer experience. It handled that part, but it did not address the public-cloud ecosystem part.
How’d we get to this point? Was this the natural evolution from platform-as-a-service (PaaS) and application containers?
It was Docker images and Docker’s packaging side. The older approach was deploying into virtual machines, and there was all kinds of automation built around that. Then there was what Facebook was doing with Tupperware — very custom-built and at truly large scale. And then Docker arrived and basically delivered this container image, and everyone could treat it like a tiny VM. I can now ship my app and instead of a 600MB virtual image, it’s now a 10MB container. But you can handle it the same way, because it includes everything it needs.
That opened the door to bring in an orchestrator like Kubernetes that still lets you treat applications like mini VMs, but then also go one step further and actually treat them as microservices. It gives you the ability to do both.
I would say the biggest leap from Docker to Kubernetes was that Docker was centered on developer experience. It handled that part, but it did not address the public-cloud ecosystem part. It did not have, or necessarily aim for, tight integration with cloud providers. Kubernetes solved that.
Who do you see operating Kubernetes inside companies? Is it individual application teams?
There’s an interesting change that came with cloud native, which is the rise of the “platform team,” I’ll call it. They’re not application engineers. They have some network ops background and they have quite a bit of security knowledge. They have SRE knowledge and they know how to do cloud automation. They provide the platform for application teams and treat those application teams as their customers.
Platform teams are the ones purchasing Kubernetes and related technologies, which they use because they’re responsible for delivering that next-generation infrastructure to keep modern app teams happy.
I think there’s definitely a place for serverless, especially for very rapid application development. But in enterprises, we are seeing cloud native as the new layer on top of virtualization
Is that a brand-new buyer or a brand-new team? Or are platform teams more like something that exists inside places like Google or Facebook and are now becoming mainstream?
They’re mostly a new team. I think they are, in part, similar to the SRE teams at Google and Facebook. However, application teams probably own more of application deployment in enterprises, because enterprises do not have this very clear split between software engineers and SREs that Google and Facebook do. I would say this progression is very similar to how you had virtualization teams, and then lots of network ops moved from — or evolved or advanced from — being about network hardware to being about network virtualization. And these teams, for example, began to operate VMware NSX. The same thing is happening here.
Although, it’s not necessarily new budget. We see budgets moving from security and networking to this platform team, for example, as cloud spending rises and less is spent on network hardware. They often work with the security team and with the network ops team to get buy-in, but they actually control a pretty substantial share of the budget.
Cloud native innovation
How do you see the Cloud Native Computing Foundation changing, and will Kubernetes always be at the center of it — or of the cloud native movement overall?
Kubernetes is what launched the CNCF, and in the first couple of years it was all about Kubernetes and public cloud. What we’ve seen since about a year ago is that it’s now no longer just about Kubernetes, it’s actually more about cloud native principles. This actually means it’s not necessarily cloud anymore either, not even private cloud. It’s often even traditional enterprise networking, boring on-prem infrastructure, bare-metal servers, and all of that, but with the cloud native principles built in.
The new norm is now hybrid and includes multiple public cloud providers, as well as on-premises infrastructure. Companies want to deliver the same application developer agility, or provide observability with modern cloud native tools, or do security with modern cloud native tools — for example, authentication, instead of just segmentation or identity-based enforcement — all those new cloud native concepts on existing infrastructure.
We’re seeing very strong demand to still connect to the old world and speak MPLS, VLAN, sFlow, and NetFlow — the entire existing set of enterprise requirements. None of them have disappeared.
About a decade into it, the cloud native space doesn’t seem to be a fad. How much room is there for it to keep evolving?
There was definitely a period when people said, “Oh, Kubernetes is probably short-lived, and serverless is going to be the next layer.” Or, “Kubernetes is like OpenStack. Or, “It will vanish and it’s going to be an implementation detail.” And that has not happened.
I think there’s definitely a place for serverless, especially for very rapid application development. But in enterprises, we are seeing cloud native as the new layer on top of virtualization, and we believe it has a similar shelf life as virtualization. Which means we’re at the very beginning of the cloud native migration.
What big problems still need to be solved at the infrastructure level?
We’re seeing enterprises in a situation where, all of a sudden, whether they want it or not, they need a multi-cloud strategy. Because they also have on-premise infrastructure, they now need a hybrid cloud strategy on top of that. And they need to work out how to do security and other functions universally across this infrastructure without locking themselves into a particular public cloud.
So this is the next big challenge: Who’s going to be that agnostic layer for multi-cloud and cloud native, like what VMware became? Who’s going to be the VMware for cloud native?
I believe the lesson has now set in: if you want to win modern application teams and support rapid go-to-market cycles, you have to give them cloud native infrastructure.
And even if cloud native adoption may have been fairly straightforward for the modern web companies that got there early, the difficulty, from your point of view, is creating new technologies that close the divide between this modern world and existing enterprise tools and systems?
The difficult part is that modern app teams expect the infrastructure layer to change as fast as they do. That pushed the infrastructure layer to become even more programmable and more adaptable. That is why we now really see a networking layer and a security layer sitting on top of the cloud networking layer. But enterprises are now entering the picture, and we are seeing very strong demand to still link to the old world and speak MPLS, VLAN, sFlow, and NetFlow — the entire current set of enterprise requirements. None of that has disappeared, and all the compliance rules remain the same. And even some modern SaaS companies now run into these issues as they get larger and care about compliance and similar concerns.
From a technology standpoint, it is about connecting that new cloud native world with the existing enterprise requirements. A lot of these issues were concealed by the public cloud providers. Public cloud providers handled the compliance issues, but they did not open source or publish any of that; they solved it themselves. It is part of the cloud value. Enterprises now have to rebuild and purchase that if they do not want to lock themselves into public cloud offerings.
Where do you think the next wave of cloud native innovation will come from? Does it still come from a company like Google, or is there a different kind of company taking the lead?
It is very interesting. I would say it is probably not coming from the Googles and the Facebooks. The innovation will likely be open-source, and the customers and users pushing the demand will be companies one level below the hyperscalers — already substantial companies that are still highly disruptive, like Adobe, Shopify, or GitHub. But also companies that could be disrupted by technology, such as financial services, insurance providers, and telcos. These companies all share an interest in standardizing infrastructure with repeatable development and infrastructure models.