For DevOps engineers, one aspect of getting hired is like any other job. Getting attention when applying for a job often means your resume, or LinkedIn profile, needs to be what some call “buzzword-compliant.” You have the right words that hiring managers are looking for.
But one thing is different for DevOps engineers: few words get attention like “DevOps.”
The term “DevOps” first appeared in 2009 at developer conferences that held a series of “DevOps Days.” Since then, there have been DevOps Days conferences held in many countries. The term itself is a portmanteau of “development” and “operations,” because it seeks to unify the two sides of an enterprise that oftentimes don’t speak, much less see eye to eye.
DevOps seeks to unify the development, deployment and maintenance of apps through rapid and continuous updates. It’s built on the Agile development mode, where an app is constructed segment by segment, rigorously tested, then a new segment added.
In older development methods, like the “waterfall” method, the entire app would be built before testing began. This was often difficult because bugs would be hard to trace, and when one thing was fixed, something else might break. Agile divided the process up into pieces.
And that’s the heart of DevOps. There is no linear path forward. It is about finding new ways to do new things. Only in a few constructs, like Agile, does DevOps exist as a single entity.
DevOps Engineer is…
DevOps is not like Agile or automation or the cloud or any of these other areas primarily focused on the emergence of new technologies to enable us to do new things in different ways. A cloud engineer uses AWS or Azure and other specific technologies. There is no technology, no tool, for DevOps.
And that leads to the first thing you have to remember: most people engaged in DevOps think of it as a philosophy more than a skillset. It’s a way of working, a belief system almost. It’s almost a management technique. It’s about collaboration and working together and breaking down silos. So it’s hard to say you’re a “DevOps engineer” when that’s a way of thinking, not a skill.
“What people mean when they say ‘DevOps engineer is Agile development, a full stack engineer, or site reliability engineer. What [hiring managers] are looking for is skills on DevOps platforms, techniques and processes,” said Andi Mann, chief technology advocate for Splunk, a Big Data analytics software developer.
In terms of platforms, think of things like automation tooling like Ship and Puppet, configuration automation, app release automation tools like Electric Cloud. These are the process automation tools and a must for DevOps.
“A lot of the tech that underpins the way people work in DevOps is automation. So when you are looking for a DevOps engineer, you want someone who understands all that automation and someone who works in an environment where everyone works in a collaborative way,” said Mann.
“The people in demand are people who can straddle different roles,” said Jez Humble, CTO at DevOps Research and Assessment LLC and co-author of “The DevOps Handbook” and “Continuous Delivery” and is one of the co-creators of the DevOps term.
“They are people who are comfortable doing programming, understand networking and system admin. The people who came up with DevOps never meant to limit it to development and operations. We wanted to get to address this problem of how to build secure, reliable and resilient systems at scale. To achieve that goal you have to know more than development and operations,” he said.
The DevOps Engineer “Must Have”: Flexibility
To be a successful DevOps engineer, flexibility is a must. The days where you learn one language and one toolset and it’s a career have been left behind with mainframes and COBOL. DevOps means learning lots of methodologies and tools, and relearning as new ones emerge.
“DevOps is different from the software development of the past 15 years in that development teams need to consider and test for operability and operational aspects as part of their normal work,” said Matthew Skelton, co-founder and principal consultant at Skelton Thatcher Consulting, which specializes in helping organizations to adopt and sustain good practices for building and operating software systems.
“Previously, many software teams would leave operational testing, security, performance, to a late stage of the software development lifecycle and often expect another team to do it. With DevOps, the team that builds the software can and should be responsible for how that software runs in production. They might even be on-call for live incidents,” he said.
And that means doing a lot more managing and non-coding work. Humble said most problems in development projects are due to a lack of communication between teams, so managing relations between teams is a key piece at being effective at DevOps. So if you are someone who just wants to code all day long, you won’t enjoy a DevOps scenario.
“Programmers work in silos and are often happiest writing code. In as much developers measure productivity by writing code, they won’t be happy in this role. You’re going to spend less time coding than if you were a developer full time. A lot of the problems aren’t coding problems. They are problems of procedural implementation, configuration management and poor collaboration. That’s why it’s not for everyone,” he said.
And that means no more holing up in the cubicle, staring at the monitor. “To know or do DevOps, you must: value and promote collaboration with different kinds of teams,” said Skelton. “You must promote a team-first approach to building software rather than many individuals working separately and you should work to promote the operability of the software you’re building.”
It’s bringing more people into the fold, and bringing in more discipline, added Mann. “It’s a job role, for better or worse. When you get to the large enterprise scale, that means more teams, more focus on technology, things are more codified, then you get training and certification and maturity curves,” he said.
Where previously programmers could say “I have a DevOps competency,” they were talking about the ability to work together and make operation’s life easier. “Now for an engineer it means I need to learn how to use Puppet or build a configuration in production, or talk to QA or security in the same collaborative, knowledgeable way. In terms of communication and procedures they have to follow, the way DevOps has evolved means that engineers need to do learn think a lot differently.”
The Future for DevOps Developers
So where is DevOps headed? It’s hard to say since it changes so much. In addition to new skills you need to be a quick study because of the constant change.
“What’s crucial is not knowing the environment but coming up to speed on it,” said Humble. “It used to be you could become an expert in Oracle and live off that for the rest of your life. Now you have to accept that there will be new tools coming along every few years, with the knowledge that you may have to throw that all out in a couple of years. No one was using Docker three years ago. Now everyone is. That’s going to keep happening.”
“As DevOps has moved into the enterprise, it’s encountered a whole new range of teams and job roles and tools and risk aversion and more that just doesn’t exist in the Web scale and startup businesses where DevOps started,” said Mann.
That means more formal training is needed, and this is an industry where many programmers are self-taught. Plus, leadership must be involved if you are going to do it in a large organization.
“You will eventually hit a ceiling where you need management support,” said Mann. “They aren’t going to buy into a philosophy. Cultural change is hard. So concrete steps are needed to show managers how they can help with things like paying for training, moving teams, and changing role definitions.”