Is DevOps just a conspiracy theory?

There is something to unpack here, says Baruch Sadogursky as he takes the stage at the Miami Shift Conference. A conspiracy theory, even. 

And here it is:

“DevOps is a conspiracy by Ops people to make developers work harder.”

Jokes aside, Baruch urges us to look into who teaches us about DevOps. A quick Google search along the lines of “What is DevOps” reveals that the answer to this question can be found on the websites of AWS (an Ops platform), Atlassian (a DevOps company), Gitlab (Offering DevOps in the box), Synopsis ( Observability platform). Is it a coincidence that all sources that teach us about DevOps are (dev)ops or DevOps-adjacent companies?  

Why do they want to sell DevOps ideas to us so badly? Is it about the revenue that the industry generates? A DevOps salary is almost double that of a system administrator (with not that great of a difference in the job description); there are almost 20k open positions for DevOps engineers in us alone, and let’s not forget about the certification business behind it. 

One could easily make the connection between money and the push for DevOps – but only if we forget to go back in time to when DeOps first started. When it was first conceived and gained momentum, the money was just not there, Baruch notes. 

This looks familiar

If we look at the DevOps cycle, it seems pretty familiar – it is basically an agile development cycle, with an Ops cycle plastered on there, and suddenly it’s supposed to all be dev work! Even when we look at the main aspects of DevOps work, we hear Ops concepts: deploying code, going from code commit to running code in production, unplanned outages, and degraded services.

Baruch protests that none of them feature in the basic postulates of dev work: Developers do new features, refactor, and fix bugs; that’s the job. The code passes the tests; it works, and the job is done. What happens in production is beyond the scope of work, so there is no room for these ops concepts there, right?

Well, it’s not that simple. If we take a look at a software craftsman definition of done Baruch provided, the list is much longer:

The project is done once the dev understands what needs to be done; the code is simple, readable, and easy to deploy; non-functional requirements are met; no tech debt was created; tests pass & QA is happy with the code; team lead, PO and client are all satisfied. That’s a much longer list, and what stands out is quality.

Baruch leads with another difficult question here: What is quality, that we’re so concerned about?

Testing in production = caring about what happens in production

Quality is an ever-evolving concept. It’s certainly not what it was ten years ago, as Baruch illustrates with an example of his old bank website, which allowed you to check your balances and transactions but nothing more complex. It was nice to have but not critical, so when the website was out for 12 hours for update & maintenance to ensure quality of service, that was not a big deal.

That era is gone – we expect more of our software now. In terms of banking, we do it via mobile app and expect everything to work at all reasonable times, and to work quickly and efficiently. Code quality alone is not enough to cater to that.

Let’s just look at the size of the global datasphere – 175ZB. There is more and more data in more and more companies, which makes testing harder. Since we have so much data in production that we cannot, or at least it’s not worth replicating in staging. So, we test in production:

And if we’re testing in production, and being in production is what is needed to ensure the software quality that’s so important to us as developers, that means we now care what happens in production.

And if we care about what happens in production, that means we have to be there when we throw untested software on unsuspecting customers in production and observe the blast radius from our bunker. We have to be there in the middle of the night with the ops people because this is actually the first time we get to test our software.

The new scope of work

This new turn of events means that there are some more items on the developers’ to-do list:

• We understand how our software is going to be deployed
• The build is reliable, repeatable & fast
• The code is stateless & scalable
• It starts fast and dies fast
• It is observable
• It supports feature flags
• It’s backward & forward-compatible
• The code emits event streams

This is what you need to ensure the quality of your software in production, says Baruch, so starting now, you care about this stuff:

10 years in, developers are still not excited about DevOps. But still, we have to be there – because we care about what we’re doing. So how do we go from 🙁 to :).

So, is DevOps a plot by Ops people? For sure, Baruch says, but it’s also an evolution and a means to an end. The end being quality, new features, lean software and security. DevOps just delivers what every business needs.

DevOps engineers are rainbow-farting unicorns

So now that you’re thrown into DevOps, you better get to know it. If we look at the traditional DevOps Venn diagram, we can see that DevOps is an intersection between Devs, QA, and Ops. So, are you supposed to master all those disciplines? If that thought terrifies you, Baruch has some good news: 

That person does not exist. It is a rainbow-farting unicorn, completely made up. DevOps is not about one person; it’s about collaboration. 

Instead, he suggests there are T-shaped people: People who know their job (coding) well but also understand what the Ops and QA part of the house means. This doesn’t mean developers have to become QA and Ops; they just take an interest in what they do. 

That’s not so bad, is it? Or, in Baruch’s own words: 

“DevOps is fine.”