Docker: Where Does It Leave the Network Admin?

It’s the end of the year, and a good time for thinking back. I’m thinking back to a dark past long ago, when physical servers ran server operating systems, and ran applications—when those servers plugged into a switch, and each endpoint was a single server. The network team could see every device, endpoint, or switch, and could trace packets from end to end. Network admins would tell you that those were Golden Days, when troubleshooting was easy and networks were simple. Then, ten or so years ago, along came server virtualization. All of a sudden there were multiple servers on any given endpoint, and worse, the servers would move between endpoints not only at will, but mid-flow. Troubleshooting became Hard, with a capital H.

Out of this came innovations such as VMware’s dvSwitch and the Cisco 1000V distributed vSwitch. These gave network admins the tools they required to push their traces deeper into the virtualization systems and to regain the end-to-end connectivity they desired. As time progressed, the ability to mirror flows and to extend technologies such as NetFlow into the hypervisor brought the VM world back into network admins’ view. As time advanced further, network functions virtualization (NFV) moved some of the functions of the network into the hypervisor, or into VMs, but the interaction between the flows remained fairly constant. The more recent developments of overlay/underlay networks have again pushed the end-to-end traffic flows into the twilight of tunnels (encrypted or not). The two-tier network model has made troubleshooting harder again, with layer 2 networks tunneled through layer 3 switch interconnects. Now Docker is throwing another spanner in the works.

On the one hand, Docker offers the potential to put the “OS” back to a single endpoint. On the other, that OS is now running multiple throwaway apps that move and change at a rate unheard of even a couple of years ago. This creates both challenges and opportunities for the network. Docker’s deep integration into OpenStack means that all the SDN tools created for the OpenStack world are close to, if not completely, compatible out of the box. Times are certainly not quite as dim as when virtualization stacks broke onto the scene.

VMware is on hand to help the pure VMware shops with the Photon project. One of the aims of that project is to ensure that each container has an element in the VMware infrastructure, so that NSX and vRealize can interact and the containers do not simply vanish from view. This means that the brunt of vLog Insight and vRealize Operations Manager can be brought to bear on the entire estate, be it VM or container.

Outside of the VMware worldview, Docker opens up doors for the more generic SDN vendors. Where Docker runs “bare metal,” there is still a Linux base OS that can be tapped into relatively freely. Big Switch Networks has taken advantage of this with the ability to install its Big Cloud Fabric (BCF) plugin, making the Docker host another aspect of the fabric and bringing it into the entire control and monitoring suite it provides. Where Docker is running within the VM world, all of the techniques that have been developed to monitor and steer traffic from VMs can be brought to bear.

As server virtualization has evolved, so too have the networks underpinning them. The complexity in both cases has increased at a rate that could not have been foreseen at the start of the century. With that complexity has come both difficulties in troubleshooting and opportunities to work in much more efficient and agile ways. No longer are racking and stacking, manual network configuration, and long hours tracing Cat5 cables a delay to the provisioning of apps. We don’t wait five months to order a box and have the cables connected and brought online. We wait five minutes, even five seconds, for an image to deploy, with networks created and network functions chained in real-time.

Perhaps those network admins lamenting the past have some powerful rose-tinted spectacles. Indeed, the past always seems as though it were a more comfortable era. The future brings new challenges that are oftentimes difficult to grasp, and that take time to get used to. The brave new world of SDN, though, is bedding in, taking new challenges in stride, and adapting in a way that only a software-defined future can.