The Rise of Kubernetes and the End of Networking & Security as You Know It.  What’s Next?

In a few short years, Kubernetes has gone from being a “bleeding edge tech” to the “new enterprise standard” for how modern applications are built and operated. Enterprises and telcos are now past the initial “Day 1” challenges (e.g., “which Kubernetes distro do I run?”) and are in the deeper “Day 2” challenges, with a major focus on how they scalably connect, secure, and observe the connectivity between these modern API-driven applications. Despite this shift in customer requirements, the traditional networking and security ecosystem has proven unable to make the jump to this new world, setting the stage for one of the largest disruptions the industry has seen in decades.

Today, Isovalent is announcing our $40M Series B fundraise to continue our leadership of the open source eBPF and Cilium technologies that are bringing networking & security into this new cloud native era.  This is an era defined by the rise of Kubernetes-based platform engineering, which is enabling both existing applications and modern microservices to run with greater automation, resilience, and efficiency across multi-cloud infrastructure.  All three major cloud providers (Google, AWS, and now with this funding announcement, Microsoft) singled out Cilium as the new de facto standard for Kubernetes networking & security, and we are privileged to work with leading enterprises like Adobe, Capital One, Ikea, and Sky and telcos like Bell Canada and Telenor to empower their modern Kubernetes-based infrastructure.

What led all these leading companies to seek out a fundamentally new way of tackling problems they have for years addressed using physical (and virtual) network devices from traditional vendors? This is a story about the shift toward API-driven application design and the rise of Kubernetes-based platform engineering. This is a story about how (once) an obscure Linux kernel technology called eBPF is transforming Linux into a powerful new multi-cloud infrastructure layer. In short, it is the story of Isovalent.

Your Traditional Networking & Security Devices Don’t Understand Kubernetes

Running workloads on Kubernetes does not change the fundamental requirements of enterprises and telcos that have fueled the traditional (and massive) networking and security ecosystem for the past 30+ years. These requirements include the need for:

• security and compliance,
• reliability (e.g., load-balancing and device fail-over),
• SLAs and network monitoring / troubleshooting tools,
• performance and scale.

What’s new is that the traditional mechanisms used by enterprises and telcos to achieve these, don’t work in the world of Kubernetes. Want to use network segmentation to isolate tenants? Sorry, VLAN, subnet, and even security-group based segmentation doesn’t work with Kubernetes. Want to use your hardware load-balancer to front-end all applications? Maybe at first, but it won’t scale past an initial set of apps. Want to use traditional IP-based tools for network monitoring or flow audit logs in an incident investigation? Think again, your Kubernetes cluster is a blackbox for these existing observability tools.  

While the initial workloads deployed on Kubernetes may be the less demanding apps as platform teams “get their feet wet”, once an organization starts deploying mission-critical workloads from multiple tenants onto Kubernetes, these gaps are impossible to be ignored.       

A New Connectivity & Security Layer, Driven by the Needs of the Platform Team

As organizations look for the best way to solve these challenges on modern Kubernetes platforms the most obvious technical requirements are: 

• Highly distributed & efficient processing to handle the explosion of east-west communication (centralized devices become bottlenecks and per-workload “sidecar proxies” are too heavyweight).
• Workload identity and API-layer visibility as a first-class construct for both zero-trust security and observability (since IPs and ports are nearly meaningless in a Kubernetes environment).
• Configurable via standardized and automation-friendly APIs (e.g., Kubernetes CRDs such as Services, Ingress, NetworkPolicy).
• Integrates with legacy networks and legacy workloads running outside of Kubernetes.

But beyond these strictly functional requirements, the fact that routers, firewalls, and load-balancers, are no longer standalone devices but rather tightly-coupled components of a broader Kubernetes platform offering introduces a new key influencer: the Kubernetes Platform Engineering Team. This team adds a new set of key criteria when evaluating a solution to these challenges: 

• Well-aligned with the Kubernetes and CNCF community. 
• Simple to adopt and operate: a single component to install/upgrade/monitor rather than different moving pieces for firewalling vs. load-balancing vs. observability.  
• Multi-cloud: provides consistent connectivity, security, load-balancing, and observability across any type of underlying infrastructure.  

Since no traditional technology comes even close to meeting all these requirements, a new layer is forming to meet these needs. As is often the case when a new layer emerges, naming will vary early on, and only solidify over time.  Some call this layer “Kubernetes CNI” and others a “Service Mesh”. Others may look to coin more general terms like  “Cloud Native Networking” or “Secure Service Connectivity”. Regardless of the eventual name, what is already crystal clear is that a critical NEW LAYER of the enterprise infrastructure stack is emerging.

eBPF Empowers Linux to be the Multi-Cloud Infrastructure Control Point

