Cloud doctors, DevOps and unconferences: Pass the Vicodin

Storagebod At the recent London CloudCamp - "an unconference where early adopters of Cloud Computing technologies exchange ideas" - there was a lot of discussion about DevOps on the UnPanel. As the discussion went on, I was expecting the stage to be stormed by some of the older members in the audience. Certainly some of the tweets and the back-channel conversations which were going on were expressing some incredulity at some of the statements from the panel.

Then over beer and pizza, there were a few conversations about the subject and I had a great chat with Florian Otel, who for a man who tries to position HP as a cloud company is actually a reasonable and sane guy (he does have the slightly morose Scandinavian thing down pat but that might just be because he works for HP). The conversation batted around the subject a bit until I hit on an analogy for DevOps that I liked. And although it doesn’t quite work, I can use it as the basis for an illustration.

Firstly, I am not anti-DevOps at all. The whole DevOps movement reminds me of when I was fresh-faced mainframe developer - and we were expected to know an awful lot about our environment and infrastructure. We also tended to interact and configure our infrastructure with code; EXITS of many forms were part of our life.

DevOps, however, is never going to kill the IT department (note: when did the IT department become exclusively linked with IT operations?) and you are always going to have specialists who are required to make and fix things.

So here goes: it is a very simple process to instantiate a human being really. The inputs are well known and it’s a repeatable process. This rather simple process, however it instantiates a rather complicated bag of blood with parts that are not properly fail-proofed and are often irreplaceable, running several processes which can go wrong in many ways.

When one of these processes or parts goes wrong, often the first port of call is your GP. The generalist physician will poke and prod and ask questions, and, if they're good, the GP will listen and treat the person as a person. They can fix many of the well-known bugs easily and you go away happy and cured. But most GPs actually have only a rather superficial knowledge of everything that could go wrong; this is fine, as many problems are rather trivial. It is important, however, that the GP knows the limits of his or her knowledge and knows when to send the patient to a specialist.

The specialist is a rather different beast; what they generally see is a component that needs fixing. They often have a lousy bedside manner and will do drastic things to get things working again. They know their domain really well and you really wouldn’t want to be without them. However to be honest, are they a really good investment? If a GP can treat 80 per cent of the cases that they are faced with, why bother with the specialists? Because having people drop dead for something that could be treated is not especially acceptable.

As Cloud and Dynamic Infrastructures make it easier to throw up new systems that have complicated interactions with other systems, unforeseeable consequences may become more frequent. And while your GP might be able to fix 80 per cent of the problems with a magic pill or tweak here or there ... when your system is about to collapse in a heap, you might be quite thankful that you still have your component specialists who make it work again.

OK, they might work for your service provider, but the IT ops guys aren’t going away. In fact, DevOps have taken away a lot of the drudgery of the Ops role. And when the phone rings, we know it is going to be something interesting and not just an ingrown toenail.

Of course the really good specialist also knows when the problem presented is not their speciality and passes it on. And of course, then there is the IT diagnostician: I'm not pointing fingers but they are grumpy Vicodin addicts and really not very nice. ®