What Is a DevOps Engineer?

Demand for people with DevOps skills is growing rapidly because businesses get great results from DevOps. Organizations using DevOps practices are overwhelmingly high-functioning: They deploy code up to 30 times more frequently than their competitors, and 50 percent fewer of their deployments fail, according to our 2013 2014 State of DevOps report (Note: Updated to latest report, which includes lots more info, including how culture improves IT and organizational performance). With all this goodness, you’d think there were lots of DevOps engineers out there. However, just 18 percent of our survey respondents [in 2012 survey] said someone in their organization actually had this title. Why is that?

In part, it’s because defining what DevOps engineers do is still in flux. That hasn’t stopped people from hiring for DevOps skills, though. Between January 2012 and January 2013, listings for DevOps jobs on Indeed.com increased 75 percent. On LinkedIn.com, mentions of DevOps as a skill increased 50 percent during the same period. Our survey revealed the same trend. Half of our 4,000-plus respondents (in more than 90 countries) said their companies consider DevOps skills when hiring.

What are DevOps skills?

Our respondents identified the top three skill areas for DevOps staff:

  • Coding or scripting
  • Process re-engineering
  • Communicating and collaborating with others

These skills all point to a growing recognition that software isn’t written in the old way anymore. Where software used to be written from scratch in a highly complex and lengthy process, creating new products is now often a matter of choosing open source components and stitching them together with code. The complexity of today’s software lies less in the authoring, and more in ensuring that the new software will work across a diverse set of operating systems and platforms right away. Likewise, testing and deployment are now done much more frequently. That is, they can be more frequent — if developers communicate early and regularly with the operations team, and if ops people bring their knowledge of the production environment to design of testing and staging environments. Discussion of what distinguishes DevOps engineers is all over blogs and forums, and occurs whenever technical people gather. There’s lots of talk, for example, about pushing coders - not just code - over the wall into operations. Amazon CTO Werner Vogels said in an interview that when developers take on more responsibility for operations, both technology and service to customers improve.

"The traditional model is that you take your software to the wall that separates development and operations, and throw it over and forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer."

The resulting customer feedback loop, Vogels said, "is essential for improving the quality of the service." Longtime developer and entrepreneur Rich Pelavin of Reactor8 also sees benefits from DevOps culture in terms of increased responsibility for everyone: "I’ve seen organizations where engineers get beepers, so they’re the ones who get beeped if it goes wrong [in deployment]. That pushes them into the rest of the software lifecycle. I think that’s a great idea." That's a real change from non-DevOps environments, where developers make their last commits and head home...or to the ping-pong table.

What is a DevOps engineer, anyway? And should anyone hire them?

There’s no formal career track for becoming a DevOps engineer. They are either developers who get interested in deployment and network operations, or sysadmins who have a passion for scripting and coding, and move into the development side where they can improve the planning of test and deployment. Either way, these are people who have pushed beyond their defined areas of competence and who have a more holistic view of their technical environments. DevOps engineers are a pretty elite group, so it’s not surprising that we found a smaller number of companies creating that title. Kelsey Hightower, who heads operations here at Puppet Labs, describes these people as the “Special Forces” in an organization. “The DevOps engineer encapsulates depth of knowledge and years of hands-on experience,” Kelsey said. “You’re battle tested. This person blends the skills of the business analyst with the technical chops to build the solution - plus they know the business well, and can look at how any issue affects the entire company.” If DevOps is understood primarily as a mindset, it can get awfully fuzzy. But enough people are attempting definitions for us to offer this list of core DevOps attributes:

  • Ability to use a wide variety of open source technologies and tools
  • Ability to code and script
  • Experience with systems and IT operations
  • Comfort with with frequent, incremental code testing and deployment
  • Strong grasp of automation tools
  • Data management skills
  • A strong focus on business outcomes
  • Comfort with collaboration, open communication and reaching across functional borders

Even with broad agreement about core DevOps attributes, controversy surrounds the term “DevOps engineer.” Some say the term itself contradicts DevOps values. Jez Humble, the co-author of Continuous Delivery, points out that just calling someone a DevOps engineer can create a third silo in addition to dev and ops — "...clearly a poor (and ironic) way to try and solve these problems." DevOps, he says, proposes "strategies to create better collaboration between functional silos, or doing away with the functional silos altogether and creating cross-functional teams (or some combination of these approaches)." In the end, Humble relents, saying it’s okay to call people doing DevOps by that term, if you really want to.

Becoming a DevOps Engineer: What Does it Take?

If you believe DevOps is the future, you’ll want to start expanding your skills — and experience — to compete for these new jobs. While it’s great to beef up your coding skills, and get familiar with automation tools, you’ll also want to seek out projects and new roles that allow you to exercise the “soft” skills that are at the core of DevOps. Find opportunities to collaborate within and outside of your team. Help your company move to a faster test and deployment rhythm. Be open to listening to others’ ideas. Keep in mind that DevOps is less about doing things a particular way, and more about moving the business forward and giving it a stronger technological advantage.

Learn More

Comments

