Yesterday, I posted about cloud distruptors that are pushing the boundaries of cloud. The same forces pull at OpenStack where we are working to balance between including all aspects of running workloads and focusing on a stable foundation.
Note: I am seeking re-election to the 2015 OpenStack Board. Voting starts 1/12.
For weeks, I’ve been reading and listening to people inside and outside the community. There is considerable angst about the direction of OpenStack. We need to be honest and positive about challenges without simply throwing stones in our hall of mirrors.
Closing 2014, OpenStack has gotten very big, very fast. We’ve exploded scope, contributions and commercial participants. Unfortunately, our process infrastructure (especially the governance by-laws) simply have not kept pace. It’s not a matter of scaling processes we’ve got; many of the challenges created by growth require new approaches and thinking (Thierry’s post).
In 2015, we’re trying to put 10 pounds of OpenStack in a 5 pound bag. That means we have to either a) shed 5 pounds or b) get a bigger bag. In classic OpenStack style, we’re sort of doing both: identifying a foundational base while expanding to allow more subprojects.
To my ear, most users, operators and business people would like to see the focus being on the getting the integrated release scope solid. So, in spirit of finding 5 pounds to shave, I’ve got five “shovel ready” items that should help:
- Prioritizing stability as our #1 feature. Accomplishing this will require across the broad alignment of the vendor’s product managers to hold back on their individual priorities in favor of community. We’ve started this effort but it’s going to take time to create the collaboration needed.
- Sending a clear signal about the required baseline for OpenStack. That’s the purpose of DefCore and should be felt as we work on the Icehouse and Juno definitions.
- Alignment of the Board DefCore project with Technical Committee’s Levels/Big Tent initiative. By design, these efforts interconnect. We need to make sure the work is coordinated so that we send a clearly aligned message to the technical, operator, vendor and user communities.
- Accelerate changes from single node gate to something that’s either a) more services focused or b) multi-node. OpenStack’s scale of community development requires automation to validate the new contributions do not harm the existing code base (the gate). The current single-node gate does not reflect the multi-node environments that users target with the code. While it’s technically challenging to address this mismatch, it’s also essential so we ensure that we’re able to validate multi-node features.
- Continue to reduce drama in the open source processes. OpenStack is infrastructure software that should enable an exciting and dynamic next generation of IT. I hear people talk about CloudStack as “it’s not as exciting or active a community but their stuff just works.” That’s what enterprises and operators want. Drama is great for grabbing headings but not so great for building solid infrastructure.
What is the downside to OpenStack if we cannot accomplish these changes? Forks.
I already see a clear pattern where vendors are creating their own distros (which are basically shallow forks) to preserve their own delivery cycle. OpenStack’s success is tied to its utility for the customers of vendors who fund the contributors. When the cost of being part of the community outweighs the value, those shallow forks may become true independent products.
In the case of potential forks, they allow vendors to create their own bag and pick how many pounds of cloud they want to carry. It’s our job as a community in 2015 to make sure that we’ve reduced that temptation.
1/9/15 Note: Here’s the original analogy image used for this post
Hi Rob, good post.
> I hear people talk about CloudStack as “it’s not as exciting or active a community but their stuff just works.” That’s what enterprises and operators want.
I’m from the CloudStack community and appreciate your compliments though would like to clarify that the CloudStack community while may not be as exciting, but we’re quite active – we’ve fairly good mailing list traffic, discussions, development work (we’re past 25k commits https://github.com/apache/cloudstack with 160+ contributors) and two big annual conferences (CloudStack Collab Conferences) where you should check us out along with local meetups and other activities. To add our community is highly focused on one upstream project with 1 or maybe 2 forks. CloudStack is used by several enterprise and businesses (http://cloudstack.apache.org/users.html), last time I checked it was 200-300 or so, and because of dayjob I have personally seen that it just works in production in very large deployments.
I think OpenStack is great but I find it as a framework or library which can be used to tightly couple existing workloads and build clouds, rather than a single IaaS platform product. Unlike CloudStack clouds which can be operated by a few small team say as low as 1-2 people, a successful OpenStack cloud requires a big team of engineers say 10-50 since it has so many components and it’s like a framework and not monolithic server like CloudStack. I would just like to point out that there is place for both the projects, use-cases and trade-offs and in using them and I think it’s just unfair to compare two technically different though intersecting projects.
It seems to me that most enterprises who have bad experiences (with both projects) may not know if they want a framework that allows them to run modern cloud styled workloads but requires tight coupling (OpenStack) or a platform that can do both traditional and modern workloads that is monolithic (various components such as compute, networking, storage etc. are just one big component) and would just work (CloudStack) – they may have bad experiences.
Rohit – thank you! You are making exactly the right points and also using a the right measures of success. Focused activity is very valuable. I keep thinking about Metcalfe’s law when it comes to activity (you can have too much and the wrong types).
Pingback: 2015, the year cloud died. Meet the seven riders of the cloudocalypse | Rob Hirschfeld
Pingback: More Signal & Less Noise: my OpenStack Tokyo Restrospective | Rob Hirschfeld
Pingback: More Signal & Less Noise: my OpenStack Tokyo Restrospective | GREENSTACK
Pingback: My OpenStack 2016 Analysis: Continue Core, Stop Confusing Ecosystem, Change Hybrid Approach | Rob Hirschfeld
Pingback: Weekend Reading, 1/9 - OpenStack Superuser
Pingback: Will OpenStack Go Supernova? It’s Time to Refocus on Core. | Rob Hirschfeld