Monthly Archives: February 2014

Essential Characteristics of PaaS

There’s been a lot of discussion on the Internet about the definition of Platform-as-a-Service. Here’s just a few very active Twitter discussions to illustrate the level of activity and passion over the topic:

This is just a few of the hundreds of tweets returned when I queried “Paas” and “definition”. The interesting thing is that the sheer breadth of the discussion makes it very difficult to nail down exactly what it is.

Gartner Group’s method of responding to the madness was to develop their own taxonomy of PaaS, which seems to have been very helpful for them in organizing their research, but, in contrast to many other things Gartner has led on defining, their PaaS taxonomy has not really caught on with the cloud community. The Gartner taxonomy breaks things out based upon the primary functionality of the platform, such as application development, business process management and event processing. However, this dichotomy actually impairs their ability to abstractly define the essential characteristics of a PaaS.

At a minimum, PaaS is a cloud service model and as such should meet the NIST essential characteristics for cloud computing, which are:

  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured service

The question then becomes what are the essential characteristics that follow on from these? Some that come to mind include:

  • Support binding and unbinding from composable multi-tenant services. This binding can be explicit as it is with some of the container-based PaaS or implicit through the use of APIs.
  • Enforce scaling of platform services. In the case of container-based PaaS, the user has the option of having their application also participate as a service and, thus, be managed by the container’s scaling capabilities.
  • Ensure appropriate authorization for use of given services.
  • Provide a means for monitoring and ensuring the health of the platform and its services.

Putting the above list together was an exercise in remaining non-exclusionary. It’s easy to think about all the great capabilities that container-based PaaS provides and add those to the list, but container-based PaaS is not always the best option for existing workloads that were developed as silo applications stacks. It also doesn’t account for the platforms that deliver platform extensibility, such as Force.com and NetSuite.

To keep me pure of heart, I leveraged my three archetypes of PaaS that I presented in my PaaS workshops at Cloud Connect. These are presented as follows:

Application Infrastructure Platform

API-Based PaaS

Container-based PaaS

As much as I would have liked to add characteristics, such as, manages application lifecycle, supports routing of messages into and across services, etc. that clearly would have been establishing a bias toward container-based PaaS. The above archetypes provide a wide berth against which to select the best architecture for a given cloud application and keeps the established characteristics to those items that are common across all PaaS archetypes.

DevOps Master: Building Bridges Between Dev and Ops

I will admit I have been a strong opponent of those listing roles and organizations as DevOps. Primarily because DevOps is a way to do something and creating a role DevOps Engineer is just putting lipstick on the pig for those looking to hire a Linux Sysadmin or infrastructure script coder. Likewise, the DevOps organization is a somewhat more likeable term, but still ambiguous at best. It’s either the organization that is helping to redefine IT by having development and operations individuals work together on the same team, which is really just IT using a different process and should go away once it succeeds, or it’s the infrastructure team trying to sound cooler and more sexy.

Today, however, I had a bit of epiphany about using DevOps with regard to a title or role in an organization. I was thinking about a project I was on where we used agile Scrum methodology. On that team we had a Scrum Master whose job it was to orchestrate the agile process and helped the team to move through the various stages of the agile process. This was a very important role that analyzed the velocity of the project, helped to prioritize stories and figure out how many points would be finished in each sprint.

This particular project also leveraged a process of continuous build, which meant that someone had to manage the establishment of the code repository and develop the automated test and build processes. This was a critical aspect of ensuring that every developer was checking in code that passed unit testing. Once a day there was also an integrated build, which would deliver a working version for testing, hopefully.

It’s this supportive environment that ensures that the development team is indeed able to complete their sprints and deliver high-quality software at the end of the process. So, if DevOps is an agile methodology, then who is responsible for clearing the hurdles for the development and operations teams to work more closely together? Who is responsible for instituting the tools that will help automate the collaboration between these two teams?

The people I speak to that are moving to DevOps (or helping businesses move to DevOps) all claim that it’s currently working one of three ways:

  • DevOps is really infrastructure/data center led and they select the tools and DevOps is really about automation of provisioning
  • DevOps is really development driven and the application development team is selecting the tools, which are really just extending current agile approaches
  • The development and operations teams are evaluating together and struggling to select a single platform that meets both of their interests

All this brought me to the realization that successful DevOps implementations will require a DevOps Master. This individual, like the Scrum Master, is responsible for implementing the necessary processes and procedures that will allow these two teams to do their individual tasks and yet have their work culminate in a high-quality production delivery. The DevOps Master will choose the platform(s) to enable this collaboration and manage the individuals who will set up the environment. In essence, they will build the bridge that development and operations will use to facilitate communication and automation of the design, build, test, operate process.