What are DevOps? What is the OPS part of devops? Some of you are purists, and maybe thinking that devops is a movement, one where dev and ops are joined in harmony and everyone can do everything to ensure operational excellence. To some early adopters of devops, the mere suggestion that devops engineers are anything like on-premises sysadmins can be demeaning.

Many organizations have been able to find this balance, especially if they build a team from the ground up, to build a brand new product. But what happens if you try to bring devops methodology into an existing organization? Can devops happen at enterprise scale?

What work needs to be done?

The goal of devops is operational excellence. Operations people design, create, build and manage infrastructure in cloud web services, continually testing, improving and evolving those infrastructures so the product that developers are building can be deployed faster and more reliably.

Here are some of the skills that employers look for when they hire for the operational side of devops:

devops-wordcloud

These terms are identical to skills required to architect, build, manage and maintain on-premises datacenters (physical and virtualized). There are some new concepts and technologies, and everything is done with software, but we’ve been doing the automation bit on the hardware we manage for a long time. What what a good devops engineer can bring to the table is the understanding of how to make continual improvements that will stay inside of business requirements (regulatory compliance, for example).

What sort of jobs are being created to do this work?

I’m curious as a technologist, and as a product marketing manager about the evolution of the job market as more enterprise organizations start adopting devops practices. I posted a non-scientific twitter poll to get some real-time feedback about the job roles people are currently accepting in this space:

unscientific-twitter-poll

The other titles people sent me included Infrastructure Engineer, Software Engineer, Cloud Engineer, Staff Engineer, SRE, and Potato Farmer. I’d like to dig into a few of these:

  • Several of the responders told me that these are their actually titles (e.g. Software Engineer), because changing the titles in orgs they serve is a very long process. Some of these folks are spending half of their time on the operational duties, and the other half on development, which was surprising to me.
  • SRE (Site Reliability Engineer): This blog post explains the concept of SRE really well. The basic principle is: everyone in an org is responsible for operational excellence. If you are a software developer, understanding and being able to execute operational duties will make you a better developer. If you are in operations, understanding and being able to execute development duties will make you even better at operations.
  • Potato Farmer: I’m pretty sure the friend who claimed this title did so as a joke. But I think it really does matter what we call ourselves, because jobs have to be funded. If an org hires for a job title but the skills will never bring the desired results ultimately the business will become frustrated and see the exercise as a failure. In traditional ops, we have a lot of experience dealing with this, and it’s hard to recover from this sort of failure.

What needs to happen to get to operational excellence?

First of all, let go of the idea that you don’t need people who have strong operational backgrounds on your devops teams. You can teach someone new technology, but you can’t teach the experience one gains from fighting the on-premises fires.

If you have been working in operations, and are ready to improve your skills, start learning how to manage systems in a cloud environment. One of my favorite learning sources is vBrownBag. Right now they are running training on how to use github, devops tools, and training for the AWS SA Associate exam. Learn the new things, and blend it with your on-premises data center experience.

We’re in the midst of another big shift, and we can’t get to operational excellence without ops people. Don’t be overwhelmed, just learn how to adapt what you know. We need you!