Understanding the "as a Service" Revolution
I recently wrote a piece that was published on Datamation that outlines 5 guidelines for implementing private PaaS in the Enterprise. Check it out here!
What do you think?
If you’d like to mingle with others in the Cloud space, the SaaSBlogs group on LinkedIn now has 4200+ members and is growing every day; make sure you’ re not missing out and join today!
read more
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:
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
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
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:
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:
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.
One-man bands are impressive; typically able to play harmonica, guitar, drums, and a bunch of other instruments all at the same time with some meaningful composure but, unfortunately, with very little harmony. Despite this seemingly impressive feat, you never see a one-man band on the Billboard Top 100 – never (and John Popper doesn’t count). The reason for this is simple: one-man bands are good at getting attention on the side of the street, but they simply don’t make good music, let alone music that can be compared to that of a band of specially trained musicians. Being an expert at say, the guitar, requires that you dedicate every ounce of training energy into being a master of that one instrument. It also means that either as part of a band or solo, you can probably make the Billboard Top 100. This level of depth and dedication means that you won’t be relegated to a sideshow alongside the likes of that guy that pours molten lead into his mouth and spits out a cooled, solid lead slug; you have the opportunity to become a music legend. Certainly, Eric Clapton put in much more effort in learning to play guitar than every one-man band guitarist out there, and probably more than a few of them combined.
Building a PaaS is no different than making music. You can one-man band the hell out of programming languages and stack runtimes, but you’re just going to be making noise that sounds OK and gets eyeballs on the street. What you’ve done doesn’t have durable, legendary potential. It seems that lately, every PaaS provider wants to add as many languages as possible as quickly as possible. A week doesn’t go by where there isn’t a press release that is written in the stock format “<Insert Favorite PaaS Here> introduces game-changing, atom-smashing, world class support for <Insert Whatever Language the Other PaaS Said They Support Here>” This is a recipe for disaster both for the market in general, as well as for customers. There is an easy framework for understanding why this is bad business, and it all starts with being a real PaaS rather some heavily diluted manifestation of PaaS.
Building a PaaS the right way means that you’ve either:
In either case, the PaaS is doing some intimate, lower level heavy lifting and likely building a host of “base services” that are highly dependent on the language and/or underlying runtime. Those base services are exposed as APIs and are part of provided frameworks, or are capabilities that are instrumented into guest applications of the PaaS. Building all of this is non-trivial and takes a long time to build, but provides extremely rich next generation value to customers. This is the true meaning of “supporting” a language.
Much like the one-man band, when a PaaS starts laying claim to supporting its 37th language, they’re juggling too many things to properly be an expert at any one, and their version of “I’m good at the guitar” is not Eric Clapton’s version of the same statement. This statement redefinition and implied level of expertise is a good parlor trick, but can’t stand the test of time. The way PaaS providers achieve this is that they define “support” as deploying and loosely managing apps of that newfangled language or runtime type, but don’t provide any uniquely differentiated, high quality value. When a PaaS provider says they support a new language, they likely mean that they can move some pile of indistinguishable bits to a new underlying target application server and issue a “Website Start” command to whatever that target is (e.g. Tomcat, IIS, etc.) If that’s “next generation value”, then I’m in the wrong industry.
The huge downside to this multi-language craziness is that it creates a tremendous amount of market noise and distraction, and robs customers of time and value. Up front, a customer gets excited when they see “support” for so many languages. Some customers might not yet understand what the real potential and long term value of PaaS is. They’ll be satisfied with that PaaS, at least for a while. Once they starting building more complex cloud apps and realize that the PaaS does nothing to help them with this because it isn’t a runtime, then they walk away disenfranchised. For customers with more up-front sophistication, they see “support” as woefully inadequate out of the gate and began to get frustrated with PaaS as a concept in general.
A PaaS releasing support for language after language is a bad smell. It typically (I can’t claim always) means that they don’t have a sufficiently valuable piece of machinery under the hood, and they are likely not offering a runtime model. If they did, supporting the N+1th language would be hard work, and I would hypothesize that each N+1th language would take more time to support than the Nth language (rationale is fodder for another post). Now, to temper my sentiment, I do believe it is possible to support multiple languages/runtimes, but it has to be done correctly. The result is likely being able to support a small number of languages, rather than all of them.
If you’re an observer, practitioner, or customer in the PaaS space, don’t get distracted by the one-man band on the side of the street while walking to the rock concert – that would be a terrible reason to reach the ticket counter and hear the words “Sorry, we’re sold out.” If you’re a PaaS vendor, please, do it the right way and stop being distracted by shiny objects: support very few languages very well, rather than all languages very poorly. And remember, you might hire a one-man band to work your 8 year olds birthday party, but people pay lots of money and wear their finest clothes and jewelry for one night out at the symphony.
read more
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
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.
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.
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?
