There’s a great deal of excitement, as well as challenges, around Docker and containers. One challenge has been networking. The platform was designed to help developers write and test code on a single host; however, the architecture proved problematic for production environments that required inter-host container communication.

Docker acquired SocketPlane in March 2015, and the acquisition resulted in changes to Docker’s networking design.

SocketPlane’s solution to the networking problem

In the current Docker design, containers are not exposed directly to the layer-2 network. The impact of this design means external systems requiring direct communication with a container would have to address that container using the IP of the container’s host and a TCP socket. If a single host has thousands of containers that are accessed externally from the host, network management becomes extremely difficult.

SocketPlane addressed the problem by creating an overlay network, allowing containers to connect directly to an Open vSwith (OVS). The approach allowed direct layer-2 and layer-3 connectivity to the container from remote hosts. Cross-host container communication became as simple as today’s cross-host VM communication.

SocketPlane’s solution was still in beta when Docker acquired the company.

Docker’s plugin architecture approach

Docker has taken a plugin approach to extending the base capabilities of the platform. The company offers application program interfaces (APIs) that allow for the replacement of Docker-provided functionality by third-party solutions. An example of the plugin architecture is cluster management. For example, Mesosphere can replace Docker Swarm. If a customer is currently using Mesosphere to manage their data center, they can add the Docker Engine as an additional compute resource for their Mesosphere data center.

Docker has taken the same plugin approach for extending network capability. The SocketPlane way of solving the problem didn’t embrace Docker’s “bring your own batteries” thinking to consuming and managing containers.

In April 2015, Docker introduced a new open source project named libnetwork, which offers an API for third-party solutions to provide network services. The plugin architecture allows companies such as Nuage, VMware, and Cisco to offer integration with existing network infrastructures. The solution offers incredible flexibility, and the additional network plugin architecture takes into consideration existing environments.

According to the network breakout session during Dockercon, Docker 1.7 provides a limited preview of the functionality. I was unable to get a commitment from Docker on the timeframe of a fully supported solution.

Share your thoughts on containers

Have you investigated containers for your environment? If so, has network management been a barrier to using containers, or were other pain points more of an issue? I’d love to hear your comments.

Note: TechRepublic and ZDNet are CBS Interactive properties.