They say necessity is the mother of invention. That statement has been true in networking for decades now, as many of the innovations in the network have been driven by changes in compute.

For example, Ethernet became the de facto standard to consolidate all of the various LAN protocols that once existed. Another example is the virtual switch. That was invented to solve the hair pinning problem associated with moving traffic between two virtual machines on the same host.

There’s another major compute shift going on that will drive the need for network evolution, and that’s the rise of containers. If you’re not familiar with containers, think of them as a lightweight runtime environment that includes an application and all of its dependencies, including configuration files, binaries and libraries. Containers are similar to virtual machines except they share a single operating system and kernel, so it’s much lighter weight. A VM can be a few to tens of gigabytes in size,where a container is likely to be just a few megabytes.

The advantage of containers is they are much more agile and portable. Because of their lightweight nature, they can be spun up and down almost instantly. VMs on the other hand can take several minutes to boot up and begin running.

We are still early in the container adoption cycle, so they haven’t had a big impact on the network yet—but they will soon. To help understand what’s required from the network, I talked with Prashant Gandhi, vice president of product management and strategy at Big Switch Networks.

——————————————————-

Zeus: Can you describe the deployment models for containers?

Prashant: There are two types of deployment models for containers. The first is to run containers in a virtual machine. This is used by enterprises that either want to user vCenter as a management tool or are concerned about the security ramifications of the shared kernel. The other model is to run a container on bare metal. This is the dominant model used by telcos and webscale companies that want the increased agility and flexibility of containers.

Zeus: How do containers impact network operations?

Prashant: Containers are an entirely new paradigm in compute and will have a significant impact on the network. The lightweight nature of containers means businesses can run more containers per server and spin them up and down more often.

Also, traditional applications were deployed with one or few VMs, whereas modern distributed applications could leverage tens or hundreds of containers.  A network is needed to connect the containers within the server but also between them, similar to the role of vSwitch with virtual machines. However, containers are far more dynamic with a shorter lifecycle than VMs, so the network needs a higher level of nimbleness. Containers make IT fast, and the network needs to be equally fast.

Zeus: In my experience, legacy networks are neither dynamic nor nimble. What’s missing?

Prashant: The thesis that legacy networks are not aligned well with containers is most certainly true. The two missing ingredients are visibility and automation. Visibility helps network mangers track what hosts, virtual or physical, containers are running on, when they are invoked, turned off and if they move. Network managers need full visibility into what containers are on the network and what host they are running on. 

Visibility into the environment also helps networking team see if an issue is in the container, hypervisor, server or the network, which is critical to shortening troubleshooting time. 

Automation is necessary to ensure the network can be configured at container speeds. Network teams today do almost everything manually, and that is just too slow. Automation can provide a number of benefits. 

First, core network services and policies can be applied to a container in real time with configuration automation. Manual provisioning methods simply can’t keep up. Also, automation can be used to continuously check the network for configuration drift that could impact the operations of a container.

Automation also plays an important role in testing and validation of network state. One last requirement is that the network needs to be automatable across both physical and virtual infrastructure. Ideally network professionals would not be required to think about the day-to-day operations of the network and could focus more on strategic initiatives. Automation makes network engineers nervous, but it’s a necessary component of container networking. 

Zeus: What is the right network architecture for containers?

Prashant: I consider two key architectural principles necessary for the network to be ideally suited for containers. The network needs to be a leaf/spine fabric, and it needs to be controlled through an SDN controller. Containers’ distributed nature demand a scale-out, high-performance network and hence the need for a leaf/spine fabric versus box-by-box network. 

An SDN controller, on the other hand, provides a single point of API integration for network automation with container orchestration systems such as Docker, Kubernetes or Mesosphere.

The legacy approach of box-by-box API interactions is highly inefficient, has much higher response time and can lead to API scaling problems. Moreover, SDN would ensure zero-touch fabric operations, which is necessary for rapid scale-out and change management as well as deep fabric- and container-wide visibility for application performance management and availability. 

There are additional benefits offered by SDN fabrics for containers. For instance, during container-to-container troubleshooting, it can provide fabric-wide flow tracing and eliminate the complex hop and hunt process applied in box-by-box troubleshooting. A smart SDN fabric can integrate with multiple orchestration systems simultaneously, so IT organizations can leverage the right container environment for a given application on a shared network infrastructure. 

For containers embedded in vSphere VMs, an SDN fabric would even integrate with vSphere for additional VM-level visibility and network automation. 

And finally, for bare-metal container environments, an SDN fabric would control and manage Open vSwitches (OVS) to provide a unified physical and virtual network for containers.

I see such modern capabilities as the new norm in container networking, which makes SDN fabrics an ideal architectural choice.

Zeus: Is there any other advice you would like to offer network professionals regarding containers?

Prashant: A successful container environment requires an ecosystem of technology to work together. It’s critically important that businesses use vendors that are built on open standards. Proprietary solutions may have worked in the past but now can significantly limit choice down the road.

For example, when deploying containers on bare metal servers, there’s a large ecosystem of vendors that support OVS today. Choosing a network fabric supplier that is OVS-compliant gives the organization a large number of options in the future.