The Disastrous Consequences of PaaS Provider Lock-in: Why Open PaaS Makes Sense

Dec 21, 2011 by Sinclair Schuller

Lock-in is a problem that is as old as the software industry. In fact, there is arguably no way to avoid it entirely. If I choose a programming language, application server, or RDBMS, I would end up writing apps that basically couldn’t run atop of anything but that vendor’s (or community’s, in the case of open source) platform technology. Practically speaking, one would make a conscious choice to use that platform, and know that lock-in is part of the game. I could spend time evaluating the tech, and assuming I did a decent amount of diligence, I would get enough comfort to move forward with it because the perceived benefits outweigh the lock-in risks. The reason I could make this judgment call is that outside of relatively infrequent releases, the evaluation I did today is likely to be valid tomorrow because the underlying assumptions do not change that much over time. In fact, I would have little reason to believe that on a new release, the vendor would drastically changing the platform in a way that was severely out of whack with historical context, and I could even expect pricing to stay in a somewhat reasonable margin of what I’ve paid in the past. This “traditional” form of lock-in was very static in nature because of how fixed the underlying assumptions remained over time, and the ongoing contextual validity one would have with respect to the original decision to be locked in vs. the current state of the platform.

Unfortunately, the negative potential of lock-in has increased in severity due to cloud, and more specifically, due to PaaS. Lock-in risk in PaaS is defined as the sum of two components: a static lock-in risk that is the same in nature (as described earlier) as the platforms of prior computing paradigms and dynamic lock-in risk that is dependent on a set of constantly changing assumptions. When one decides to build apps on a PaaS, they should be evaluating two things:

1. How good is the ‘P’ part of PaaS – the platform itself? This is an evaluation of the actual runtime, APIs, frameworks, management capabilities, and engineering value I can extract when I write code targeting the platform. Additionally, how proprietary is all of this to the PaaS provider (i.e. how severe is the lock-in requirement to get access to this value? Is it just APIs, runtime behavior, etc. or a new, proprietary and non-standard language?)
2. How good is the ‘S’ part of PaaS – that is, the service. This is an evaluation of the stability, cost, performance, and quality of the hosting capabilities of the PaaS.

Evaluating P is relatively easy because you can experiment with it and get a feel for the value and whether you are willing to trade that value for some lock-in. Additionally, P lock-in is much more static in nature which means that you likely don’t need to worry about significant changes in expectations. The S is scary. Hosting quality, service levels, performance, and price could be one thing today, and something very different tomorrow. You might deploy to a PaaS and say “Wow, things are running so smooth and fast, and the price is just right,” only to have the rug pulled out from under you without notice, or worse. If the P is high/non-standard lock-in and the S is limited or no choice, you’re screwed.

Why does this happen? The short of it is that if a PaaS provider is the exclusive vendor of both P and S, any lock-in to P translates directly into lock-in at S. That is my code can only run where my PaaS vendor tells me it can run. For most PaaS vendors, this means that you can run it on the service provided by – wait for it – the PaaS vendor alone! This is some really dangerous stuff and a tremendous amount of business risk. Having mission critical apps coupled to a hosting layer that needs to prove itself each minute of each day and has a very dynamic nature both in terms of quality and price is not good. How do you protect against this? Some of us (Apprenda, CloudFoundry, Cumulogic, among others) have decided that the P part of PaaS is the high value layer, and that S should be commodity and flexible, and frankly, irrelevant so long as it delivers on basic promises. This ‘Open PaaS’ model is one where rather than having P coupled to a single S, you might have dozens or even hundreds of services that offer the platform, essentially giving the developer choice of where to deploy apps while getting the full value of the platform; a “no lock-in” hosting model. This portable PaaS form factor is here to stay. Not only can one deploy to any service provider that is offering a (hopefully) differentiated instance of that particular PaaS, but the PaaS software is likely downloadable so that you can even download the PaaS software and run it on your laptop. This decoupling of the P from the S is what can bring lock-in down from the clouds (cheesy pun intended), and back to some sense of normalcy. Sure, you still need to commit to the PaaS and adopt its APIs and will grow dependent on its runtime capabilities, but as a customer of ours put it: “I’m OK committing to a platform, I’m not OK being locked into a service provider.”

read more

Is Salesforce.com’s Apex a Platform?

Feb 6, 2007 by Matt Ammerman

