The Future of DevOps
By Alex Grote
DevOps has steadily evolved in the 15 years or so since it gained prominence. Processes have changed, agile has taken over, and – ultimately – millions of releases have gotten out the door. It’s been a fundamental shift in how software is built.
We know where DevOps has been, evolving from the initial waterfall philosophy. It’s been – as the name suggests – a marriage of development and operations, although at times it’s been a shotgun marriage. It’s been considered the tools we use to make the end product. At NetApp IT, we don’t necessarily disagree with this, we just think it’s more than that.
So, we’ve seen where DevOps has gone. However, where is it going?
What DevOps Should Be
Traditionally, one of the North Star metrics of DevOps has been the number of deployments a team pushes. I’d question that and posit that the frequency of releases is a better measurement of business impact.
By measuring frequency instead of volume, you’re displaying a team’s capacity for delivering against shorter turnaround times. It’s not about just how much you’re doing, it’s about how quickly you’re doing it. It’s a measurement of efficiency.
Ultimately, an effective DevOps team should be:
– Transparent – Don’t work in the silo and advertise the work you’re doing
– Timely – As discussed above, releases should be constant
– Effective – Don’t just deliver code, deliver GOOD code
Doing this creates one of the most valuable things a DevOps team can have: trust. It also enhances the “velocity of innovation”, a term that has gained some level of notoriety over the last few years. It refers to how quickly a program or operation is able to deliver new ideas and solutions that create business value. It’s a focus on creating business value that improves efficiency, and ultimately, the team’s effectiveness.
Multipliers of Intelligence
Organizations are made up of individuals and good organizations are made up of individuals that are empowered to do their best work – and that starts with how we manage. We strive to have “multipliers” as mangers, leaders who want to foster an environment of intelligence and innovation in their organization. Employees that feel smarter, become smarter.
They are also more likely to have a feeling of community and ownership, which leads to better products. Coders that feel they are product owners, not product contributors, are more likely to do their own work. I want our developers to feel like they’re doing really cool stuff and that they’re the reason that it’s cool. We also want to avoid prima donnas that put personal needs over what’s best for the product.
Our Best Answer to “What’s the Best Way to do DevOps”
Our first step is to instill that mentality of product over personal wants. Get your team working together towards a common cause and you’ll go far. Second is to embrace site reliability engineers. SREs live in concert with DevOps to manage fragility – or guide DevOps through deployments. They translate issues to developers and show where issues live, offering unique insights into what issues there are and how to fix them. The two roles are bound by a common goal – deliver a quality product – with SREs being the editor to the writer/developer.
We’ll discuss the evolving responsibilities in an SRE in an upcoming blog.
A successful DevOps team isn’t just coders working with operations. It must have shared buy-in and toss aside siloes to create a holistic organization that builds trust through a steady stream of quality products. This isn’t easy to do and needs to be nourished, but when working correctly, these teams are capable of amazing things.
Alex Grote is a DevOps Architect with NetApp IT.