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

Dec 21, 2011 by

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

Related Posts

Tags

Share This

Does PaaS Depend on IaaS? Nope.

Dec 20, 2011 by

If you agree with the title, you probably already know where I’m going with this. If you don’t agree, I really hope to change your mind. There seems to be this misconception in the market that PaaS is dependent on the existence of IaaS. Typically we see “cloud stack” diagrams that looking something like this

The cloud stack of SaaS-PaaS-IaaS

I’ve even drawn this myself (and will continue to do so in the context of market education). The problem is that this diagram is intended to communicate a conceptual, “lay of the land” hierarchy that describes a cloud-only stack where all layers are dependent only on other cloud layers. Clearly, there are tons (dare I say even a majority) of SaaS vendors that do not fit this at all. Some have neither PaaS nor IaaS below them, and some have only IaaS below them. Some SaaS vendors didn’t have these options at their disposal when they built their SaaS offerings. If they were starting today, I would encourage them to use a PaaS layer for a number of reasons. PaaS is no different in that one could be built without depending on IaaS. The one difference between PaaS and SaaS, however, is that I wouldn’t encourage anyone to build a PaaS that explicitly depends on an IaaS layer.

PaaS is typically built in one of two ways:

  1. With infrastructure multi-tenancy, where each guest application is isolated from other guest applications by using virtual machines. Each application gets its own dedicated OS instances, so the PaaS isn’t really multi-tenant, but instead, relies on multi-tenancy one layer down. In this case, the PaaS is a fancy packaging system and VM template manager with some load balancer bells and whistles.
  2.  With true PaaS multi-tenancy, where the PaaS manages pools of OS resources and co-habits applications on shard OS instances. This is typically achieved using something like process level isolation to safely segregate different guest applications from one another. In this model, there is no inherent functional dependency on virtualization (IaaS or otherwise) because the PaaS does some complex leg work to do its own higher density multi-tenancy.

In architecture 1, there is an absolute dependency on either an IaaS or some hypervisor technology. For a variety of reasons, I do not consider this an optimal PaaS architecture. Architecture 2, which I do consider a real PaaS, is doing work inside of the OS rather than outside of the OS. It achieves multi-tenancy using a much different technique. This technique can be layered on any pool of OS resources, physical or virtual. Nothing about architecture 2 creates a hard dependency on virtualization or IaaS.

If a PaaS is built using architecture 2 (which is what we’ve done with the Apprenda PaaS), it should purposely avoid acknowledging the existing of a hypervisor technology. In fact, it should assume that everything is a standard OS instance. This does three things:

  • It promotes implementation behavior that prevents the PaaS from being locked into underlying expectations
  • It ensures that the PaaS provider writes an appropriate systems architecture so that interaction with an IaaS/hypervisor layer can be bolted on as an optimization to ease management of the PaaS. For example, if I am operating the PaaS and I need to provision more capacity on the fly, it would be nice if the PaaS could detect it is running on EC2 and spawn new VMs to include as PaaS capacity, or do the same if it is running in a private cloud environment atop of virtual machines on <insert your favorite hypervisor here>.
  • Allows a PaaS to be deployed in a reduced complexity and lower cost environment where no virtualization exists. Let’s assume that 10 years from now, an enterprise or public PaaS provider achieves 100% penetration (all new apps going forward only on the PaaS), why keep virtualization around? The apps don’t care about virtualization, and certainly, the PaaS provides the elasticity and insulation from effects of the underlying hardware but at a new layer.

The end result is a highly flexible PaaS environment that can be run on any environment (on-premises or in the cloud), and that can still provide integration tooling to optimize deployments on environments where the PaaS has the knowledge and ability to do so.

At CloudExpo 2011 in Santa Clara, there was an expert panel on PaaS that answered a question from the moderator that implied IaaS/virtualization had to exist in order for PaaS to exist. I decide to ask the question of whether the panelists felt PaaS requires the existence of virtualization, and one of my favorite Cloud evangelists, James Watters from CloudFoundry, had a good answer, which I will paraphrase here: “no, but the dominant design principle applies and virtualization has enough inertia that it will be an intimate part of PaaS anyway”. This doesn’t mean that PaaS is dependent on IaaS/virtualization from an implementation point of view, and PaaS providers who have built that explicit dependency are either using virtualization for multi-tenancy, or unnecessarily knee-capping flexibility. For the customers’ sake, leave virtualization down a layer, and stop letting it become a leaky abstraction to what should be a cleaner systems architecture. If you build PaaS without a dependency on virtualization, you can then introduce integrations to IaaS layers as an optimization rather than a requirement. No one likes lock-in, particularly in the context of an operating layer.

