fork_prisonWe are four years into the whole OpenStack Revolution. One of the principal concerns four years ago was the ability of the platform to avoid vendor lock-in. Some initially questioned if the approach of multiple cloud providers building natively interoperable clouds was a realistic goal. Bringing together a crowd of commercial interests to make a cohesive ecosystem that makes for relatively simple portability between providers seemed an elusive vision at start. Today, it’s fair to ask if the current model has created vendor lock-in.

What is OpenStack?

Before discussing how lock-in can occur in OpenStack, it’s crucial to understand what it is and is not. There’s several competing corporate and product agenda’s within the community. Many OpenStack champions pointed to Linux as an example of a multi-vendor based open source project that was able to overcome the challenges with code forking. However, OpenStack is different in nature from Linux. Contrary to the OpenStack Consortium’s marketing, OpenStack isn’t an operating system. It more appropriately described as a framework that product and services could be built which allows some interoperability.


The fight against AWS

The appeal of OpenStack in the provider space is obvious. All of the Cloud providers in the OpenStack Consortium have a common competitor in AWS. There are very few if any providers that can go head to head against AWS on both product offerings and price. The aspiration of competitors banding together in this community is to create an ecosystem (or the appearance of an ecosystem) that could compete with the scale of AWS. On paper, a consumer can build a private cloud based on the OpenStack framework and extend their private cloud to one of many OpenStack compatible providers. It’s important to note due to the difficulty of rolling out the raw OpenStack distribution at scale is difficult. Similar to other open source projects such as Linux, this as created a cottage industry of vendors who sell packaged OpenStack distributions, which they help deploy and of course support.

Who consumes OpenStack

Application developers are the eventual consumer of OpenStack based clouds. It’s essential to remember that the primary desire of the major sponsors is to battle against AWS, as well as other OpenStack providers. As such, OpenStack providers, must differentiate themselves from AWS and other OpenStack providers by offering new and compelling services. In these early days of OpenStack, there are plenty of opportunities to build custom services that separate the opposition. And this is where the lock-in difficulties are exposed.

Related Post – OpenStack is hard but the community is here to help

One of the major services offered in the Icehouse release of OpenStack is Trove, the Database as a Service (DBaaS) module. Prior to the release of Trove, providers such as Rackspace offered DBaaS products by leveraging MongoDB to build the underlying service. While the underlying DB technology is the same, the cloud wrapper is different which may require code changes to implement. Earlier examples are solutions to problems integrating VMware vSphere. Prior to the Havana release, providers and black box vendors such as Piston and Marantis would build custom code or “forks” to provide the capability required by their customer.

Little forks add up

It’s these forks of the mainline framework that creates the challenges. In theory, you can undertake the activity that Rackspace is undergoing with their DBaaS by bringing their MongDB based offering in line with Trove. However, in practice this is a disruptive undertaking especially when additional customizations have been added to provide even more capability. If you’ve ever had to upgrade an ERP such as PeopleSoft or SAP after customizations have been added then you can relate to the pain.

Advice to the enterprise

If considering OpenStack for the ability to move from provider to provider, you need to weigh heavily the cost of leveraging differentiators such as DBaaS. The OpenStack Consortium is cracking down on branding of products that don’t stay true to the core compute and network services. While this gives some level of certainty for these core services, it’s important to understand what customizations have been applied to non-core services. The challenge is these customizations can be key differentiators and key in selecting a private cloud distribution such as CloudScaling over Marantis. This same value-add may also keep you locked-in to a specific vendor’s OpenStack implementation. A framework is not the same as a standard and thus shouldn’t be treated as such.

Tagged on:

2 thoughts on “OpenStack alone doesn’t prevent vendor lock-in

  • Pingback: OpenStack alone doesn't prevent vendor lock-in ...

  • May 11, 2014 at 2:41 am
    Permalink

    “OpenStack is different in nature from Linux.”

    “OpenStack isn’t an operating system.”

    Linux isn’t an operating system either. Linux is only a kernel, which can be used to build an operating system. There are vendors and projects that do that. RedHat, Suse, Debian, Canonical. They bring together parts and pieces and build a distribution, sometimes in different flavors (aka an operating system/solution for customers).

    When using open source software. Almost always pick a vendor where anything developed by the vendor is done as part of the normal open source project. They might have some deployment mechanism build around it. But what you are deploying should be part of the main project so you don’t paint yourself in a corner.

    Unless you are an early adopter. :-)

    Reply

Leave a Reply

%d bloggers like this: