For a field as precise and unambiguous as software engineering, we are terrible at agreeing to a single definition of a term. Then that term is given to recruiters who have only the high level, two sentence definition and they have to somehow filter using it on job postings and sites like LinkedIn. The one which has caught my attention recently is DevOps. So, join me as I explore the term, look at the definitions I have come across in the wild, and where it originally comes from.
History Lesson
Where does this magic made up word come from? Wikipedia is pretty light on the history, although it has lots of wonderful details regarding the different facets. Essentially, DevOps, like many practises in software, is something which has developed organically to suit a particular purpose. It is generally considered to have come to the surface in the late 80s or early 90s, meaning that it should be well established.
Whilst I’m not convinced that it is the first or only such story, The Phoenix Project really highlights the importance and difficulty of bringing DevOps to life. The narrative fiction hits home with a lot of developers, we’ve seen different variations of the same nightmare scenarios play out, time and time again. So, I’m going to suggest that perhaps the practises espoused in the book make a good basis for defining what DevOps really is.
What is DevOps?
Etymologically, this is a portmanteau of Development and Operations. Development, traditionally, is the process of turning concepts and ideas into software which can achieve those stated goals. The precise method of writing the software may be agile or not, it doesn’t matter. What matters is that a bunch of code is written — might be tested — which does something. Operations on the other hand, is everything from infrastructure management to customer support and bug reports. Testing may fall into the realm of operations, as it is really about the reliability of the software.
So, when you bring these two things together, you start seeing new practises evolve. From test driven development and domain driven design, to software teams taking on support roles and having oncall rotations. In the most extreme cases, the same team owns the entire stack from the infrastructure to customer support. Going back to The Phoenix Project, the key point of bringing these things together is to speed up delivery without compromising on quality. You might have an infrastructure expert in the team, but they are also involved in design, testing, and implementation of the feature. This collaboration shortens the software development life cycle (SDLC).
DevOps is not a specialisation in infrastructure management. DevOps is not really a stand alone role. DevOps is far more than that. So when you are looking for a DevOps person, or when I say I do backend engineering, with a focus on DevOps, I do not mean I am a database expert, or that I can tell you the details about network engineering. I do have a basis in Infrastructure as Code (IaC), but that is because I know the best way to run the software that I write.
Instead, my preferred definition of DevOps is this:
a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality [source]
I asked on LinkedIn how others define DevOps, and I got kind of the answers I was expecting. We need to focus on the process and the practice more than on defining a type of engineer as a DevOps engineer.
Dale gave a second opinion which I really liked:
If you have a DevOps team then you probably should rename them to infrastructure team or something like that, I’ve always assumed that DevOps basically meant the developers were prodding the stuff they deployed too…
Where “prodding” really means “putting the code into production, and making sure it stays usable while there”.
But I might choose to use Candice’s definition next time we need a team building event:
Isn’t it when you get a team of Developers suit them up in kamo, with some paintball guns and force them to take each other on at a local arena?
What does this mean?
Jokes aside, the point here is that there is not a single definition of what DevOps is. It is generally accepted as a principle, and some people will be better at it than others. Just like some people function better in a Scrum atmosphere, and others in Kanban. The basis I want to underline is that any team which has to handle operations — meaning they have an oncall or pager-duty rotation — is doing DevOps. They might also have an infrastructure team who help them set up firewalls (Network engineers are next level superheroes), but they are owning their own bugs. That is what makes you a DevOps team.
Stop being scared of DevOps and telling people you don’t do it. Most teams are now doing DevOps to some extent, we cannot afford the “throw it over the fence” type of shipping which may have worked in the days of software being shipped on a floppy disk. Continuous Integration and Continuous Deployment are here to stay, and your customers definitely want those quick turnaround times. If you want specialists in infrastructure management or DevOps tooling (y’know the cool gitlab stuff), then be precise about it. I am always happy to do extra development work to take the Ops out of DevOps, but don’t tell me you don’t do Devops when your engineers are on an oncall rotation.
Pippa Hillebrand 