On “DevOps”
DevOps is a very “hip” word right now, but I’m beginning to feel like it doesn’t mean what I believe it should. I keep seeing “DevOps” jobs, or pushes to make a Systems team learn how to write puppet modules to “automate” their infrastructure; often I see people try to simplify DevOps down to “infrastructure as code”.
I also see this notion that Systems Administrators need to learn to “program”, or they will be out of a job. I think that’s absolutely ludicrous, as a software developer who also dons the sysadmin hat occasionally I think we do not give enough credit to the amount of work Systems teams have outside of installing software and deploying new servers.
Wikipedia has a great description of DevOps
DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
That’s right, DevOps emphasizes communication between software developers and other information-technology professionals.
I’m going to take a bit of a harsh segue here to discuss what I do everyday at work. My official title is Programmer/Analyst, I am member of an internal Development team within my company that writes line of business applications for our internal customers. We automate repetitive tasks and write tools to make our company more efficient, freeing our human labor to focus on getting work done instead of clicking through websites repeatedly to get information or manually identify pieces of paper that should be attached to an account.
I want to emphasize two phrases from this:
Our internal customers: I see a lot in IT and internal software development to use the term “user”. This word is accurate, but it can often have a certain amount of animosity or complacency around it. We often see ourselves as keepers of the castle, and we allow “users” to use the services we provide.
This, I feel, is why IT is often seen as a cost-center instead of an important part of an organization, not because it doesn’t produce revenue. However, internal development teams have an almost identical issue; but it’s toward the IT team instead. There is often a lot of animosity between Systems and Development, we often see “the wall” and how bits are tossed back in forth. It’s been turned into comic after comic, and joke after joke.
DevOps is a practice that stresses communication between development and the systems, but I don’t think that definition goes far enough.
Automate repetitive tasks…focus on getting work done: My team’s slogan is “Automate. Create. Innovate”. In our industry there’s a lot of tedious work, a large chunk of our time is spent removing it or making it quicker. We create tools for our customers to increase productivity by letting them focus on their jobs, not ancillary tasks that just waste their time.
I think this is where my views about the term “DevOps” diverge from the mainstream. My team is responsible for automating repetitive tasks for the rest of the company, I feel where “DevOps” is concerned that means our role extends to our Systems team as well.
Piecing these two important details together, I believe a successful DevOps implementation does not involve making your Systems team learn to program, in tandem it doesn’t mean your entire development staff will ever replace your Systems team. Instead, I see it as a collaboration of your Development and Systems staff.
Essentially, your Systems team should become another customer of your Development staff, being provided with tools to automate repetitive tasks so they can focus on things that cannot be automated (and there is still plenty out there). Importantly, the relationship of customer and provider should be one of mutual respect. A company providing a service will not stay in business for long if they do not listen and respond to the needs of their customers, and a customer develops a certain amount of trust with a provider that engages with them to develop the products they use every day.
Don’t make your Systems team learn to program, find a developer or two who wants to learn parts of what your Systems team does, and then set them on a project to write tools to let them work more efficiently. Break down the wall between your two teams by establishing a relationship of mutual trust, where both teams can rely upon the other, and ask each other for the tools they need to accomplish their respective goals.











