The following statement is a commonly held misconception that needs to be addressed here and now: without standards, I'm going to get locked-in if I go down a PaaS path.
Addressing another PaaS myth and misconception
This misconception has its probable roots in 4GL type of offerings à la Salesforce's Force.com, one of the first PaaS offerings to ever hit the market and which was very quickly a great market success. Force.com aimed at providing a high-productivity, development environment that was tightly integrated within their existing CRM solution. In doing so, Salesforce delivered a PaaS that came with its own proprietary language (APEX), its own database, its own APIs as well as its own process for staging and deploying new code to production. With the success of Force.com came the realization by many Salesforce customers that any new line of APEX code was one step further down the path of being locked-in. If one day a company moved to a CRM competitor, any customization, integration, custom behavior, etc. would have to be rewritten from scratch, based on a new database model and schema. Hence was born the PaaS equals lock-in association.
The benefit of a PaaS is in it being delivered as a service to you.
Sacha Labourey, Cloudbees CEO
However, it is easy enough to step back and realize that in that specific instance, lock-in has nothing to do with the cloud or PaaS: any company that would use a proprietary language, database, set of libraries and development process would be digging their own lock-in hole. This situation is totally orthogonal to the question of whether this happens on-premise or in the cloud, on top of an application server or within a PaaS environment.
Instead, if you look at the mainstream play for PaaS today, providers will typically try to leverage, as much as they can, existing developers' expertise, existing ecosystems, existing communities. Today's PaaS will offer support for mainstream build and testing tools, languages (Java, Ruby, PHP, node.js, etc.) and databases (MySQL, MongoDB, CouchDB, etc.). The goal is obviously to offer a low barrier to entry to developers. Yet, in doing so, to also create some type of equal playing field that shifts decision power to the users of those PaaS solutions, not the vendors, and makes it possible for them to relatively easily switch from one vendor to the other, including … to their own "IT vendor" - i.e. their on-premise datacenter!
So, where is the catch? The benefit of a PaaS is in it being delivered as a service to you. Consequently, if you were to decide to bring back that software in-house, you'd obviously have to re-assume that task. As we discussed in Myth #5, stepping up to service delivery on your own is no small task, and you shouldn't think you're going to be recreating the PaaS yourself. So does using a PaaS mean you are locked in? No, but you'll have to spend considerable amount of time, talent, money and energy assembling the required software layers and delivering yourself the service … that was once served to you. Hence, we are not talking about a cost of lock-in here, we are talking about a cost of doing things on your own, which is very different.
Playing musical chairs with your PaaS provider
However, the most likely scenario is not so much that you'll want to bring that application back in-house but that you might want, for a variety of reasons (cost, performance, vendor consolidation, etc.) to relocate it to another provider's PaaS. In that case, the lock-in is more likely to reside in the automation and integration you might have performed across services that the PaaS is providing (through a variety of tools and scripts). It should be noted however that this level of lock-in is relatively weak (and easy to fix) and has no impact on any application or database lock-in: your IP crown jewels are safe!
It is worth nothing that some other forms of lock-in might happen as you leverage a PaaS solution, but those are NOT directly related to PaaS, they are actually related to your application architecture, topology and deployment choices. They include:
- A number of companies are (logically) attracted by the services provided by IaaS providers (AWS has dozens, such as CDN, DNS, queuing, etc.) While those services offer great value at typically a low price point, they also typically introduce a dependency that's not always easy to replace. Again, as discussed above, this is a tradeoff between control, cost and risk that any enterprise has to constantly weigh.
- As more and more applications get deployed in the same cloud datacenter (say, AWS US-East), it gets harder to shift to a different datacenter, provided by a different IaaS provider (say, Rackspace); applications have likely been placed on IaaS infrastructure with implicit considerations of things like physical location, so as to minimize round-trip latency to a database. Such applications can't be easily moved piece-by-piece.
Unless these choices are made as explicit decisions, that is as conscious business trade-offs, they become lock-in" - though of a different type, which might also exist on-premise - and might come back and hurt the company. From that standpoint, if anything, PaaS providers only reduce that risk as they make it easier to migrate from one IaaS to the other, by abstracting key IaaS-provisioning and behavioral differences.
With the vibrant marketplace that exists today, based on standard software stacks available across multiple suppliers, concerns about PaaS lock-in are mostly misplaced.
What concerns do you hava about PaaS adoption? Let us know.