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 Vendor Hypervisor Cloud Management  Stack under Full Control of Cloud Vendor? License Fees Paid to Software Vendors On-Premises Version Available? Quality of Service Level Guarantees
Amazon EC2 Owned by Amazon (derived from Xen)  Developed and owned by Amazon Yes – Amazon has full control of all source code  No Yes – but only through a separate company,  Eucalyptus Abysmal to non-existent
Microsoft Azure  Owned by Microsoft (derived from Hyper-V)  Developed and owned by Microsoft Yes – 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 with AppDynamics and New Relic; no end-to-end service level guarantees

Google Compute Cloud Red 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 unknown No  Google has acquired Stackdriver, which should lead to a solution in this area
VMware vCloud Hybrid Service  VMware ESXi  VMware vCloud Automation Center Yes – 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 pay Yes – the VMware vCloud Suite is effectively the on- premises version of vCloud Hybrid Service The VMware vCloud Suite includes extensive operations management and monitoring through vCenter Operations; no application-level monitoring is provided
OpenStack-based clouds KVM OpenStack No – public cloud vendor relies on OpenStack community for fixes and enhancements Cloud vendor may have to pay Red Hat for KVM licenses for its public cloud Depends on cloud vendor  Service quality management not a part of OpenStack
Virtustream Choice of VMware, ESXi, or PowerVM  Virtustream xStream No – Virtustream relies on either ESXi or PowerVM for the hypervisor but owns and controls its own cloud management layer Yes – Virtustream has to pay for the hypervisors, but not for the cloud management layer Yes – xStream S Yes – 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.

Share this Article:

Share Button
Bernd Harzog (324 Posts)

Bernd Harzog is the Analyst at The Virtualization Practice for Performance and Capacity Management and IT as a Service (Private Cloud).

Bernd is also the CEO and founder of APM Experts a company that provides strategic marketing services to vendors in the virtualization performance management, and application performance management markets.

Prior to these two companies, Bernd was the CEO of RTO Software, the VP Products at Netuitive, a General Manager at Xcellenet, and Research Director for Systems Software at Gartner Group. Bernd has an MBA in Marketing from the University of Chicago.

Connect with Bernd Harzog:


p5rn7vb

Related Posts:

9 comments for “Is OpenStack Dead?

  1. Dmitry Smirnov
    June 2, 2014 at 8:37 AM

    > 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…

    Pardon me? vSAN has just been released, and OpenStack has had Ceph for a while now. The suitability of those offerings for real-life production use is a different matter though.

  2. June 2, 2014 at 10:46 AM

    Not sure I agree with this. If the statement was “OpenStack as a public cloud platform is dead” then maybe I could see it, but that’s not where (IMO) its future lies.

    We are slowly seeing the cloud ecosystem align to an inside-outside pattern, where a vendor has some control over a workload regardless of whether it run inside a customer’s firewall or outside it in a public could. VMware is the best example, but Microsoft is right behind, and it’s no coincidence that those companies own the vast majority of the traditional, legacy, x86 workloads running inside enterprises today.

    Amazon has the opposite issue. They own such a large percentage of public cloud workloads that it’s hard to figure who is in second place, but they have nowhere (other than Eucalyptus) to go inside the data center. OpenStack can be that if the drive to include core API compatibility is successful. OpenStack doesn’t have to *compete* with AWS, they can be the private cloud version of AWS and ride those incredibly long coat-tails into enterprises who love the operational and consumption model but can’t (or won’t) move everything outside their data centers. It will also be a huge boon for companies who have to repatriate apps back in-house for whatever reason.

    I think we’ll see a time where enterprises need to decide which ecosystem they want to be in, and then leverage the inside-outside model provided by that ecosystem. VMware and Microsoft are pretty far down this road, moving inside-out, and I think (hope) that AWS/OpenStack will do much the same thing just in the opposite direction.

  3. Bharzog
    June 2, 2014 at 11:36 AM

    Hi Jeramiah,

    So your argument boils down to that concept that OpenStack might evolve to become the on-premise version of Amazon. I agree that API compatibility is possible. But I seriously doubt that a combination of Red Hat, IBM, HP and Rackspace can keep up with Amazon on the innovation front. API compatibility is rather useless if all of the underlying services are not there. And Amazon is demonstrating an amazing rate of innovation in the development, enhancement and delivery of those underlying services. I am frankly skeptical that anyone except for Microsoft, Google and VMware has a chance to keep up.

    Hi Dmitry,

    My understanding is the Ceph is a separate open source project from OpenStack leaving it to the OpenStack vendor or customer to integrate them. With VMware there is one throat to choke.

  4. Mike Norman
    June 2, 2014 at 4:06 PM

    By the way, Bernd and I have slightly different perspectives on this. My perspective is that there is a reason why Amazon isn’t taking AWS inside the datacenter and is letting Eucalyptus burn that particular bucket of VC-backed sales dollars. Amazon is betting that public cloud will eventually dominate and it can ride the growth curve quite happily until it does so. I guess I’m seeing it more in terms of innovation in the application space as being the driver of growth, rather than the application legacy.

  5. Bharzog
    June 2, 2014 at 7:46 PM

    So what is great about being a TVP Analyst is that I get to debate with great people like Mike Norman.

    My perspective is that the workloads (applications) in the world fall into three buckets:

    1) Those that will never run in any kind of a public cloud (think J2EE apps with Oracle back ends, with mainframe CICS back ends).
    2) Those that will migrate over to the cloud over a 20 year period as the cost of maintaining them exceeds the cost of rebuilding them (think all of the the web apps from the dawn of the Internet including first generation client/server, CGI scripts, ASP, ASP.NET, etc.
    3) Webscale apps built for elasticity in the cloud, or applications that can be rebuilt around this model.

    IMHO clouds are only useful for web scale apps that require some level of elasticity and that therefore require the technical and economic benefits of moment by moment scalability.

    Few apps require this, and therefore the use case for the public cloud is limited to those apps in the near term.

  6. Samuel A. Falvo II
    June 3, 2014 at 9:53 PM

    To suggest that Rackspace is in the dumps because it isn’t the leading committer to OpenStack is the same argument that Linus Torvalds is technologically inept because he’s no longer the leading contributor to Linux. Rackspace established a community for a reason — so it WOULDN’T be the leading committer!

  7. Bharzog
    June 4, 2014 at 9:50 AM

    Rackspace has admitted that it has problems. Read Steve Beaver’s post “Stacking Up Rackspace Options”. So I think that OpenStack has problems because Rackspace cannot make the investments that are needed into OpenStack. This is reflecting the declining commits to OpenStack by Rackspace.

  8. Neil Martin
    July 2, 2014 at 1:45 AM

    Very uninformed piece of writing XEN, VMWARE and Hyper-V are all part of Open Stack

    So run your workloads where you need to

    Somebody needs to go and do some factual based research, this article is based on inaccurate data which leads to flawed conclusions
    Open Stack does not need to succeed in the public cloud to be a success – multiple clouds can and will exist.

    In the private cloud area the business decision process is much more about consolidation of internal processes than the religion of cloud vs cloud.

Leave a Reply

Your email address will not be published. Required fields are marked *


− 3 = four