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.