Here’s what DevOps isn’t

This article focuses on clarifying certain misconceptions that revolve around DevOps. However, considering the fact that there might be readers in the audience not aware of what DevOps actually translates to- as a definition, I’m going to shamelessly copy WikiPedia’s definition of the term “DevOps” and try to dance around it in a really intellectual way. The definition reads as follows:

DevOps (a clipped compound of “development” and “operations”) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives

Tbh (where “h” is short for “honest”), DevOps is a continuous process of improvement- which is what makes it interesting and worth pursuing. From a design background, when I first jumped into programming and development (back then, all “development” for me was re-writing Android kernels and cherry-picking commits from established skins or “ROMs”) I found myself in a worn-out state. However, DevOps captured my interest- it’s a never-ending process of betterment.

Now that we’re familiar with what DevOps really is, let’s focus on the subject this article’s title shines the spotlight on- what DevOps isn’t. There are a lot of misconceptions surrounding DevOps and really, I’d fallen for a lot of those “misconceptions” as well- until an actual DevOps engineer cleared them out for me.

Misconception One- All one needs to do to call themselves a proficient #DevOps engineer is learn a bunch of tools

No. DevOps is not just the discipline of learning “a set of tools.” It’s a lot more than that. Certainly, one mustn’t ignore all said “tools” like Docker, Jenkins and Ansible (all three of which are Open-Source) at any cost- one must also have proficiency in them. DevOps engineers are basically “the folks who take the code that the dev team writes and enables it to be run reliably on servers in a production grade environment.”

In addition to being familiar with the tools, one must also be if not proficient in, familiar with programming languages like Ruby, Python, Go, Javascript and C++.

Misconception Two- “Our company does DevOps. We use Jenkins to automatically deploy!”

Before jumping into the #DevOps “scene,” all I used to do was create websites. That’s literally it. As soon as I used to have a new idea, I’d create a website for it- which made everything seem a little more “official” and which made my GitHub graph a little greener.

I feel like I side-tracked a bit there. However, the point being- there’s this tool called “Netlify” that helps developers serve websites they create websites using their favourite programming (I know) languages like HTML and CSS and (okay, even Javascript at times) by binding GitHub, GitLab or BitBucked repositories to the service.

Apart from the fact that one can attach a domain to Netlify for free and the service imparts an automatic (and free) SSL certificate to the domain, the fact that Netlify automatically triggers a new deploy as soon as a change is merged at the repository, is what makes it truly beautiful.

However, as a developer who has a certain website deployed onto the Interwebs using Netlify, I am in no place to say that I “did DevOps” or “indulge into DevOps to deploy the site.” Just no.

Misconception Three- DevOps isn’t only automation

Although automation is a large part of DevOps, we just can’t equate the entirety of DevOps with automation. There’s a lot more that goes on when it comes to DevOps- no doubt, again, automation is a necessary and “key” part of it.

Imagine, you’re standing before an Auditorium full of audience, people who are well-versed in the subject you’re delivering a talk about and one of your colleagues blurts the term “DevOps” out. Imagine, all you’ve ever done is make websites using Netlify. At this point, (thanks to repetition and clear directions) you know that the subject here is me and the colleague of mine just said “DevOps” to “sound cool and more experienced.”

Imagine you’re in that situation and an actual DevOps engineer questions our usage of the term. Although my colleague handled the (extremely awkward) situation with immense confidence, he did inaccurately state that DevOps was nothing but automation and things as simple as having an automated deploy can help one call themselves a real “DevOps Engineer.”

Concluding

Concluding, hope this DevOps Roadmap created by Kamran Ahmed helps you as much as it helped me. There are dedicated roadmaps for Front-End and Back-End as well, you might want to check those out as well. To know how real-life DevOps Engineers actually work, you might want to read Harvey Johal article on the Onfido Tech blog.

PS- Feel free to suggest improvements to the way I articulate facts and publish ☺

Originally published at punyavashist.com on May 10, 2018.