We 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.
@virtualizedgeek it’s a framework for building IaaS products and services. Neither a CMP nor a Cloud OS, really.
— Joshua McKenty (@jmckenty) April 11, 2014
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.