What is Devops?

Last Updated: February 2026 — Nine years later, the core thesis holds: DevOps isn’t a title, it’s a convergence of skills. But the landscape has shifted. Below the original post, I’ve added a 2026 update on Platform Engineering, AI Operations, and where DevOps is heading.

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. :)

2026 Update: From DevOps to Platform Engineering (and Beyond)

Nine years is a long time in tech. The four paths I outlined above? They’ve converged into something new: Platform Engineering.

What Changed

DevOps became a victim of its own success. Every company wanted “DevOps,” but few understood it as a cultural and operational shift. Instead, they hired “DevOps Engineers” and expected magic. The result: oversized teams, tool sprawl, and developers still waiting weeks for infrastructure.

Platform Engineering emerged as DevOps at scale. Instead of every team reinventing the deployment pipeline, platform teams build golden paths: internal developer platforms that abstract the complexity while preserving flexibility.

The 2026 Landscape

AI Operations: The New Frontier

The biggest shift since 2017 isn’t Platform Engineering? It’s AI Operations. Running LLMs in production introduces new problems:

• Inference cost optimization: GPUs are expensive; wasted tokens are wasted money
• Model versioning: deployments now include weights, not just code
• Prompt engineering at scale: moving from craft to systematic approach
• Data pipeline complexity: training data, fine-tuning, RAG pipelines

The DevOps skillset (automation, troubleshooting, systems thinking) applies directly. But the tools are different, the failure modes are different, and the stakes are higher.

What Hasn’t Changed

Despite all the new terminology, some truths remain:

• Pragmatism beats dogma. Platform Engineering isn’t a religion; it’s a response to organizational complexity. If your team is small, you probably don’t need a platform team.
• Tooling is secondary. The best CI/CD pipeline in the world won’t fix broken communication between teams.
• Someone still needs to wake up at 3 AM. Whether it’s a Kubernetes node or nvidia plugin getting into a CrashLoop, the pager doesn’t care about your job title.

Where We’re Going

DevOps as a term may fade, replaced by Platform Engineering, SRE, or AI Infrastructure. But the underlying need, someone who understands the full stack, automates ruthlessly, and keeps systems running, isn’t going anywhere.

The “DevOps Engineer” of 2026 is likely a “Platform Engineer” with Kubernetes expertise, SRE with a focus on reliability engineering, or AI Infrastructure Engineer optimizing inference pipelines. The paths have evolved, but the destination is the same: reduce risk, reduce toil, reduce time-to-recover.