It’s been a few months now since Salesforce.com introduced Apex to the world, and we’ve all had ample time to digest the concept, analyze it, debate about it, and just generally figure out our own positions on the proposition.  One thing’s for sure, the announcement of Apex brought the total level of industry ‘saas platform’ buzz somewhere into the realm of, oh, stratospheric.  Salesforce.com, of course, should be commended for this.  But now here we are roughly five months later and the landscape for SaaS in the enterprise software market, regardless of Apex, has grown and changed drastically.  Platform players have emerged, some having SaaS platform offerings in development long before the Apex announcement.  Some pure play SaaS application vendors are backpedaling to attack the platform need.  Some platforms formed through partnerships between partial solution providers.  Although we may use the term ‘platform’ for them all, there are decidedly different approaches to the concept, even this early in the game.  So now that the field has widened we can frame Apex against a broader notion of SaaS platforms, their requirements, and the different approaches being taken to provide SaaS enablement.  It is time to re-examine our initial response to Apex.  I wonder, is Apex really what SaaS vendors need?  In fact, I dare ask: is it really a platform?

As has been the case before, Salesforce’s own marketing messages have kindled these kinds of questions in my mind.  The kind of questions that make me furrow my brow and think “Just what do they really mean by that?”  Take, for example:

1. George Hu, Salesforce.com’s chief marketing officer said during a keynote speech to an audience of developers: “Go out and create the next Salesforce.com” 
2. A press release dated Jan 16 of this year reads “With Apex, Anyone Can Create the Next Salesforce.com ”
3. And you know I’m not going to leave this one out: Speaking to an audience of customers, CEO Marc Benioff said “We want you to be the next Salesforce.com” 

Sure it seems like a kind-hearted message with success written all over it, and it is undeniably unified in its presentation.  But now couple that mantra with the technological implementation that is Apex and here is where the meat of my questions arise.  According to their own Apex landing page, Salesforce.com wants you to create the next Salesforce.com using the ”same tools that salesforce.com’s own development team uses to build” [salesforce.com].  Besides being a lot of Salesforce.com’s in one sentence, this seems like a cleverly veiled way of saying “we’ll let you build the next Salesforce.com, but no better.  And we’ll keep you from doing this by giving you only the tools that we give our own application developers (or gave them months ago)… who you may ultimately be competing with.”  Remember, a good deal of Salesforce.com’s AppExchange apps are indeed of their own making.  See, this way Salesforce.com’s own developers define a ceiling… a guarded gate through which the ISVs they are ‘enabling’ cannot pass through.  You see, you can’t really create the next Salesforce.com; you may be able to create what Salesforce.com is today.  Tomorrow Salesforce.com will have progressed, and then you can try to be that.  Sound fun?  Sound endless?  By bringing in developers through Apex, Salesforce.com is swallowing competition in an enterprise application market that it is certainly not abandoning.  Is Apex simply a vehicle for making sure that Salesforce.com stays ahead of the game?  After all, if you outgrow or otherwise find little need for the tools provided to you by Apex, you pretty much have to dismantle your application and start over on a different technology stack - putting you far far behind.  Sounds kind of Borg-ish to me.  Come to think of it… didn’t we talk about the risks of this thing called lock-in before?  In the case of Apex we might be talking about lock-in through assimilation!  Heck, you even have to learn the Apex language.  I rest my case.

In all fairness, an answer to this question may require a solid grasp of the definition of ‘platform’, and in the context of the SaaS world this definition is constantly being tugged at and remolded.  However, here’s something to start with:  I propose that a true SaaS platform, one that will in fact revolutionize the industry from the perspective of the ISV and end user alike, is not a body of technological implementation that binds and assimilates and attempts to lead by example (Ahem. “We want you to be us.”), but one that can better be likened to the traditional concept of the platform that is used for elevation – not of the platform itself, but of those that stand upon it.  Yes, I am saying that a SaaS platform must get out of the way of the applications, and likewise the ISV business models, it enables.  ISVs will find true enablement through a platform that serves only one purpose, and does it well – to make the development and delivery of robust enterprise SaaS applications as easy as writing software and delivering it on premise.  To elevate, or enable, without demanding explicit recognition from the application or those that use it meets the true definition of a platform. A platform is a very humble, simple, and oft overlooked thing - yet a well-engineered platform silently keeps entities aloft that are many times its size.

And so I turn it over to you:

Is Apex really a platform?

 

*** UPDATE 2/7/07 9:56am ***

Marketing Consultant Joe Bentzel wrote a similarly-themed article a couple of weeks ago.  This is terrific further reading: Salesforce.com APEX: Platform or ‘Platformula’?

 

 

read more