Inside the Briefcase

The IoT Imperative for Consumer Industries

The IoT Imperative for Consumer Industries

This IDC white paper examines current and future...

How to align your visual brand guidelines and create consistently on-brand content

How to align your visual brand guidelines and create consistently on-brand content

In this ebook, we’ll explore the various themes leading...

Your B2B Content Strategy in 2017: How To Think Like A Movie Studio + 6 Other Tactics

Your B2B Content Strategy in 2017: How To Think Like A Movie Studio + 6 Other Tactics

Jon Lombardo, Creative Lead, LinkedIn, reveals in this presentation...

2017 State of Technology Training

2017 State of Technology Training

Pluralsight recently completed an in-depth survey of 300 enterprises...

IT Briefcase Exclusive Interview: Keeping Your (Manufacturing) Head in the Clouds

IT Briefcase Exclusive Interview: Keeping Your (Manufacturing) Head in the Clouds

with Srivats Ramaswami, 42Q
In this interview, Srivats Ramaswami,...

Understanding PaaS Limitations

May 1, 2012 1 Comment

Written by: Gabriel Monroy, co-founder and CTO of OpDemand

PaaS1 Understanding PaaS LimitationsBy many accounts 2012 is the year Platform-as-a-Service goes mainstream.  PaaS offerings from Heroku and Cloud Foundry are awash in positive press.  Stories of progressive developers adopting and succeeding with PaaS are increasingly common. Even IaaS poster-child Netflix is now promoting a PaaS strategy.

Is PaaS really ready for prime time?

For low-volume web applications built using common stacks, the answer is a resounding yes.  Deploying a standard Ruby-on-Rails application on Heroku couldn’t be easier.  The PaaS workflow is ideal for today’s agile development teams.  Although adoption is still nascent and there aren’t many high-profile PaaS success stories yet, there will be soon.

But before you get swept up in PaaS fever, it is important to note that there are some fundamental drawbacks of PaaS that all IT decision makers should be aware of.

Vendor Lock-in

The most common criticism of PaaS is vendor lock-in – and rightfully so. PaaS users are at the mercy of their provider when it comes to price increases, unwanted technology changes and shifts in provider direction that (in extreme cases) can even require entirely rewriting your application.

Application Requirements

In order for PaaS technology to deploy and scale different applications in the same fashion, all applications must conform to a set of rules and best practices – for example Heroku’s twelve-factor app methodology.  This means:

  • Your applications must conform exactly to PaaS vendor specifications
  • It probably won’t be worth porting your legacy applications to a PaaS
  • You should only consider PaaS for new apps built with modern stacks

Runtime Limitations

PaaS runtimes are optimized for a specific set of languages and frameworks.  Google App Engine only supports Python, Java and Go.  Cloud Foundry only supports Java, Node.js and Ruby.  Because access to the operating system is restricted, even if your desired programming language and framework are supported, chances are you will find yourself fighting against runtime limitations:

  • The version of your desired framework and runtime may not be available
  • You may not be able to install the dependencies and libraries you need
  • You may be blocked from performing common OS-level system calls

Add-on Limitations

PaaS providers understand that most applications require some type of backing data store, caching layer, message­-bus and other middleware services.  Some PaaS providers offer a set of add-ons to fill this gap.  Because add-ons are built to support the most commonly requested use-cases, they often prove limiting:

  • Available add-ons may be insufficient or unsuited to your use-case
  • Integrating your own add-on equivalents may be difficult or impossible
  • You may have limited control over managing multi-tenant add-ons

Operational Limitations

PaaS providers strive for a NoOps methodology, where IT infrastructure is abstracted, IT operations skillsets are irrelevant and developers can operate deployments themselves.  While this may be feasible for simple applications, PaaS can limit critical operational capabilities:

  • You may be prevented from customizing build and deploy automation
  • You may be unable to debug live production deployments
  • Your security, networking and storage options may be severely limited
  • You may have no control over hosting decisions, including an inability to deploy to specific geographic locations

It’s important to note that not all PaaS’s contain all of these limitations.  For example, Cloud Foundry’s VM model offers greater control over hosting decisions.  Heroku build packs can be customized provided you have the expertise. However, with all Platform-as-a-Service you give up some measure of control in exchange for a streamlined workflow and less operational headache.  The trade-off may be worth it; it may not. The answer depends on the PaaS, the application and the organization it is serving.

gabriel monroy Understanding PaaS LimitationsGabriel Monroy is the CTO of OpDemand, a next-generation platform for agile cloud infrastructure management. Gabe is an expert in information systems design with a focus on automating secure and scalable systems in the cloud. Gabe has advised public and private companies on a range of issues including cloud computing, software and systems security and IT operational efficiency.

Fresh Ink
One Comments to “Understanding PaaS Limitations”
  1. [...] about PaaS – you may already be using one.  Before you dive into PaaS, it’s important to understand its limitations and how they apply to your organization.  Once you have made the jump, succeeding with PaaS [...]

Leave a Reply




IBC 2017

ITBriefcase Comparison Report