Container Networking: From DIY to Buy

There’s been little to no coverage from the analyst community of enterprise-grade container networking solutions—a market that has until recently consisted of mainly open source solutions.

Networking in complex environments such as multicloud/multicluster deployments is difficult, and generally speaking, workforces don’t have the skills for it. So while building a networking solution on top of open source container networking interfaces (CNIs), ingress controllers, and service meshes has worked so far, I expect that larger and more complex deployments can be managed more efficiently with enterprise-grade solutions.

As a proof of concept, we can look at a neighboring technology that went through a similar growth phase: cloud networking.

Parallels with Cloud Networking

Today, there’s huge demand for enterprise-grade cloud networking (multicloud specifically) and dozens of vendors are developing these exact features.

Ten years ago, however, enterprises were taking a DIY approach to managing cloud networks. But with cloud service providers offering native networking functions, organizations experienced many difficulties managing networks across different cloud providers. The market quickly saw the need for cloud networking solutions that could enable connectivity across hybrid and multicloud environments.

I believe that container networking is going through a similar evolution—although while cloud networking proved difficult to manage across different providers, managing clusters of containers in different cloud environments is significantly more difficult.

Where cloud providers natively offer virtual networking appliances that can be set up using GUIs and are documented by the cloud providers themselves, networking across containers has so far been a community effort with very little prescriptive advice for how the network needs to behave.

Container Networking Solutions Can Fill the Skills Gap

A DIY approach to container networking is much more difficult compared to cloud networking. Container networking requires knowledge of both container runtimes and orchestration platforms and requires multiple third-party plug-ins such as CNIs and ingress controllers. This is a completely different kettle of fish than what networking folks are used to dealing with, having followed a training path that consists of certifications such as CCNA/CCNP or Network+.

These certifications include very few details about real-world use cases of dealing with networking in Kubernetes or other container runtimes and orchestration systems. CNIs, ingress controllers, service meshes, and network models are generally foreign concepts to network admins.

So, the networking burden falls on DevOps teams who have not traditionally been (and should not be) responsible for network deployment and management. To do so, they need to learn about Layers 3 to 7, border gateway protocol (BGP), subnetting, network address translation (NAT), and the like, but that’s a fairly long training path.

I believe that a container networking solution can level the playing field in terms of the skills required and team responsibilities. Specifically, in exchange for a paid plan you get:

  • A nice GUI.
  • Policy definition engines.
  • Security that goes beyond allow/block rules.
  • Analytics and observability.
  • Multicluster capabilities.
  • Advanced routing capabilities.

My efforts in researching this space attempt to make enterprise-grade container networking solutions a top-of-mind consideration for organizations, DevOps, and network teams.

Market Maturity and Competition

As the container networking space has been driven mainly by open source projects, it’s challenging to define exactly which capabilities an enterprise-grade container networking solution should offer and which vendors can effectively deliver these features.

Historically, organizations have looked at open source CNIs to make a start on Kubernetes networking. Cilium and Calico are some of the most widely deployed CNIs, and their enterprise-grade versions are an obvious choice for many organizations. This is especially true as several CNIs—such as Flannel, Canal, or kuber-router—lack an enterprise-grade plan, and others—such as Tungsten Fabric and Weave Net (the latter having been a widely deployed CNI)—have been discontinued and are no longer supported.

Interestingly, a considerable number of networking vendors such as Cisco, Juniper, and Arista have developed proprietary CNIs to offer container networking as part of their product. The challenge with this approach is that many organizations have opted for open source CNIs as part of the DIY trend. Migrating from an already deployed open source CNI to a commercial solution with proprietary CNI may entail more effort, and organizations will need a strong incentive to do so.

It’s too late for networking vendors to enter the market with an open source CNI. Instead, they can and should capitalize on the existing deployments of Calico and Cilium and build their enterprise-grade container networking solutions to offer advanced features and integrations with these vendors’ wider product portfolios.

Next Steps

To learn more, take a look at GigaOm’s container networking Sonar report. This report provides a comprehensive overview of the market, outlines the criteria you’ll want to consider in a purchase decision, and evaluates how a number of vendors perform against those decision criteria.

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.