How DevOps Engineers can Grow Their Scope Beyond IT Ops
Around the time when the world was moving out of the 2008–2009 recession, the tech industry also found itself at a rather unique crossroads. On the one hand, IT Ops have always been a staple, especially in large corporations. Today, job openings for these roles have mostly been eradicated and replaced by… *drum roll* the DevOps Engineers!
Back in those days, IT Ops specializes in taking away work from Software Engineers so that the latter can focus on software development and the former on software operations. (Hence “Ops”) This is not rocket science. Humans are conditioned to optimize for cognitive load. So untangling software creation from software operation is certainly a good move.
But wait!! A Million Dollar Question has to be asked!
Am I not describing the role of a DevOps Engineer?
If you have seen enough of the IT Industry, this comes as a non-starter. There’s supposed to be some difference, but most companies don’t even differentiate! In other words, it is highly probable that the DevOps Engineers in your company are simply IT Ops Engineers! As Malcolm Muggeridge once said, “All new news is old news happening to new people.” An industry living in perpetual inexperience like IT is bound to give old practices new names thinking they’ve hit the summit of profundity only to find their predecessors sitting at the summit long before they came.¹
What do IT Ops do? Well, to put it simply, back before there was Jenkins and Circle CI, there were already similar tools like CruiseControl. Back in those days there were already Infrastructure as Code solutions similar to Helm Charts and Terraform. These are IT Ops work that now DevOps do. The job titles are different, but the scope is the same.
Yet where do IT Ops and DevOps deviate and why are we still doing old stuff now that we know so much better?
Great question!
Modern DevOps takes into account more verticals that traditional IT Ops, at that time, hasn’t had the knowledge, the know-how, nor the tools to do what we can now do today.
For example, we now know from extensive research that there are four leading indicators for the Director of Engineering to look at to find out whether his team is performing well or not. These are the DORA metrics.
The DevOps Engineer ought to have regular conversations with the Software Engineers to
- Monitor the DORA metrics.
- Develop improvements in tooling and process to improve the metrics.
Not only do most DevOps Engineers not know about the DORA metrics, forget about them thinking about improving development velocity. Interestingly, AWS describes DevOps as “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”
The primary purpose of the DevOps Engineer (or team for that matter) is to ensure that every effort is made to improve development velocity. DevOps Engineers are supposed to be force multipliers. A strong DevOps Engineer should think about how his work can give the company $2 for every $1 it spends. In bigger companies, The DevOps department involves Site Reliability Engineers, Infrastructure Engineers, and Developer Productivity Engineers. In smaller companies where highly available distributed systems is not yet a concern, the DevOps Engineer should be responsible of all these roles.
Speaking of costs, the DevOps Engineer is also to be concerned about monitoring expenditures. I’ve found that many a time, the DevOps Engineers don’t talk with the Software Engineers and Product Managers enough to know what’s on the horizon. Are we prematurely optimizing our infrastructure? Are we overprovisioned? Are we regularly reviewing our usage? Do we still store data we no longer need? Did we validate the product hypothesis post-launch? How do we rightrize our infrastructure to meet current and near term demand?
Come to think of it, is it a surprise then why the margins of Cloud Providers are vast? If the DevOps team don’t regularly do all these, how does the company know if it’s paying too much for something it can pay a fraction of?
The DevOps engineer is also supposed to be the one tying the threads together between Product Operations, Product Management, Software Engineers, and QA Engineers. Think of Full Stack Monitoring solutions like DataDog and New Relic. If all logs can be consolidated in one place such that a T1 Support or a Manual QA Engineer can tell where the issue lies because everyone has full stack visibility on errors, imagine how much communication overhead is saved. The DevOps engineer ought to think about how they can bridge the gap between various departments to improve operational efficacy. Adding visibility and making sure everyone knows how to find their way around helps tremendously in organizational agility.
Again, this is what the industry, in the days of IT Ops, is not mature enough to think through, nor does it have tools to do so. Today, this is widely available and yet to be utilized sufficiently.
In order to drive excellence for DevOps, the question is not as simple as asking what tools to use or how to use them. It’s about how to think about what’s best for business and working your way down into how your function can support that… and yes, we haven’t even touched security yet in this article… but you get the idea!
____
¹ Take for example, Spotify’s Squad Model. This was once called Matrix Organization, invented in the 1950s.
