Your Own Private Cloud – Part I: Understanding PaaS (Platform as a Service)

Note: This is part 1 of a two part series on deploying to private cloud environments. Also see “Part II – Deploying Django applications on Stackato” .

“Cloud Computing” is a term that is frequently used but seldom explained. While it seems that the solution to nearly every problem these days is “in the cloud”, some organizations have been rethinking their cloud plans given the recent news of PRISM and other data gathering technologies. However, tools are quickly being developed that allow organizations to target environments that mimic the best features of large scale cloud providers, and yet can be hosted anywhere.

This post discusses the options for the so-called “Platform as a Service” (PaaS) cloud offerings, as opposed to “Infrastructure as a Service” or “Software as a Service” cloud offerings. The below diagram (taken from a Microsoft Azure talk) does a good job at simplifying the differences between the three types of Cloud services.

saas-paas-iaas+diagram

Software as a Service has been around for many years, and was previously known as Application Service Provider (ASP) or simply “Hosted software”. Infrastructure as a Service is a fancy way of saying “hosted virtual machine”. More recently, Platform as a Service (PaaS) has become popular, which primarily targets developers. PaaS takes care of the configuration, deployment, security and scaling infrastructure for a web application so developers can easily deploy their code without the need of an systems administrator.

Up until recently, nearly all Paas offerings have been managed by third parties. However, there are new options emerging that will run in any environment (including on top of IaaS providers). The remainder of this post discusses the various PaaS offerings.

PaaS Timeline

The first PaaS offering was a small company called Mosso (now Rackspace Cloud) that was spun out of two developers from Rackspace in 2005.  In 2008 Google App Engine appeared along with new companies like Heroku and Engine Yard.  In 2010, Microsoft joined the party with Azure to give both Windows/.NET and Linux developers a PaaS offering.  In 2011, more PaaS offerings appeared, such as RedHat’s OpenShift, and VMWare’s Cloud Foundry. Many of these offerings are multi-language (aka “polyglot”) environments that support Ruby, Python, Java and PHP.

Cloud Foundry is one of the first open source cloud computing platforms that was deployable to nearly any environment.  With Cloud Foundry anyone can roll their own PaaS on their own servers, anywhere on the internet.  In 2012 Active State launched Stackato, a new product based on Cloud Foundry that provides additional management and scalability features along with enterprise support.

PaaS Service Advantages

PaaS provides many advantages to developers: no physical hardware to be purchased, no data center rack space needed, and no concerns about backup tapes or maintenance windows. In theory, a developer would no longer would need to know how to setup and optimize a webserver and database. This can eliminate or reduce the need for operations staff, therefore saving money and time. It also provides a standard way to setup and deploy a project, so everyone on the team can have a consistent environment.

The biggest selling point for PaaS is the (again, theoretical) ease of scaling. Load spiking? Simply spin up more instances to handle the load. Sunday evenings are slow? Drop your number of instances and save money. The promise of PaaS is that it allows you to scale your app with the click of a button.

PaaS Service Disadvantages

Unfortunately, there are some disadvantages as well. The first (and biggest in most opinions) is vendor lock-in. There are some general similarities to each platform but changing from one to another requires a significant amount of work.  Moving from Google App Engine to Amazon’s Elastic Beanstalk is not as simple as switching from one hosting company to another.

The second issue is that the reliability of your application is dependent on the reliability of the PaaS provider. Amazon (itself a PaaS provider) hosts many of the PaaS providers. When Amazon goes down, they all go down. Amazon’s advice is to plan for outages by purchasing redundant servers across their network in different availability zones. While this is good in theory, it adds to the overall cost — which is one of the important drivers in choosing PaaS in the first place.

Once an application reaches a certain size, scaling can also be a major issue. Most PaaS providers are not as performant as similarly priced IaaS systems, trading off flexibility and ease in spinning up a new instance for the raw speed of an individual instance.

Finally, any application hosted on US-based Cloud services can have privacy issues in regards to the US Patriot Act and more recently the PRISM surveillance program by the NSA.

Privately hosted Cloud – the best of both worlds?

Privately-hosted PaaS products aim to address the major concerns of third-party hosted PaaS. With privately-hosted PaaS, you get the flexibility of a traditional PaaS product for quick development and deployment, combined with good scalability options and the ability to host your application anywhere you like (including an IaaS provider or on physical hardware for maximum performance). By choosing a provider in the country you prefer, you can also ensure that your data is protected.

While you are “locked in” to the environment of the open source PaaS, most are based on standards and provide a fairly straightforward target for porting applications.

In Part II of this series, we will take a look at the effort required to port an existing Django application to Stackato .