Virtualization for PaaS: Asset or Liability?
During the Microsoft Management Summit last month, I had an interesting chat with Rakesh Malhotra who is the VP product of Apprenda. It made me to think more about two important technologies: virtualization and PaaS. As we know, virtualization is almost a must for IaaS. Will it be the same case for PaaS?
Pure PaaS or PaaS over IaaS
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
There are two types of implementations in PaaS today. One is the Google App Engine approach, which is built without virtualization. The tenant isolation is done at OS and middleware level. The other is the Amazon AWS approach, which is PaaS over IaaS where the related software stack is pre-installed as virtual machine image.
As far as I know, the first approach hasn’t got buy in from most customers simply due to the potential lock-in and lack of flexibilities. Google’s expertise in running data centers and development/deployment platform is great. But can you find an alternative in case you are no longer happy with the service? Because the answer is no, you can hardly make up your mind to build your critical applications on Google App Engine.
The other disadvantage is the customers get what’s offered – type of services, limited versions of middleware, etc. If you are familiar with developer’s mindset, we always want to try latest/greatest technologies and newest versions that may not be available by the PaaS vendor. To achieve the economy of scale, a vendor has to standardize on its selected and tested middleware of particular versions. I think Google had figured out the problems and started Google Compute Engine years after Amazon’s AWS. That is a separate topic worth its own discussion.
For service offering, the PaaS over IaaS captured a sweet spot that balances the standardization and portability. It comes with its challenges in that you have to manage the middleware stack and operate the platform by yourself, not to mention the overhead caused by virtualization. It may also require some extensive expertise in scaling the system.
Public PaaS vs. Private PaaS
The PaaS is a way of building cloud therefore it’s not necessarily limited to public PaaS offerings. The same idea can be applied within enterprises to be private PaaS.
As we discussed above, the PaaS over IaaS is a preferred way for public PaaS, meaning virtualization is (almost) a must there.
For private PaaS, the dynamics are quite different. Because the IT infrastructure is owned by customers, there is no concern on the lock-in. For the flexibilities, most enterprises have some standardization on what middleware/versions are recommended or supported.
While the two concerns with public PaaS are no longer important for private PaaS, the question on virtualization should be re-examined. The overhead caused by virtualization may become a big concern, therefore enterprise may avoid virtualization and take the Google App Engine approach but with open source runtime stack.
It’s not an easy job for a typical enterprise to build a PaaS even for its own usage. It opens up a new type of software products that build and manage PaaS for enterprise customers. Easier said than done, especially done right.
In theory, PaaS should be independent of the underlying platform. Virtualized or not should not matter. In reality, PaaS over IaaS is the preferred and mainstream way for public PaaS; PaaS without virtualization will be the favorite way for private PaaS. In other words, virtualization may be an asset in public PaaS; a liability in private PaaS.