OpenStack will Open Source Vendor Certifications

Boris Renski, Mirantis- February 18, 2014 -

Here’s what many don’t understand about OpenStack: it’s not just open source cloud software, it’s a movement to commoditize infrastructure. When first launched, it disrupted the cloud software market, forcing established players like Eucalyptus, CloudStack and even VMware to reconsider their market direction. As the OpenStack community evolved, it started to commoditize poorly differentiated technologies around it – such as billing and metering systems, proprietary installers and third party platform tools. Every day more and more infrastructure companies have to answer the much-dreaded question of “how are you really different from OpenStack?”

Big deal, skeptics would say. MySQL followed Oracle; JBoss followed WebSphere. Rebuilding AWS under Apache 2.0 is no commoditization wave. Well, today the community is onto something that is much larger than just re-building AWS. OpenStack is now moving to disrupt one of the key hooks of lock-in that has little to do with software code — the traditional hook of “vendor certifications.” And we at Mirantis are going to help the community do this.

Let me explain.

One of the most powerful ways used by large companies to build competitive barriers is through platform certifications. “I’ll certify your OS to run on my hardware…I’ll certify your software to run on my OS, and so on…” Add one part compatibility testing, two parts public relations, mix together and you have your competitive barrier. We see signs of this happening in OpenStack right and left. Large software powerhouses have been notorious for exploiting the platform certifications advantage against the smaller, disruptive vendors for years. But the OpenStack community is about to change this. How?

Enter open compatibility testing. Goodbye proprietary certification.

The OpenStack community is now building a standard, open set of tools that vendors can use to self-certify compatibility of their solutions with the upstream OpenStack codebase. Vendors will set up their own internal testing labs, link these labs to the community-driven OpenStack continuous integration system, and dynamically expose the results of their certification tests in a publicly available dashboard. Jay Pipes, who recently joined the Mirantis team, is helping spearhead this effort and has published a series of posts to help infrastructure vendors join and participate in this program:

More than a dozen major infrastructure vendors, including VMware, NetApp and HP, as well as large OpenStack users such as Yahoo and Dreamhost, are supporting the initiative. We’ll be asking all partners integrating with Mirantis OpenStack to formally join this effort and are committed to helping vendors set up their internal testing environments. To that effect, we’ll also be offering free support to all vendors setting up their internal testing labs. Third party vendor drivers that haven’t been tested following this process will likely be deprecated from the OpenStack trunk by the end of 2014. If you aren’t already a part of this effort, please contact us.

When this is done, everybody looking to adopt OpenStack will have access to accurate and objective information on how well a vendor’s solution works with OpenStack with no involvement on behalf of a downstream distribution vendor. Moreover, everybody will know what tests were conducted and what process was followed to justify any certification.

The reason I am particularly excited about this is because this initiative advances a bigger mission of the OpenStack community. In my opinion, that mission is not just about software and has little to do with how easy OpenStack is to implement, how well it scales or how many bugs it might have. That bigger mission is about breaking down competitive barriers that large vendors leverage to extract unfair margins from customers and slow the pace of infrastructure innovation.

When Amazon launched EC2 and the concept of infrastructure cloud was born, it took the world a while to understand that “cloud” is a paradigm shift in infrastructure computing, not a VMs-on-demand offering. Today, many who criticize OpenStack are stuck in the mentality that OpenStack is just open source cloud software, where in reality it is an infrastructure commoditization movement. Ultimately, OpenStack is not about the software. It is about establishing an even playing field where innovative technologies stand a chance against the big dogs.

With this initiative OpenStack is once again redefining the boundaries of open communities, while pushing the vision of vendor-agnostic cloud closer to reality.

So this is great stuff, but to be fair this is something that started prior to the Hong Kong summit and has been actively worked on in projects like Cinder. Also a process (albeit imperfect and very limited currently) was discussed agreed upon in the Icehouse-1 release and started last Dec.

None of that matters much to me, the end result is the same result I’ve been pushing and driving for as Cinder PTL so that’s great. The whole thing about working as a community is working together for a common end goal.

What does give me pause however is what the example you have here is meant to depict? Or more importantly what it’s meant to lead people to believe?

