One question I hear a lot is “How do I learn DevOps?”

As straight-forward as the question may seem, the answer is actually full of a lot of nuänce. There are many ways to answer, depending on exactly what is meant by the question. So in this article, my goal is to clear up some confusion about “DevOps”, and provide some pointers for those who want to learn about it.

What is DevOps?

Ask 10 people what they think DevOps means, and you’re likely to get 12 answers. If we can’t even agree on what a thing is, how can we set out to learn that thing?

A common (but “wrong”) definition of DevOps

DevOps is a job role, characterized by the use of Cloud-native technologies such as Docker, AWS, and Kubernetes.

Most people who ask me “How do I learn DevOps” are probably confused by this popular, but ultimately meaningless, and therefore “wrong”, concept of DevOps. To an alien visiting from another planet, reading LinkedIn job postings, this is probably close to the definition they’d come up with.

But what’s wrong with this definition?

A number of things, really, but let me focus on two here, and a third with the next definition.

1. DevOps is not cloud-specific. While many companies that practice DevOps use cloud-based technologies, this has more to do with the current state of the art than with DevOps. Many companies also use DevOps principles in on-premise installations, or even embedded systems, or any other kind of IT or software project.
2. DevOps isn’t about what tools you use. You can learn Docker, Kubernetes,Terraform, or any other set of amazing tools, and use them in a way that is completely out of line with the DevOps philosophy (more on that in a moment).

The origin of DevOps

Well if that definition of DevOps is wrong, what is the right definition? I’ll get to my preferred definition of DevOps in a moment, but first a short history lesson to explain why my definition might make any sense.

Way back in the good old days, we used to split up our IT operations into two (or more) groups of people, each focused on their own area of expertise. Developers would work on creating great software, hopefully using Agile methodologies so they could produce software fast enough to keep up with customer demands. Operations people (sometimes also known as administrators) would manage the networks, servers, and any other systems required to operate the software developed by the development team.

Development’s job is to add new features Operations’ job is to keep the site stable and fast

This sounds fine on the surface. But it doesn’t take a lot of thinking to realize that this puts Dev and Ops at odds with each other. Devs’ job is to change things (as quickly as possible) in the form of adding features. Ops’ job is the opposite: To make sure things never change, as change is the opposite of stability.

How do we approach such an impasse?

In 2009, John Allspaw and Paul Hammond proposed a solution to this dichotomy their seminal talk 10+ Deploys Per day, in the form of reframing the goal of Operations as:

Operations’ job is to enable the business

If we acknowledge that the business requires change, and that it is Operations’ task to enable the business, then this Dev vs. Ops mentality goes away, and what are we left with?

Cooperation between Dev and Ops, which was later dubbed “DevOps”.

My definition of DevOps

So now we’re ready for my favorite definition of DevOps:

DevOps is aligning the goals of Dev and Ops for cooperation.

Or as a handy shorthand:

DevOps is cooperation.

I’ll go so far as to say that you should be able to replace the word “DevOps” in any sentence with the word “cooperation”, and it should not substantially change the meaning. If it does change the meaning, then the word “DevOps” was misused.

The common theme across most bad uses of the word DevOps is that they are actually the literal and exact opposite of DevOps.

If you have a DevOps “team” ,separate from your development team, you’re literally not doing DevOps, because DevOps is about cooperation across teams.

Okay, so what should we call our “DevOps” team, then?

Whenever someone learns for the first time that a “DevOps team” is an oxymoron, they’re faced with a problem: What name should we use?

Well, what does the team do? Most so-called DevOps teams are simply Operations teams. How about we call them that instead?

A minority of DevOps teams are teams made up of developers and operations, in a cross-functional sense. Let’s just call them a product team.

You’ve convinced me, but how do I learn DevOps?

Let’s get back to the original question: How can you learn DevOps?

By not it should be clear that this can mean one of (at least) two different things. Let’s apply my earlier test:

Is this what you meant when you asked me how to learn DevOps? If so, you’re in luck! Because I have a daily email list, The Daily Commit, where I talk about exactly this. It’s completely free. Sign up!

How do I learn cloud-native technologies?

I expect that more than likely, what you really meant with your question was:

“How do I learn Cloud-native technologies such as Docker, Kubernetes, and AWS?”

If this is what you meant, then the answer is also simple: Find a tutorial on Docker, Kubernetes, or AWS (or whatever other tool you’re keen on learning), and get to work! Here’s a web site that can help with that search.

But what technologies should I learn?

Perhaps what you really meant to ask was:

“What technologies should I learn, so that I can become a competent DevOps, er I mean Operations, engineer?”

There are a ton of exciting technologies out there, and a certain amount of competition between products. I cannot tell you whether you should learn AWS, Azure, or Google Cloud, for example. They all do roughly the same thing. Which is “best” mostly depends on who is paying your salary (now, or in the future).

So here’s my general advice to anyone who’s interested in becoming proficient in the types of technologies used in modern Cloud operations environments, and in working with DevOps-minded teams:

Learn to write and deploy your own application.

It’s that simple. And it’s that complicated.

You don’t need to be a star programmer. You don’t even need to be a good programmer (but becoming at least a little bit good at programming is invaluable in modern operations jobs). You can just run through a simple tutorial for your favorite web framework (React, Laravel, whatever), to get a toy application running. Then figure out how to deploy it. Deploy it to AWS, or to Azure or Heroku, or anywhere else.

Simply doing this will begin to teach you everything you need to know about modern operations. If you get bored with that, up the ante. Deploy a more complicated application. Or re-deploy to a new cloud provider. Or set up auto provisioning. There’s literally no limit to how complicated, or interesting, you can make your deployment.