Platform-as-a-service is one of the most popular cloud service modalities. PaaS operates at a higher level than IaaS. It provides a complete development and production environment while abstracting from the underlying infrastructure. It is located at a lower level in the stack than software-as-a-service.
The benefits of PaaS are obvious. Application developers and providers can build and deploy applications without concern for the lower levels of the software stack or infrastructure management. The PaaS provider creates a development environment and developers build applications for that environment.
And therein lies the problem with platform-as-a-service. Applications developed for one PasS will almost certainly not run on a competing service without a great deal of retooling. An obvious example of this problem is library versioning. PaaS users are often forced to develop against a specific version of a library, because they have no control over the software stack. It’s a take it or leave it scenario. If other vendors choose a different version, there’s no way to easily move between platforms.
The problem is further compounded by the way that PaaS platforms like Google’s App Engine — one of dozens of PaaS products — require deep integration of platform and application. Applications are often required to use the platform’s runtime environment, proprietary APIs, and tools. Applications are literally built to run on that platform. Its requirements are written deep in the application’s code.
This is no secret. A couple of years ago, Peter Magnusson, Google’s engineering director for App Engine wrote:
“Let’s acknowledge the problem outright: if you develop an application on App Engine, it will require some work to move it somewhere else … it’s mostly unavoidable, and it’s not our strategy — in fact we actively work to minimize it.”
While the company may work to minimize vendor lock-in, later in the same article Magnussen acknowledges that:
“We know very well what it takes: for a large application, it’s about 3-4 months of work”
Three to four months of developer time to move an application from one platform to another isn’t a trivial expense. If a developer needs to move their application because of poor performance or the need to leverage features not provided by the platform, that’s four months of unavoidable issues.
Vendor dissatisfaction isn’t the only reason to move an application. The PaaS market is fiercely competitive. Vendors go out of business regularly. No sensible business owner want to be stuck on a platform with a four month migration timeline when the lights go out. Furthermore, vendor lock-in works against the establishment of sustainable disaster recovery strategies. It’s essential that a company be able to move quickly in the face of an unforeseen catastrophe.
Compare the situation with PaaS to development on bare metal. Server migration is well understood problem. Moving between one server or cluster and another is relatively straightforward, but bare metal on its own doesn’t provide the features of PaaS that make it so compelling to businesses.
We mentioned in a previous article that container technologies like Docker provide most of the advantages of PaaS with few of the negatives. Like PaaS, containers provide an encapsulated, easily built environment. With Docker, it’s a simple matter of running a dockerfile on your bare metal server or development server / laptop and you’re good to go. Unlike PaaS, you choose the makeup of the container and environment.
And, most importantly, containers are portable. They can easily be moved between servers, vendors, platforms, and even operating systems.
Vendor neutrality was one of the clarion calls of the cloud, but PaaS does not live up to that promise. Bare metal alone or bare metal with containers provides an alternative that is truly vendor neutral.