9 hidden talents of devops ninjas

Adam Bertram |
Jan. 26, 2016

The secret to devops success begins with an open, flexible, and lazy approach to systems and code.

This talent is about retooling the concept of a "job." Sure, we each have our areas of expertise, but the true devops ninja is flexible. Developers must be responsible for their code and assist system administrators when server resources suddenly spike. On the other hand, system administrators must be able to read a developer's code well enough to understand it might be a code problem that will require getting the developer involved in the solution.

This talent is about realizing you are not a horse meandering down the street with blinders on, seeing only the road in front of you. It's about removing the blinders and, instead of getting spooked at every distraction, becoming more open to others' positions in the team.

8. You use configuration management tools

The pace of devops is fast. After all, continuous deployment is the goal. That means only one thing: continual speed. Without proper tools in place, you'll never be able to keep up. This talent is loosely related to No. 6 (“You can let it go”). One issue with engineers that don't possess the ability to "let it go" is perfectionism, even to the extent of disliking automation. They don't trust tools but are constantly trying to reinvent the wheel and do things "right," in their eyes.

To be a true devops ninja, you must realize that tools are critical to your success. Granted, high-performing devops organizations build their own tools -- for good reason. However, I'd argue that configuration management shouldn't be one of them. Teams have no excuse not to use one of the many choices out there for your configuration management needs.

Configuration management tools can automate so many tasks and allow you to focus on what's important: writing code and getting it deployed to your customers.

9. You think in code

This talent is more geared to the system administrators. Software developers build products by writing code. These products are then packaged and placed onto infrastructure to service the customer. If developers need to make a change, they don't have to get up from their desk, go into the data center, and physically manipulate an object. It's text. A few keystrokes from their keyboard and a commit will make the change. Code is dynamic, flexible, and easily changed. If not, how do you think agile development practices survived this long? That's a lot of changing!

An ops devops ninja has learned and can see the benefit of the "infrastructure as code" paradigm. Though this is a new concept to most system administrators, you must be able to see the obvious benefits of treating infrastructure as code rather than physical objects. You must be able to understand "disposable" servers and keep your cool while that server is simply rebuilt from the logic already built inside of the code.