An article defining PaaS caught our attention a few months ago. Entitled, “What does PaaS really mean? Let us know if you find out,” the article explains how the technology industry and IT organizations are confused about what PaaS is and use the term “confusingly.” The author, David Linthicum, then offers a definition, however we think his definition isn’t quite correct. Given his request to “let us know if you find out,” we are eager to respond with what we think PaaS is.
Technically Correct: The Best Kind of Correct
The author looks to the National Institute of Standards and Technology’s definition for PaaS, essentially talking about the first part of that definition: “The capability provided to the consumer to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.” However, that first part of the definition is actually the least interesting piece of the definition. It basically says that PaaS is applications you either built or didn’t build with some programming languages, etc. the provider supports, making the provider’s role appear limited. It doesn’t say anything about the provider having to design platform APIs or having to be vendor-specific or anything like that. What the author talks about is not what developers would talk about regarding PaaS, which is more important as developers are the ones who are going to be using those programming languages and other sets of tools.
What as a Service?
What the definition of PaaS should focus on is distinguishing PaaS from IaaS and SaaS. Essentially, PaaS is a service to manage your infrastructure for you. The part of the NIST definition that the author refers to that’s really the important part of the definition is the one that states, “The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, or storage…” That basically means PaaS is much more about the application run time and environment than it is about how you build the application that’s being hosted — you can’t claim something to be a PaaS when it’s really just about how it’s developed. The author states, “Although infrastructure is typically involved, that infrastructure is not a part of the PaaS,” but that’s actually the definition of what makes a PaaS different from IaaS. It’s not what restrictions you have and what languages are supported; it’s about how the infrastructure is managed.
Shut Up and Ship It
A large part of what the author is talking about is actually a framework for rapid application development. If you look at some of the examples in that area, such as Force.com, and look at related sets of tools, such as those from Progress or Oracle, you may find they describe themselves as PaaS. However, many describe themselves as frameworks, toolkits or application development environments. The fact that those tools are moving to the cloud is not surprising because all kinds of software is moving to the cloud and becoming available as SaaS.
Most developers would use the word “framework” for what the author is talking about. When you say “frameworks,” people often think of web frameworks, but of course there are other kinds of frameworks, such as those for graphical programs. Those frameworks can also include secondary tools, such as those that support application deployment or debugging, and they can come with a console version of the application, tests for the application, and dependency management software. What the author is really talking about is a separate trend with those frameworks moving to being SaaS-oriented and calling that PaaS. However, developers would not call that PaaS.
Comparing PaaS Providers
To illustrate, I would compare Heroku and Force, Salesforce1’s platforms. Heroku is clearly a PaaS and it would be silly to say it’s not a PaaS. It’s what people think of when they think of PaaS and it actually provides very little capability for rapid application development. It has a lot of services that you can take advantage of, but it’s much more oriented around deploying “standard” applications quickly. Most of the applications that you deploy with Heroku would have very minimal changes to deploy them in other environments. You have to write more code, because you’re creating the application based on a general purpose language like Ruby.
Force.com is also clearly a PaaS — it’s Salesforce’s PaaS — and another platform that comes up as an example of PaaS. It is almost exclusively oriented around vendor APIs and building around the Salesforce platform. There’s no way you could take a Force application and go run it locally, much less on another platform. Salesforce is providing not only the hosting environment but also a set of high-level, proprietary APIs for accessing data sources. Those two examples are from the same company, and the thing that really unites them is that you have no worry about the infrastructure; that’s all taken care of for you. One of them is heavily oriented around having ready access to Salesforce’s data and being able to read and write to it and not worry about the application boilerplate. With Heroku, you can quickly deploy and scale your application, but you’re really writing code the same way.
All things considered, in the effort to nail down a definition of PaaS, it’s probably best to ask the people who are actually using these systems. You can find out which systems they agree are a PaaS and which ones they don’t. Readers: let us know if you find out.