We should do DevOps… right?
Euh… yeah you probably should, but are you sure you know what it means?
I’ve been spending the the last couple of years to spin my head around this term and I’ve found that there are many different views on this subject. I’d like to share some of the more popular definitions that I encountered:
- DevOps: operations crew as part of the (agile) development team
An idillic world in which both developers and operations crew are working together in multi-disciplenary agile teams.
- DevOps: operations crew that can automate stuff
The automation of Operations, basically the implementation of the “automate everything” strategy.
- DevOps: let’s fire the operations crew
Having developers do operations on-the-side, basically merging two previously full time jobs into a single job description.
- DevOps: aww yeah, check out my cool new job title
The “I-have-no-clue-what-I’m-doing-but-it-sounds-cool-so-let’s-just-give-everyone-a-new-title-and-more-salary-because-the-other-companies-are-also-doing-it” approach.
Surprisingly, I’ve found that each of these interpretations has it’s own merit (even the last one!).
#1: operations crew as part of the team
One of the reasons you’re looking into DevOps is because you want to improve the collaboration between dev teams and ops, speed up development and deployment and perhaps even change the company culture. You do this by merging the ops crew into the development teams. Each team now has a dedicated operations crew. Can this be considered DevOps?
“What you’ve basically done is move around some desks and gave dev teams a toy-ops”
Well… not really. What you’ve basically done is move around some desks and gave each development team their own toy-ops team member. It did not involve a culture change (the ops person will basically do… ops, and the devs will continue to do… dev). It merely split up a coherent group of specialised people who will now have increased overhead to share knowledge about the technical infrastructure which creates room for (human) error.
Yet, there are some situations where this has merit. If you need to speed up individual development teams it will certainly do the trick. Having a dedicated ops member will help the team to increase its productivity.
Unfortunately, this is a short-term gain and will result in long-term pain. But if that’s ok for now, go for it. It’s probably one of the easiest DevOps implementations (except for #4).
#2: operations crew that can automate stuff
This is probably my favourite (being an ops guy who likes to dev). This interpretation does not involve a wide-spread culture change or any additional collaboration between devs and ops. Unfortunately, this is probably also why it’s not really a valid DevOps implementation on it’s own.
You keep the separate operations team and hire operations team members that know how to code and that will bring your IT infrastructure into the 21st century using software-defined solutions.
When it comes to IT there is a simple rule: You. Can. Automate. Anything.
When it comes to IT there is a simple rule: You. Can. Automate. Anything. And you should. But in order to do this, you’ll need an ops team that knows how to develop software. That has a software-first mentality.
The downside of this approach is that it does not really implement DevOps in your organisation (only in the ops team). And that you’ll have a very very very hard time finding someone to fit the profile in your long list of traditional system engineers, IT operations engineers and application managers that respond to the job opening.
So when does this approach have any merit? If you want to first optimise your operations crew as part of phase 1 prior to going full DevOps.
#3: let’s fire the operations crew
Just like the full-stack developer myth, this interpretation of DevOps assumes that the developer can do it all.
He or she can create a nice front-end using LESS SASS with awesome user experience based on AngularJS ReactJS with a modular grunt / restify gulp / browserify build system that works perfectly with the micro services, pub/sub, detached cloud-based systems architecture back-end (with 100% automated test coverage) running on Docker LXC whilst using apache nginx / SAN glusterfs / F5 BigIP ha-proxy / ubuntu CoreOs / and some other much hyped crazy-named awesome hipster technology which will change the course of history.
See what I did there?
We’ve come a long way from the cubicles of uninspired code monkeys
Over the last few years the job description of an average software engineer changed dramatically. We’ve come a long way from the cubicles of uninspired code monkeys in Office Space to the over-communicative engineers of Schubert Phillis. That’s great, I really support this, but there is reason why we had multiple disciplines in the first place. If done right, these are all full-time jobs: Front-End developer, Back-End developer, UX designer, QA Engineer, Product Owner, Systems Engineer, Application Manager, Service Manager. You could merge them into a single full-stack-devops-rainbow-unicorn-centaur, but I’m not sure those actually exist on this planet.
And yet again, even this interpretation definitely has some merit. Being responsible for running your application code on production systems will improve the mutual understanding between developers and the operations crew.
In addition, if you are a small start-up you might not have a real choice but to have your developers do operations as there is no dedicated ops person on your team. And that’s a good thing. When your company grows and you start hiring operations specialists you’ll have that mutual understanding as a long standing part of your culture.
#4: aww yeah, check out my cool new job title
Oh well… this is kind of self explanatory. You’re basically having a hard time recruiting and think that you’ll have more luck if you go for a fancy job title. You know what… I can’t really blame you. I’ve done it in the past. Guilty as charged.
If you’ve reached this far you might not be surprised that after all these years, I believe that the actual correct interpretation of DevOps is… all of the above:
- Collaboration between developers and your operations crew, preferably team-based (#1)
- An operations crew that knows what it’s like to code, and which has a software-first, automate-everything mentality. The application is not a generic, black-box, one-in-a-million interchangeable piece of software. It’s your product (#2)
- A culture of mutual understanding and shared responsibility between devs and ops (#3) without overloading developers with a long list of additional requirements whilst pretending that ops is not a full-time job on it’s own
- An awesome job title that nobody really understands (#4)
What’s yours? Share it in the comments!
Originally published at www.linkedin.com.