Does your company have the DevOps nature?

A few months ago, in my post The Elusiveness of DevOps, I asked John Arundel of Bitfield Consulting what his definition of “DevOps” was. Now, we dig a little deeper in this interview in which John discusses DevOps.

What is your history with DevOps?

I’m the same age as the microprocessor. I wrote my first computer program in 1981 (it probably just printed out ‘John rules’ a bunch of times). The computer I had (a Sinclair ZX81) was a few inches across and weighed less than a pound. In the following years I worked on bigger and bigger computers: the biggest (a Sun Enterprise machine) had to be delivered on a flatbed truck and weighed about a ton. After that they got smaller again. Today I work on an iPad that’s a few inches across and weighs less than a pound.

I started out in the industry as a tech writer, writing manuals for Psion palmtop computers, but somewhere along the line I got sucked into running the company’s website and some internal servers. I soon switched to being a full-time sysadmin, mostly in software companies, and for years I did the usual kind of stuff you do: installing stuff, configuring stuff, backing stuff up.

But I was working with a lot of smart software programmers, who used things like version control, deployment automation, and scripting. They were lazy, in the good sense: if they had to do anything more than once, they would just write code to automate it. I thought this made a lot of sense, so I started doing things like keeping my config files in CVS, and writing little Makefiles to update them. As new automation tools came along, they just iteratively improved this process: I would provision machines with Cobbler and Kickstart, build them automatically with shell scripts and CFEngine, then Puppet, when that came along, and so on.

I worked in some top-flight companies and learned how really smart solutions architects build global resilient systems, designing high-availability clusters, redundant data centres, and all the rest. But they were usually all built by hand, with relatively low-paid data centre people following written procedures over and over, typing commands, checking output, running tests. It struck me that if you did all this with automation, you could build incredibly powerful and resilient infrastructure very cheaply, and run it with just a handful of people.

This vision of bringing enterprise-level clustering and fault-tolerance to smaller clients is what drove me to become an independent consultant. With cloud computing, automation, and PaaS tools, companies can build IT infrastructures in a few days that once took weeks or months (and a flatbed truck). They can also be very agile; if you sign a deal on Monday evening, you can deliver something to the client Tuesday afternoon.

These days, at Bitfield Consulting, my role is basically to solve hard problems for clients (they don’t call me in for the easy problems). That includes designing and building infrastructures, performance and capacity planning, clustering and distributed computing, advising on things like security and backups, compliance, and helping to build great DevOps teams.

How do you define DevOps?

Like hard-core pornography, you know it when you see it. Companies which run successful IT operations, particularly web operations, tend to have certain qualities and ways of doing things. You see the people who write the software working closely with the people who deploy and maintain it. Often, they’re the same people. You see a lot of pairing, learning, cross-skilling. People operate in fluid, focused, multi-disciplinary teams based on projects rather than skill sets. There’s a sense of constantly dancing on the edge of failure, keeping just ahead of the business, never writing a line of code you don’t need.

Also, you see a continuous drive for improvement. DevOps people love metrics, and they measure everything. They’re always working to make things faster, better, cheaper, more reliable. Because they can build things quickly, it’s cheap to try out new tools and technologies, and adopt those that work.

Companies that have the DevOps nature also treat their people well. You’re rewarded for what you do, not what your business card says. (You probably don’t have a business card.) If you have a bright idea and you can sell the team on it, you can go do it. People don’t worry about demarcation too much. Teams are highly autonomous and self-organizing, with minimal interference from management. Management enables and supports DevOps teams, removing obstacles for them and shielding them from politics.

When you’re working in a DevOps environment, every day is exciting and challenging. You’ll have to think on your feet, learn new skills, come up with ideas, and work with intense and sustained focus on problems which will need all your skill, intelligence, and energy.

If you wake up in the morning feeling depressed about another day as an unvalued cog in a pointless machine, your company doesn’t do DevOps. Go find one that does. As Steve Jobs said, “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work.”

What are the main challenges DevOps face today?

DevOps is actually very rare. Lots of organizations pay lip service to it, but then keep on doing the same old things. On the other hand, companies that have had great culture and great operations for years, before anyone talked about ‘DevOps’, keep on having them and being successful because of them.

One of the biggest challenges is simply reprogramming a company to have the DevOps nature. In many cases, I suspect that’s impossible, because the bad old ways of doing things are so entrenched. In that situation, the smart and capable people leave to find somewhere more conducive to a good DevOps environment. What you’re left with is, to put it kindly, people who are change-averse.

So this isn’t a challenge for DevOps, it’s a challenge for organisations to reconfigure themselves in this fundamental way. I suspect very few are successful in this effort because, if the management understood the value of these ideas in the first place, they would already be doing them, and there’d be no need to change. You can’t adopt DevOps—it’s not a process like ITIL. You can’t hire it—it’s not a skill set like Rails or UX design. You can’t buy it—a consultant can come and tell you the company needs to change, but that doesn’t actually create change.

As a CTO or VP of operations, you should probably stop worrying about your ‘DevOps strategy’ and ask yourself instead, “Are my people happy? Are they listened to? Can they get things done? Am I hiring the best engineers I can afford? How many Dilbert comics are pinned up around the office?”

(Sidebar: at one company I worked for, the management realised that the prevalence of Dilbert comics was a red flag that they had some serious corporate culture problems. Their solution? An email to all staff: “No Dilbert comics to be displayed in the office.”)

What defines a good beverage?

As you’d expect, I have a highly-optimized beverage programme for my workday: starting with a jolt of fresh espresso, which of course I grind myself using an instrument which looks like a computer-controlled uranium centrifuge. Later in the day I’ll transition to measured doses of tea, to keep my hydration levels up during long conference calls.

Finally, after a hard day inventing the future, I’ll wind down with a carefully-selected artisan beer.

Would you recommend any DevOps related books?

I’m reading Eric Sammer‘s excellent Hadoop Operations — I wish there were more books like this.

Who are your DevOps heroes?

I don’t have heroes exactly – however I do have some excellent friends and colleagues whose opinions I rate highly. Patrick Debois, Kris Buytaert, Stephen Nelson-Smith, Dean Wilson, and Matthias Marschall are all worth listening to.