As a cloud fanatic and CEO of PaaS company Apprenda, Sinclair focuses his efforts on helping move both public and private PaaS into the mainstream of enterprise IT. Before co-founding Apprenda, Sinclair held positions at Morgan Stanley, Eden Communications, and the State University of New York (SUNY). Sinclair holds a dual Bachelor of Science in Computer Science & Mathematics from Rensselaer Polytechnic Institute, where he graduated Summa Cum Laude.
read more

Related Posts

Tags

Share This

Meet me @ VMworld 2011 in Las Vegas August 29 to September 1

Aug 22, 2011 by

Next week I’ll be travelling to Las Vegas to present at VMworld 2011. The session is going to focus around a reference architecture on how to auto scale the Apprenda Platform using vCloud Director and other VMware technologies while maintaining your applications running without disruptions. In the fast evolving space of cloud computing applications are becoming increasingly harder to develop and manage but expectations of uptime and reliability are higher than ever so taking advantage of a PaaS (Platform as a Service) layer like Apprenda’s can help enterprise IT and ISVs to excel in the cloud.

VMworld: August 29 – September 1

Session Details

Date: TBD
Time: TBD
Title: Reference Architecture to Autoscale an Instance of Apprenda’s Application Fabric for .NET through VMware vCloud Director
Session: TEX2833
Registration: Content Catalog

Agenda

- Understanding Private PaaS Benefits
- Introduction to Apprenda’s PaaS
- Reference Architecture Breakdown
- Takeaway and Summary

Hope to see you all there but if you are not coming don’t miss the action and follow me on twitter at @asultan.

Cheers,
Abe

read more

Related Posts

Tags

Share This

The Cure for the Common Cloud

Apr 20, 2011 by

Let’s face it.  There’s a lot of hype around “the cloud.” Lots of promises, lots of claims, lots of vendors, and lots of lackluster results.  All the while, software engineers and architects are getting sick of it.

If you’re a software engineer or architect, what does the cloud do for you? It’s elastic and infinitely scalable, so you just put your app up there and everything magically works, right? The cloud solves all of your scalability challenges, all of your app delivery challenges, and it just plain works, right?

Wrong. You’re the one responsible for building the software that the cloud exists to host and deliver, and you know full well that there’s a lot more to it than that.

What about onboarding new customers or business units to your app?  The individual end-users – how do they get access, and to what are they entitled?  What about charging for different features, or different transactions?  What about managing the application lifecycle, and rolling out updates?  What about the underlying architecture to make use of the cloud in an intelligent way?  To actually take advantage of the raw compute power at your disposal, and not just use the cloud like it’s the late 90′s again and people are throwing their apps online like it’s going out of style.

These are the types of things that software engineers and architects are thinking about.

Haven’t we been through this before?


There are many significant engineering challenges associated with building and delivering applications today.  This is very similar to when we first started developing applications for the desktop PC.  Back then, everyone wrote code to manage memory, to interface with specific hardware, etc.  Then the desktop OS came along, and made all of that complex and time consuming (but CRITICAL) work a thing of the past.

While the challenges themselves were different, they were still challenges that were specific to the delivery method, rather than challenges associated with building the actual software functionality.  Those challenges will always be there, because the passion to innovate and develop applications that help facilitate better business performance, and meet the needs of end users is what drives great engineers/organizations.  HOWEVER, the challenges associated with the delivery method/paradigm go away in time, as layers of abstraction come about to solve those problems for us.

The “Cure for the Common Cloud” is Here


Now let’s get back to today.  Shouldn’t we expect that all of these challenges associated with building and delivering next generation software applications in this new cloud era will become a thing of the past?  Won’t we be able to focus on building great software again, and not worry about all of the complexities of the delivery method?  Someday?  Maybe?

Yes.  We can today!

A large and increasing number of organizations and developers have discovered the “Cure for the Common Cloud“.  They’ve found the abstraction layer that handles all of the complex engineering challenges associated with building and delivery applications today, and truly leveraging private or public cloud infrastructure in an intelligent way.  They’ve found the one technology that decouples apps from infrastructure, developers from IT/Operations, and business execution from IT implementation.

