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

A Language a Day Keeps Value Away: Getting PaaS Right

Dec 5, 2011 by

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:

  • Invented a brand new language and execution runtime, or
  • extended an existing runtime (JVM, CLR, etc.) into a new higher order runtime and systems architecture

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

Related Posts

Tags

Share This

Cloud Middleware: The Language Shared by Network Engineers and Developers

Jan 28, 2011 by

Jeff Kaplan posted an article on Internet Evolution this morning entitled “Bridging the Great Divide in Cloud Computing“. It’s a nice little piece that focuses on a burning problem: the Cloud has been very infrastructure focused, to the point that if you attend industry events you’ll find that, as Kaplan identified, “Those events that promise the latest information and insight about the nuts and bolts of the leading IaaS offerings will likely be overrun by network engineers or storage and security specialists. ”

My experiences have been the same: for the most part, cloud has provided tremendous value in creating a highly flexible datacenter abstraction, democratizing access to high end infrastructure offerings, and trivializing a number of deployment and management issues (think PaaS). Most of this is something that network engineers love (I don’t believe it’s a pari passu displacement of IT staff – Cloud has created a set of more interesting, higher value challenges that modern IT operators need to tackle) Additionally, the Cloud has provide some basic value to software engineers through some highly available and scalable nuts and bolts services (like blob storage solutions, etc.), but the problem domain of building Cloud/SaaS offerings has not been directly addressed by most Cloud providers since the focus has been entrenched at this network and virtualization tier. Cloud at the infrastructure tier is absolutely necessary, but the development community needs more Cloud value that solves modern software architecture problems. The Cloud, with its vast elasticity and democratization of software access to end users, has created challenging software delivery problems like cost efficiency delivery, scalability, and the need for codification of critical operating workflows. These are things that Cloud tech to date has predominantly shied away from.

Historically, middleware/infrastructure software has provided a common layer that acts as a single point of interest shared by IT network level operators and software developers. Think IIS, WebSphere, database servers, etc. These infrastructure software products typically provide a wealth of tooling to network folks in support of applications written by developers that use the pattern and practice productization value captured by these “application servers” to ease use case specific software engineering burdens. When the developers finish building something, the network ops teams can communicate in a familiar way with the same product, but through a different lens.

Looking at the state of the Cloud, it seems pretty obvious to me that we are at an inflection point. The “great divide in cloud computing” is something that can, should, and will be filled by modern middleware purpose-built for the Cloud. This middleware is what can act as the intermediary between the new architecture pressures that software developers must face and the Cloud management requirements of the IT staff. Without middleware handling this, we fundamentally have a better way to host software, which is hardly a catalyst for continued innovation.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

read more

Related Posts

Tags

Share This

Has SaaS & Cloud forced the server operating system into irrelevance?

Jul 6, 2010 by

I had the pleasure of reading a Structure 2010 follow up article written by Stephen Lawson titled “VMware’s Maritz: OSes are having their jobs stolen.” In it, Lawson outlines VMWare’s CEO Paul Maritz’ position that modern applications are relying on frameworks farther up on the stack for abstract services that used to be provided by the operating system, and that those frameworks insulate the application from even knowing what the operating system is.

This “commoditization” of the server OS is expected to some degree and is a case of “what’s old is new again.” Looking back through history, we’ve seen software development take on an evolutionary path of abstraction. Starting from assembly (x86 is my personal reference point) through higher order abstractions like C++ through byte code targeting virtual machines (as in the JVM and .NET CLR), we’ve always looked to move away from various OS level complexities in an effort to boost productivity, increase maintainability, and reduce coupling risk. However, these benefits were only considered OK so long as it didn’t jeopardize the programmers’ ability to express complex solutions to complex problems because of functional crippling that might arise from being too abstract. Typically, two things have held true:

  1. New paradigms in solution expressiveness have driven the introduction of new languages that embody those paradigms. For example, once “modeling” became en vogue, object oriented programming made sense. Now, we’re seeing a resurgence of functional languages or hybrids.
  2. Transitions in delivery paradigm have typically acted as catalysts to the creation of new frameworks (passive libraries) and runtime technologies (active application layers) to support the new delivery paradigm.

What we’re seeing today in that Cloud is that scale of technology coupled with the introduction of new application architectures and delivery needs that operating systems were not built for. OS’ are general purpose beasts with explicit and valuable capabilities and coordinating a fundamental execution platform. They are not specialized enough to really understand the upstack pressures being exerted on software developers. Clearly, they could be modified to do so, but were never meant to constantly evolve in that fashion. Instead, they are participating as a critical component at the bottom part of a stack.

When we look at SaaS and some of the architecture dimensions specific to SaaS such as multi-tenancy, the need to be able to achieve web-scale, and have operating tools in place to manage the application, we start to see that new modern frameworks, and in many cases, new types of middleware, are needed. This is the whole motivation behind why I helped co-found Apprenda and we set out to create SaaSGrid. In the early days, my co-founders and I frequently had conversations about how today’s applications need not know about OS specifics in order to function properly, which lead to some of the early architecture decisions of having SaaSGrid act as a mechanism that would leverage the decoupling of app components from their underlying network and OS dependencies to help facilitate scale-out (many details, of course, which go beyond the scope of this post.) As SaaSGrid matured, it took on a number of architectural dimensions on a guest application’s behalf, such as providing baseline single instance, multi-tenancy at all tiers or scaling out by offering partitioning services that can help reorganize application component distribution across a network of servers without reconfiguring or rewriting parts of the application. In effect, SaaSGrid started to manifest a number of “OS-like” capabilities, which go far beyond the frameworks that Maritz describes. It seems inevitable that upstack pressures will also hoist value-add solutions away from the core machine/VM OS, but we should all remember that a stack isn’t a stack if the bottom-most piece is missing or instable.The traditional server OS has simply transformed from necessary and sufficient to necessary but not sufficient.

