Henry Ford was famously quoted as saying, “If I had asked people what they wanted, they would have said faster horses,” in response to complaints that he ignored customer input in favor of his own vision when it came to the Model-T.  While it is debatable if Ford actually uttered those exact words, most historians would agree that Ford had a vision for manufacturing automobiles that was often at odds with customer demands – “Any color as long as it is black.”  It is also not debatable that Henry Ford was able to marry this homogenous design approach with the assembly line process to drive down the cost of manufacturing automobiles and create a new market that the Ford Motor Company was able to dominate from 1908 to 1920.

The debate over how to best drive product/project innovation, either by meeting customer demands or by assuming customers know what they want but not necessarily what they need, is one that is garnering increasing attention as OpenStack continues its push into the Enterprise, or as Geoffrey Moore first pioneered as a model, attempting to cross the chasm from the early adopters to the early majority.

Recently, the guys over at The Cloudcast, Aaron Delp and Brian Gracely, talked in their podcast about the impact of the VMware crowd joining the OpenStack community, with VMware Customers’ unsurprising call for OpenStack to be a “free vSphere” alternative, and if there is a need for a split between modern and traditional IT.  A few days before the podcast, I had a short exchange with Brian and Mark Twomey, a.k.a. Storagezilla regarding the same topic.

That exchange (which was the inspiration for this post) originated from some observations I tweeted regarding what I have been hearing as I’ve spoken with enterprises about their interest in and adoption of OpenStack.  While some view, correctly, that OpenStack is designed today to be the cloud platform for next-generation cloud-native/3rd Platform workloads, many others want OpenStack to be an open source alternative to VMware’s vSphere and vRealize Suite.  While I was at Rackspace and talking to enterprise customers who were starting to investigate OpenStack, the most frequently asked question I heard was, “does OpenStack have Virtual Machine (VM) High-Availability (HA) and vMotion [Live Migration]?”  As customer understanding of OpenStack capabilities has grown over time, my conversations with EMC customers also frequently lead to questions about how we can add VM HA and Live Migration features to OpenStack.

And it’s not just EMC customers either.  I recently joined the OpenStack Foundation’s Win The Enterprise (WTE) technical working group.  As the group’s wiki indicates, the mission of this joint multi-vendor/multi-end-user group is “to look at “Pet”-style workloads on Private Clouds in large, process-heavy organisations” and “to conduct gap analysis of OpenStack vs. Enterprise Private Cloud needs, identify issues, and create action plans [i.e. blueprints and documentation] to solve them.”  As the public meeting notes indicate and the meetings I have attended confirm, there is a strong interest in making deployments and operations easier, which I doubt anyone would disagree are much-needed improvements.  However, there is also strong desire to add feature, such as VM HA, Live Migration, Distributed Resource Scheduler (DRS), and shared Cinder volumes, to core OpenStack projects.  The inclusion of these features, long found in enterprise virtualization technologies such as VMware vSphere, has long been debated since OpenStack was open sourced as a project.

These debates have become more vocal as enterprise customers and vendors have increased their push to include such traditional virtualization features through initiatives such as WTE and at the Design Summit sessions.  At these sessions, you see clearly developers who want to preserve the purity of OpenStack as a next-generation cloud platform, in the mode of Amazon Web Services (AWS), with shared-nothing architectures and relying on application-level resiliency.  You can also hear from many who believe that for OpenStack to mature as a platform for enterprises to use, it must add features to accommodate legacy/2nd platform workloads that required shared infrastructure level resiliency.

Who is right here, the “cloud purists” or the “enterprise pragmatists?”  I find myself both sympathetic to and in opposition to both sides at various points. As I see it, there are at least three approaches that the OpenStack community can take, all with pros and cons to them.  The names I am proposing are how I believe the proponents of these disparate approaches see themselves.  Hopefully, I am not creating straw men.

