Grant Fritchey

4 March 2022

DevOps 101: What, who, why, and how?

Organizations around the world are turning to DevOps as a way of working together to improve the efficiency and quality of software delivery and increase value to the business. But what exactly is DevOps and what does it mean for you and your organization? Welcome to DevOps 101.

Our new monthly webinar series aims to explain exactly this. Each live session will be hosted by me, Grant Fritchey, starting with the fundamentals to expand your knowledge and understanding of DevOps.

In the first session, I tackled the essential DevOps questions of what, who, why, and how. This is a recap of what I talked about.

What is DevOps?

“DevOps is an agile culture that better supports collaboration between people, using automation and tooling in support of the process.” This is my own simple, straightforward version of what DevOps is.

Microsoft’s Donovan Brown defines it as: “The union of people, process and products to enable continuous delivery of value to our end users.”

You’ll notice that in both definitions the focus is the same: people before process, before automation. That’s what DevOps is. It’s just a short way of saying let’s build a process, let’s build a culture that supports people first, focusing on collaboration and communication, let’s create well defined and disciplined processes that we can then automate so that we can make it faster, safer, better, and stronger.

Who is involved in DevOps?

The short answer is everybody.

The long answer is a lot of people think it’s obviously developers. Well, yes, absolutely, developers are the foundation. Developers are driving this process, they’re fundamental to what you’re doing, you absolutely need to have your development team engaged as a part of building out a DevOps process. But you’re going to want to bring in everyone else as well.

Management needs to be engaged for us to deliver this. They need to understand what it is you’re doing. Not at a detailed level, but at least the broad strokes. You’re automating things, focusing on people first, processes second, and automation to ensure that all of it works fast, smooth, and good.

Your admins need to be on board. Whether we’re talking cloud admins, database admin or system admins, they’re helping build out servers, virtual machines, and a whole lot more, so they also need to be engaged in this process.

You need to make sure it’s not a mentality of ‘Well, it’s only developers’, or ‘It’s only operations’, or ‘Because it says DevOps, it leaves out the security team, so we need to have a separate SecOps.’ No, that’s not the way it works.

DevOps is an umbrella term that covers everyone you want to be engaged. It’s all about that communication and collaboration across the teams. You’re going to tear down walls, you’re going to remove the barriers that prevent us from ensuring that we’ve got the right stuff to get the job done.

Everyone is fundamental. Everyone helps make DevOps work.

Why should we be doing DevOps?

Well, first up is improved communications. When you’re focusing on your people and on collaboration, you’re going to communicate better. Improving communication means teams have a better understanding of one another. What is it that the developers are working on? What is it that the DBAs need? What is the admin team struggling with? What can we do to help them improve? Communication solves all of these.

What you’re doing is removing the friction between teams, eliminating that wall that keeps them from talking to one another. Improving communication is like throwing grease into a ball bearing: it increases efficiency. You’re going to be able to do more, and do it better, because you are tearing down those barriers. The whole concept here is that, as Donovan Brown puts it, we’re delivering value to the people that we need to deliver value to. And if we can deliver that value faster, we can deliver that value continuously. That’s a major win.

People who are successful with their DevOps implementation will not only see this faster development, but also fewer failures. Why? Two reasons – practice and testing. In short, you’re going to be deploying and testing throughout the entire process from QA and Testing to Development and Production, which all means fewer failures. You’re not going to have bad deployments, broken deployments, or deployments that break things, because you’ve got testing and practice to add protection. So, not only are you moving faster, you’re also moving safer. All of this together results in lower costs.

When I say lower costs, do I mean money? Yes, because if you’re not down for a day to do a deployment then you’re saving or making money. If you’re not causing outages with deployments, you’re saving or making money

But it’s not just about money, it’s also about time. As you automate processes and deliveries, you can spend more time delivering functionality. You’re no longer spending time on manual deployments – instead, you’re deploying faster through automated processes, and focusing on delivering functionality that offers value to customers, lowers costs and increases profits.

How do we implement DevOps?

Step one has to be pick a project. Contrary to popular belief it doesn’t need to be a new project. Existing projects are a little more difficult because there’s already an established way of doing things and you’re introducing change, but that doesn’t make it impossible. I’ve successfully implemented DevOps into existing projects, and there’s often a more visible reward because you have before and after comparison points.

But the reason I say pick a project is because I have seen people go ‘Okay, we’re implementing DevOps’, and they implement it everywhere across 20 different projects with 30 different teams. Then they fail. They haven’t had the chance to build it out and understand it, and they hit issues. Start with one project, get that ironed out, figure out the problems, and then move forward. That’s step one.

Step two, identify champions. Find people who understand DevOps, with a good appreciation of what it is and belief in the reasons you’re implementing it. You need at least two champions, one who will be on the line actioning the changes and growing support among the team, the other in the higher tier of your organization focused on why you’re doing DevOps and the benefits.

Step three, you need buy-in. Management needs to understand that you are figuring this out as you go. They need to let you make a couple of mistakes, to mess up a few times, iron it out, and make it work. Without that buy-in, the first time you have one of those incidents they may shut the whole thing down. Get that buy-in, onboard the idea that we’re dedicated to making this work, and then measure.

Speaking of measuring, step four is measuring your pain upfront. How many outages have been caused by bad deployments? How long were we down? How much time is spent recovering from deployments? Measure the pain involved in your process today so you have a comparison point. You can look back on when it used to take a week to do a deployment, now it takes an hour, or when it used to take three days to get a bug fix done, now you can do it in half an hour. Share these wins, and then expand, bring in new champions, bring in new teams, bring in additional projects, start growing it out into other environments and other processes.

Choose your project, find your champions, get buy-in, measure the pain, and then expand. This is how you’re going to implement DevOps.

DevOps 101 Summary

What? DevOps is a shorthand for people over process, over automation.

Who? Everyone, from the development team and DBAs to the operations team and management.

Why? Increasing efficiency increases our speed, increases our safety, and ultimately lowers costs.

How? One project at a time with champions and measurable outcomes, then expand.

If you haven’t read them yet, you can catch up on the other posts in this DevOps 101 series:

• DevOps 101: How do you get buy-in from people?
• DevOps 101: How to kick-start your DevOps initiative
• DevOps 101: Introducing Database DevOps
• DevOps 101: The role of automation in Database DevOps
• DevOps 101: Unlocking the value of frequent deployments