OpenStack Embraces Containers

Next Story

Yahoo Shares Fall Sharply On Report That It May Incur Higher-Than-Expected Tax Bill On Its Alibaba Stake

The recent interest in containers has often been perceived as a threat (or at least an alternative) to OpenStack, the open source cloud computing infrastructure platform founded by RackSpace and NASA in 2010. Containers — and container management platforms like Mesosphere, Kubernetes and others — could negate the need for a OpenStack, the thinking goes, because they could manage their own infrastructure, without the need for an OpenStack layer.

The message from the OpenStack community, however, is quite different. Containers are actually a hot topic at this week’s OpenStack Summit in Vancouver, and the OpenStack Foundation’s COO Mark Collier spent quite a bit of time on the topic during his keynote presentation today.

His main message was that people should think of OpenStack an an integration engine. Just like the project integrated with different hypervisors to help developers manage virtual machines a few years back, the community will also take containers and container management platforms like Google’s Kubernetes and integrate them into the platform.

“The important thing for us as a community is to think about OpenStack as an integration engine that’s agnostic,” Collier said. “That puts users in the best position for success. Just like we didn’t reinvent the wheel when it comes to compute, storage and networking, we’ll do the same with containers.”

To show that the project is serious about this, Collier invited Google Cloud Solutions Architect Sandeep Parikh onto the stage today to demonstrate how Kubernetes could enable developers to run a single distributed application on both an OpenStack Cloud and on Google’s cloud infrastructure at the same time.

The OpenStack foundation also recently launched the ‘Magnum,’ project, which takes care of the technical implementations necessary to integrate containers deeper in the project (Nova, OpenStack’s compute platform, has also offered somewhat limited container support for a while now).

The idea, in the end, is that OpenStack should offer developers a single API to manage their workloads, no matter whether those run on containers, virtual machines or some combination of the two.

This, in many ways, is the same message we’ve been hearing from various OpenStack vendors, too, and indeed, there is no reason why using one technology would have to exclude the other. Integrating containers into OpenStack means developers can get the advantages of containers, combined with the infrastructure services OpenStack provides them (security, authentication, networking, etc.).