At its Paris summit, the OpenStack community celebrated the 10th release of what has become the leading open source Infrastructure as a Service cloud platform software. What stood out about this latest iteration and the progress of its ever-growing ecosystem of vendors, users and service providers was the lack of excitement that comes with maturity. The Juno release addressed many challenges holding back enterprise adoption to this point and showed signs that 2015 may prove to be the year its use shifts over from mostly test & dev, to mostly production. Forrester clients will find a new Quick Take on OpenStack that analyzes the state of this platform and recommended actions here. In this blog post we look at looming questions facing the OpenStack community that could affect the pace and direction of its innovation. 
 

Now that OpenStack has established itself and is showing signs of readiness for enterprise production use, the long wait as enterprises and service providers move from the sidelines into true implementations can take place in earnest. The long wait means we should see a slow but ever-growing string of enterprise and service provider announcements as they light up production environments and move across their key applications. Many enterprises making this move, may find it behooves them to go public about this, as a recruiting tool for potential employees. These announcements will be a trickle between now and the May 2015 OpenStack Summit in Vancouver, BC but should show strong momentum by October 2015 when the summit moves to Tokyo. In the meantime, there are a few key issues the OpenStack community needs to deal with that could prove to be distractions from the consistency, maturing and innovation of the platform necessary to keep this momentum driving. They are:

  • Define compatibility or core? There is little debate in the community around whether there should be compatibility between OpenStack implementations. But there’s significant debate around the means of assuring this. The definition of core OpenStack up to this point has meant everyone shipping the now 11 core components as built and hardened in the every-six-month release cycle. While a good strategy as the core was stabilizing, it is now failing as a mechanism for compatibility as the maturity of the core elements are not in lock step and alternative implementations have been proven thus far to be possible while still maintaining compatibility at the API call level. Thus DefCore has been shifting from requiring the code in the 11 core components to the API layer around these components. But the shift has not been complete due to debates in the community over the code in question. The community is dominated by developers who take pride in their code and code contributions are core to the community model. If a core component can’t scale efficiently to meet a large customer’s requirements, a distributor needs the ability to change that architecture to accommodate the customer. If a service provider needs greater multi tenancy than the current release supports or greater introspection to deliver secure sharing, they shouldn’t have to wait for the community to accept their contributions or risk losing rights to the OpenStack badge. Hopefully the move to a more API-centric model will yield the right kinds of changes between now and the Vancouver summit such that we can see a future path forward that will help OpenStack proliferate across a wide variety of use cases.  
  • The release train is now a tweener model. The OpenStack community deserve significant credit for releasing updates to the platform consistently and frequently since its founding in 2010. But the method of release is becoming a new tension point. On one side are enterprises and service providers used to 12 to 24 month release trains and taking 6 to 9 months to evaluate and transition to new releases. They are pushing back on the pace of change because they simply can’t (or aren’t willing to) accelerate their update processes. It also doesn’t help that most current OpenStack implementations are highly custom (a separate issue).  On the other side are development teams and those who live in the modern continuous delivery world who have shelved the release train model and embraced a services model where each independent service is its own entity and has its own continuous delivery cycle. For them 6 months is way too slow and the lock-step of 11 core components is a major hindrance.  Staying with the 6 month release cadence serves an important purpose both in the core projects and from a marketing standpoint but is a tweener model that satisfies neither constituency. Staying here will push OpenStack more cleanly into the old world camp aligning it more closely to how applications have been built mostly up to this point, while slowly nudging IT operations and waterfall development teams into the future at a conservative pace. Google, AWS and arguably Microsoft Azure are built using the services model that empowers this new modern app world and thus could distance themselves from OpenStack as the fuel for modern apps. It’s time OpenStack moved off the train and put each service on separate more agile release cycles. They could still package a release every six months but without the train. 
  • Workload-specific enhancements can cause contention. OpenStack is getting massive numbers of requests for enhancements that meet specific requirements for certain classes of workloads and vertical markets. Case in point is the big data lure which resulted in the new data management service (Sahara) added to core OpenStack in the Juno release. This service enables the deployment of Hadoop environments atop OpenStack along with similar data-centric workloads. Did the support of this workload need to be added to the core of the platform? Or should it have stayed an optional component? Clearly not all OpenStack implementations will require this but once compatibility testing mandates it to call your release compatible, then the core of OpenStack services you must include has grown in size and complexity. While this core data management service may fuel use of Hadoop it might also impede innovations in the space that use alternative technology foundations. Such has already been an ongoing debate in the storage space. Vertical markets will drive similar concerns such as…
     
  • …Telecommunications companies see OpenStack as a means to freedom. A running theme at the Paris summit, was discussion about OpenStack’s role in the NFV (network function virtualization) movement. This initiative, led today by many telecommunications leaders is an effort to drive key network capabilities, such as core routing, traffic QoS, line-speed security and other capabilities out of the proprietary appliances from Cisco, Juniper, F5 and others and into virtualized software running on commodity infrastructure. These entities see OpenStack and its orchestration capabilities playing a key role in driving this change. However for OpenStack (and more so Linux where most of the key changes are required) to achieve the needs of this market will require significant enhancements that it is not clear the rest of the market would benefit from. Thus tilling at this windmill could prove a major distraction for the community to the detriment of the mainstream enterprise market. Satisfying the unique needs of the telco community has proven a major distraction and R&D suck for many a large enterprise vendor in the past. The lure of changing the world in telecommunications is attractive to developers who dominate the community today, but those with hard-earned experience with this market will need to caution and guide the community with a heavy hand to keep the NFV distraction at bay.

What it Means: For now enterprises are advised simply to watch these areas as they develop; for right now they are rising only as potential issues that the community is well aware of and debating strongly how to address. However, don’t ignore them altogether as these issues could turn from distraction to market impacts if not managed effectively and then become your issue as an OpenStack customer. Want to ensure these battles go in your favor? Get involved. The OpenStack community still is too heavily weighted with vendor voices and welcomes enterprise involvement with open arms. If you plan to make a strategic bet on OpenStack treat it as such.