We founded Isovalent five years ago because we believed that this new layer would emerge.  Our core bet was that a (at the time) little-known Linux kernel technology called eBPF held the keys to building this new layer “the right way”. Because we’ve written a great deal about why eBPF is so interesting already, I’ll just quickly summarize here:

eBPF is an incredibly powerful (yet complex) Linux kernel capability co-maintained by Isovalent and Meta. You can mostly think of eBPF as a way to “teach the Linux kernel new tricks”, in a way that is fully compatible with whatever mainstream Linux distribution you already use.

eBPF lets us achieve what was impossible using legacy networking and security technologies like iptables (traditional Linux firewalling) or traditional userspace proxies (like haproxy, nginx, etc.), in particular:

• eBPF allows us to build efficient & scalable networking, security, and load-balancing natively into the Linux kernel. 
• eBPF allows us to natively understand not just IPs + ports, but service identity and API-calls.  
• eBPF allows us to infuse the connectivity & security layer with efficient observability as a first-class construct.  

And because eBPF operates at the Linux layer, and is not tied to underlying hardware or hypervisors, it can be the foundation for a consistent set of networking, security, and observability capabilities for workloads running on any cloud, private or public.   

Cilium: The Standard for Multi-Cloud Kubernetes Connectivity & Security

eBPF is incredibly powerful, but it is also extremely low-level (one is literally writing kernel-level code when leveraging eBPF directly – See Liz Rice’s great 15-minute talk for a live-coding example). So we’ve built and open sourced Cilium to bundle powerful eBPF-based networking, security, and observability code with easy-to-use “human-level” constructs (e.g., YAML-based Kubernetes CRDs, YAML-based firewall and load-balancing rules, JSON-based observability events, a Service Map UI, Prometheus metrics & Grafana dashboards, etc.).   

Cilium has taken the world of Kubernetes connectivity and security by storm.  The Cilium adopters page has successful user stories across a large number of industries, including financials (banking, payments, insurance), retail & e-commerce, enterprise SaaS, telecommunications, entertainment & gaming, governments, and more, as well as pointers to the many cloud providers and other service providers who have bet on Cilium.   

Cilium is also a thriving open source community, with over 20,000 commits from 463 contributors, over 12,800 Github stars, and over 12,500 members of our eBPF & Cilium Slack community. Last year, we doubled down on our community and donated Cilium to the CNCF (the Cloud Native Computing Foundation – the guiding body for the Kubernetes and closely related open source projects). Cilium stands alone as the only CNI accepted by the CNCF at or above the Incubation level, with full Graduated project status expected in the first half of 2023.  This has further cemented Cilium as THE de facto standard for the Kubernetes community. 

Let us Collaborate to Keep Building What’s Next

At Isovalent, we are here to build amazing technology, foster thriving open source communities around eBPF and Cilium, and help enterprises, telcos, governments, and other organizations overcome critical challenges as they run their mission-critical applications on Kubernetes. Cilium started with a focus solely on Kubernetes networking & security, but our users have continued to guide the way, driving us to expand the scope of Cilium to include network observability, service mesh, and even runtime security. This funding round, led by Thomvest Ventures with strategic investments from M12 (Microsoft’s venture fund) and Grafana Labs empowers us to rapidly grow the team and continue to execute on this exciting and expansive mission to build out the connectivity layer for the cloud native era (and of course, we’re hiring!).

Our commercial product, Isovalent Cilium Enterprise, combines a hardened distribution of open source Cilium, proactive customer support, and additional enterprise-only networking, security, and observability features.  We integrate and test Isovalent Cilium Enterprise with many of the other strategic technologies our customers have bet on as critical components in their Kubernetes stack. This includes certifying and simplifying the installation of Cilium with leading Kubernetes distributions like AKS, EKS, GKE, OpenShift, Rancher, and more. We also make it easier to store, analyze, and visualize observability data from Isovalent Cilium Enterprise in your observability platform of choice, including popular offerings from companies like Grafana Labs, Elastic, Splunk, Datadog, and others.

Making our customers successful has enabled us to grow revenues ~3X for each of the past two years, and our growth is continuing to accelerate at a similar rate through 2022. Strong business growth despite difficult external economic conditions only strengthens our conviction that we are solving important customer problems not addressed by existing vendors and speaks to our long-term staying power as a business.

We’re grateful to our team members, our community, our customers, and everyone who has bet on our (at the start preposterous, but now industry-defining) vision for how eBPF will be the critical puzzle piece to create a new networking & security layer for the cloud native era.

Whatever term you use for this new layer (Kubernetes CNI, Service Mesh, or something else), if you are into “Day 2” of your Kubernetes journey and are figuring out how your business tackles these important challenges, let us chat!

And if our vision and our journey ahead excites you, join us! We are hiring! We have always been and continue to be a remote-first company and are hiring across all geographies.