Explain DevOps Like I'm Five

Comments

[Bertil Muth]

It is winter, and one cold evening, a fairy visits you.

"You've got three wishes", the fairy says.

"I want a machine that throws snowballs", you say.
And puff, there's the machine. And the fairy disappears.

You invite your friend Simone over, and tell her what happened.
"Wow", says Simone. "How do you use the machine?"
"I have no idea. It's got like 1000 buttons.
It is way to complicated."
"Oh my god", says Simone. "What a pity."

That night, you sit in your room crying.
Suddenly, the fairy appears again.
"What's up? Why are you crying?"
"Well, you gave me that awesome machine, but I can't use it.
Simone can't use it either. It's too complicated."
"Well, you didn't say it needs to be simple. But remember.
You've got 2 wishes left."
"Ok. My friend Simone and me, we want to know which buttons to press. So that the machine builds snowballs, and throws them."
"Your wish is my command", says the fairy, and disappears.

You invite Simone over. But now, there is another problem:
you know exactly which buttons to press to make the machine build a snowball. But only that. You're kind of like the developer of snowballs.

Your friend Simone knows which buttons to press to make the machine throw a snowball. But only that. She's kind of like the operator of the machine.

If Simone and you work together, you can make the machine build and throw a snowball. But neither of you knows the whole story. Neither of you can use the machine alone. You always need Simone around. And while you can build snowballs that look really good, Simone often complains that they are too heavy and don't fly far enough.

But you're friends. You observe each other, and talk about the machine a lot. Because it's the most fascinating thing you know. And over time, you learn which buttons to press to operate the machine. And Simone learns to build a snowball with the machine.

You were a developer, and learned to operate the machine.
Simone was an operator, and learned to develop snowballs.
So now both of you are a developer, and an operator. You are DevOps.

One winter evening, you visit Simone.
Suddenly, the fairy appears again.
"You've got one whish left", the fairy says.
"It's your turn", you say to Simone.
Simone sits on her chair silently for a minute.
Suddenly, she jumps up.

And with a smile on her face, she says:
"I want a button on the machine that builds and throws a snowball.
And both my friend here and I can use it.
Don't trick us again. We are DevOps after all."

[bigzoo]

Thanks a lot for this. So you think it makes sense to always have a team where everyone's title is software engineer or one where others devops engineers + % other engineers...

I know there's the scenario where teams requiring larger/more complex setups need devops teams who's sole purpose is infrastructure but is that really only what devops is all about?

[Bertil Muth]

In my opinion, DevOps is first and foremost a topic of organizational culture.

In contrast to my story, developers and operations often have conflicting interests. Developers prefer to have an easy, fast, frequent deployment process. Operations prefer a stable, high quality release, so they are often more conservative.

So the goal of DevOps would be: bring these two viewpoints together by collaborating closely. Have easy, fast, frequent AND stable and high-quality releases.

On the operations side, that would mean: gain empathy for the development side. Learn about developing automation of operation functions, like Infrastructure as Code.

On the development side, it would mean: gain empathy for the operations side. Use a continuous delivery pipeline with different kinds of automated tests. Lean about Monitoring, Rollbacks in production, Chaos Engineering and so forth.

I think both of the scenarios you describe are feasible: having all team members with DevOps skills, or having a separate team.
But if you have a separate team, this could be a smell that the cultural prerequisites are not there yet.
So the question would be: do the developers and that operations team work towards common goals?

[upendramanve]

Loved this explanation.

[David Muckle]

You're on a team that builds race cars. One part of the team builds the cars, the other drives them. However, having people that only know how to drive and people that only know how to build cars is a little inconvenient. Instead, some of the people that build the cars may be able to drive them, and some of the people that drive them may be able to diagnose or even fix an engine if it's making some weird noise.

DevOps is more a culture of shared responsibility between devs and operations. Less chucking code over a wall, more handing it over a small fence. That said, many places have their own definitions of DevOps, as well as their own implementations. DevOps may give devs a pipeline to automatically build and deploy their projects, and be a bit more hands-off. DevOps may also be in charge of the infrastructure the projects are built and deployed on. Or it may be that devs and ops are one in the same, and the same people that build projects are the same that deploy and monitor those projects.

[Alan Barr]

The people that give you computers to run your application are also in charge of giving you more computers in the future, check it when it breaks and fix it or tell you to fix it, and possibly has a recipe for doing these things repeatedly.

[Ben Harvill]

Your older sibling has a cool new toy, and you want to play it. Your sibling says, "No, you can't play with it. You'll break it. You don't know how to use it."

"When can I play it?" you ask, because it's cool, and it will make your life better and more enjoyable.

"Here, let me show you," says your sibling.

This is DevOps. The older sibling is the operations team. They don't want you to break anything or cause any problems. But you want the cool new thing because it will make your life better.

In a non-DevOps world, the response would be "Wait until you're older" or "Never" or "Get your own (but you can't use anything we don't approve)" in order to keep everything important (i.e., in production) safe. But now you can never use the new thing, or at least need to wait years, and then you miss out on all of the fun and goodness of the new thing for those years and live a sadder life.