In my position I am not an Operator, though I do operations; I am not an an Administrator, though I do administration; I am not a Developer, though I do write code.
I am not an Architect, I am an Engineer.
I don't engineer software, hardware, or physical machines. I engineer systems. Systems of interrelated hardware, software, tools and people. I can't abstract my position away from any of these things. Like any good engineer, part of my job is getting my hands dirty working with those systems.
I am a Systems Engineer and the title is very appropriate. If things fail, I do bear a higher burden of responsibility than many others, but certainly not always the only responsibility.
Back in the before times that role was 'Systems Analyst' it can be very fulfilling but it takes a special person to be good at it. I try to keep track of systems people I meet over time, good ones are rare.
If DevOps fails, it should be a failure of the entire company. and The reality is that DevOps is a culture that should be accepted by every facet of your organization
How is it a failure of the payroll officer, the loading dock crew, the counter staff, the cleaners? (Or relevant departments). DevOps failed because the receptionists weren't buying in? Us techies get the blinkers on and think that it's only us that are important to keeping the company rolling. Finance people often suffer the same delusion.
Either I'm missing something, or the author and I have wildly different definitions of 'devops'.
As the owner of a startup DevOps consultancy, I'm also extremely tired of the "DevOps is not a job title" meme.
If you work on configuration management, cloud automation, monitoring, deployment automation, continuous delivery, infrastructure agility then it's an extremely adept label for what you do. This work is at the intersection of development and operations and empowers both sides to deliver business value better.
Likewise, if you work as a higher level change agent, breaking down dev/ops siloes, removing bureaucracy, empowering people to deliver, refocusing dev/ops on business delivery etc etc then DevOps is also a really nice badge to describe what you do.
If you cover both of these then you are squarely at the root of the DevOps philosophy. Wear that title with a badge of honour because it's tricky but extremely valuable if you can carry it off.
From the article: When you are the Head of DevOps, you “Own” DevOps. If DevOps fails it is your failure, when it should be a failure of the entire company to change, adapt, and accept the cultural shift.
If you are the director of DevOps then it is your job to influence and deliver that cultural and organisational change as well as just running operations. If you do the latter then you've simply given yourself an inappropriate job title. It doesn't mean it's a bad one in other contexts.
Problem I've see is DevOps isn't seen as a specific role encompassing the areas you lay out. Instead a lot of companies are adding it on as a skill set requirement for those doing other aspects of engineering.
To put it simply, devops is a function of a job rather than core to a job for many companies.
"We do devops" means - you write the code and do administration as well. When the required skills sets dont always overlap.
I find it telling that so many people are so irked by the change in the nomenclature of ops. There are many people and businesses who have set their stall out to be transformative agents in operations, moving from old ops to devops.
But the problem is that devops has gone from being aspirational for many to the de facto for many.
It's the post devops world. There is no devops anymore, just ops.
The problem I have with the DevOps label is that it is trying to lump yet another task on the overwhelming heap that is your average system administrator's task list - namely, doing the actual coding and developing of the system you're managing.
In my 20 years of experience, the two roles of developer and admin have had very conflicting purposes in that one is encouraged to change and expand systems, while the other is encouraged to stabilize and reliably maintain. The conflict can only serve to make one role suffer over the other, or provide poor quality results for both.
The SRE title at Google/Facebook was designed specifically to highlight the fact that it's an engineering role, and the goal is to automate all of your routine responsibilities so that everything you do is creative problem-solving. The position within the organization is different from a traditional sysadmin, as well: in many organizations developers throw their programs over the wall to sysadmins and say "Make this work, and deal with any problems that come up", while the SRE/SWE relationship at GooBook is "We'll consult with you on reliable software development practices, and we have the authority to block any changes that have a large probability of taking the site down."
I am not an Architect, I am an Engineer.
I don't engineer software, hardware, or physical machines. I engineer systems. Systems of interrelated hardware, software, tools and people. I can't abstract my position away from any of these things. Like any good engineer, part of my job is getting my hands dirty working with those systems.
I am a Systems Engineer and the title is very appropriate. If things fail, I do bear a higher burden of responsibility than many others, but certainly not always the only responsibility.