Chapter 3. Types of PaaS
In the previous chapters we briefly discussed the concept of portability, which lets you move applications and deploy them on different systems. While portability is in many cases an attractive feature, there are trade-offs to both portable and non-portable PaaS.
Non-Portable: Following a Template
With a non-portable PaaS you build an application by writing code around the unique specifications and APIs of that platform.
This means that the structure of your code needs to adhere very strictly to a certain template or API. The APIs might be centered on the service’s databases, storage mechanisms, or search mechanisms. Other times, the APIs are lower level and code related. Sometimes you must even use specialized languages that are built only for that platform.
As you can see, there can be various types of hooks into a platform that make it non-portable. The earliest forms of Platform-as-a-Service were built around these highly structured ideas. They were the underpinnings of the early experiments that turned into what we now know as Platform-as-a-Service.
But questions quickly arose. Why should you write your code around a proprietary API? Are the benefits and access to the data worth the lack of flexibility? Before we examine how a new generation of companies answered those questions, let’s take a look at some of the major players in the non-portable PaaS category.
Launched in 2008, Force.com, Salesforce’s developer platform, allows you to build applications ...