“A Pass on PaaS”–Strategy That Won’t Last


Today I noticed a @CloudBlogs tweet along the lines of “Taking a Pass on PaaS.”  My first thought was, “That’s not a good idea!” Then I thought, “This must be a reverse psychology tweet crafted to make you take a look.”  So, in I went; hook, line & sinker.

To my surprise, however, the tweet was true (forward psychology?). William Louth’s article actually proposes that it is foolish to build on Platform-as-a-Service.  To wit:

…it is becoming clearer to me that for the time being it is much wiser for customers and vendors to Pass on PaaS….

Mr. Louth goes on to recommend that customers and vendors should

…focus on consuming and building AWS like cloud services that scale, perform and are themselves far more resilient than any of todays technologies, frameworks, libraries, components and most importantly operational processes.

The article doesn’t seem to specify what “AWS-like cloud services” means.  At the very beginning of the article, the author indicates that Amazon’s ElastiCache launch may have triggered him to write the article, so maybe readers are expected to use ElastiCache as a prototype for “AWS-like cloud services.”

Furthermore, the author seems to confuse PaaS with some specific implementations he has in mind.  In particular, he refers to “containers”

Coming from a CORBA/J2EE/JavaEE background I can very well understand the allure of a container like approach (or glorified process launcher aka CloudFoundry) to architecting and deploying a new cloud application or service. But the problem I have with this is that I’m not convinced that an integrated container is the best option and should be the interaction point for services. [Emphases added]

The author seems to be saying that PaaS is (or is based upon) a “container like approach.”  This characterization is far afield of PaaS, and the explanation by different colored telephone booths is more confusing than clarifying.



To be clear, Mr. Louth is not completely off-base. The problem is that he has too broadly painted all PaaS as unwise.  We can all agree that PaaS is no panacea, but neither is it unfit (technologically or in current implementations).  Mr. Louth’s article argues that solutions built on SalesForce.com’s Force PaaS are misguided or foolish.

Although not anathema to Infrastructure-as-a-Service (IaaS), Platform-as-a-Service is geared toward abstracting infrastructure.  Among other benefits, this approach provides for:

  • Shorter delivery time-frames
    • Requiring fewer developers
      • Less monitoring and maintenance
        • All reducing overall costs

NIST provides a fairly good definition of PaaS:

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.


IaaS providers – such as Amazon Web Services or OpenStack – and PaaS providers – such as Force.com or Microsoft Azure – offer differing capabilities for different application requirements.  These layers of cloud computing are often more complementary than competitive.  Application architects and designers must take these differences into account as they consider how to best deliver application requirements.

This site uses Akismet to reduce spam. Learn how your comment data is processed.