September 21, 2015
Should PaaS actually be called Platform as an Application (PaaA)?
By: Mark Rendell

I’ve been aware of Platforms-as-a-Service (PaaS) for a few years, but I wouldn’t say I completely understood their importance, until now.  The name alone leads me to think PaaS is all about receiving a service, but I believe if we treat our Platform as an Application (PaaA)—this is where the real value lies.

The evolution of my understanding
Google App Engine was the first PaaS to catch my attention. 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).

Heroku caught my eye next 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 had an “ah-ha” moment. 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.

Next, I found CloudFoundry and 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.).

  • Now, I was 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!

The big question
Will running a PaaS make my life easier and 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, complex and quite opinionated about how to do things.

My conversion
Over the next couple of weeks, we stabilized the platform and started to enjoy the benefits:
  • We could easily rebuild our entire data center in about 1 hour from networks up to all test environments including a working application with data.

  • 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 of a 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.

To 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-able 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 (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 siloed processes all the way to the logical extreme: the platform is treated no different from the application.  I was interested to read in the Next Gen DevOps that Grant Smith reached a similar conclusion that platform tools deserve to be treated as first-class products.

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.

More blogs on this topic



      COMMENTS (0)




      Your Data Privacy

      By providing your e-mail address, you agree to the terms
      outlined in our privacy statement associated with
      commenting on the site. Your e-mail address will not be
      used for promotional marketing purposes.

      Retype the CAPTCHA code from the image
      Change the CAPTCHA codeSpeak the CAPTCHA code