Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Docker acquired SocketPlane in March 2015 to add software-defined networking expertise as users began building applications from containers spread across multiple hosts. The deal was a focused capability-building move: Docker wanted network configuration to travel with applications, while keeping room for users and partners to choose how networking was implemented.
Why networking became Docker’s next problem
Containers made it easier to package and move application components, but applications composed of multiple containers still needed those components to communicate—often across different machines. As orchestration made multi-container, multi-host deployments more practical, networking became a platform problem rather than a detail each developer could handle once and forget.
In March 2015, Docker vice president of enterprise marketing David Messina described the challenge as making network configuration portable. In an interview with Data Center Knowledge, he said, “They shouldn’t have to redefine everything from a networking standpoint.” The strategic need was to let teams express how an application’s services connect without rebuilding that configuration every time the application moved to a different environment.
What SocketPlane brought to the deal
Docker announced the acquisition of SocketPlane, a recently formed startup focused on software-defined networking for Docker, in March 2015. Contemporaneous coverage described the team’s networking expertise as the central addition. Data Center Dynamics reported that Docker intended to apply that expertise to the project, with attention to networking APIs and collaboration with partners.
#1 Best Overall
The announcement fit Docker’s “batteries included, but swappable” approach: provide useful networking capabilities as part of the platform, but avoid forcing every user into a single implementation. This was a capability acquisition, not evidence of a broad networking company takeover. Data Center Dynamics reported SocketPlane had a six-person team, while Data Center Knowledge placed the deal among Docker acquisitions involving small operations and specific skills. Those details support calling the move focused; they do not establish a formal acquisition policy or reveal Docker’s internal decision process.
How the strategy balanced simplicity and choice
The design problem involved competing needs, not a choice between networking and no networking. Application developers wanted a straightforward way to connect services. Network and infrastructure teams still needed control over the systems, policies, and service levels underneath those connections. Docker’s stated direction was to give each group an interface suited to its work while leaving implementation choices open.
| Design dimension | What Docker’s approach aimed to provide |
|---|---|
| Developer simplicity | A way to describe connections among application services without managing low-level network plumbing. |
| Administrator control | Room for network IT teams to manage infrastructure and service levels. |
| Built-in capability and replaceable plugins | Networking available within the Docker platform, with plugins allowing users to select implementations suited to their needs. |
| Portability and infrastructure-specific implementations | Application-level network configuration that could be expressed consistently while implementation choices remained adaptable to the underlying environment. |
Docker’s March 2016 explanation of its networking design says the company treated plugins as first-class so users could choose implementations suited to connectivity and service discovery needs. The Register quoted Docker CTO and chief architect Solomon Hykes describing the developer-facing goal: “Individual developers, through a single command, can establish the topology of the network to connect discrete Dockerized services into a distributed application.” That describes the intended abstraction, not a measured performance result.
What happened after the acquisition
At DockerCon in June 2015, Docker introduced networking capabilities with plugin support. TechCrunch connected the launch in part to the SocketPlane acquisition and feedback from networking partners; The Register also linked the new software-defined networking features to the acquisition while emphasizing partner input and the swappable architecture. The launch is evidence that the acquisition aligned with Docker’s networking direction, but the reporting does not establish that SocketPlane alone produced every part of the stack.
The longer-term fit is clearest in Docker’s later design explanation: networking needed to be simple enough for application teams to use, yet open enough for infrastructure teams and partners to accommodate different environments. SocketPlane added expertise to help Docker address that platform challenge as containerized applications became more distributed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What is—and is not—known about the deal
Contemporaneous reporting said the financial terms were not disclosed. The available accounts do not quantify the acquisition’s return, specify how much code or other intellectual property transferred, or show how much of the later networking release came from SocketPlane. The defensible conclusion is narrower: Docker acquired a small SDN startup to strengthen networking expertise and help shape a modular networking strategy for multi-container, multi-host applications.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
