Infrastructure-as-a-Service (IaaS) is fairly well-known by now. Whether Amazon, OpenStack, Eucalyptus or any proprietary offerings, the basics are all the same: virtual machines, key-value buckets etc.

Not so for Platform-as-a-Service (PaaS). There are lots of vendors, but the architectures and basic assumptions behind their products differ widely — and those differences are less well-known than it should be.

Ashraf Khader, who apparently works for Microsoft in the Middle East, has done us all a great favor by breaking down the technical alternatives. His categories are as follows:

• “Instance PaaS”:  within each virtual machine, only one app is deployed. His examples: Azure, Elastic Beanstalk, Engine Yard’s AppCloud.
• “Framework PaaS”: apps are deployed to a framework. Multiple apps may share the same virtual machine, but whether they do or not is of no concern to the developer. Examples: AppEngine, Heroku, VMforce.
• “Metadata PaaS”: A special-purpose visual programming environment acts as the (only) programming language, the execution engine is opaque to developers. Examples: WaveMaker, Cordys Business Operations Platform, Microsoft LightSwitch.

Maybe the labels can be improved, but the categories are great. As a result, it becomes quite clear what a given PaaS can and cannot do. For example, if an app needs to perform a lot of file system-level operations, the logical choice is an “instance PaaS” with awareness of which VM is which.