DevOps: as you make your bed so you must lie in it.
I wholeheartedly agree that DevOps should not be a role. However, the current reality is that IT IS a role.
During a DORA community meeting (dora.community), the recurring question, "Is DevOps a role?" surfaced once again. My daughters are peacefully asleep so I've decided to delve into this topic.
Over the past seven years, I've dedicated five years to leading a "DevOps" team, and for the last year, I've served as the Head of DevOps and Platform Engineering.
Before embarking on my DevOps journey, I thought of myself as a Software Engineer, passionate about problem-solving, irrespective of the technology or stack involved.
I found joy in transitioning from frontend (backbone.js/Angular/ReactJS) to backend (Ruby on Rails, Django, NodeJs), tooling (Jenkins/Sentry.io/ Rabbitmq), and infrastructure (from Xen machines on Dell servers in remote data centers to AWS infrastructure using Chef/Puppet/Ansible, etc.).
Yet, even if I called myself a Software Engineer, I was a Backend Software Engineer when working in the backend, Fronted Software Engineer when working in the frontend, and a mythological full-stack when working on both.
Somehow though my role's definition became ambiguous when I started working on tooling and infrastructure. Suddenly, I was no longer a Software Engineer but a DevOps.
In 2016, when I began leading a team of DevOps Engineers, it became increasingly apparent that the traditional Frontend and Backend Engineer roles didn't exist in this realm. Instead, the term 'DevOps Engineer' became a catch-all phrase.
At this juncture, you might be thinking, "BUT WAIT, WE SAID DEVOPS IS NOT A ROLE!!!"
Allow me to share my perspective on this. I wholeheartedly agree that DevOps should not be a role. However, the current reality is that IT IS a role.
I don't oppose the idea of DevOps being a role because DevOps IS A CULTURE, but primarily because we are doing ourselves a disservice by categorising it as a role.
If we consider Google's definition of DevOps capabilities from a few months ago (though it seems they've removed some), we find:
These further expand into:
Version control, Continuous integration, Deployment automation, Continuous testing, Continuous delivery, Architecture ...,Code maintainability, Working in small batches, Visual management capabilities, Westrum organizational culture.
From the list above, it's clear that the world of DevOps encompasses a wide range of specialisations.
The Roles
What if we took a leaf out of the Software Engineers' book and define roles in DevOps?
Consider this: what if we took a leaf out of the Software Engineers' book and defined roles for ourselves, such as:
Infrastructure Engineers: Specialists in setting up and maintaining infrastructure, whether on-premise or in the cloud.
Site Reliability Engineers (SRE): Professionals focused on ensuring system uptime, resilience, scalability, and performance.
Platform Engineers: Experts in abstracting infrastructure and providing a clear, easy path to production for application teams.
Security Engineers, Cloud Engineers, DevOps Practitioners, and so on...
Defining specific roles will aid in skill development and career progression. It allows us to concentrate on deepening our expertise, attending relevant training, and advancing in our chosen specialty. It's much easier to tick off 5 boxes than 20+.
The hiring process will also benefit from this
Enabling companies to advertise for specific positions and conduct more focused interviews. Professionals can filter out the noise and find roles that better align with their skills.
In Conclusion
As with many aspects in tech, the "right" approach often depends on context. A generalist might suffice for smaller organisations or projects (aka "full-stack"). However, as systems grow in complexity and scale, specialisation becomes not just beneficial but necessary.
We should view DevOps not as a role, but as a philosophy -- a way of working that emphasises collaboration and communication. Within this philosophy, there's ample room for specialised roles that bring deep expertise to their specific domains.
So if you want other to stop using DevOps as a role our task is to work together to define these roles within DevOps. Sounds easy right?
Whom should I talk to to get started with this?
Technical Director, Product and Platforms at Nearform
1 年"Existence is not a predicate" — unless you can tell me that unicorns are also real (at which point I'm fully onboard ?? )
VP of Software Engineering @ The Flyover | Technical Product Management | Engineering Leadership | 7+ yrs in ML & AI
1 年I totally agree! I hired someone to do “DevOps” who was wildly brilliant and told them in the interview when asked “you’re saying in a best case scenario for the team, this role doesn’t exist. So how do I promote out of the role?” And I replied “the goal should be to automate and teach the other engineers how to manage their own IaC, deployments and pipelines. When you do that, you will be promoted.” He promoted in just under 6.5 months. When you’re honest about your goal to automate and distribute knowledge, making that the role’s focal point, you also don’t have to worry about knowledge hoarding. What I will say is that this however; I told the business my goal of automation, and when he was 90 days in role, I started telling the leadership team he was going to do it in half the time I expected getting them ready for an insanely quick promotion. If you can be honest and transparent, it will probably scare the shit out of candidates. He admitted in his first week that he wondered if he had made the right move and contemplated quitting. I’m glad he stuck it out. 9 months after his promotion he became our first, and currently only, voluntary resignation. Stars don’t shine, they burn. I know this now.
Communications Strategist | AI | Open Source & InnerSource | Executive Coach & Advisor | Change Agent
1 年Insightful. Have you heard of InnerSource?
“Fractional CxO | SaaS & AI/ML Expert | Enterprise Sales Leader & Product-Market Fit Advisor | Entrepreneur & Business Angel in DeepTech
1 年Specialisation will always come back packed with scaling, so especially the hyperscalers' but even any average business' compute resource demand is such that the hyped word DevOps will become a role name, which is an oxymoron! ?? what can one do? Sure , somehow personally engage in daily fight against the windmills, at least in one's own nearby zone. Maybe ww should notice that in some areas DevSecOps has emerged as a process name competing into the same labelling weirdness...
London Observability Engineering Meetup Organizer | Helping developers and on-call teams cut through production noise to effortlessly catch & fix business-critical application issues. ?? Sign up for our Beta @ Kerno.io
1 年Spot on Luca! Every time someone asks on Reddit "What should I learn to become a DevOps engineer?" answers are all over the place. It seems like every few months or so the definition gets broader ??