It seems the future battleground for private clouds will be VMware and its army of system integration partners fighting the large system vendors that will be pushing OpenStack. It's for this reason I say OpenStack is going to be important for IT organizations going forward. When all the vendors align on a single solution, it's hard to imagine it's not going to become a core piece of IT infrastructure.
Deployment Matters, Not Just Development
On the other hand, don't let all the hoopla and triumphalism distract one from a vital reality: OpenStack is a young product that's not yet mature. The most vivid evidence of this is the Summit's overemphasis on developers and development-or, perhaps I should say, the absence of deployment discussion and sessions.
If OpenStack is truly to achieve its destiny as the de facto private cloud orchestration product, it has to be easy to consume. That means deployment has to be given priority. It's an open secret that upgrading OpenStack from one release to another is not seamless, and the releases come hot and heavy every six months. In fact, it's typically easier to start fresh rather than try and migrate an existing installation to a new release. That's unacceptable to a mainstream enterprise IT market.
OpenStack release plans and decisions need to incorporate end-user deployment requirements much more than has been done in the past. It can't just be lip service, either. Once a technology moves past the early adopter market, stability and manageability commonly become much more critical to the rest of the potential user base. Ignoring these requirements in favor of developer priorities will greatly hinder OpenStack mainstream market uptake.
Interoperability: How Should OpenStack Providers Compete?
Interoperability came up frequently at the Summit, and it's interesting that it did. When OpenStack was originally launched, founders trumpeted its use of the Apache license, citing the license's flexibility, which would let OpenStack providers modify the product for competitive differentiation purposes.
The downside of that licensing approach is that everyone's OpenStack product is different and incompatible. "Incompatible" is a word enterprises hate, because they know that, over time, they will end up with at least one of everything-and if they can't work together or, worse, work differently, it's a nightmare to manage.
I participated in an interoperability panel and made the following points:
- Interoperability is typically important to users. At a minimum, users want to know that major versions of a product, such as OpenStack Grizzly, provide the same functionality. To date, OpenStack "distros" vary significantly more than Linux distros do. That's unacceptable. A Grizzly distro has to be nearly identical for core functionality, no matter who it comes from.
- Specification interoperability-for example, when a vendor certifies that it developed its product to a certain standard-always gives way to creation of a test suite and certification of conformance to the standard by successful completion of the suite. Critical to this is definition of APIs and testing of API conformance. Using the same source base, while useful, is not sufficient for interoperability. Interoperability is based on behavior, not contents, so a test suite validating API conformance will be the true measure of OpenStack interoperability.
- OpenStack providers are going to feel significant end user pressure in the future to provide better interoperability. My prediction: This will lead to creation of a test suite and certification process and, once one large vendor (say, HP) certifies, everyone will have to do so ASAP for competitive reasons.
Sign up for MIS Asia eNewsletters.