Do you agree that the server OS is becoming commoditized with respect to cloud offerings, or is this an over-dramatization of what’s happening? If you feel the OS is fading into the backdrop, is there an opportunity for the OS to “modernize,” and if so, how?

read more

Related Posts

Tags

Share This

Do We Need Cloud API Standards?

Jun 26, 2010 by

I was on a panel entitled “HYBRID CLOUDS — THE BEST OF BOTH WORLDS?” at the Structure 2010 conference this past week. (Check out a recording of the panel) For those readers who are unfamiliar with the concept of the “hybrid” cloud, essentially, it’s the idea that one logical infrastructure cloud can be composed from two or more clouds of different deployment locale (on-premises vs. elsewhere) or visibility levels (public vs. private)

I was lucky enough to be on this panel with a number of very intelligent people who had some amazing insight into the topic. One of the questions posed to the panel really struck a chord. Essentially, the question was something along the lines of “Are standards necessary for the hybrid cloud to become a reality?” (Roughly minute 29:07 in the recording) The standards being referred to are standards that would abstract the command and control of virtual infrastructure. Each cloud provider (e.g., Amazon through EC2, GoGrid, etc.) typically provides an API by which one can control the deployment and ongoing operations of a virtual resource. Since each cloud provider has a different API, there is a form of lock-in that rears its head since, although each cloud might provide a similar container (say, a Windows 2008 Server), your code for managing and leveraging that cloud is non-portable.

Mårten Mickos, CEO of Eucalyptus, fielded the question stating that standards are necessary for hybrid cloud to really take off and that a standard would accelerate adoption significantly. I agree with the spirit behind Mårten’s view, but not with the idea of formal standards (and as you’ll read, I think Eucalyptus is poised to do some amazing things). Now when we discuss “standards” we mean an industry standard sponsored by a standards body or some sort of consortium. Others on the panel respectfully disagreed with Mårten’s position. Joe Weinman responded that standards aren’t necessary, and that different providers need to be free to evolve solutions that best fit the problem domain and customer need. My position was somewhat in alignment with Joe’s; standards, by definition, must cater to lowest common denominator subsystems which can bias efforts towards standardization rather than on new techniques to solve new problems in the cloud. It’s important to understand why this is the case, and also why it doesn’t mean that although a formal standard shouldn’t be pursued in the near term, generalization should absolutely be pursued.

In some instances, “formal” standards can stifle innovation or distract focus from solving specific problems by becoming abstract enough to be standards compliant, but not specific enough to solve a problem as well as possible. For example, if some cloud provider comes up with a novel way to address something new, they can still conform to the standard, but any uniqueness they bring to the table will be lost behind the abstraction. Just think of the SQL-92 standard. Most every DB vendor has some level of conformity, but various RDBMS’ do something amazingly useful things outside of the SQL-92 standard. If you leverage those proprietary pieces, you can no longer benefit (at least not by much) from the standard itself since you’ve broken conformity. Furthermore, any standards that have evolved in the past have typically fragmented into many sub-standards, dialects, etc. (just like the SQL case)

Now, does this mean that we shouldn’t pursue standardization? Well, if we’re talking about a “formal” standard, we probably don’t need to rush it. Technological generalization, however, is a different story. We’re at a point in the cloud’s evolution that requires organizations like Eucalyptus to focus on providing a coherent means to manage multiple specific cloud implementations. This is amazingly powerful and valuable and doesn’t require a formal standard. Eucalyptus has focused generalizing the Amazon EC2 API as a standard API that could be applied against any other cloud system. Overall, EC2 is a wise choice since it has the broadest market penetration and the most generally applicable API when looking from an abstraction point of view. Eucalyptus is doing some amazing work to make sure that you can leverage API expectations to work with a variety of virtualization clouds. Their efforts will undoubtedly boost adoptability, reduce adoption risk, and increase the viability of private and hybrid cloud deployments. Given Amazon’s API penetration, a market “gold standard” has been created just by shear adoption, and I think people will naturally flock to a proper abstraction like Eucalyptus because of sheer necessity to ensure compatibility with the gold standard while preserving the ability to experiment with new solutions. By choosing EC2, Eucalyptus’ approach provides a standards-like advantage without the baggage since the standard is chasing the market leader, rather than creating a standard and trying to enforce it. Kudos to Mårten and Eucalyptus for helping catalyze adoption of the cloud!

Do you feel that formal API standardization will be absolutely required in order for cloud, private cloud, or hybrid cloud to work, or will things organically tend to a relatively standard oligopoly of well known abstractions without a formal standard in place? Do standards create stifle and slow down innovation by always focusing on the lowest common denominator, or does it promote innovation by guaranteeing a baseline?

read more

Related Posts

Tags

Share This