eric.senunas

Is OpenStack Dead? A Virtualization Practice Perspective...

Discussion created by eric.senunas on Jun 9, 2014

From our friends / smart guys at the Virtualization Practice - Let us know what you think in the comments below:

 

Is OpenStack Dead? | The Virtualization Practice

 

June 2, 2014

 

By Bernd Harzog and Mike Norman

Is OpenStack dead (or rapidly dying)? We ask this question from two perspectives. First, can any OpenStack-based offering be economically competitive with offerings from Amazon, Microsoft, Google, and VMware? Second, can any consortium of vendors produce a viable public cloud offering in competition with vendors who own their own stack and can practice agile development and DevOps on that stack?

 

Can OpenStack Public Clouds Be Economically Viable?

In Public Cloud Computing—Economics and Throats to Choke, we first discussed the problem of vCloud’s partners having attempted a cloud offering that was price-competitive with Amazon while paying license fees to VMware. This turned out to be a very serious issue; serious enough to kill the entire vCloud effort and for VMware to replace it with its vCloud Hybrid Service, which offers cloud service directly to the customer. It turns out that it is a great advantage from an economic perspective (affecting cost, which drives the price at which services can be offered) for a public cloud vendor to have complete ownership and control of its stack of software and to owe no license fees. Amazon, Microsoft, and VMware are in this position. Google might be in this position if it is not paying license fees to Red Hat for KVM (whether it is or is not is unknown).

The table below compares the positions of Amazon, Microsoft, Google, VMware, an OpenStack cloud vendor, and Virtustream with regard to stack ownership and competitiveness of price.

Cloud VendorHypervisorCloud Management Stack under Full Control of Cloud Vendor?License Fees Paid to Software VendorsOn-Premises Version Available?Quality of Service Level Guarantees
Amazon EC2Owned by Amazon (derived from Xen) Developed and owned by AmazonYes – Amazon has full control of all source code NoYes – but only through a separate company,  EucalyptusAbysmal to non-existent
Microsoft Azure Owned by Microsoft (derived from Hyper-V) Developed and owned by MicrosoftYes – Microsoft has full control of all source code

No

Yes – over time as Azure components get integrated into Windows Server

At the application layer through partnerships withAppDynamics and New Relic; no end-to-end service level guarantees

Google Compute CloudRed Hat KVM Developed and owned by Google No – Google relies on Red Hat for KVM but has full control of its cloud management layer Business relationship between Google and Red Hat is unknownNo Google has acquired Stackdriver, which should lead to a solution in this area
VMware vCloud Hybrid Service VMware ESXi VMware vCloudAutomation CenterYes – VMware controls its own hypervisor and its entire cloud stack No – however, in some cases, the VMware vCloud Hybrid Service runs in third- party data centers for which VMware has to payYes – the VMware vCloud Suite is effectively the on- premises version of vCloud Hybrid ServiceThe VMware vCloud Suite includes extensive operations management and monitoring through vCenter Operations; no application-level monitoring is provided
OpenStack-based cloudsKVMOpenStackNo – public cloud vendor relies on OpenStack community for fixes and enhancementsCloud vendor may have to pay Red Hat for KVM licenses for its public cloudDepends on cloud vendor Service quality management not a part of OpenStack
VirtustreamChoice of VMware, ESXi, or PowerVM Virtustream xStreamNo – Virtustream relies on either ESXi or PowerVM for the hypervisor but owns and controls its own cloud management layerYes – Virtustream has to pay for the hypervisors, but not for the cloud management layerYes – xStream SYes – Virtustream uniquely offers end-to-end application response time guarantees for business-critical applications like SAP

Who Is Motivated to Evolve OpenStack?

OpenStack is, as we all know, an open-source project with many contributors. The major contributors to the Icehouse release of OpenStack are indicated in the graph below. What is notable is that Red Hat is in first place, and  Rackspace, the originator and supposed ultimate champion of OpenStack, is in fourth place. Perhaps this is explained by the fact that Rackspace is “investigating strategic alternatives,” which in English means “our business model has failed, and we are now trying to sell the company.” This is explained in full in “Stacking Up Rackspace Options,” by Steve Beaver.

OpenStack.Icehouse.Code.Commits

OpenStack Icehouse Code Commits

Source: Bitergia

Now, neither IBM nor HP are economically motivated to make OpenStack into a viable public cloud offering that competes with Amazon and that anyone can just pick up and run without paying any license fees to IBM and HP. Red Hat has an open-source business model and could assume the lead role, not just in code commits to the OpenStack project, but also in the sales, marketing, and support of OpenStack. However, if a public cloud vendor has to pay Red Hat for support, that is only marginally better than having to pay someone for license fees, which again raises the question of the economic viability of OpenStack as a public cloud platform.

Where Will the OpenStack Workloads Come From?