A number of those vendors you have listed have not done any of the existing cert work, and a couple have voiced that they do not want to. Even worse, a number of them I know for a fact currently do not pass the simple tempest volume api tests.

In addition the comment about deprecation is a great scare tactic, but currently it’s really just that. Perhaps we’ll end up there and that’s fine but currently the discussions (at least on the Cinder team) have been to focus on public presentation of the data and information. Things like deprecation open up a whole new debate that we haven’t gotten to yet. Honestly I don’t think we’ll even get there, most people IMO want to deliver good code and good products that work and they will. The trick thus far has been showing them how to verify that their code does that.

It’s a fantastic and much needed effort and kudos to Mirantis, I appreciate the focus here and the willingness to move this along. I do however think that accuracy is just as important as effort.

I especially want to thank Jay Pipes of Mirantis for driving a process and publicly documenting how to implement in house.

We are fully aware of the history of this effort and definitely want to attribute the credit to solidfire and you personally for driving this… apologies for not having explicitly listed you guys in my blog among the supporting vendors.

You are also correct that there is still a road to travel for all the vendors to fold into this process. We’ve talked to most everybody who has written drivers during the last month and while everybody is onboard in principal, we as a community still have work to do to get people to deploy in-house test environments.

Discussion on deprecating drivers is something I got from the very thread you’ve been evangelizing – http://lists.openstack.org/pipermail/openstack-dev/2014-February/026999.html. I too am unclear if this is necessarily the best strategy. At least, it’s something that will need to be gradually phased in over time… I also believe that positive reinforcement could be a better strategy to drive all vendors to adhere to this such as properly communicating to the public which vendors, do, indeed, pass the tests and which do not via a clear, dynamically updated dashboard. That is arguably more powerful than scaring people into doing things by deprecating drivers from the release. This is also exactly what we intent help the community with and Jay is pushing this forward.

I think enterprise adoption and vendor certification are related to some extent, perhaps unfairly so I’m quite happy the certification initiative is gaining traction. It will even be a nice way to add some meat for architects looking for quick hanging fruit re how Proof of Concepts are assembled, executed and communicated to the enterprise.

Love the idea about enabling self-cert for enterprise vendors. Don’t like the editorial comments about enterprise vendor motivations.

I think Boris, and some of the other OpenStack thought leaders, need to backoff about one of OpenStack’s goal’s is to “commoditize the infrastructure” and that enterprise vendors “slow the pace of infrastructure innovation”.

Innovation is not just for startups.

By taking this approach, the community actually inhibits innovation by the 10,000’s of engineers at these companies. Who wants to help innovate a project that is targeted at minimizing VALUE-ADD DIFFERENTIATION? The tone needs to change. (my opinions).

In all honesty, neither myself, not any one person has the ability to define the direction in which OpenStack community evolves. By stating that “OpenStack is commodotizing infrastructure,” I am not attempting to encourage the community to do this… instead I am merely describing my personal observations.

I wrote about this property of the OpenStack movement in a separate piece, where I talk about it being impossible to monetize OpenStack with the open-core model.

The concept sounds good at one level, but I am concerned about the following “active variables” involved in trying to make it work;
1) The large vendors that want to create their own OpenStack version, or to embed it inside and wrap it around their own products and make it a Super OpenStack or OpenStack ++ Power version.
As these two types of market participants move forward, they will have chellenges keeping up with a 6 month rolling change cycle. Many will modify things and go their own way, or refuse to include new technologies or fixes that break things in their versions, or that overlap in functionality.
2) Third party ISV’s and IHV’s that want to be compatible with OpenStack that they can test to, certify to, recommend to customers that they are compatible with, and to have someone accountable to support that OpenStack version with their product, for a reasonable period of time.
I feel that this 2) group is 90%+ of the ecosystem potential to build around OpenStack. They are not looking to add code to OpenStack, mainly support and build around it.
The model being proposed has some flaws in my view in being able to pull that off effectively with that many vendors as part of the control process.
Maybe this will be better than prior attempts at this sort of thing in Linux and UNIX for example. But it still feels like it could unravel fairly quickly.
Will see