The obvious upside of PaaS is that you do not have to take responsibility for constructing virtual machine images with all your system pre-requisites on them, add your applications and then launch the images. A downside we have experienced is that the vendors' choices of pre-requisites can cause problems. We initially developed a couple of servers using Python 2.7. When we came to deploy, we first picked OpenShift, which it turns out supports only Python 2.6. We then learned by trial and error which of the libraries we had used are missing in Python 2.6 (OrderedDictionary and json were two). We then developed a Ruby application using Ruby 1.9.3, which happens to be the level supported by OpenShift, so we did not have problems deploying there. Sadly, when we deployed the same application to CloudFoundry.com, we discovered the highest version of Ruby they support is 1.9.2, which does not have one of the classes we were using (Net::HTTP::Patch, in case you are curious). You might remember a previous post where I mentioned that neither CloudFoundry nor Openshift support either replication or sharding with MongoDB, so if those are important to you, you could add them to the "list of downsides" of PaaS. One of the things we plan to do is to make our own virtual machine images for our applications and deploy them on AWS ourselves. If nothing else, the experience will give us a better appreciation for the value we are getting from the PaaS vendors.
A downside of PaaS
Martin.Nally 0600016EKX 635 Visits