Docker is moving into orchestrating an application's server and networking. Does that supplement cloud function or replace it?

Charles Babcock, Editor at Large, Cloud

April 2, 2015

6 Min Read
<p align="left">(Image: <a href="http://pixabay.com/en/users/Stevebidmead-249424/" target="_blank">Stevebidmead</a> via Pixabay)</p>

Microsoft 'Project Spartan': Hands-On Demo

Microsoft 'Project Spartan': Hands-On Demo


Microsoft 'Project Spartan': Hands-On Demo (Click image for larger view and slideshow.)

Are containers a valuable addition to infrastructure as a service, whether in the public cloud or a private cloud on-premises? Or do they replace some IaaS operations with their own functionality? Of late, it seems to me more likely a replacement.

A year ago, when I first heard Lydia Leong at the Gartner Group offer the idea that Docker might replace some functions done by cloud management software such as OpenStack, I was skeptical. Two recent events have changed my mind: Pivotal's new ability to use Docker to launch Amazon Web Services workloads, and Docker's acquisition of SocketPlane. Here's why those two events are notable.

Containers have the potential to change the nature of cloud architecture, stripping away much of what currently gets decided by the cloud at the moment of orchestration. In its place will be instructions carried inside the Docker format, with highly automated systems accepting those instructions and building a logical server from them. That server will be sized to fit the specific workload -- not as a standard small, medium, or large server size preset by Amazon or some other IaaS provider.

In some cases the cloud will respond to a request for computing power by deploying a virtual machine, much as we see today. In others, the VM will be disregarded in favor of a bare metal deployment. In the bare-metal case, container-based deployment will have one distinct advantage: The deployment considers only the application's computing needs and its dependencies, not how the cloud needs to operate. In that event, it will be up to the infrastructure-as-a-service-providers to understand containers, as opposed to the container owner needing to understand the cloud.

[Want to learn more about container orchestration? See Docker Preps Containers For Amazon, Other Clouds.]

Pivotal provides an instructive twist to illustrate this change. Pivotal is embedding a virtual appliance that can launch a Docker container upon its arrival at Amazon Web Services. An on-premises user of Pivotal Cloud Foundry who wants to put a workload into the public cloud can trigger an appliance in the Cloud Foundry environment to build similar servers under Cloud Foundry on Amazon. The systems administrator tells the appliance how many servers will be needed, and the appliance uses Amazon's APIs to go into the cloud and create them.

Under Pivotal Cloud Foundry (Pivotal CF), Docker provides a workload control point from which the cloud can be directed to launch and run containers in a way that mimics their use back in the enterprise data center. Docker Compose, Machine, and Swarm orchestrate how the workload is prepared and launched. In this example, it’s the Docker Engine and Docker tools that are doing the configuration, orchestration, and load balancing, with the cloud simply providing a vehicle -- a virtual server -- on which it will do its work.

Beyond mere orchestration, however, Docker is starting to look like the administrative manager for setting up virtual networking as well, a role that's currently part of IaaS software. In the Pivotal CF example, the appliance provides specifications for how networking will be set up once the workload reaches the cloud. We all know virtual networking is already part of the cloud. What's not clear is where cloud virtual networking starts and container virtual networking will end.

Container builders can currently designate a port in the container as one used by the workload, then define which port it's supposed to connect to on the host. That's a way for a container to connect to an outside service or another container.

Docker Buys Into SDN

Early in March, Docker acquired SocketPlane, a seven person startup in the software-defined networking market. Docker needs SocketPlane expertise because of "the rapid growth in multi-container, multi-host applications," said Docker CTO Solomon Hykes, in announcing the acquisition. Needless to say, networking is a critical part of allowing applications to function as a set of distributed and containerized services.

If Docker leaves it to the cloud supplier to decide how containers are connected, it will run into the cloud vendors' approach of using virtual machines as the basic building blocks, and thinking that the virtual machine is what needs to be connected. Docker ties the network into the application itself. There might even be several related application services, each in its own container, but all in the same virtual machine. Who will decide how that virtual networking will work? Docker keeps showing up with an application-focused approach; the cloud keeps thinking, "virtual machine."

If networking starts with the container, "all aspects can be software-defined with complete portability that ensures that a distributed application is not bound to a specific vendor or cloud provider," said Docker's March 4 announcement. For that reason, Amazon, Google, or Microsoft may not want networking in the cloud to start with the container. We'll see.

VMware was playing a disruptive role when it bought SDN vendor Nicira, bringing its co-founder and CTO Martin Casado in-house. Casado at Stanford was an originator of the OpenFlow SDN-type protocol. Now Docker is acquiring SocketPlane, bringing its CEO Madhu Vanugopal in-house. Vanugopal is co-author of the Open Virtual Network specification, and his six employees have experience in networking at Cisco, HP, Red Hat, and Dell. They've been active with OpenStack, OpenDaylight, and Open vSwitch, the effort to create the equivalent of the VMware hypervisor switch as open source code.

So how much will container virtual networking disrupt cloud virtual networking? Are these two things destined to work side by side in complementary ways or will one tend to override the other? At the moment, it's Docker that's adding to its capabilities at a rapid pace.

Docker enables disruption on several fronts, with cloud networking being one of them. Docker enables "myriad networking use cases," noted Vanugopal in the announcement. "We believe strongly that we will be fostering broad opportunities for partners to build differentiated capabilities based upon Docker’s open standards,” he said. That doesn't exactly sound like a pledge of allegiance to AWS.

In addition to gaining orchestration and being on a path to at least specify virtual networking, Docker has also added a graphical user interface that can be put in front of the Docker Engine to drive container formatting. It allows building containers to work as a check-box, menu-selection, or drag-and-drop process. Most Linux developers are using a command line interface today. A graphical user interface will push Docker out to another developer realm, including the Microsoft .net developer set, and bring in more adherents.

Docker is simple enough and useful enough to gain a broad following of developers quickly. The contributors to the Docker project are looking for new ways to expand its core functionality. So will Docker users have to learn the ways of the cloud, or will the cloud have to learn to speak Docker?

Attend Interop Las Vegas, the leading independent technology conference and expo series designed to inspire, inform, and connect the world's IT community. In 2015, look for all new programs, networking opportunities, and classes that will help you set your organization’s IT action plan. It happens April 27 to May 1. Register with Discount Code MPOIWK for $200 off Total Access Conference Passes.

About the Author(s)

Charles Babcock

Editor at Large, Cloud

Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive Week. He is a graduate of Syracuse University where he obtained a bachelor's degree in journalism. He joined the publication in 2003.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights