Give me a platform. Let’s rock, let’s rock, today.
– Dewey Finn, School of Rock
The term Platform as a Service (PaaS) has become overloaded to define any ‘platform’ that provides ‘services’ to its users. The term PaaS is formally defined by NIST as:
“The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”
– The NIST Definition of Cloud Computing, NIST, US Department of Commerce, Sept. 2011
Like most terms in the IT industry (or to really generalize, the human communication medium known as language), PaaS is overloaded, overused and misunderstood. A quick web search or even a visit to the Wikipedia page on PaaS proves my point.
I prefer to look at such overloaded terms in context. In this post I am going to look at PaaS thru the lens of DevOps (no surprise to a reader of this website). I will explore what it means to an organization looking to adopt DevOps and leverage the services offered by utilizing a PaaS platform. I will explore and contrast a ‘build your own’ in-house platform as a Service or a subscription based commercial PaaS offered by a vendor. I will use PaaS offerings from IBM to illustrate my points. (Disclosure – IBM pays my mortgage).
Lets start.
Defining PaaS:
The most critical section of NISTs definition of PaaS, that differentiates PaaS from an ‘Infrastructure as a Service’ (IaaS) consumption model for cloud is:
“… The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”
This picture better illustrates the differences.
As you can see in this picture, what distinguishes the two cloud adoption models – IaaS and PaaS – is how much of the stack is managed by the user (or client) vs how much is managed by the Cloud Platform provider. What is important to highlight is two things:
- Every capability in the stack is available as a managed service – this would be a shared, multi-tenant, service available to users, with the underlying implementation abstracted from the user
- The Client/user only has to be concerned about managing their own applications, data and user access, leveraging the services available on the platform, which manages the rest
Platforms as a Service may be either public (IBM BlueMix, CloudFoundry from Pivotal, Google App Engine, etc) or private (hosted CloudFoundry; self built and hosted platform). Organizations may also build their own hosted and managed leveraging multiple technologies, self hosted on a private cloud. For a private instance of course, the organization hosting it in their own data center would be responsible for managing all the services hosted on the platform. Building a PaaS on an IBM PureApplication System, would be a good example.
DevOps and PaaS:
When one looks at DevOps on PaaS one has to look at the services that need to be hosted on the platform in order to implement a DevOps services platform. If one looks at a DevOps pipeline and the core components that make up a delivery pipeline up, each of the components need to be available as a service, in order to provide a complete ‘DevOps on PaaS’ solution. Namely:
- Development tools as a service (and/or an ability to connect the services on the platform to a desktop IDE)
- Build as a service
- Deploy as a service
- Test as a Service
- Monitoring as a Service
These would be what one refers to ‘DevOps Services’.
In IBM’s new PaaS offering – Codename: BlueMix (in open beta), these DevOps are services are an inherent part of the platform. There services on Bluemix are:
- Git hosting as a Service
- Web based IDE
- Agile planning & tracking, team collaboration as a Service (Jazz.net)
- Mobile Quality Assurance (MQA) as a Service
- Continuous Integration as a Service (Jenkins as a Service)
- Deployment Automation as a Service (powered by UrbanCode Deploy)
- Performance Monitoring as a Service
These capabilities working in concert, provide a Continuous Delivery Pipeline on IBM Codename: BlueMix.
DevOps as a Service (DaaS?)
So, to conclude. The value proposition for adopting a PaaS platform is self-evident. If you are an organization that delivers software, and is looking to adopt DevOps, a PaaS offering that includes DevOps services allows you to adopt DevOps at a very low cost of entry. You do not need to craft a Delivery Pipeline and implement the whole Continuous Delivery toolchain. Integrations, hosting, servicing – not your problem. Pay-as-you-go, and allow for scale. It is however, not a viable option for all organizations, as it is a drastic shift in corporate culture and potentially policies. Especially if you look at a public PaaS. If you are a born-on-the-web organization, or an enterprise with born-on-the-web applications, you should take a closer look. Check out Codename: BlueMix at www.bluemix.net.
