What is PaaS?
Monday, January 31, 2011
Getting people to agree on the meaning of IaaS--Infrastructure as a Service--isn't hard. Prerty much everybody seems to view it as the ability to get VMs on demand, have root access to those VMs, and pay for them by the hour. In other words, IaaS is what Amazon EC2
does. Amazon invented this market, and their core technology still defines what this term means.
With Platform as a Service, though, there's less agreement. My favorite way to think of PaaS is as something where a developer just supplies an application, then lets the platform run it. Unlike IaaS, there's no need to create the foundation--the infrastructure--on which the application executes; it's already there. Give a PaaS platform an app, and it runs that app.
This definition applies to Google App Engine
, Microsoft Windows Azure
, Salesforce.com Force.com
, and even Amazon's recently announced Elastic Beanstalk
.It also provides a straightforward way to differentiate PaaS from IaaS.
Look a bit deeper, though, and things get more complicated. PaaS platforms can provide a variety of features, and they vary quite a bit. Here are some examples:
- Auto-scaling: When the load on an application increases, such as a spike in the number of users, a PaaS platform that provides auto-scaling will automatically increase the number of instances of the app that are running. When the load decreases, the platform will shrink this number. Google App Engine provides this, as does Amazon Elastic Beanstalk, but Windows Azure doesn't. Force.com offers this to an extent, but with built-in governors that limit the resources an application can use.
- Updates with no downtime: Can I update a running app without taking it down? I can do this on App Engine and Windows Azure, but I can't on Elastic Beanstalk.
- Root access to the underlying VM: Elastic Beanstalk offers this, and Windows Azure offers a form of it with VM roles, but neither App Engine nor Force.com let developers do this.
- Charging: Windows Azure and Elastic Beanstalk both charge per VM per hour, while App Engine charges per hour of CPU time. Force.com, however, charges per user, per month--your bill isn't explicitly based on the compute resources your app uses.
Are any of these qualities part of the definition of PaaS? Given the variations across the different PaaS platforms, it's hard to see how they can be. Yet lumping together cloud platforms that vary in all of these ways under a single label is bound to be confusing. Add to this other uses of "PaaS", such as Oracle's cynical attempt to apply the "Private PaaS"
label to its existing on-premises middleware, and the water gets even muddier.
All of this reminds me of the Enterprise Service Bus debacle. There was never any widespread agreement on what an ESB was, and so every vendor defined the term to match its own offerings. It wouldn't surprise me to see "PaaS" become this year's "ESB", i.e., a term that each PaaS vendor tries to define in its own way. Whatever happens, it's important to understand that there's lots of variation in the diverse technologies grouped under this single label.