This blogpost is meant to initiate a conversation about DevOps Engineers and the value they bring with their automations

image

Early in my career, a senior developer challenged me with a question: “Isn’t DevOps just glorified support?”

As a recent graduate facing a sea of unfamiliar acronyms and complex automation processes, it felt like a jab. I wondered why building layers upon layers of automation seemed so important, and what real impact it had.

Instead of accepting his statement at face value or getting defensive, I decided to take a different approach. Afterall this wasn’t just a random job I fell into; it was a conscious choice based on what I like to do and what skills I had. But before I could convince anyone else about the value of my work, I needed answers for myself.

So began my personal journey to understand not just the mechanics of DevOps, but the deeper purpose that went beyond lines of code and scripts.

Fast forward a few years, and I have a much clearer perspective than that bewildered graduate. In this post, I’ll share what I’ve learned, not just to debunk the “glorified support” myth, but to reveal the transformative power of DevOps.

A Subjective definition

Enough has been said and written about DevOps by the experts over the years, and yet it is not possible to bind DevOps into a static definition. The reason why DevOps is so hard to define, boils down to “people are different”. People make teams, teams constitute an organisation and decide what tools they would use, what procedures they may follow, what standards they must hold etc. The variance in what DevOps means for different organisations hence makes binding DevOps into a genral definition very difficult.

Its not that people have not tried. Just look at how Google talks about their way of DevOps that they have evangelised as Site Reliability Engineering. Its how a certain organisation “Google” happens to run their business and systems. They define their standards in objectives (SLOs) and they decide their own metrics (SLIs) to enforce adherence to their standards. Now, many other organisations have emulated or tried to emulate this approach to DevOps and ended up with their own versions of SRE that can be at times completely different from what Google or any other organisation for that matter, may see their SRE as.

Then there is Platform Engineering, that abstracts away the infrastructre and lets people do what they are best at doing. So Devs can focus on building their applications, testing it and deploying it in a reliable way, while Platform Engineers making sure that the systems are resilient enough to handle the volume of changes required. But even the way that Platform engineering is implemented at different organisations is quite distinct.

In esssence you may find that even seemingly the most well defined and published implementations of DevOps, may have so many different versions. Its safe to say that even trying to define DevOps in terms of “what it containes” is futile. So instead, let me try to define DevOps in terms of its impact on an organisation. Essentialy, I’d define DevOps as an organisational firmware that does the following things:

  • Improves the flow of work/changes by standardising and automating processes, improving the visibility of factors affecting the work and promoting collaboration and mutual understanding by sharing knowledge and responsibilities.
  • Identifies and collects key metrics and feedback that is critical to business, and integrates it into the development process.
  • Embraces the chaos of change by expecting failures and continuosly learning from failures.

The above definition is a tradeoff between an exact definition, and a definition covering most if not all aspects of DevOps, in the favour of the latter. It is influcend by popular DevOps literature like The Pheonix Project, SRE Handbook and my own experiences of working with different teams and orgs.

So, what does it means to be a DevOps Engineer?

Since I defined DevOps in terms of its impact and outcomes, I’d say a DevOps Engineer is a professional who champions the changes that are needed to bring these outcomes. In bigger teams and orgs, this might becomcome blurred, since the responsibilities for implementing DevOps are greately distributed between different stakeholders like scrum masters, product owners, project managers, leads etc. This is actually the evidence that DevOps is quite mature now and needs less evangelising and more implementation within most orgs. Even without knowing what is the impact of your work as a DevOps Engineer, you might be able to contribute towards the DevOps goals of your team and org.

However, only by knowing what DevOps stands for, can one truly see the impact and see if there is deviation and take corrective measures. You maybe writing and maintaining deployment pipelines, IaC, automation scipts or setting up monitoring, provisioning cloud resources using n umber of custom, open source tools, but in the end, how it impacts the business is what derrives the value of your work.

I hope I was able to give a new perspective to how you see DevOps. Feel free to reach out if you want to talk more about this or anything else in tech.