You’re using the word DevOps badly

I recently attended a conference, designed to bring together security and engineering teams, I was struck by how many people use the word DevOps in different ways, and to me - badly, wrongly and out of context.

“DevOps” used badly #

• I heard people ask, are you DevOps?
• Do you do DevOps?
• Recruiters hiring for a DevOps engineer

What does DevOps mean to me? #

DevOps is modern, cultural approach to engineering. To understand this more, we need understand historically what we did before this idea came to be.

Traditionally engineering teams were split, into those who wrote code, and those made sure production carried on working. These teams were also known as “Developer” teams and “Operations” teams.

This produced some communication and handoff difficulties between the two styles of teams, as when the Developer team was ready to run something in production, they would “kick the code over the wall” and hand it to the Operations teams. The Operations team would rightly want to understand whether the various non-functional testing had happened, then would also need to make the various changes to make it run their production environment.

The way the teams were setup was to encourage the Development team to want to ship as quickly as possible, and for Operations to resist as much change to production as possible. This would naturally cause tension, as Operations would want to allow as few changes as necessary - this previously being understood to reduce the risk of an outage.

Change packages would then be bundled up by the Development team in to large changes, and handed off to the Operations team to be deployed at an undetermined time.

The Phoenix Project really solidified this idea for me, originally published in 2013, it still is very relevant in our teams today.

What does DevOps mean to me, attempt 2 #

DevOps is a cultural approach to engineering teams. It starts by bringing Operations and Developer teams into the same team, breaking down the silos. This new team, can start to be cross-functional. Beginning to understand and estimate each others tickets, talk to each other regularly in ceremonies (retrospectives, stand-ups, refinement etc).

Eventually, this one team will understand both parts of what is required to build an application, writing code but also shipping it to production. The mindset will move towards thinking about how to run it, before writing a single line of code. These requirements will feed into the initial design and implementation phases, with a priority given to shipping regularly, quickly but safely.

This can all come together through significant automation and collaboration, more on CI/CD automation another time… but here’s something I wrote earlier about it.

Therefore, you can’t “do DevOps” it’s a way of working, not a check list item. You can’t hire a “DevOps engineer” as it’s cultural. The most appropriate term would be “Full Stack engineer”, where this to me means frontend, backend and platform/infrastructure.

Thoughts? I’m @florx on twitter.