How to Avoid Cloud Vendor Lock-In when Evaluating a PaaS - Archived

Vendors love Lock-in

Ah, vendor lock-In.  It has been with us for ages.  Classic examples include “locked” GSM cell phones, printer ink cartridges that are printer-specific, and even today’s Gift Cards are a form of vendor lock-in.  And why not?  If you are selling a product, wouldn’t you want to build it or sell it in such a way that it would be painful for your customers to move to a competing product?  Wouldn’t this be just good business sense?  Well, the initial vendor forays into cloud computing’s Platform as a Service (PaaS) used just this logic when building and launching their services.

What’s a PaaS?

As a refresher, remember that Platform-as-a-Service is one of the three canonical service delivery models for cloud computing as defined by the National Institute of Standards and Technology (NIST).  Platform-as-a-Service provides a mechanism for allowing application developers to easily take advantage of the power, efficiency, and elasticity of cloud computing by providing a complete application platform running in the cloud.  This application platform is a build and execution environment for applications coded by developers.  When using a PaaS, developers need only worry about their code because the PaaS platform takes care of all operating system and middleware administration and automation duties.  The developers just code their app and push it to the PaaS where it will run in an auto-scaling fashion.

PaaS 1.0 – Lock-in is a feature

As mentioned, the early PaaS offerings (we’ll call them PaaS 1.0) were built and designed in a way that created user lock-in.  There were a number of ways that lock-in manifested itself in these PaaS offerings, including:
  • Proprietary programming languages specific to the PaaS
  • Non-Standard versions of open source programming language implementations including PaaS-specific APIs
  • Specialized infrastructure services offered by the PaaS and accessible by APIs not supported elsewhere
  • Specialized data repositories and databases offered by the PaaS but not supported elsewhere
Eager to jump on the cloud computing band-wagon, developers flocked to these early PaaS offerings because they were the only game in town.  Many developers invested hours, days, or weeks crafting their applications to take advantage of the PaaS and the proprietary features and services that it offered.  They built applications that supported their livelihood and became mission critical to them.  They were excited to be able to use “The Cloud” to their benefit!
Then, one day, the PaaS vendor decided to increase the fees that they were charging for the PaaS, pretty much because they could.  
So, in order to avoid changing their own business model, the developers decided to move their application to a different environment that was cheaper.  Except that once they looked at their code, they realized that they were stuck!  It finally dawned on them that the cool storage features and APIs that they had coded into their application were uniquely specific to their PaaS vendor!  No other solution offered those same services or supported those APIs. So, these developers were “Locked In” to their PaaS vendor’s solution. :(

PaaS 2.0 – Open by design

The good news for us (and a hard lesson learned by those developers) is that in today’s technology world built around collaboration, open source, and interoperability, there is no excuse for vendor lock-in, especially in Platform as a Service. Because of this, savvy developers are now putting lock-in at the top of their evaluation criteria along with functionality and pricing.
Developers and Enterprises that want to leverage the power of cloud computing by utilizing a PaaS to build, deploy, and run their applications should make sure that they look for a next generation PaaS (PaaS 2.0) that is a No Lock-In PaaS.  In order to prevent Lock-In the PaaS should have the following features:
  • Polyglot (Multi-Language support) – The PaaS should support app development in multiple languages so that developers can change programming languages in order to use the right tool for the job when needed.
  • Built on Open Source – The PaaS should include and support standard open source language runtimes and implementations.  By leveraging a PaaS that runs pure open source languages, a developer can very easily take his application that he has written and move it to another environment where that open source language is running.
  • Be Open Source – The PaaS itself should be open sourced.  That is, the vendor’s PaaS should be based on an open source project which would allow other implementations of the same PaaS to be created.
  • No Proprietary APIs – The PaaS should leverage standard file, datastore, network, and memory access libraries so that applications can be moved off the PaaS to other environments if desired.
Requiring that your PaaS vendor provide the above feature set will go a long way toward making sure that if, for some reason, you need to move off of that particular PaaS, then you will be able to, i.e., you won’t be Locked In.
At Red Hat, the OpenShift PaaS is open by design so “No Lock-in” is something you check off your evaluation checklist from the start.


Thought Leadership
Comments are closed.