Shaun Mouton

Shaun Mouton

I like what @adamhjk said here:
http://www.krisbuytaert.be/blog/apparently-devops-not-jobtitle

> Systems Administrators and Software Developers, depending on whether they focus primarily on building the application or building the infrastructure that runs it.
>
> The "DevOps" movement is about having everyone understand how the entire system works, and everyone being able to express what their underlying business value is. This has traditionally been very easy for Software Developers - if the business *is* software, their value is obvious. For Systems Administrators it's been harder - is your value that you keep things up? Is it that you keep costs down? As a profession, we've been bad at making it clear. (The answer is that you tie operations to revenue, and you make availability the problem of the entire company, not just systems administrators.)
>
> As for what we call people using Chef, Puppet, and Cfengine, we call them "good at their job". :)

More on the topic:
@ripienaar http://www.agileweboperations.com/what-devops-is-not
@petecheslock http://blog.petecheslock.com/2013/05/03/devops-in-your-job-title-is-doin...

I would much rather be called a systems administrator or operations engineer, because that feels like the best fit for what I know and what I do. I would just as soon put LinuxNinjaPants Engineering Mutant on my business card because then people would be able to clue in on my sense of humor and know that I'm OK with being foolish. DevOps Engineer as a title means that a) your company wants to make up for not being able to pay you by giving you a hip title; b) you are out of your depth; c) you think too much of yourself; d) your company thinks too much of itself; e) more than one of the above.

I worked at a nonprofit organization that made up for not being able to pay us very much by giving us decent insurance and not giving us job titles (except for the Executive Director). It meant that we could talk about ourselves in the context of what our primary duties were at the time, and leave off the mucking about with titles and whatnot. I liked that. Where I work now, I have a formal title, and most days I feel like the name of the group I work in says more about what I do than my job title or my job description does.

Brian Dunbar

Brian Dunbar

'DevOps Engineer' - finally a name to put with where I've been trying to direct my career.

I'm not overly fond of the 'engineering' part, however. To my mind 'engineer' is a guy who has studied engineering, has some certifications testifying to this, and can be entrusted with building a bridge that won't fall down.

But I will admit that, in a world where a guy answering the phone at Oracle is called 'engineer', that horse has long since galloped out of the barn.

Where I in charge, we'd revive the mainframe billet of 'systems programmer' and apply it to this role.

Byron Miller

Byron Miller

All this said, and I still don't know what a DevOps engineer is :) I think this stuff is awesome and the skills are amazing and i'm exciting to see people doing cool stuff with everything labeled "devops" but I have a gut feeling is if we're so focused on the path to getting where we want to go that we're losing sight of the destination. What does all of this achieve? What are your goals? How does this solve problems facing your organization? Once your "ecosystem" is developed, whats next? How does this help you innovate? Iteration is great, but iteration isn't innovation if you're iterating in a bubble.

I wrote about Silos in my blog linked as my website here and i'm working on another piece about the culture often discussed with devops now. The more I think and write about this stuff, the more I relate it to the humble beginnings of dot-coms and ISP's where we "Sysadmins" were often "DevAdmins" having to invent everything as we went along and now that the "Dev" portion is done, we're learning and specializing in vertical tools and processes and getting deep domain knowledge.

So with that said, if I were hiring teams, I'd hire people to make sure we can support the end game and not be so focused on the abstractions that get us there. Those abstractions, such as using puppet will mature in their own ways and the manifests/scripts/dsl will become standard fair and the integration between vendors will be done by you guys, not internal projects.

The best way you can align yourself with your businesses revenue is to realize what your product is. Sometimes its best to buy off the shelf, regardless of open source because in some cases, you're not an ERP / CRM / Financials / Accounting / OS provider.. and even if you use open source, I hope you're buying support and supporting these awesome companies, including Puppet!

All to often though, I get the impression that some people only see the devops movement as a tool-set of free as in beer and little to do with what really matters.. its a misguided concept of everyone else is doing it all wrong and I can do it better and sadly, that's what many "DevOps Engineer" job descriptions look for.

Sorry for the wall of text :)

Jilles van Gurp

Jilles van Gurp

I'm a reluctant devops. I'm reluctant because it is not the most fun part of my job and actually a huge distraction. But it is stuff that needs to be done if I am to be successful at the other parts of my job which is to convert the startup I am working for into a revenue engine by developing software.

Being a startup means that if you want something done, you have only a limited group of people that can do it (including you) and if you want it done well you pretty much have to do it yourself. Hence I've recently spent about 80% of my time doing what hordes of other reluctant devops do world wide: convert bits and pieces of poorly integrated software, otherwise known as Centos or Ubuntu, into a deployment infrastructure for our bog standard software (bog standard as in millions of developers are working on and deploying similar software). This stuff shouldn't be hard but it is hard, error prone, and tedious work.

