DevOps is the new Big Data. People aren't really sure what it means exactly, but that isn't going to stop them putting it down as a requirement for a job...

I have been doing development and operations since before it was cool to mix the two (and yes, before you ask I DO have a beard). I've managed and hired for teams that practiced most of what we associate and these days I'm a DevOps Consultant; If there was such a thing as "a DevOps" then I'd be one, so I've thought a lot about this.

Given the number jobs I've seen advertised recently, and people asking about how to "get in to DevOps", I wanted to put down what I think is useful for getting good at DevOps:

  • Take programming seriously
  • Spend some time on-call
  • Learn a cloud
  • Use configuration management
  • Use source control
  • Always be learning

In most cases people interested in DevOps are coming from either Development or Operations, so not all of these things are going to be new depending on your background. Here's a bit more details

Take Programming Seriously

Pick a programming language and get comfortable with it. It doesn't matter much which one, but really make an effort to learn it. You should be comfortable enough with it to the point that you know when you probably should NOT use it (i.e. you know its weaknesses, not just its strengths).

Don't get too hung-up on which one you go with initially, just pick the one you like the look of the most. While you might always have a soft-spot for the first one you learn, chances are you'll have to switch main language at least once - if not more - in your career.

While you're doing this, you should naturally get exposed to the fundamentals of programming; Learn OO. Learn functional. Learn your patterns. You don't have to be a master at any of them, but knowing of them will help you pick the right tool for the job in the future.

Make sure you give TDD/BDD a red-hot go. This will make you familiar with the automated test/build cycle/pipeline, and tools and services that make it run smoothly.

Read the classic programming texts. Some that come to mind are:

Spend Some Time On-Call

It only takes one "What could possibly go wrong?"/Friday night release that go like this to to start seeing the value in DevOps practices.

What could possibly go wrong?

Being called out in the middle of the night or on the weekend due crappy releases with completely preventable/testable issues gets old really quickly.

Depending on how long you spend in this kind of role, you will hopefully walk away with a healthy dose of reality when it come to failures in IT systems; They will happen. They will be weird. There is no such thing as a perfect, failure-proof system (otherwise we'd all be using it!) so plan accordingly (think mean time to recovery, etc).

Learn a Cloud

I'm partial to the big yellow cloud, but I hear good things about the blue one too.

It doesn't matter too much which one you learn, as all the decent platforms will will force you to think the right way when it comes to DevOps practices. That is, you should be architecting for failure. Once you're less attached to the hardware your applications are running on (and you're only paying for it by the hour), you can really start treat infrastructure as cattle, not pets.

Use Configuration Management

There's plenty to pick from: Chef, Puppet, Ansible, SaltStack. I've seen some people recommend Ansible for beginners to config management, but Puppet is so widely used and documented I don't think you can go too wrong with it.

Like the cloud you choose, it actually doesn't matter too much which one of these tools you pick. Just using any of these to the point of proficiency will expose you to practices like immutable infrastructure and treating your infrastructure as code. Having idempotent and repeatable configuration for your servers is what's going to be useful for you in the long-term.

Use Source Control

If you're coming from a development background, this is probably a non-issue. If you're background is in operations this might be more effort - I've met many a SysAdmin who's idea of "source control" was a USB full of go-to scripts and hacks in their back-pocket.

If you want your configuration to be repeatable - and more importantly, roll-back-able - then do yourself a favour and version control the lot.

While I have a strong preference for git and don't think you can go wrong with it (because you WILL be using Github at some stage), this is another one of those anything-is-better-than nothing.

Don't be too intimidated by the complexity that's possible with SCM tools (e.g. branching strategies, et al) - I don't think I really knew what I was doing with git for the first year I used it. Just learn the basics and the rest will come naturally.

Always Be Learning

While this is true of anyone in IT it's doubly true for those working with "the new hotness", which at the moment is DevOps.

While there's agreement on most DevOps practices (i.e. the why) you should be aiming for, we're still working out how they should be done best.

New tools and services are coming out weekly to make these tasks easier and easier, which means there's really no excuse to suck at DevOps any more...


If you've got contrary opinions, I'd like to hear them in the comments or by email. Just like all the points in the list above, I'm still learning as I go.