The Cure for the Common Cloud is here.  Do you have it?


read more

Related Posts

Tags

Share This

The Up-stack Scramble – Cloud Nine for Developers will be Trench Warfare for Vendors

Mar 23, 2011 by

The Cloud Computing industry has been in a state of technologic and rhetoric driven flux ever since the term “cloud computing” was coined. Coming from both a software and venture capital background, I enjoy paying close attention to the often incongruent evolution of both our industry’s capabilities and its marketing claims. This disparity isn’t unique to the Cloud industry. Most new markets experience this while the vernacular jargon gets socialized and standardized on. Case in point, the term Nanotechnology was actually coined to refer to the concept of self-replicating autonomous bots (ala Michael Crichton’s Prey novel), what the world got was a much broader and less grandiose set of mainly micro-scale innovations all loped under that industry name.

Similarly, Cloud Computing was initially taken to mean perfectly abstracted infinitely elastic computing scale in an on-demand basis. We don’t have this yet. What we have, and Im referring specifically to IaaS since it is our basic building block, is easy to configure, easy to provision, on-demand, utility priced virtual machines. This is a great progression for the software and IT professions, but it falls short of fulfilling the fanciful capabilities drawn in people’s minds. Cloud IaaS makes it easier and cheaper to do what we’ve been doing for years, but hasn’t profoundly changed the actual requirements, workflow or operational hassles that developers and IT administrators face. As a Senior Enterprise Architect at a large enterprise remarked to me last year – “we’ve run the course with virtualization, we did that years ago.”

Making compute power available has been solved – the current challenge is to put that instant-on horsepower it to work. To be clear – this is being done fairly well in some use cases: big data crunching (CG rendering, map reduce) and consumer facing websites come to mind because they have scale mechanics that rely on simple replication and balancing.

Business applications, however, are still beholden to the underlying topology of servers that supports them. The application itself and the IT system must be intrinsically wired together in order to function properly. For example – business applications often store large amounts of data and will store data across multiple servers. If user number 523 logs in and her data is on DB server number 5, how do you fetch that data when she sends a request through UI server 3? Answer – the application has to know who she is, where her data is stored and how to retrieve it. This enmeshing is necessary to solve many similar complexities, but makes it extremely difficult to take advantage of today’s current Cloud infrastructures – without completely re-architecting and rebuilding applications from the ground up and adding multiple highly complex new systems.

In order for this current world of instant-on cloud servers to be truly impactful and revolutionary for developers and IT operators we must continue to elevate them further away from the underlying mechanics and break the bonds between application and infrastructure. In order to do this, we need some middle tier that abstracts the application away from the underlying server topology and surrounds that application with the management, authentication, user-routing and scaling mechanics needed to seamlessly take advantage of newly provisioned resources. This is why we are seeing a universal up-stack migration by the industry leaders like Amazon, Microsoft and SalesForce.com into the still-evolving realm of PaaS (platform as a service) where the original vision of throwing code into an autonomous external cloud of elastic computing power is starting to coalesce in a couple offerings.

SalesForce.com’s “Force.com” platform for instance holds true to the “deploy and forget” ideal, but ties the developer to a restricted programming environment based on their own proprietary programming language in return. To counteract this, SalesForce.com has made bold moves by first partnering with the leading provider of virtualization technology (the underpinnings of the cloud movement) VMware to create VMforce for Java and then acquiring Heroku for the Ruby programming language. It wont be long before these two additional platforms are able to take advantage of the value added capabilities built into Force.com. The last few months have also seen the acquisition of Makara (another PHP PaaS) by Redhat, giving this enterprise heavyweight a compelling Private PaaS story for their client base. Amazon, the standard in IaaS, has been building new up-stack capabilities in-house and recently released their Beanstalk service which simplifies scaling Java applications. Not to be outdone, VMware last week announced the acquisition of WaveMaker a Rapid Application Development tool that compliments their SpringSource acquisition. Its not hard to imagine a new RAD-PaaS offering with these capabilities.

Scrolling this stream of movement, it can be hard to divine where this is all heading and where the competitors will bump into one another. It all comes down to the application developers and what up-stack capabilities you can offer them that improve one or more of: their build-time productivity/speed; the business value they can incorporate into their applications or the ease/quality of the ongoing application delivery. The following graphic gives a basic snap shot of where we are and how I see this evolving.

Cloud Ecosystem

read more

Related Posts

Tags

Share This