)
Can OpenStack take the crown as cloud king? In our increasingly hybrid infrastructure environment, the path to the top means making it easier to user to defect from the current leaders (Amazon AWS; VMware) instead of asking them to blaze new trails. Here are my notes from a recent discussion about that exact topic…
In May, I had the privilege to (re)present my OpenStack Summit talk to the OpenStack Denver meetup group. The group and discussion (90-minute!) were lively because the attendees were both experienced and passionate about making OpenStack great.
We started with the idea that AWS determines OpenStack Interop based on my post.
On the surface, that seems to make OpenStack a second-class citizen so we spent a lot of time talking about the market gravity of AWS. After much discussion, consensus was that AWS operational patterns (not the APIs!) are the expected behavior for cloud users. As dedicated OpenStack users, this is not an easy thing to accept, however, I believe that accepting it allows us to better expand and help our users.
Here’s what I showed the group: I kicked off a seven OpenStack cloud test using the Digital Rebar cloud provider model. Of that deployment, only one cloud (Dreamhost) was able be completely provisioned. While the scripts successfully used the APIs (go DefCore!) to create seven running VMs, most of the clouds failed to assign an externally addressable IP address that Digital Rebar could use to complete the provisioning process.
Hold on! That’s the right thing! Floating IPs are the default model for OpenStack.
The group listed many very good reasons and technically valid reasons for OpenStack to default to no external access including scarcity of IPv4 addresses and security. Ultimately, we agreed that this was confusing to users because AWS (and Google and Digital Ocean and …) provide external IPv4 access by default. This is a simple case where OpenStack does not follow AWS implementation choices (NOT API) and creates pain for users who are trying to work in hybrid environments.
The ideal fix, use IPv6 for external access, is also blocked by AWS. Since they are IPv4 only, most of the tooling and ops skills are not v6 ready.
It’s frustrating, but AWS choices drive the market for now.
Does that mean that we should just mirror AWS? No! Infrastructure is increasingly hybrid and diversity is a benefit to the market. The theme of the discussion is that we need to be more intentional about where we match and where we diverge. Each difference creates impedance issues for users and the OpenStack community should limit these variations.
As for my second concern, variations between OpenStack clouds, we need to address that too. It’s going to be a long time before DefCore creates uniformity since many of my implementation issues are not even included in the latest guidelines. Once again, the solution is to treat AWS as that benchmark rather than arguing which OpenStack implementation is more right.
David Medberry said it well: “sometimes the right technical choice is wrong for the project.”
The hardest decisions are always between multiple right answers. We’ve done a great job keeping OpenStack open and flexible; however, that variation makes it harder for users. Cloud already has a lot of variation between the major platforms. It’s time for us to give OpenStack users less to worry about.
If you’d like to connect with me in person, I’ll be at Dockercon in Seattle and OpenStack East in New York. Of course, I’m always stirring things up as @zehicle on twitter and posting about cloud, containers and hybrid DevOps on my blog: RobHirschfeld.com.
Superuser is always interested in OpenStack community content, get in touch at [email protected]
Cover Photo // CC BY NC
