Tech Tuesday: The ‘DevOps Engineer’ Problem
2 August 2016 |
Chris Wintle | About a 5 minute read
Ask anyone in this industry ‘what is DevOps’ and you’ll likely get one of a hundred different responses:
“It’s having Developers do your Ops work”
“It’s having a team that handles our CI and deployment processes”
and anything in-between…
The problem is that there is no real formalised definition, beyond ‘DevOps’ being a cultural thing (we’ll come to this later). Having all of these incomplete (or incorrect) definitions is actively harming our industry – ‘DevOps’ is one of those buzzwords which is being abused in every area – often with harmful results.
Let’s start with an experiment. Go on to CWJobs and search for ‘DevOps Engineer’. What do the Job Specs involve? I’m willing to bet that they are (mostly) looking for ‘someone to build our AWS stack and deployment tools’.
Does that really fit with a culture of shared responsibility and collective ownership? That sounds a lot like another silo in a business that likely already has a lot of (harmful) silos.
The Job Specs also probably sound a LOT like ‘Operations Engineer’ or ‘Sys Admin’ roles, but with extra stuff added on from what we used to see 10 years ago (now you’re dealing with infrastructure issues as well as writing Chef scripts, Ansible playbooks or what have you).
This brings me back to a good analogy I heard on the Arrested DevOps Podcast (https://www.arresteddevops.com/) a while back:
“Our Canary was dying in the mine – so we replaced it with a bigger, stronger Canary”
What this is referring to is that 10 or so years ago, we would typically have developers build our code, then throw it over the wall to the ops team, who would package it up and deploy it to a server. Naturally, this had problems. Releases were continuously broken. Go-live days were utterly terrifying.
Now, instead of looking at the root cause of this problem (which isn’t hard to see – the problem is silos), our solution has been to take that Ops team and give them more tools and put more automation in place between them and the developers. Sure, we’ve smoothed out significant parts of the process – but we still have the problems of big brick walls, so we still have the same root problem!
What it boils down to are the following two statements:
“All of the fancy CI/CD processes in the world won’t help you if your development team doesn’t understand the infrastructure their code is running on and how their code is built and deployed.”
“Your Ops team can’t possibly provide and support appropriate infrastructure if they don’t understand the fundamentals of what the codebase is doing.”
The reality is that your codebase and infrastructure are coupled to the point where there may as well be as little distinction between them as possible. Without infrastructure to run on, code is worthless. Without code to run on it, your infrastructure is a very expensive empty box.
Now, this isn’t to say you don’t need an Infra/Ops team. Maintaining infrastructure is HARD work. It’s a full time job, like coding. The same applies to Network Engineers. What it means is that these groups of people need to be sharing information and working together. They ideally need to be sat in the same room and have the same priorities – they’re all there to do the same thing in the end – make the product be the best it can be for your users.
This then leads back into the ‘DevOps Engineer’ role. It probably sounds like I think that role shouldn’t exist, which is entirely not true. I just think that we should not be palming off responsibility onto that person/team, as that is just creating another silo.
In my mind, a DevOps engineer/team should be a knowledge base. These are those that have a deep knowledge of the intersection of code and infrastructure and can help your business understand that. They should be your ‘DevOps Champions’. The role should be about teaching as much as it should be about doing. If your DevOps people are building things without understanding and input from the other parts of the delivery team – then they’re not helping to fix the problem. They shouldn’t be putting a wall around their team and ‘owning’ things, they should be helping the rest of your delivery team own it.
The ‘Agile Infrastructure’ idea was coined by Patrick Debois (@patrickdebois) and Andrew Clay Shafer (@littleidea) a while back and it applies nicely to this discussion. The Agile Manifesto is all about collective ownership and collaboration across teams – and it definitely applies in this instance. We happily apply these ideas to product development – why wouldn’t we go the extra step and apply it to our engineering and infrastructure processes?
The reality is that ‘DevOps’ is actually not a clearly definable thing. It’s about having a culture of collaborative ownership between the various areas of your delivery team, who all recognise that software is too tightly coupled to infrastructure for silos to be an effective working arrangement. It’s about letting the strengths of these various teams support each other and share their hard-earned knowledge and experience with everyone else, because we’re all in the same boat.
Read More From This Author
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested