4 minute read

Whether in job searches or on resumes, “DevOps” has become one of the coolest buzzwords to throw around. However, are you using it correctly and does it even matter? According to Wired’s J. Wolfgang Goerlich–it isn’t a job, but DevOps is still important.


Traditionally, companies have at least two main technical teams. There are the programmers, who code the software that the company sells, or that its employees use internally. And then there are the information technology operations staff, who handle everything from installing network gear to maintaining the servers that run those programmers’ code. The two teams only communicate when it’s time for the operations team to install a new version of the programmers’ software, or when things go wrong. In my last job (and about 10 years ago), our small, agile programming team was segmented away from the rest of the pack. We were self-contained and self-managing with our own analysts, DBAs, and, much to the loathing of our Networking and Operations team, we had and maintained our own servers.

Until then, anyone outside of Networking even approaching a server was considered sacrilege and nearly a cause for termination; however, it was crucial to our team’s function that we could install, maintain, roll-out, and schedule our own infrastructure changes.


We needed the flexibility to install updates on-the-fly, roll-out patches every night to the 15+ internal and external applications we serviced, and not get tied up in the bureaucracy of silos.

Didn’t this make it difficult to follow {insert process here}?

Sometimes. But that was the point. We had the same change control processes that everyone else had (even used the same arcane systems), but instead of days to consider a rollout, we took minutes. The most important process to change was the feedback loop. We broke down the idea of annual releases and started viewing every application as an ongoing project with cycles, maintenance, and features releases.

(via AppDynamics)

What skills did the team need?

Most of all, it created a huge change for the team needing server, infrastructure, and networking skills. Up until now, at least in our environment, the developers knew their coding language and their IDE, but not a lot else. Now we needed them to understand how servers were managed, how packets made their way through the network, and how to manage it all (we were a Windows, RHEL, and Solaris environment).

For those of us, like me, who originated in hardware, it was a simple transition; however, for others, we had constant internal mastery afternoons to get the team up to par.

What I didn’t know at the time was we were organically becoming a DevOps shop.

What Does DevOps Actually Mean?

Dominica DeGrandis, who teaches DevOps techniques, tells us that thus far, DevOps has been mostly defined by what it isn’t, rather than by what it is. But she suggests that it can be described as a collection of practices that improves automation of IT processes, increases trust and collaboration between different departments, and speeds up the process of getting feedback from end-users.

The DevOps movement grew out of a related idea called agile software development. In 2001, a group of programmers published the Manifesto for Agile Software Development, describing a new approach to building software that emphasized, among other things, small but frequent changes to code meant to make the entire process more efficient. The ideas caught on over the years, but the problem was that even though programmers were creating software faster, they were creating problems for the operations teams that had to deal with more frequent updates and the problems they caused. DevOps is, in part, a response to that.


That said, there are skills that tech professionals can learn that will help them adapt to a DevOps way of thinking. Goerlich suggests IT operations staff get started by learning about automation tools like Puppet, Chef, and Microsoft’s PowerShell language. “Then use the time that frees up to spend more time with developers and end-users to understand what they’re doing and why,” he says.

Developers on the other hand should start by learning more about the infrastructure their applications actually run on, and by learning about tools for continuous integration, which help programmers manage constantly changing code bases.

Ultimately, DeGrandis says that DevOps is mostly about soft skills like listening, being adaptable and, mostly importantly, communicating—useful for any tech job, no matter what you call it.

comments powered by Disqus