In the first of two posts on the topic, Kris Saxton highlights the key criteria he sees in evaluating the plethora of new PaaS solutions that are coming to market, as well as offering a couple of “red herrings” to be careful to avoid…

There was a time just after the ipod was launched that you could gauge the level of general insanity on the Internet by the rate at which new ipod docking stations were launched. With a new one launched seemingly every week (Empire at the time of writing) PaaS projects are starting to feel like a good candidate yardstick for the hype around cloud, but how do you select the right platform for your needs?

PaaS Fit for Large Enterprise?

As with all of these nebulous computing trends (cloud, DevOps), I have to spend a bit of time defining what PaaS means to us at Automation Logic.  As a consultancy focused on the large enterprise, our customers are typically blessed with at least one of the following: legacy, regulation, change control, complex internal processes, a terrible canteen.  So the PaaS variant that I have in mind is the sort where you are provisioning more complex services on top of your existing IaaS rather than the black-box development ecosystem where all you need contribute is application code.  In short; more Cloud Foundry than Heroku.  A platform here means a complex, multi-node service or environment required to host an application, rather than just a hosted language runtime.

So, if you’re working for an Internet startup with a single product based on a cloud you didn’t build, lucky you, you can get back to your flat white.  For the rest of us, read on.

Still here? Good.  With this type of PaaS in mind, there’s no doubt that the potential to go beyond the infrastructure and manage entire services and environments has substantial value, but in such a fast moving, immature sector how do you ensure you aren’t backing a lemon?

Having implemented a few of these now, this article outlines what we think are a sensible set of criteria for large enterprises to adopt when evaluating a PaaS.  It also challenges a few commonly pushed criteria which we think have little real merit (at least right now).  In a follow-up post, we’ll overlay these requirements onto the current PaaS frontrunners  and see how they measure up.

1. High Level Objects

In order to be able to provision and manage platforms, a PaaS needs to be able to describe and manage objects beyond simple compute, storage and networking – it has to look beyond the infrastructure. What these objects represent can be quite varied, they can be arrangements of servers (server groups, tiers) or provisioning activities (change control, monitoring enrolment); essentially they represent all the things you need to sort out to produce a fully-fledged service, environment or platform. Whilst the objects themselves are little more than named nodes, they act as pegs on which to hang more interesting stuff such as relationships, ordering, data and workflow (all described next). Consequently, a rich taxonomy for these higher level objects is a good sign of a flexible PaaS, the converse being something that is likely platform-specific (e.g. good at deploying Java onto AWS but not much else).

2. Relationships

Even if you have some magical app where stateless nodes can join and leave as they please, chances are (in enterprise land) there will be elements either side of the main app which must also be automated as part of the platform provisioning process, and which have to happen in a certain order. Whether its declarative dependencies (nice) or procedural ordering (good enough), your PaaS needs to be able to support this capability.

3. Data Persistence and Discovery

Provisioning a service involves changing the environment in which you’re operating, IP addresses get consumed, things get named, new nodes come online. When you move beyond the single server and need to start provisioning platform components that relate to one another, you need a method of exchanging information between those components such that they can dynamically configure themselves. The simplest example is a two tier platform with a database and front-end component. The front-end needs to connect to the database but doesn’t know how until that database is provisioned (and given an IP address). In this scenario either the database component writes its IP address back to the persistence layer for the front-end to pick up later, or the front-end component is able to discover this information through a real-time network query. I’ll give practical examples of how various PaaS (and IaaS) implement this in my next post .

4. Workflow

Generally you want to separate (or loosly couple) the modelling aspects of the PaaS which describe the platform components and their relationships from the code which actually performs the service provisioning. It’s a natural break and allows you to develop and maintain all the provisioning code (the bulk of which will be integrations with 3rd party services) independently. Tight coupling to the point where you can’t even really tell workflow from the data model or (worse) from internal PaaS code is a sign that you’re looking at a point-solution and not something that’s going to survive the new services you will need to integrate over the life of the PaaS.  Ideally, the workflow component will be something that can run independently of the PaaS, that way you’ll be able to reuse it in your IaaS and for other IT process automation tasks.

5. Lifecycle management

A server is not always just for Christmas. PaaS projects can be guilty of wishful thinking, they assume they are dealing with stateless, transient servers that can come and go without any wider impact (wouldn’t life be easy if everything was just a web server dishing out static files). The reality is that most servers are still provisioned with the assumption that they will be, if not long-lived, then at least around long enough such that they need ongoing management. Patching, auditing, growing, shrinking. It all needs doing, otherwise you’ve just created an automated muck-spreader.

6. API

Do I really even have to write this? If your PaaS doesn’t have an open, comprehensive, robust, documented, public, supported API for everything – don’t touch it. Throw it in the bin, then throw yourself in the bin for even considering it – what were you thinking?!

7. Rules Engines

Workflow can be further subdivided into business rules and provisioning logic and there’s an argument for keeping the two separate.  Business rules answer questions such as: “if I’m in development, provision to AWS, if I’m production, provision to our private cloud”, whereas provisioning logic takes care of the actual implementation of these rule outcomes, usually with a focus on 3rd party integration.  The differences in the developers, maintainers and governance of these two types of content usually warrants them being kept separate – you may even implement them in separate tools.

And those two Red Herrings…

1. IaaS Agnostic

This is the classic kind of requirement I see coming from industry analysts (I mean, who wouldn’t want to avoid vendor lock-in?),  but let’s consider what this would actually be like to implement today.  With no common data formats or interface definitions for IaaS consumption, you’d have to reimplement your IaaS integrations over and over again for each IaaS you wanted to remain ‘agnostic’ from.   To be truly IaaS agnostic today means integrating with every IaaS provider and maintaining those integrations independently – obviously this is bonkers.  Decide which IaaS you want use, pick a PaaS which supports them (or allows you to develop that support) and then just live with it.

When I first went to India, I went to my Doctor, worried about getting ill.  My Doctor said: “don’t worry about getting ill in India; you’re going to get ill – so don’t worry about it.”

Similarly, don’t worry about vendor lock-in.  You’re aren’t going to experience this so much as solution-lock in.  Pick your PaaS with a two year lifespan, make sure it can deliver the business value you need in that kind of timeframe and then expect to replace it.  Today, your efforts are better spent in ensuring your IaaS exposes nice, clean interfaces so that you can more easily replace your PaaS when the time comes (and it will).

2. Hybrid Cloud

Similar to the above, let’s be serious here.  We (as an industry) don’t even have a common format for describing a compute node.  So unless you’re willing to abstract based on the lowest common denominator across all potential cloud providers you aren’t going to be dynamically moving workloads based on compute spot price like I see in so many pitiful marketing slides.  At best your hybrid cloud will consist of a catalogue of items which can run on multiple cloud providers, but expect the underlying provisioning automation to be cloud-specific (i.e .you’ll have to maintain them all separately).

That’s all for now, I’ll post the PaaS evaluations next.

Time for a Twix.