While tools such as puppet and vagrant definitely help me make devops less tedious, it still feels like I spend an awful lot of time reinventing wheels. Surely I can't be the first person to figure out that it would be nice to have such trivial things as a firewall running on our production architecture. You wouldn't guess from the amount of hoops you have to jump through to get simple stuff like that working in a sensible way (and yes I use a poorly documented puppet module for this). Until I started this project of getting our deployment architecture in order, I had little clue that deploying bog standard ruby, nodejs, and java code onto servers required so much custom development. Most linux distributions are pretty much a DIY operating system construction kit and do very little the right way out of the box.

Most of what a devops person does is in fact development but it is of the non value adding variety. Basically a devops person spends the vast majority of their time configuring common off the shelf software, scripting this or that, etc. It's necessary work but doing it well only gets you to a level playing field where all your competitors are probably/hopefully doing something similar. It doesn't really add value if you do it well but can destroy your business if you don't. That makes it different from e.g. feature development that directly translates into stuff you can charge your customers for.

So the trend of devops is definitely a good one. It's a sign of our industry maturing to a point where it is now actually feasible for this stuff to be done inside development teams. But surely, there's room for some massive improvement. The vast majority of the stuff I have done the past few months could have been a lot less hassle if centos and ubuntu got their act together instead of just throwing bundles of poorly configured software at their customers.

Aliza Earnshaw

Aliza Earnshaw

Jilles, that's such a great explanation of what you do. Thanks for offering up so much detail.

Xcode

Xcode

Devops value can be recognized at the critical moments,when things get to the edges!.
Production/staging issues blocking releases or impacting online products/users , this is because they're the central point between all parts.
(DAB,Network,Software Engineers) They're the Gods of Environments!,they're the part who is gluing system components ,by defining relationships and applying it..

They know what/where is every bit in the system :) , And while the Developer wrote part of the code and everyone in the team did a part ,devops have deployed all these parts ,they automated things based on understanding what have been done...

also At 3:00-4:00 Am with p0 outages..Devops shining!!.

Tom Rose

Tom Rose

I have been doing DevOps for over 20 years. So have all good developers and Sysadmins. Nice that we now have a label for it.

chief

chief

Hi. I like the courage you posted online. Is there anyway you can train or assist me getting knowledge for this skills.
Please, if anything i can do. my email: owolabis1@yahoo.com.
Thanks

Vu Nguyen

Vu Nguyen

devops is the middle ground between a real coder and a sysadmin.

Most coders can do some sysadmin work, but would you really want them to do that in a production environment? Probably not. You probably plenty of coding work for them to do anyway so why distract them with sysadmin work. Frankly, you only want coders to do sysadmin work when you don't have a real sysadmin.

On the other hand, sysadmin can code. Actually, they script. That's a major part of their job. No company in their right mind would hire a sysadmin who couldn't script.

Since devops is the middle ground between real coders and sysadmins, here's the real key - the language you want the sysadmin to code in.

sysadmins, by default will code in a shell scripting language. This makes sense since they spend most of their time in the OS. coders, on the other hand, don't spend of of their time in the OS; instead they spending their time coding the app so their primary language is something like java, c, or perhaps php or even javascript/node. To get these two groups of people to agree on one workable language, you need to agree on that "glue" language. These days the fad is python. A decade or two ago, that language was perl. A few years from now, that language will be ______ (your guess is as good as mine).

Really, that's it. The formula is sysadmin + python = devops.

Some people ask why can't the glue language be java, c, php, etc, itself. Why python or perl? A sysadmin won't be as good a coder as a real coder. They didn't go to school for this. They don't code all the time like a real coder. Thus, if you have some complex coding project/task, do you really want your sysadmin to do it? Of course not. Sysadmins are much better when you have them doing sysadmin tasks. So if you have a lot of coding to do, make your coders do it; that's what they're there for. Sysadmin can do light python, but I wouldn't ask them to do more.

Now here's the part no one wants to talk about. In all likelihood if you hire a devops person and use them as both a sysadmin and a light coder, you won't be getting someone who's very good at either. Why? Well, they're not a full time sysadmin so even if they were before, their sysadmin skills will erode over time. The flip side is also true as I've already mentioned; this person won't be a very good coder either.

Personally, I would rather hire a very good, experienced sysadmin. That person, regardless of title would undoubtedly be a good scripter, has experience working with engineering teams (aka coders). Similary, I would try to hire the best coders I could. The people in that group would have experience working with sysadmins.
I feel if I have very good sysadmins and very good coders, they'll work together fine as opposed to trying to hire devops people.

usaims

usaims

HeyVu Nguyen!
You don't need to go to school to code! I learned by buying a book and practice, practice, and practice -- that's how I learned and I'm a full time coder with no degree making just as much as a Ph_D whom dumped hundreds of thousands for that diploma.

david tooke

david tooke

Devops is all about coding and automation tools like puppet and cfengine to quickly and consistently deploy new systems.

Sagron

Sagron

Vu Nguyen - Actually I'm a sysadmin who DID go to school for coding (Computer Science) - Can I code in C as well as the best people who do it every day for a living? Heck no, although I can do at least as well as the average coder (and better than a lot I've seen). Different people have different skill-sets, but what you do best usually depends on what you do frequently.

Leave a comment