DevOps Isn't a Job

What is DevOps?

You can find endless amounts of books on the topic and endless blogs. Smarter people than me have written mountains of content on it - and I won't presume to rehash the multiple, conflicting definitions stated. Rather, I'd like to focus a moment on the concept of DevOps.

Development Operations, DevOps, is when you enable your development team to also do operations. In the 90s and into the 2000s, this was impossible - a developer couldn't possibly be able to also know how networking worked and how to update your Cisco controller, walk over to your data center and shove some new hardware in, get the firewalls up and running, setup telnet and ssh, compile and deploy your Linux image, and then deploy your Java application. It was a lot and automation was not nearly there.

Today, however, we have it. Whether you use the industry titan of Terraform, your cloud specific version like AWS CloudFormation or Azure Resource Manager or any of the other many Infrastructure as Code tools, you can suddenly find that your networking is defined and deployed, your hardware requestes are (nearly) instantly filled, your firewalls are precisely defined, your imaged machine is ready, and your app can deploy - all with fewer lines of code than that first Tic-Tac-Toe Java program you wrote back in high school (or college if, like me, you didn't learn Java until you had to).

What does this mean? It means that your developers no longer need to wait for another team to do things, they can just build their own request, deploy it, and manage it. No longer do you need to submit a ticket to the network team for minor changes, you can instead write the code, open a pull request, and let the automation do what it needs to do. All from someone whose title is Engineer, Developer, or something similar.

So, what does a "DevOps Engineer" do?

The Rise of the DevOps Job

Originally, when I first encountered DevOps Engineering as a practice, I thought it to be a necessary thing - after all, CloudFormation is practically a language of its own (to fellow esolang nerds: it is not but work with me here). I have a lot of experience with Cloud and sometimes a developer has no idea what the difference between a Security Group, a NACL, and a Transit Gateway in AWS are. That's why you bring in a DevOps Engineer - to help smooth that for your Development teams.

I've worn this title and it became surreal compared to the time before DevOps. It got to the point that a Developer actually created a card on a Kanban for me to open an SSH port on a VPC. I remember looking at this card and realizing that this was the very thing that DevOps was meant to overcome. Why did the developer not go open a pull request on the code that built the infrastructure themselves? Why were they waiting the half-day (as they were across the globe) for these 3 lines to be written in? Wasn't this the very thing we wanted to solve with DevOps was not waiting on another human?

I made the change and opened the PR before I finished my glass of tea and there it was, a story ready to test and commit. The engineer that opened it was already offline for the day, as expected, so they wouldn't get the 7 minute change notified as complete until long after I signed off for the day. Which mean this 7 minute change took roughly 24 hours to get back to the person who needed it. The exact opposite of the DevOps idea.

Another colleague of mine, with the title of DevOps Engineer, simply wrote deployment pipelines. Are deployment pipelines a little tricky? Absolutely - I will stand on the hill that the scripting language that Jenkins uses, called Groovy, was the scripting language no one asked for. Should someone try to write these from scratch? Absolutely not, copy, use templates, don't just open your IDE and hope (after all, hope is not a strategy). Gitlab, my personal favorite CI/CD tool, uses yaml which has a ton of its own learning curves. But they hired someone just to try to write something developers use to deploy something - not necessary how to do operations.

Today, I jumped on LinkedIn and searched for "DevOps Engineer" and found 46,615 posts. Granted, not all of these are a DevOps Engineer as LinkedIn tries to be "helpful" with similar jobs, but that means there are likely 40,000 open jobs for a DevOps Engineer. Yet, as I pick through these, they rarely define DevOps Engineer - more of tasks they will do. However, DevOps Engineer is something that also is in demand by potential employees too and for good reason - Levels has most DevOps Engineers clearing 100,000/yr and reaching over 250,000/yr and Salary.com puts the most entry level at an average of $76,000/yr and a DevOps Engineer II at $100,000/yr. That's not trivial amounts of money for sure!

So, how did the DevOps job rise? A lack of clarity. What I've done in the role and what other contemporaries of mine have done in the role could be called things such as "Site Reliability Engineering", "Engineering Enablement", or "Developer Experience" which are more defined. But the term DevOps really took stride in about 2016 according to Google Trends - and it is used in a few named things today, like Azure's CI/CD tool Azure DevOps (which is the evolution of Virtual Studio Team Services). However, the term as defined needed someone to execute on it and the whole mindset was missed - not an uncommon things with buzzwords, such as agile.

What should we do?

Teach DevOps as it is intended - to enable developers to do their own operational activities. This is not easy, it means developers have to use new skills they've never touched before, learn a new language (esolangs: I'm still sorry), and keep up on various trends and changes in yet something else. However, after this training and learning and mentorship, speed becomes apparent. I've gotten to work with organizations that have the mindset without the title and they can move quickly. "Modernizing" some developers can be a bit of a challenge and that's all part of growing as a developer or engineer.

How do I learn DevOps if not as a DevOps Engineer?

If you're looking at learning DevOps, I encourage you to consider learning some of the Infrastructure-as-Code type services above, or perhaps Gitlab's CI/CD tools (especially pipelines), GitHub Actions, or Jenkins. Finding ways to automate and control your destiny as a developer is one of the most important things you can do to really embrace the DevOps mindset.

I recently got to play an excellent game of Twilight Imperium (the picture) above and it reminded me that not everyone has the same abilities, even for the same goal. I played a faction that didn't get to evolve new technology, another had ships that moved really fast, yet another that could grow new technology in a very different way - but we still were competing to win. The game was literally a 1 point win - everyone was at 9 when the winner hit 10. I feel we all played our factions well and the game was likely one of the best games of Twilight Imperium I've ever played.

What does that have to do with DevOps? It has more to do with learning - strength before weakness, specifically. There's no one who can master every DevOps technique with simply books and Udemy courses, you must do DevOps to learn it. You can, if you want, start with the hardest part to you and work backwards - if you lack networking knowledge, maybe you start with NACLs and firewalls, if you believe JSON superior to YAML, maybe you go after Gitlab Pipelines first, if you hate questionable scripting languages, you go rock some Jenkins. However, in mentoring and training others, I've found it easiest to start with the things they know best and work towards those other pieces as you need them. If you're an application developer, the idea of a server may be an easier thing, so you write a script that deploys a server to AWS. Then you look at it and want to block some traffic, and write a script that does that. Applying your strengths before your weaknesses is critical to growing and there's a massive amount of things to learn in DevOps.

If you want more ideas on how to go forward, feel free to reach out to me and I am glad to point you in the directions of things I know and resources or ask my network of people if you need something specific (like Pulumi or Azure Resource Manager).