In an interesting post from Jeff Knupp, he laments the increasing tendancy for development and operations roles to merge into one:
Rather than temporarily taking on a single role for a short period of time, then transitioning into the next role, they are meant to be performing all the roles, all the time. And here's what really sucks: most good developers can almost pull this off.
Now I'll strongly disagree with one major part of that blog post -- that developers are a "totem pole" above operations and QA -- but it's a thought provoking article.
There's often a strong need for seperate ops roles -- a skilled operations professional knows all the ins and outs of how an EC2 load balancer scales up, how to orchestrate upgrades, how to best suggest caching strategies, how to respond to system failures, and what things need to be monitored. He or she has a tuned intuition about how software behaves at scale and has passed the bar of understanding Murphy's Law. Specialization of ops also lets developers focus more by spending more time with their software.
I understand the frustrations when one specialization is asked to do the role of another, when financial or market pressures encourage crossing the streams, as they increasingly do. However, I disagree with Jeff's assertion that automation is taking time for developers to help them "play ops". When done correctly, automation tools are giving them time back -- and helping out of this problem of needing to wear many hats. Though I'll go on to say how wearing many hats is a great thing, but we need powerful tools to allow us to operate in these environments. Naturally, all things in moderation.
Back to the article, the comments on Hacker News are particularly interesting -- and very dissimilar. And yes, I think it could be said that the 15% of the internet that is not composed of cat pictures is at least half composed of discussions about what DevOps means. Here's a few:
A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development.
The last time I looked for a senior sysadmin -- less than a year ago -- I didn't get anyone who was comfortable programming in Perl/Python/Ruby until I started using the term DevOps.
There are companies where the developers are responsible for creating the automation scripts to deploy their code into production as services and expected to keep in running in production.
DevOps is about developer empowerment. It's about creating the systems and tools that give developers more control over the operation of their applications.
Saying "DevOps person" is like saying "Agile person". I think it's a fundamental misunderstanding. DevOps is about getting development and operations to communicate directly and work cooperatively, without impediments beyond inherent complexity.
- Getting developers to understand production more
- Getting operations to understand code running in production more
- Using automation tools to eliminate repeated tasks (see our favorite blog post of all time, DevOps is Ruining My Craft)
- Applying development style practices towards automation (such as using source control) - commonly described as "infrastructure as code" (or in our case, infrastructure as data), to enable branching, auditing, and review.
- Researching new operations technology such as new cloud or monitoring software
- Applying agile practices typically applied to software to IT operations (such as Kanban)
- Reducing the politically-imposed communication barriers that come from competing departmental goals to make development and operations groups work better together
- Seeking continuous improvement, as established from for example, Japanese auto manufacturing
- Viewing the product not as code or the servers, but code running on the servers, in production
- Focusing on the customer rather than battling business units
- Setting up more discussions between "technology" and "business" units of a company, in addition to healing apparent divides between development and operations.
