The Cloud: Platform as a Service

This is part two in a series of posts about The Cloud; for an overview see the original article.

There is also a discussion of SaaS.

With this post we’re going to explore the Cloud from a Platform as a Service perspective.  Platform as a Service allows you to purchase software middleware services just like you purchase electricity, water or internet service to your home.  Middleware sold as a service over the internet.

Platform-as-a-Service Big-egg-in-the-carton
It’s easy to be the biggest egg in the carton; with PaaS your application can easily scale.

So while SaaS provided pre-built software for end-users, PaaS provides software developers with the tools needed to build their own software applications running in the cloud – and likely offer it as a SaaS solution.

PaaS is very exciting for developers and businesses looking to build software, because PaaS eliminates infrastructure and middleware maintenance issues.  Like reusable VB components in the ’90s or reusable .NET components in the ’00, PaaS offers developers powerful pre-built services that can be leveraged to accelerate application development and enable massive scaleability.

Of course – just like SaaS – the cloud PaaS provider makes sure the underlying operating system is maintained and patched, the database is distributed properly, etc.

Two types of PaaS

There are a lot of PaaS capabilities available from vendors, and several vendors are offering “PaaS App Stores” where developers can offer up their PaaS service for other developers to consume.  Of course the big players such as Amazon, Google, and Microsoft have PaaS offerings, but so do “smaller” players such as Red Hat,, and even VMware.

But the two types of Platform as a Service seem very different.

With Platform as a Service, even little guys can build big apps by using PaaS services as application building-blocks.
With PaaS, even little guys can build big apps by using PaaS services as application building-blocks.

PaaS type 1:  Application platform as a service (the boring type)

The more basic PaaS – it’s almost Infrastructure as a Service – simply provide a hosting environment to run your existing applications.  So a basic Java PaaS might simply provide WebSphere or JBoss hosting in the cloud, allowing the developer to deploy their EAR/WAR in isolation without worrying about setting up and maintaining the Java container.  To me this is a rather boring vision for PaaS that misses the richness of what is available.  However, for a Java shop with access to the huge variety of Java open-source technologies and simply looking for an easier way to deploy their application on the internet this might be ideal.

There are lots of examples of this:

  • Google App-Engine is a big example of this type of PaaS play,
  • Cloud Foundry is an example of a smaller player providing host-your-app service.  “Focus on your code, not Infrastructure” states their homepage.
  • Engine Yard hosts only Ruby, Node.JS and PHP applications.
  • Heroku hosts Ruby, Node.js, Python and Java application.

PaaS type 2:  Platform building services (the cool type)

The second type of PaaS are the component-style web-services available from the bigger vendors, and the “PaaS App stores”.

For example, Amazon and Azure provide the following types of services (and many more) for building applications:

  • Push notification capabilities to support mobile applications
  • On-demand media trans-coding
  • Storage of data blocks with fast look-up
  • Cheap “cold” storage of data with slow look-up (excellent for backup software)
  • E-mail services (which is actually much harder than it sounds to correctly configure MX records and avoid being labelled SPAM)
  • Identity and Access Management – user authentication through Facebook, Google, or Microsoft accounts, or private cloud-scaled Active Directory for authorization; even multi-factor authentication is supported.
  • Advanced workflow services
  • Limitless data queues for ordered processing of data
  • Business Intelligence – Reporting and analytics solutions in the cloud such as Hadoop and Microsoft SQL Server Reporting Services or SQL Server Analytics Services.
  • Cloud DNS, Load balancers, Monitoring, Virtual Private Networks (VPN) capabilities, regular scheduled data transfers, etc.

Heroku has a page dedicated to “Heroku Add-ons“.  They’ve got all the basics, and then advanced things like:

  • Scalable machine learning and data mining; this is incredible!
  • Time series data storage with built-in analysis, monitoring and predictions
  • “Urban Airship” – Deliver customer and location targeted cross platform push messages
  • Full-text search services with auto-complete, query, result management and analytics
  • All sorts of powerful queues, monitoring, logging, caching, and analytics capabilities
  • Media capabilities, document management, PDF and Excel file creation and manipulation
  • Website security and scanning
  • Payments

This is amazing stuff, and the developer only pays for what they use.  Previously developers and businesses would either try and build all this themselves, do without, or buy big solutions and then pay, host and maintain it themselves.

Of course, just like SaaS there downsides.

The downsides of PaaS

As you can probably imagine, building your application in a PaaS environment is a very different development experience than traditional software development.

Your cloud application will probably be designed to run with core application on either Type-1 PaaS or IaaS – scaled across multiple machines/instances – and then leveraging different services running on completely different servers in different data centres.  This is not your father’s application where you just call into Java JARs or .NET DLLs running locally.  Large parts of your application will be calling into remote services, so it becomes essential that your application is highly asynchronous (which is hard).

Additionally, you need to be ready for failure of any one of these components.  Not just the “it failed so we’ll log it and have our support guy look-at it” either type of “dealing with failure”.

The cloud runs on commodity hardware; so it’s not that the cloud doesn’t fail – it fails all the time – but cloud applications are designed for failure.

So if any one component fails how will your application react?  If you’re using the search and auto-complete capabilities of some Heroku add-on service how does your application work when it goes down?  What if your image or video processing service goes down, what then?  You don’t want it to bring your entire application down, so you need to design appropriately and recover automatically and transparently.  Probably your application should keep queuing requests and then automatically scale up the video-processing servers when they become available.

It’s also very possible that your cloud-based application is dealing with enormous amounts of data (or you’re hoping it will if your start-up venture is successful).  So you need to make your application highly scalable.  Traditional applications – ironically, especially in the enterprise – are typically not scalable at all and are instead highly dependant on session-state.  So “scalability” is achieved by using sticky-sessions and increasing the number of servers hosting the application.  But this means that if one server goes down all the users on that server loose their work.  This kind of all-or-nothing behaviour is not what we’re trying to build in the cloud.

So development of a cloud application is a very different thing than traditional development.  There are great rewards to be had if you can adapt your design/development/test life-cycle:  faster time to market, amazing capabilities, incredible scalability, and all for reduced operational costs.  Should be quite the adventure!


Leave a Reply

Your email address will not be published. Required fields are marked *