For any public cloud to succeed, there has to be a simple process either to create workloads or to onboard workloads from on-premises virtualized data centers or other public clouds. Creating new workloads in any public cloud is not that tough if you approach it correctly. If you use tools like Puppet and Chef to provision images, it is relative easy to provision them in different places. If you use Docker containers, deploying one to various instances of Linux in various clouds is relatively easy to do. If you use a tool like ElasticBox to encapsulate your entire application system, it handles all of the issues concerning deployment in various environments for you.

However, when it comes to existing workloads, the picture gets a lot tougher for OpenStack. OpenStack is typically deployed on KVM, and most of the virtualized images in the world do not run on KVM. Most of the virtualized servers in the world are either running on-premises on VMware ESXi or Microsoft Hyper-V, or on Amazon on Amazon’s version of Xen. Thus, unless the vendor of the OpenStack public cloud does a deal with a vendor like HotLink or Racemi, which can migrate workloads between hypervisors and clouds, the installed base of workloads is simply incompatible with OpenStack. Amazon has just demonstrated that it understands this problem by building a plug-in to vCenter that allows VMware customers to easily migrate workloads to Amazon.

Can OpenStack Compete with Amazon, Microsoft, Google, and VMware in Cloud Functionality?

OpenStack was conceived as an open-source project in the mould of other open-source consortia, such as Apache and Eclipse, in order to create benefits:

  1. To spread the cost of development across multiple partners
  2. To provide interoperability amongst disparate vendor toolchains and infrastructure components, leading to a richer set of combined solutions that dynamically track market trends.

Open-source consortia in the past have been very good at competing against proprietary software initiatives, due simply to the breadth and enthusiasm of those contributing to them. If the governance model of the consortium strikes the right balance between control and freedom (and therefore allows point two, above, to flourish), there comes a point at which the initial “anchor” of the consortium can scale back its resources and the network effect takes over.One might argue, therefore, that Rackspace’s apparent distancing from OpenStack is a good thing: that it reflects a maturity in the consortium. However, this almost certainly is not the case; the scaling back of resources typically occurs once the consortium has a dominant position. There is no sense in which OpenStack dominates. Rackspace is scaling back because it has lost the bet that it took on OpenStack, or perhaps more precisely, it hasn’t got the capacity to see itself through to the point where its bet would make good.A number of factors have made it hard for OpenStack to attain market dominance within the time frame that Rackspace has been able to allow for it:

  1. It started too late. Amazon’s dominant position was already established in the public cloud, and VMware’s was already established in on-premises data centers.
  2. Rackspace was slow to put in place the governance model for allowing significant third-party contributions. Open-source consortia can be very nimble once the techies are given free rein, but individual contributions to open source are a myth. Almost everyone is contributing on behalf of their employer, and they need “permission to play” from their legal department. They will only obtain this if the governance model is in place. It took Rackspace years.
  3. IaaS cloud is a very high-margin business. This may not be obvious if you are in an enterprise and used to paying for data centers, but resources on AWS still cost a very significant uplift on what they would cost as bare metal in a rack in a colocation facility. You are paying for the elasticity,  fault-tolerance, and convenient way in which the services are bundled; from that uplift, Amazon has vast amounts of margin to use to build out those services. It’s a virtuous circle. Compare that with Apache, for which the web server was close to free, and to Eclipse, for which software tools pricing was under extreme pressure. These were low-margin environments for which the proprietary solutions didn’t have enough revenue to continue to innovate.
  4. There’s a “chicken and egg” issue, but the egg is hardware and the chicken is software. For this chicken to fly, someone needs to invest in physical infrastructure to provide the public cloud. The software side of this consortium as a whole can’t act coherently to drive that investment, nor can it simply leverage whatever hardware people are using—the whole objective here is to create a viable public cloud, not to create the software by which such a cloud could, in principle, be produced.
  5. Amazon is gaining the benefit of the open-source communities that drive its constituent components whilst steadfastly avoiding putting either its own codebase or even its own APIs into such communities. Furthermore, the constituent open-source communities are letting it do this, even though Amazon’s own “secret sauce” is dwarfed by the open-source legacy it is consuming. One can debate the morality of Amazon’s actions, just as one can debate the morality of its approach to paying taxes, but there isn’t much question regarding the legality.
  6. Amazon delivers a great and innovative product. To most people, that’s all that matters.
  7. On the private cloud side, OpenStack appears to be missing a major piece of functionality in comparison to VMware’s SDDC; storage virtualization. VMware vSAN allows local direct access storage devices (DASD) in servers to be pooled and used as replacements for network-attached and Fibre Channel–attached storage. This will take money out of the hides of the enterprise storage vendors, which will make it economically difficult for vendors like IBM and HP, whose revenues are threatened by vSAN, to put similar functionality into OpenStack.

Summary

OpenStack is a dead cloud walking. It is dead, but its promoters and advocates just do not know it yet. It is dead because no one has the motivation to make it into a viable public cloud offering, and if someone did, the resulting business model would make the cloud provider uncompetitive with Amazon, Microsoft, Google, and VMware.

Outcomes