There are many definititions of PaaS that I have run across, the most succinct of which is “A Service where Code is uploaded and executed”. While succinct, this leaves a lot of “wiggle room” for what PaaS really is. The secret is PaaS isn’t one thing, it is a broad array of things that can be used and mixed together. What model ore TYPE of PaaS determines what capabilities and limitations the platform will have.
The Type 1 PaaS – Upload Your Environment
This style of PaaS is an option from several different providers including Amazon EC2 and Microsoft Azure with the VM Role. By imaging and then uploading an environment packaged as a VM, you are allowed to run legacy systems in Cloud environments
The Type 2 PaaS – Upload Your Compiled Application
This PaaS is where an environment is already provided and you are uploading and executing an Application that was written/is supported by that PaaS environment. This could be a preconfigured Amazon EC2 VM, a RackSpace Cloud VM, Microsoft Azure Role, or any of the other dozens of Cloud providers.
The Type 3 PaaS – Upload Your Packaged Application
PaaS here is presented as a container that is more restricted than a traditional environment and is more stringent on code. This could be a Java WAR file for example that leverages a container such as Apache Tomcat, Amazon’s Elastic Beanstalk is a good example of this. The solution could also just be a custom JVM such as the one that Google App Engine uses (where your App is a JAR). Why is this different than a Type 2 PaaS? It is a container in an environment, not just an OS environment like Linux or Windows.
The Type 4 PaaS – Upload Your Code
This type of PaaS allows source code to be uploaded where the compilation happens in the PaaS itself. By accepting the code as the uploaded payload a greater level of insight as to what the resource requirements are of the code can be gotten, which offers more versatility from the platform. An example would be VMware’s Open PaaS (which is in Alpha currently). Open PaaS accepts many different code types, looks at what the requirements are and adjusts the environment based on what the needs of the code are. Other examples include Heroku and Engine Yard, both do Ruby on Rails. When the Ruby on Rails code is uploaded for example, then a MySQL server instance is created to support the application amongst other things that happen. Nearly everything that is needed is allocated automatically on demand.
The Type 5 PaaS – Upload App/Platform Specific Code
PaaS here would only allow specific code which is designed to work as logic or an extension of the Platform is allowed. While this is a highly restrictive form of PaaS, it can also be powerful and is a natural move for a Software as a Service provider looking to allow cutsomization. Salesforce.com is a great example with their App Logic using Apex Code. Apex Code allows a level of customization and extension to the Salesforce solution using their own blended Java/C# like syntax.
The future of PaaS is in leveraging many of these models to best meet design decisions and customer needs. The biggest question will be what happens in the future when Enterprises want to adopt and adapt PaaS in their Data Centers. While the economies of scale will always be with Public Cloud PaaS providers, there are benefits to having PaaS implementations inside the Enterprise.
In my next post I will talk about where PaaS could go.
Data Gravitas 
Very good summary attempt. There is no right or wrong answer here. In that spirit, I differ from your classification slightly.
I believe that:
PaaS type 1 and 2 don’t really deserve to called PaaS, as they are mere repackaging of existing apps into a VM, either pre compiled or post-compiled. It is purely a manual intervention to do so.
PaaS should provide a set of development services to app developers beyond mere access to infrastructure resources, such as code compilation, cloud deployment or IDE.
Type 4 and 5 may be combined, as 5 is a minor variant of 4 and doesnt mandate its own category.
SO I THink that leaves 2 simple categories of PaaS:
A more restricted PaaS such as Google App Engine, AWS Beanstalk and a less restrictive PaaS such as Heroku, Engine Yard, Salesforce’s force.com.
Just my views to hopefully provide a different perspective and raise dialog.
I tend to agree with your take on Type 1 and 2. EC2 is the canonical IaaS option – and Azure “Role” per my other post is really Type 3.
Did you get ‘more restrictive’ and ‘less restrictive’ swapped in you last paragraph?
Nice summary of the deployment side of paas. I like the addition of the logos – that really helped. I think that the we need to find a way to express the importance of data services (ala data gravity) as part of the paas equation.
I agree and hope to begin that with the follow on post to this one. There will be a third post that attempts to weave all of this together (hopefully it will turn out well).
The post is great, really helps in differentiating the nuances of the offerings. A couple of constructive observations 🙂
I’d say that Azure (Role) is misplaced in your taxonomy here, and really belongs in your Type 3 versus Type 2. Roles aren’t deployed per se, they are part of the larger packaged application along with configurstion information.
Also take a look at AppHarbor which likely fits into your Type 4 category.