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 20132017 State of DevOps report.

With all this goodness, you’d think there were lots of DevOps engineers out there. However, just 18 percent of our survey respondents in the 2012 / 2013 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.

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-doing-you-harm/ 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.

'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.

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 :)

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.

I come from the other side of the fence. Hearing you describe Devops it sounds like you are trying to do a Linux Engineers job and are a trained developer. Other than the fact you mentioned automation it doesn't sound like there is much devops involved. CentOS and Ubuntu are great tools and easy to use if you have the knowledge. My last job I was a Sr. Engineer over 8000 Linux servers. By the way Puppet for me has been very painful and I use other tools but, I digress. I can see why using it though your post was directed at Linux/Puppet frustration.

To me Devops doesn't mean doing development work or having to be a Linux Admin/Engineer/Architect. That certainly is a component if you need to automate spinning up bare metal or instances. To me the important part is continuous integration builds, implementing Agile deployment methods, collaboration through tools and meetings. Implementing processes like test, stage, production, getting bugs fixed, and getting releases delivered. I guess with 20+ years in Unix the Linux stuff just comes natural for me. Maybe that's why my focus is more in the software delivery and supporting developers when I think of devops.

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...

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.

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.

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.

I work in a company where we don't have titles. Dependending on what we are doing that's what we are, iOS devs, Android, frontend, backend devs. We all are devs, with the exception of three guys, who are the right hand of our manager. They are the wizzards, guys who know coding, who know tips and tricks, who know basically everything and in the same time they help the "hefe". And we feel awesome about it. Job titles are pretty useless, nobody needs them, because you can't feel realy yourself with a job title, can't you? Especially in an IT environment.

Just out of curiosity, how big is the company you work for? And how big are your engineering/IT team? I wonder if titles are less necessary in a small intimate group than in a company with hundreds (or thousands) of employees.

By the way, we will be launching our 2015 DevOps survey in the next several weeks; it would be great for you to fill it out once we publish it (it's anonymous). Watch this space! We're hoping to get an even more diverse and large sample this year than last year, and learn more about the current state of DevOps.

Hmm finally i got my role in my organization. I have been working for 5 years as a developer in release life cycle. Yes I am improving the productivity of release life cycle. And i have accepted the devOps engineer who has the 3 skills which are author mentioned in this blog. This role gives tremendous satisfaction in the organization when i made reliable & fasten the continuous delivery.

It is better to have as much as skills as possible. A degree is only one requirement you need to pass the administrative test. Skills are the ones that will separate you from other applicants. I am not a software engineer myself, but I am an engineer. In my case, for a fresh graduate, for example, if you know how to draw with AutoCad, Revit, 3dMax, Rhino, even if your GPA is about 2, I can guarantee you that most companies will accept you. All graduates have the same basic skill, and a standout skill is what most companies are looking for. Acquire those skills now!

DevOps is merging of development and operations, think of it of breaking down the barriers between these groups. Operations needs to think more like developers, and developers need to think more like operations. Gone are the "it works on my development workstation, you figure out how to get it to work in production." These days, developers need to take operational requirements into accounts. At the same time, operations needs to use development processes to it system administration, provisioning, to version their work ala Docker in the same way developers perform source control on their code.

You can call DevOps the convergence of Operations and Development groups, and you would not be wrong.

So, the one thing you didn't explain is WTF a DevOps engineer is! Article was way TL;DR. But I skimmed it and didn't even see you expand the acronym, and I still don't know what it stands for. Moving on...

DevOps is Development Operation. so the DevOps role is ensure the continous integration and build the codes at server, if there is failure fix by manual file pushing or contact the developer who made a build failure by checking the log files. check about Jenkins tool on youtube.

I am a Solution Architect with coding experience in Java and C#. What should I do to become perfect Dev Ops Engg.
I want to keep focus on SA role as well as deliver Dev Ops use cases by coding in Java or C#.

I am a Software Configuration Manager. I read all your Comments about DevOps. I have One decade of experience in Configuration Management, working on various tools.

Can somebody suggest me what are the *skills* and *tools* required to become a *DevOps Engineer*. I was not into Coding in C, C plus plus, C# and in Java. But have good experience in Scripting. I want to know that scripting is quite enough to become a DevOps Engineer?

You say "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. "

It is a very long time since every company developed their own software in-house. Building your system by stitching together open source or bought-in components has been the way for at least a couple of decades.

Automating of build, test and deployment is an independently good idea and does not need to be lumped with a bunch of other things that well run organisations have always done e.g. (Developers and Operations people co-operating) and inventing a new buzz word for it (DevOps).

DevOps engineers seem to be what they call system administrators in an Agile development environment. The two quotes I liked best from the discussion are:

(David Tooke) "Devops is all about coding and automation tools like puppet and cfengine to quickly and consistently deploy new systems."

(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."

Tom's comment resonates well - every GOOD systems administrator has been doing what a DevOps person seems to be doing. I'm a UNIX systems programmer (device drivers, filesystems, etc.) a nd I've been doing what a DevOps person (notice I'm avoiding "engineer"!!!) does forever. I owned my own engineering company and we developed hardware and software for Sun/Oracle boxes; as one of two people in a small startup, you have to do everything - but I don't think that accurately defines what a DevOps person does, although it may require you to fill that role.

David's comment is far more accurate. My take on a DevOps engineer is someone who performs systems administration and deployment in an Agile development environment. His comments that they understand automation tools like puppet and cfengine is probably the most specific statement made on the blog about what a DevOps engineer does: deployment.

As a software engineer and programmer I do NOT want to be a DevOps person; I don't want to be responsible for configuration management, customer releases, or automation because it takes away from what I am best at: architecting and implementing software solutions. Let someone else distribute the code and configure it for different platforms.

To me smashing development and operations together means either you're trying to save money by making your software developers do systems admin tasks, or you've been saving money by hiring systems administrators who didn't have the skills to do the job. If you REALLY have a situation appropriate for DevOps, you're not really developing software; you're a systems integrator, hooking together tools other people developed to accomplish a task. There's nothing wrong with that; but don't pretend that integrating other peoples software products is the same as software development.

You can play with Legos all you want; but someone has to design and produce the Lego you choose next...

One more thing: "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 20132015 State of DevOps report." (This was at the top of the blog)

NO KIDDING. You're knitting together and deploying OTHER PEOPLE'S CODE. Of course the deployments fail less frequently: the code you're deploying is code that has been already tested, released, put in use, and debugged. If your deployment fails, it's probably the scripts that tie it together, not the modules you RE-deploy. At least compare apples and apples. [I'm assuming that "50 percent fewer of their deployments fail" as compared to 'standard' software development efforts, where the code wasn't a "reusable" chunk...] Also, the "...they deploy code up to 30 times more frequently than their competitors" isn't necessarily a good thing. End users don't like it when the software they use changes frequently; they want some stability and a release from a constant learning curve. If your 'code' is just a web page and it's the content or layout changing, then it isn't software and you can't compare it to software deployments. If it's a mature application (like for instance AutoCAD or PeopleSoft) then releasing changes 30 times more frequently than other companies (who also sell mature applications) will confuse and frustrate your customer base. There's something to be said for the human factors side of things, where installing a new version of a program is something many end users look to with trepidation. And if we're talking patches and bug fixes that (should be) invisible to the end user except for the corrected functionality, that's a totally different beast and you don't need a DevOps department to implement a clean and simple method to disseminate updates.