Matt Gordon

16 February 2022

Why you don’t just buy tools to make DevOps happen

What is DevOps and how should organizations introduce it? In this series of articles, we talk to DevOps thought leaders who are leading the way in implementing advanced software development practices like DevOps for database as well as application development. What are the challenges they’ve faced, how have they overcome them, and what lessons can other IT professionals learn from them?

Matt Gordon is a Microsoft Data Platform MVP and the Director of Data and Infrastructure at Rev.io. The sophisticated billing-as-a-service (BaaS) platform provides online billing software to communications companies, IoT businesses, and technology service providers.

Matt’s role, first and foremost, involves keeping the lights on while at the same time overseeing many data-related projects, from architecture to performance tuning and DevOps implementation. His team operates as the first line of defense and the more they’re plugged into projects, the better support they can offer.

All of which makes him an informed and knowledgeable thought leader to talk to. Here are his insights to some key questions about DevOps.

We like the explanation of DevOps offered by Donovan Brown from Microsoft: “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” Does that resonate with you?

Yes, that’s certainly our goal. Our technology team has recently expanded significantly. We now have different teams across the country working on different parts of the product. With that comes a variety of perspectives and experiences.

One of the important things to realize is that you don’t just buy tools and make DevOps happen. I think some people believe that you simply need the right software to get it off the ground. Tools are important, of course, and we’re very happy with Redgate software and what it’s helped us achieve. But it didn’t magically create DevOps. You also need the right people and processes in place.

What were the drivers for the organization, and for you personally, to start your DevOps journey?

As the organization grows and matures, you must evolve from the approach of “hey, this is broken so I’ll go into the code base, fix it and deploy the hotfix myself”. Instead, you need to put processes in place. And just as our products have grown, our customers have also grown. As a result, they ask more of us and the products. This is an expected part of the maturation process.

Many companies in the growth phase will make a handful of mistakes before they realize that they can’t continue to do things the way they used to. Sometimes, you need the pain of a few mistakes to get everybody across the organization bought into the need for change and to secure a budget for the tools, people, and resources.

For my team and I, the motivation to get involved is selfish because we can spend a lot of time chasing down issues. Some are difficult and expensive to uncover, requiring involvement from multiple teams that include engineering and developers. Refining that approach with the right processes gives our team more time to focus on proactive project work.

What type of culture does an organization need to implement DevOps effectively?

That’s a tricky one. Our issue hasn’t been from a lack of enthusiasm or commitment from the technical teams. Across all different parts of the technical organization, we’re excited about the DevOps implementation work. We have different reasons for why we want it implemented, but they ultimately all land in the same place, which is to remove the manual processes.

So, culturally we’re in a good place and all in pursuit of the same thing. The issue is resourcing DevOps properly and fitting it in with other priorities faced by a growing company. It’s hard to prioritize internal projects against, say, product development or new features, especially when they’re being asked for by customers. You don’t want the customers to feel the pain of outdated internal processes, but sometimes that’s what it takes to get a commitment at all levels to resource internal projects.

How do you get the commitment of senior management to support DevOps projects?

First and foremost, it’s about reiterating the positives. There are probably also problems you can point to, or instances where customers were dissatisfied, that were caused by manual processes. For example, perhaps a deployment wasn’t done correctly. I think having those negative examples is effective because the executive team in an organization is rarely technical. Yet they need to be able to understand the impact of outdated processes to buy into the importance of the investment. Real-world examples help bring the situation to life for non-technical people.

How do you motivate your team to go on this journey with you?

Within my team, there are a few people who have spoken at DevOps events in the past. A few of us are also Friends of Redgate. In many cases, we knew of each other before working on the same team. We all like the team we’re on, know everybody’s background, and know what each of us brings to the team and project. There really was no “bringing them along” at all, as everybody shares the same mindset that we’re going to do this, and here are the people we must work with. Everybody was already on board.

What are the common pitfalls people should watch out for when implementing DevOps?

Unfortunately, we’re not as far along in our journey as we had hoped to be by this stage in the year. That really boils down to the fact that we haven’t been able to get everybody working on it at the same time.

There have been parts of the year when my team has been able to make progress with, for example, doing the SQL Compare work. But at the same time, maybe we would want somebody in development or engineering to set up a lot of Azure DevOps resources. Unfortunately, that request conflicted with other high-priority work they had. To be honest, I would say you need a dedicated project manager who has the authority to clear the space and manage the workstreams.

What parts of the software development lifecycle need to change when introducing DevOps?

It depends on how mature your processes are overall with things like source code management. Everybody starts somewhere different – some companies aren’t checking code into source control at all, for example. We’re way ahead of that and have a lot of the proper processes in place in terms of check out/check-ins and code reviews. If you have that, you’re already part of the way there. But then your deployment processes are what’s most important.

We’re not unique in that it’s a largely manual process, usually completed by a small number of people. This is because it’s intricate work that falls to the really experienced hands who have been there a long time. So, it’s difficult to speak to everything that would need to change, as it’s not a process most of us know well. But you want that deployment knowledge within the broader team and in most places, it’s not.

That would be a good starting point to fix – not getting to the point that everybody can do a deployment from start to finish, but where everybody knows the steps. That will help everybody start thinking the right way. You need to have the basic, prerequisite processes in place first and have everybody on board. Otherwise, you’ll have people in siloes, which will create inefficiencies. That’s what we found, which is one of the reasons we’re not as far along as we’d like to be.

Was there a build vs buy discussion at the start of the process?

At the outset, we knew Redgate makes the best-of-breed tools for this. We decided right away to buy them and knew that would help us. Our team will mesh in the home-built bits we have and make that part of the process. But plugging that in with cloud migration for most of our platform creates a lot of moving parts. I wouldn’t recommend doing everything on top of each other, which is the way we’ve tried.

But with that said, it wasn’t a build vs buy discussion. We’re not going to build anything else and buy the tools we know that work. We have people internally, and new people joining, who knew the Redgate tools were good and have experience using them. We knew we wanted to buy them and everyone was happy with that approach.

Who is managing the process internally, in lieu of a dedicated project manager?

One of the problems we’ve had is that it’s been a bit like a director-level game of hot potato. While my team had some capacity, I was managing it for a while. But I don’t have eyes over all parts of the process. And when we had other competing priorities, it was managed by someone else. While they initially had some capacity, when other pressures came up, they would have to hand it off to the next person. It’s like a sports team going through a season with multiple managers, which isn’t good because you’re naturally losing efficiencies.

What does DevOps success look like to you and your team for this project, and what does DevOps success look like to senior management?

It’s not like we’ll have a scoreboard where suddenly, we can say we got this much faster. But we’ll start to see progress in things such as releases going out the door faster. The people putting them together are spending less time chasing their tails for errors that the releases had or misconfigurations. We’ll probably be able to compare six-month periods vs the same six months the prior year. This will help us see we were much more productive, we saved time, and this is why.

If you’d like to know more about how modern organizations are introducing DevOps, read another post from this series of conversations with DevOps Thought Leaders: Why DevOps needs a change from a ‘me’ to a ‘we’ mindset

To find out more about how organizations can embrace DevOps and deliver value quicker while keeping data safe, visit our DevOps solutions pages.