4 reasons why Google joined OpenStack

What will Google gain by becoming a member of the OpenStack Foundation? What's in it for OpenStack? Here are four likely possibilities

4 reasons why Google joined OpenStack

Yesterday's announcement of Google joining the OpenStack Foundation was presented as great news by both parties. OpenStack welcomed the chance for Google to contribute to current and future versions of its cloud-creation software; Google made similar noises of its own.

But what will both parties really get out of this collaboration? Here's a rundown of four likely direct boons and fringe benefits both parties will reap.

1. OpenStack will have better support for containers and Kubernetes

The main reason Google and OpenStack were drawn closer together in the first place was Kubernetes, developed by Google to manage software containers (specifically, Docker) at scale. OpenStack's container management service Magnum, officially added to the project as of last March, uses Kubernetes as its orchestration component, so it makes sense to have the experts behind it contributing as directly as possible.

2. Google will be able to get more feedback about Kubernetes at scale

Granted, Google already has it, thanks to Kubernetes running on Google Cloud Platform. But getting more feedback from OpenStack customers -- and being able to make specific recommendations to the project about how best to implement Kubernetes -- ought to be useful. Customers running OpenStack on their own are likely to have experiences Google won't and vice versa.

3. OpenStack will continue reinventing itself as a container management system

Even if the recent word on the street indicates OpenStack is finally catching on with enterprises outside of the telco space, its market remains limited. Despite OpenStack's disconnect from Azure and AWS, container technology simply provides more tangible benefit to enterprises than OpenStack does.

If OpenStack adds more container management tooling, that'll help stave off irrelevancy. But it'll still have to contend with the likes of Canonical's LXD and Joyent's Triton, as well as projects such as Mesosphere's DCOS. None of those are an exact substitute for OpenStack, but they're not meant to be -- they're intended to solve problems where OpenStack may be overkill.

4. Google will look to OpenStack as a draw into its cloud services

OpenStack has been discussed as the nonproprietary avenue into hybrid clouds, but growth remains in public cloud workloads. To that end, Google might be working more closely with OpenStack for the sake of making Google Cloud Platform a seamless public complement to OpenStack -- and to expand Cloud Platform's revenue stream.

Google's blog post hints at things in this direction: 

...we hope to add container-native patterns to the toolbelt of enterprise developers, and improve interoperability between public and private clouds. We will be working over the coming months with the community to integrate Kubernetes, as well as complementary container technologies, to create a stronger hybrid cloud.

The tricky part will be for Google to provide integration without being accused of Amazon-style lock-in (not that it's hurt Amazon). Google can do so by emphasizing value-adds in its public cloud that aren't about proprietary feature sets, but rather deploying items at scale and with great convenience. (With Google App Engine, the stacks themselves are open source; it's the scale and the ease of use people pay for.)

There's scarcely been an open source innovation that a cloud service wasn't able to monetize on its own terms. OpenStack is not likely to be any different, and it would be no small irony if OpenStack becomes most useful and appealing via the public cloud components as offered by Google.

Copyright © 2015 IDG Communications, Inc.