Does PaaS Depend on IaaS? Nope.
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:
- 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.
- 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.
Related Posts
Tags
Share This
Great post! good definition of PaaS
Comment & Questions:
I think managing pools of OS resources across OS instances and making capacity available on the fly are two different things. If there was a system outside the OS that can monitor load and add capacity when needed, coupled with an intelligent appserver inside the OS that starts using the capacity, can enterprises solve the same problem that PaaS is trying to solve?
Secondly, you could do PaaS on physical environment but how close to reality is adding physical capacity as quickly as the need grows. When millions of users use google docs, I can’t imagine Google adding physical capacity and letting their GAE aware of the new capacity. If you are saying you could do PaaS on physical for smaller SaaS apps, why do I even need PaaS if I am not expecting sudden spikes?
Thanks Ranga! I actually agree with your comment. To help really drive things home, I am opposed to virtualization as being architecturally part of a PaaS implementation, and most specifically, as the way to implement multi-tenant isolation in the PaaS. That doesn’t mean virtualization doesn’t have its place as an infrastructure solution, it just has no place as an architectural solution in the implementation of a PaaS.
In fact, I would encourage lots of instances where VMs underneath a PaaS make sense, and lots where VMs should be left out of the equation altogether. One simply needs to grasp the criteria in making that decision, but that’s a long enough topic that warrants another post;-)
If you’re a LinkedIn user, a good amount of follow-up commentary to this post can be found at http://www.linkedin.com/groups/Should-PaaS-be-built-on-4084799.S.86040597
I got what you mean ,bookmarked , very nice website .