• “Purist” Approach – This was the predominant view during the early days of the project when OpenStack was envisioned as an open Source and private cloud alternative, not so much to VMware vSphere, but to AWS.  As I’ve explained in various talks and in an earlier blog post, “workload dictates architecture.” This fundamental principal explains why OpenStack was not designed to use shared components or to provide VM resiliency, which is necessary for running traditional workloads such as an Oracle relation databases or Microsoft Exchange.  The workloads that OpenStack was designed to go after are the next-generation web scale applications, like Netflix OSS, that run primarily on cloud platforms like AWS and Rackspace Cloud.  The argument of the purists is that by changing course and going after traditional workloads, the OpenStack community risks falling behind on the innovation curve and also enabling enterprises to avoid the inevitable move to the 3rd platform, i.e. giving users a faster horse when future relevance for them means they need an automobile.  The counter argument is that the purists are being tone death to user needs and not accepting the reality of technology artifacts in the enterprise.
• “Pragmatist” Approach – At the opposite end of the spectrum, seemingly, are the pragmatists who wonder what use there is to selling race cars when users are only ready for horses or jalopies at best?  The pragmatists argue that 80% to 90% of enterprise workloads today are traditional 2nd platform applications that will take many years to be rewritten or to be replaced by cloud-native/3rd platform applications.  If OpenStack focuses only on next-generation workloads, users will move to other platforms or stay with the platforms they are currently on and just look to evolve with them.  If that happens, OpenStack risks being relegated to niche product status.  The future of OpenStack lies in being able to embrace the Enterprise, to meet them where they are, and to not take the approach of “change or die.”  Adding features like VM HA and DRS will allow OpenStack to propagate in the Enterprise and for the OpenStack community to become a change agent that helps users move into the future.  The counter argument is that we would then be, as outlined before, backtracking on the original design goals behind the project and retarding OpenStack innovation.
• “Bimodality” Approach – This approach plays off a blog post on Bimodal IT, written by Lydia Leong, from Gartner.  Proponents of the bimodality approach would argue that both the purists and the pragmatists are wrong-headed and inflexible.  Either approach forces users and developers unnecessarily into a “Sophie’s Choice” dilemma that ultimately does not serve anyone’s best benefit.  Instead, we should focus on allowing enterprises to evolve naturally to the cloud-native/3rd platform with OpenStack as the preferred cloud platform for that workload, while not doing anything to make dramatic changes to the OpenStack core and leveraging features that already exist in traditional virtualization technologies.  One option in this approach, which I’ve blogged about in the past, include running virtualization technologies such as KVM and vSphere as options in a multi-hypervisor OpenStack deployment and a second option is running two distinct cloud platforms.
  •   This first option would allow customers to run legacy/2nd platform workloads in a “legacy workload” zone and to run cloud-native/3rd platform workloads, using an open source hypervisor, in a “next-gen workload” zone.  A variation on this theme is the recently announced beta for VMware Integrated OpenStack (VIO) which leverages vSphere to run OpenStack services and to manage vSphere as an OpenStack hypervisor.
  • A second option under the “bimodality” approach is to run OpenStack and other virtualization technologies as separate platforms, each running the workload best suited for that platform, and then use a multi-cloud management platform such as VMware’s vCloud Automation Center, RightScale, or others to be the master orchestration tool across all the platforms.

However, one of the primary arguments against this approach is that it still requires users to license proprietary software in order to gain the benefits of the features required to run traditional workloads and, in the latter option, to manage multiple platforms.

So as I asked earlier, who is right?  Which approach is the best to take?  While I don’t have that set definitively in my own mind, I do find myself leaning towards the “bimodality” approach, though I have concerns about creating more silos in IT.  But I find the “purist” approach often too inflexible and unrealistic in light of an industry where mainframes still run core parts of many enterprise businesses.  I also find it interesting that the “pragmatist” approach, ultimately, is not really that different from the “purist” approach that it opposes.  At the end of the day, if the argument of the “pragmatist” is that OpenStack must change to be more traditional workload-centric, then they have become simply “legacy purists” throwing stones at “cloud purists.”

And therein lies one of the potential pitfalls of an inflexible purist approach, legacy or cloud.  Eventually, Ford’s inflexibility allowed General Motors to disrupt them, less than a decade after the heydays of the Model-T, by satisfying the needs of the consumer – “A car for every purse and purpose” – while still moving the automotive industry forward and delighting customers with innovations such as annual model changes and used card trade-ins.  Instead of sticking to our “pure” principles, the OpenStack community may be best served by taking a “bimodality” approach and what I am apt to describe as being the true pragmatist approach.

However, one of the beauties of an open source community is that we all have the freedom to discuss and yes, to argue for our point of view.  I am open to being told that I am completely wrong and/or I’ve created straw men to knock down.  As community events such as the OpenStack Summit in takes place, I look forward to healthy and respectful dialogue with the community.