My journey matches that of many developers who have been looking at cloud solutions. Having hacker hearts, we naturally gravitate to the IaaS model, which rents out a barebones virtual machine adorned with only an OS, generally Linux. There, the painful process of building something useful begins: Let’s make it serve a Web app. So, add Apache; configure that. Add MySQL; configure that. Add the scripting language (let’s say Python); configure that. Add the logic; configure that. Then, wire these components together and test like there’s no tomorrow. This process, is known informally as “yak shaving.”
It can take a few days of unpleasant work looking up settings and details on the Web to get this configuration right. But we’re not nearly done. If this VM will need to scale or be cloned for use in a cluster, then additional layers of software infrastructure need to be added. Even more, if it needs to hook into caches and load balancers. All of a sudden, you’ve become a system builder and administrator — all so that you can finally start cutting some code. If I wanted to go down this path, I’d have kept building PCs and would have put away my IDE.
Enterprises see the same problem. Amazon Web Services are now so complicated to use and configure at scale — despite the availability of preconfigured templates — that they’ve become a subdiscipline unto themselves. Companies look to clouds for relief, rather than added complexity. And as a result, the tide is moving away from IaaS to PaaS — Platform as a Service — to get the benefits with much less of the hassle. In the PaaS model, the cloud instance comes with bundled services that are added as menu picks, but are properly configured for each other (and for other services) when the instance is spun up.
For programmers, a classic example of a useful PaaS solution is CloudBees. You can spin up a VM that has Java installed, and the default continuous integration server, Jenkins, running. Of course, it has SCMs installed, too (GitHub and Subversion). And once you’re done building and testing on the CloudBees instance, you can deploy the app to other cloud services. CloudBees charges only for the time you’re using the instance, so if you do such a build only at end of day, you spin up the machine then, and spin it back down when you’re done. How long would it take you to set up an instance yourself, test all the components, make sure it scales, and so on? PaaS works.
For enterprises, there are many PaaS options: Microsoft Windows Azure, Google App Engine, and a host of smaller vendors. Among the niche vendors, one called Apprenda highlights some unique benefits. Its PaaS can provide multitenancy for hosted apps. So, for example, if you’re an enterprise customer and you want a single instance of a hosted Oracle DBMS to be shared across several apps that need to be isolated from each other, you have a huge administration problem facing you if you set this up from an IaaS. Apprenda’s PaaS software handles this fairly common problem transparently. It sets up the DBMS so that each app thinks it is the only user, while in fact, the DBMS is shared. However, no app can see other apps’ data — nor view the larger, complete DBMS. Without this kind of support — unavailable in an IaaS implementation — each app would need its own database instance.
There are many kinds of PaaS options coming to market — each addressing a different set of needs; many of them catering to facilitating the cloud experience within the enterprise walls. What is clear is that PaaS products are increasingly a solution of choice — and IaaS is simply becoming a provider of bare systems for PaaS solutions to consume, rather than competing with them.
— Andrew Binstock
Editor in Chief