Do software containers spell trouble for SDN?

• 
  Patrick Hubbard

  SolarWinds
• Published: 11 Aug 2015

Software-defined networking (SDN), like software-defined storage and software-defined everything, is essential to the future of infrastructure management. Thus, SDN isn't remotely likely to disappear as a technology in the age of software containers. The days of talking about SDN as a standalone market, however, are probably numbered. Now, I'm a huge geek for managing future networks through programming rather than configuration, but the pure-play SDN vendors -- like identity management vendors before them -- will likely become acquisitions of larger software-defined infrastructure vendors.

To be clear, SDN will be at the heart of how we execute application and network service policies on ports -- virtual or otherwise. With software containers, however, we don't have to think about the mechanics of a separate SDN layer. Instead, it's just one of several coordinated orchestration services.

Whether it's in open standards environments like OpenStack, Open Compute or Core OS, or new proprietary convergence platforms like Nimboxx, networking becomes just another service expressed as properties of containerized applications, machine images, or even whole service clusters. In all of these environments, network administrators' day-to-day routines don't involve SDN configuration -- because they shouldn't have to.

SDN isn't about to disappear -- it's here to stay and we can't create dynamic service environments without it.

Admins should be able to concentrate on describing service requirements -- scale, redundancy, compute, memory and, lastly, connectivity. Notice I used the word connectivity, not networking. With containers, admins assign services to subnets and set access and quality of service rules that dictate how to pass and prioritize traffic. They do not have to worry about routing, ports, access control lists (ACLs) or IP addresses. The hosting infrastructure figures all of that out for us, and it just works. That's the point.

The other networking discipline it encapsulates is firewalls. VMware vSwitches in ESX and NSX are a good start because they at least break up firewall rules and attempt to relocate them closer to the application in the switch instead of at the edge. With container-driven deployment, Chef and Kubernetes -- not to mention their grandfather, Amazon Web Services CloudFormation -- security rules always co-reside at the point of service origination.

When they no longer need them, admins can terminate even large formations of resources, automatically removing all related service access permissions, without intervention or follow-up. It's the opposite of what we have with today's edge routers. It's like saying, "Beat it! And take your scummy ACLs with you." It removes the sponge of a firewall that over time becomes an ever more vulnerable superset of all sketchy or obsolete access policies in one juicy attack target.

And in all these deployments, in any reconfiguration, there is no management dashboard tab labeled "SDN." It's not something you buy or install. It's assumed, necessary and always included in the software container infrastructure technology of your choice. Networking collapses to resource definitions and configuration properties set on apps or resource formations. There's no SDN appliance to monitor. It's just a service, with a measurable resource slice of your orchestration engine. And if it scales linearly with the expansion of the converged infrastructure, all the better.

So, of course, SDN isn't about to disappear -- it's here to stay and we can't create dynamic service environments without it. We'll need to study it; it will become part of our certification exam question set and, yes, you'll need to list it on your resume in a few years to be considered for employment almost anywhere. But it won't be a standalone thing. It will be just one more standardized technology that takes care of itself.