Docker and its concept of containers have quickly changed the way people build applications and the way they use the cloud. Those changes have implications in networking as well, and it seems likely containers will be taking advantage of software-defined networking (SDN).

That's because containers let developers rethink the ways in which they use computing power — and the new methods call for greater levels of network abstraction. This is being revealed already in the Google Kubernetes project, which went open-source in June; it can use a proxying trick that could be categorized as SDN.

"What I do see is, things like networking and storage and security will be moving closer to a Docker container and further from being a separate appliance," says Ben Golub, CEO of Docker Inc., the company that unleashed Docker on the world. Increasingly, the way you deal with things like load balancing or bridging will be done container-to-container rather than machine-to-machine."

Launched in March 2013, Docker defines a container that houses an application along with dependencies such as binaries and libraries. That entity lives on any Linux server, physical or virtual. It's an idea that's been around for a while but had been the provinance of companies like Google — until Docker showed up and made containers standardized and easier to use.

There's an apt analogy here to shipping containers. "Prior to Docker, there were lots of steel boxes. Now there's lots of shipping containers, all the right size with hooks in all the right places," Golub says.

Complex applications can be spread around multiple containers, which then have to be in communication somehow. That's led to another phase of innovation: open-source management and orchestration for Docker containers. Kubernetes and Mesos are two examples among several, and Docker has its own, called Libswarm, which provides a common interface to them.

There are enough options, in fact, that Docker is trying to unify them with Libchan, a library for building more complex network services. "We are trying to provide common interfaces without being overly prescriptive at this point," Golub says.

People in the Open vSwitch and OpenFlow camps have been working on ways to network Docker as well, Golub says. Ideally, a container could define what it needs in the network, what ports it's using, and what other containers it needs to talk to.

Kubernetes has a specific networking idea that's very SDN-like: a service proxy that creates one IP address that fans out to any number of containers.

Unveiled in June, Kubernetes is an open-source descendent of Borg, a Google tool that lets developers pool computing power from vastly dispersed data centers. It got some heavyweight support this week from partners pledging to contribute: CoreOS, Docker, IBM, Mesosphere, Microsoft, Red Hat, and SaltStack.

The service proxy idea is a twist on networking abstraction, says Brendan Burns, a Google software engineer and one of the two people who started up the Kubernetes project.

Kubernetes uses a proxying method, whereby a particular service — defined as a query across containers — gets its own IP address. Behind that address could be hordes of containers that all provide the same service — but on the front end, the application or user tapping that service just uses the one IP address.

This means the number of containers running a service can grow or shrink as necessary, and no customer or application tapping the service has to care. Imagine if that service were a mobile network back-end process, for instance; during traffic surges, more containers running the process could be added, and they could be deleted once traffic returned to normal. Discovery of the specific containers running the service is handled in the background, as is the load balancing among those containers. Without the proxying, you could add more containers, but you'd have to tell users and applications about it; Google's method eliminates that need for configuration.

In a sense, this proxying method any given service (in the Kubernetes sense) can come with its own networking, Burns says.

The proxying scheme certainly smacks of SDN, although it isn't built on the Layer 2-3 mechanisms typically associated with SDN. "It's a binary that we write. It doesn't use OVS or anything like that," Burns says. "But we envision that being replaced by software-defined networking technology as those technologies become more widespread."