ileezhun - Fotolia
Looking for something else?
There are few names in DevOps as big as Gary Gruver. He's an experienced software executive with a knack for implementing continuous release and deployment pipelines in large organizations. In fact, he literally wrote the book on the subject. His latest, Starting and Scaling DevOps in the Enterprise,'is an insightful and easy-to-read guide that breaks down DevOps principles by putting them all in a context enterprises can use to gain alignment on their journey to continuous delivery.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Gruver, president of Gruver Consulting, sat down with DevOpsAgenda to discuss the DevOps maturity model, core DevOps maturity principles, and how small and large organizations must take different paths on their DevOps journey.
What's your take on the DevOps maturity model? Can that stymie DevOps adoption in large organizations?
Gary Gruver: A lot of people come out with these maturity models and say, 'We had some success in DevOps, and now everybody has to do what we did.'
Gary Gruverpresident at Gruver Consulting
And what I find when I go into different organizations, or even looking at different deployment pipelines within organizations, [is] that the things impacting productivity are fundamentally different. You look at a DevOps maturity model and it might claim, 'You need to have Infrastructure as code, automated deployment, test automation, and this and that.' I think that overlooks the actual problem each different deployment pipeline might have.
This is about organizational change management, and it's about getting people to work in different ways. If you don't start with the changes that are going to benefit people the most, you're going to lose the momentum in your transformation.
Therefore, I think it's important to start with DevOps principles so people can pick the changes that'll make the biggest difference to them, so they will take ownership for implementing the changes into their organization.
How does scale affect success in DevOps?
Gruver: If you're a small team and you have four or five developers, then DevOps is about just getting people to embrace and take ownership of code all the way out to the customer. It's making sure the code is meeting the needs of customers and stable in production. Then, it's responding to that feedback and taking ownership. It's a lot about helping these developers become generalists and understanding the operations piece of this puzzle.
But if you have a tightly coupled system that requires thousands of people working together, then there aren't that many people who are going to know the whole system and be able to support it in production. In these situations, someone needs to be responsible for designing how these complex systems come together and continually improve the process. It is going to require more specialists, because it is hard for everyone to understand the complexities of these large systems. The ways you coordinate five people are a lot different than coordinating a thousand.
What are some of these difficulties applying DevOps practices from small- to large-scale organizations?
Gruver: What I hear a lot of people in large organizations do with DevOps is they look at what the small teams are doing, and they try to replicate that. They try to reproduce and figure out how to make the small-team strategy work in a tightly coupled system, instead of really looking at the issues blocking them from releasing on a more frequent basis.
They're not asking, 'What are the ways we can address this waste and inefficiency and take it out of the system so we can release more frequently?' They figure if they just do what the small teams are doing and try to replicate that and create a DevOps maturity model, by some magic, they're going to be successful. Instead of doing that, they should focus on principles to figure out what's going on in their system.
Large organizations should break it down as small as you possibly can, because smaller things are much easier to solve, maintain and manage. So, if you can break your system down into microservices and make that work, those teams are always going to be more efficient. That said, rearchitecting a large, tightly coupled system can be extremely complex and time-consuming, so it is typically not my first choice.
Additionally, there are a lot of DevOps practices that can be successfully implemented in large, tightly coupled systems. In fact, I would argue that applying DevOps principles in these complex systems will provide much greater benefits to the organization just because the inefficiencies associated with coordinating the work across large groups is so much more pronounced than it is with small teams.
To build or buy? That's the DevOps toolchain question.
The three types of DevOps work: feedback, triage and automation.
It's easier to train essential DevOps skills than to hire them.