Home

Enough Already!

Too many non-DevOps talking heads have been chiming in and giving their 2 cents on what exactly DevOps is or isn’t. Let’s get something straight: I don’t consider DevOps as an official title or role. DevOps is a culmination of skills and talents in a singular embodiment; a channel to getting sh!t done. The only reason why us “DevOps” Engineers use or tolerate the term to label what we do simply because it is the easiest way to obtain universal head nods from the people in the room.

DevOps is like a mixed bag of job functionalities with everything and anything that the tech industry has not properly categorized and of which including roles that are inching towards the way of the dinosaurs. These include:

• Build Engineers (Continuous Integration)
• Release Engineers
• Software Configuration Management Engineers
• Deployment Engineers (Continuous Deployment/Delivery)
• Infrastructure Engineers
• Systems Engineers
• Operations Engineers
• Tools Engineers
• Automation Engineers
• Cloud Engineers

Honorable mentions:

• [Linux] Systems Administrators
• Network Operations Center Engineers (NOC)
• Site Reliability Engineers (SRE)

There are probably a few more that I may have missed, but I’d like to believe that’s as complete of a list, under the DevOps umbrella, as it can get.

Through my years in this field, I still have not seen any two DevOps Engineers with the exact same skill set and experience. There is usually a foundation – call this the bread and butter. Traditionally, this baseline has been Build & Release Engineering. Before I go any further I’ll need to digress a bit and define the attributes of a typical DevOps Engineer.

Attributes of a DevOps Engineer

• Highly efficient at automation
• Excellent troubleshooter and debugger (systems, networking, code, etc)
• Uber Multi-tasker
• Ability to function in hyper interrupt mode
• Avoids meetings like the plague
• Swiss army knife in knowledge pertaining to all things systems, networking, infrastructure, etc.
• Generally poor at documentation
• Can have periods of burn-outs
• Can have periods of super productivity
• Can have periods of genius level work
• Generally pragmatic
• Enforcer in processes/procedures/security
• Keeper of the “With great powers comes great responsibilities” mantra
• Generally can code
• Generally does not enjoy coding for prolonged periods; just enough for a proof-of-concept work or automate a piece of functionality
• An entire day can be spent on just one stubborn [system/tool/infra] issue – This is why some DevOps Engineers are such grumps. Like yours truly. :)
• Adventurous in the implementation of bleeding edge tools and platforms
• Agent or catalyst for change [read: growth]
• plus many more that I may have missed …

** Note: Not all DevOps Engineers possess ALL of the above attributes

Typical Evolution of a DevOps Engineer

With the above list of attributes, we can now proceed with defining the evolution of DevOps.

Path 1 (Foundation: Build and Release Engineers)

This path illustrates how a more CI/CD/Tools centric DevOps came to be.

• Most likely he/she started out as a Build & Release Engineer.
• He/she got so good at automating him/herself out of the job that boredom soon kicks in.
• He/she start to branch out and learn new subjects or take on additional responsibilities. (Unfortunately, some also choose to be complacent and get left behind by the industry. There are still a few dinosaurs out there roaming who has zero knowledge of containers.)
• New responsibilities typically include improving deployment (CD), develop custom tooling (Tools and Installer Engineering), improve scalability and resiliency of the service/app (Systems and Infrastructure Engineering).
• Natural progression into all things CI/CD/cloud based DevOps

Path 2 (Foundation: Developers)

This path results in a more development centric DevOps Engineer due to the origin.

• Most likely he/she started out as a coder but due to certain circumstances within the company (lack of resource, etc) started to implement CI/CD out of necessity
• He/she most likely excelled in this and even developed an affinity for it and started to shift their daily functionalities into the Ops area
• Natural progression into Dev+Ops.

Path 3 (Foundation: System Administrators and/or Operations Engineers)

This path lists the evolutionary steps of how a systems and infrastructure centric DevOps came to be.

• He/she started out as an IT or Ops specialist or similar role
• He/she got roped into NOC/Infrastructure and eventually deployment work at one point
• He/she enjoyed it and started making plans to pivot towards the deployment/infrastructure functionalities
• Natural progression into infrastructure+operations centric DevOps

Path 4 (Foundation: A New Role – e.g., Google’s SRE)

This path isn’t really evolutionary by any means but more of a mis-labeling by recruiters/managers.

• He/she was part of an entirely new category/role created by a giant in the tech field
• Gifted developers with a knack for custom operational tooling
• He/she was a new species with a special classification. Somewhere along the line SRE got pushed into a subset of DevOps.
• Due to the above fact, they’ve become true pioneers in pushing DevOps forward with excellent open source tools

The convergence of these four paths is what we came to know today as DevOps. As you can clearly see, DevOps has too much under its umbrella to be considered a role or designated as an official job title. Help me spread the words to make this general knowledge so we can stop the debate of what DevOps truly is. It’s a long shot, but I’m a pragmatist and optimist. :)