I finally get PaaS – they should actually be called Platform as an Application

I’ve been aware of Platforms-as-a-Service (PaaS) for a few years, but I wouldn’t say I completely understood how important they are, until now.  In part I blame the name which leads me to thinking PaaS is all about receiving a service.  Instead I believe a pattern of treating your Platform as an Application (PaaA) is where the real value lies.

In this post I’m going to share the evolution of my understanding and hopefully leave you as fired up about Paa[AS]’ as I am.

The first PaaS that caught my attention was Google App Engine.  My understanding was that it was basically:

  • a place online where Google will host your applications for you
  • something that only worked when you write “special” compatible applications
  • not something that would change my life (i.e. my day job delivering large-scale Enterprise IT systems).

The next thing that caught my attention was Heroku which to me was basically:

  • a place that supported more “normal” applications like Ruby on Rails
  • a realization that if this trend of supporting more and more application types (middleware solutions) continues, using a PaaS could be something that I’d end up doing.

At this point I realized that I’d actually already used a PaaS when I wrote my very first static HTML website back in 2000.  The hosting provider was providing me with a very simple PaaS.  It only served static content, but none the less it was a PaaS and had already proved to me that the service model works.

So my understanding of a PaaS was that it was a service supplied by someone else to provide the platform to deliver your applications.  And I was starting to imagine that the trajectory I’d seen going from a PaaS that supported static content to one supporting full-blown Rails applications meant that soon they’d be applicable to the types of IT system I worked on.

Late last year, I had the privilege of my day job putting me in close proximity with a PaaS called CloudFoundry.  My understanding evolved again:

  • this time I was responsible for installing PaaS software myself (and hosting it in the cloud)
  • this time it was fully extensible and I had the responsibility of doing this to meet the middleware requirements (RabbitMQ, Cassandra etc.)
  • I was now expected to be a PaaS provider

Building and supporting environments for test and production was nothing new to me, but this was the first time I was doing it using a PaaS.  Yet I wasn’t receiving the platform as a service from someone externally, I was delivering it using a software application (Cloud Foundry) still referred to as a PaaS.  I’d somehow jumped from thinking one day I’d receive the benefits of a PaaS service from someone else to realizing now I was having to provide one… I felt a bit cheated!

So the obvious question in my mind was: will running a PaaS make my life easier and of course improve how well I could provide environments for test and production?

The answer wasn’t immediate. Getting up and running with Cloud Foundry was definitely a steeper learning curve than using something like Cloud Formation by Amazon. Suddenly there was another application to deal with and this one wasn’t even created by the development team. It was open source and complex and quite opinionated about how to do things.

The developers weren’t in love either. They had more to learn and more rules to follow – some rules that even the Ops team couldn’t explain…

However over time (weeks not months or years) we stabilised the platform and started to enjoy a few pretty great things:

  • we could easily rebuild our entire data centre in about 1 hour including everything from networks up to all test environments including a working application and data
  • adding new applications was extremely easy – efficiently cloning our continuous delivery pipeline in Jenkins was our new challenge (which we solved)!
  • predictability across test environments and production was higher than I’d EVER seen (and I’ve spent years solving that)
  • developers had a very clean relationship with the platform and found it a very productive eco-system to work in

In short, I was very happy and now a bit fan of PaaS. But it still took another month before I really felt like I understood why.

The answer is not the fact that Cloud Foundry is some kind of magic application, the answer is that it IS an application.

Too understand why PaaS is so important, I now actually think of it as Platform-as-an-Application (PaaA?!). The true value does not lie in the fact that someone else could deliver it to you as a service. The true value is treating everything that your application relies on as a configuration-manageable, version-able, testable, release-label software application. Naturally this is complicated and consists of multiple sub-components all subject to the same rigor, but managed as one application.

Whether you achieve this by reusing a pre-written PaaS application like CloudFoundry, Stratos or OpenShift, or whether your write your own is up to you (and I suggest subject to the normal buy/build considerations).  Whether you host it for yourself (on cloud infrastructure or not) or whether you use a public PaaS (e.g. Pivotal’s public Cloud Foundry) is not the point.  The thing that PaaS teaches us is to treat your platform as an application.

It’s a lovely idea from a DevOps maturity perspective. We’ve gone from Ops having manual silo-ed processes all the way to the logical extreme: the platform is treated no different from the application. We are all doing the same things!

It’s lovely from a Continuous Delivery practice because automated build and deployment of code is a native part of your platform application.  No extra work to do!

Another perhaps understated term is infrastructure as code (if you define infrastructure as used in IaaS). It essential to implementing your platform as an application but the name could leave you just thinking you should use it write code to manipulate your servers, storage and network. Yes you should, that’s great! But not treating this code as a coherent part of one logical application that is capable of (and optimised for) hosting your application is missing out.

So where next?  It’s not hard to think of ways of making platform applications that are more powerful and more operable. Already some PaaS applications e.g. Stratos are thinking hard how to realise similar benefits earlier in the lifecycle i.e. via App Factory.

I’m sure there will be an explosion of both PaaS applications and PaaS service providers all offering richer functionality, broader compatibility and higher service levels. Naturally Docker will significantly help implement compatibility of applications to PaaS’. For me, I plan to apply the Platform-as-an-Application pattern as widely as I can and of course try out as many more pre-existing PaaS applications as I can (starting with Stratos and App Factory).

6 thoughts on “I finally get PaaS – they should actually be called Platform as an Application

  1. Pingback: So if we are treating our Platform as an Application (PaaA), what should it do? | markosrendell's Blog

  2. Pingback: PaaA is great for DevOps too: treat your Platform as a Product! | markosrendell's Blog

  3. Pingback: Security, it’s time to dance with the DevOps | Markos Rendell

  4. Pingback: Breaking the Two Pizza Paradox with your Platform-as-an-Application - Accenture Click - UK Digital Hub

  5. Pingback: ADOP with Pivotal Cloud Foundry | Markos Rendell

  6. Pingback: Minimum Viable Operations | Markos Rendell

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s