Containers are widely viewed as the next major advance in virtual infrastructure, essentially doing for virtualization what virtualization did for bare-metal hardware by allowing multiple operating systems to occupy a single virtual machine.
This is a boon for data management and provisioning, because you don’t have to go through the whole process of spinning up a new VM for every application. However, it also produces a significant networking challenge. Such finely grained connectivity demands abstraction and new layers of management.
This is a job tailor-made for software defined networking, of course, so it really isn’t a surprise that container technology’s main proponent, Docker, has brought SDN capabilities into the fold. The company recently bought out a start-up called SocketPlane that was founded just a few months ago with an idea for Docker-native networking. The two companies have, in fact, worked closely on the Docker API that is intended to provide an open platform for dev/ops and sysadmin applications.
Ultimately, Docker hopes to implement cross-host networking on the application layer while at the same time remaining infrastructure-agnostic. In this way, the enterprise can maintain full application portability within a container-based architecture, particularly when the app is spread across multiple hosts and containers. Docker already had the ability to coordinate applications across IP infrastructure without the need for complex communication buses, and now SocketPlane extends this functionality to the SDN layer to enable broad app distribution without regard to underlying networking infrastructure.
Efforts to improve Docker networking are not limited to Docker itself, however. IBM is working to leverage its SDN solution (IBM SDN VE) for Docker environments to address several specific issues. First, the use of IP Network Address Translation (NAT) to facilitate communications outside a host does not allow services within a container from reaching directly to outside clients. Secondly, containers from different hosts cannot reside on the same network, which inhibits the use of standard network topologies within containers. With SDN VE, IBM says it can pool multiple containers on different virtual networks spread across various servers, plus enable container access from outside networks and allow containers to pull data from resources that are hosted in non-container architectures.
Another company to watch is SaltStack. The company’s new Helium cloud automation system offers full Docker API support, plus key enterprise-class capabilities like CPU load tracking and a container-ready data store that can house network and port data for rapid configuration and deployment. The company is also working on unique solutions for non-Docker container solutions, like the CoreOS Rocket platform and the Linux-based LXC system, on which Docker is based. At the same time, SaltStack is broadening its automation capabilities with operating platforms like Red Hat and cloud providers like AWS to enable rapid configuration across data center and cloud infrastructure.
Container technology is already making its presence known in the enterprise, primarily through its ability to implement microservices across distributed architectures. Improving its networking capabilities will help bring more mainstream enterprise applications into the fold and is likely to foster greater reliance on public and hybrid clouds.
Docker certainly has a vested interest in maintaining a firm hold on all aspects of its platform, including networking, but in the world of open source that is not always possible. And if Docker does become the de facto container platform in the enterprise, it will be interesting to see how easy it will be to mix and match third-party SDN solutions with such an integral component of the dynamic data infrastructure.
Photo courtesy of Shutterstock.