In a lot of job advertisements I see “We’re looking for a DevOps” Engineer. Have you seen that too lately?

It’s interesting, because DevOps is not a person or role. It is methodology, describing a way of working together (same as Agile). Let’s look at what it is.

Let me illustrate this with a small example from a past work experience. I was working as a software developer in a small consultancy. We didn’t have a fixed product to work on but instead often supported other teams in their mission. Once, we were joining a relatively new startup in Berlin that was building a new product. My colleague and I formed a team to work on backend components, together with other 2-3 people teams focused on other backend and frontend components. Putting all these components together it would build the final product.

The operations team, sitting in a separate room, was lead by my boss. Their responsibility was to work together with the infrastructure provider and provision servers for all software components. Early on, they let us know that all components would get deployed on Red Hat Linux.

One of the backend teams insisted to keep developing on Windows and not use the virtual machine that was provided for them. When they handed in their components for deployment, nothing worked because their code was expecting a Windows system. They “threw everything over the fence” and let Operations deal with it. It’s the classical separation of Dev and Ops with at least a virtual, sometimes even a physical boundary (like different rooms / buildings) between them.

This caused a lot of frustration for everybody involved and trouble with the upper management because of the resulting delays.

The perfect opposite of DevOps.

Now, how does DevOps work?

As the name suggests, the boundaries between Development and Operations are disappearing. How does that look like?

To stay in the above scenario: My colleague and I chose a different approach compared to the previously mentioned team. We were using Macs but since the code was supposed to run on Red Hat Linux, we decided to go ahead and develop our code on Red Hat Linux as well. So we installed a Red Hat Linux Virtual machine (using a tool called Vagrant) on our computer. This VM was provided by the operations team, with everything preinstalled and configured as it would be in production later on.

This gave us huge advantages: We knew right away which system packages we needed to install to make sure all our Ruby Gems were working as expected. Also, we could adapt our code to work together with the specifics of the Red Hat Operating System, such as specific paths or system commands. So, whenever we had to deploy a version, we let the operations team know which tag to pull from version control and they could build and deploy everything right away and rely on the package to be working. Additionally, we could provide them with on point documentation which packages, permissions and so on we needed.

We could deliver pretty early on. Everything was well tested and documented. The other teams, well, for them it took a lot longer.

With DevOps, boundaries between development and operations are disappearing. Both teams work together, learning from each other. Developers learn more about things like network architecture and system administration, where sysadmins get more into programming, Continuous Integration and automated testing.

It’s not about tools at all, even though a lot of fantastic tools emerged through DevOps. DevOps happens much more on the process and cultural level than on the technical one.