
The Mythical DevOps Engineer - rbanffy
https://alediaferia.com/2020/07/27/the-mythical-devops-engineer/
======
jcrawfordor
While I officially have the title of DevOps Engineer, I virtually always
introduce myself as only as Engineer---not in the least because part of my job
is interacting with clients and I'm not excited to explain to them what DevOps
means. I have a somewhat unusual background in that I came to DevOps from a
background in traditional systems administration (e.g. Windows MSP, network
engineering, Linux sysadmin), and a later career background in security. As a
result I tend towards old-school. For flavor, I once held a title in
"Compilation Engineering," not meaning engineering the compilers, but managing
the clusters that ran them. My concerns tend to be radically different from
those with a software engineering background, even within a "DevOps team". I
have occasionally said that there are many "DEVops," a few "devOPS," and
almost nothing in between.

I think there's some good content in this article but also a certain amount
of, I'm not sure what to call it. Inexperience?

I can agree that in an ideal world having people with the title of DevOps
Engineer or especially a DevOps team is an antipattern. However, in most
organizations I have worked in there has been a clear need to hire people
specifically for DevOps and a good component of the work has been, at least
initially, limited to those individuals. The basic reason is that most
software engineers, even very experienced ones, are generally quite weak in
the areas of operations, network engineering, conventional system
administration, and compliance. I don't necessarily blame them as these are
areas that are addressed poorly or not at all in most academic programs, and
are not generally viewed as skills which are behooving of a software engineer.
The result is that individuals need to be hired specifically for DevOps roles
in order to get that skillset.

Further, except in perhaps some of the most fortunate startups, DevOps is
virtually always transformational---that is, it is being put in place to
either replace a previous process (e.g. development in one division and
operations in another) or to create process for the first time (e.g. a startup
which has had testing and deployments done manually by developers). This is
another factor that makes designed DevOps contributors valuable, because the
bottom line is that DevOps needs to be forced on the organization to some
extent. It can often take an outsider to drive significant change in business
processes.

Finally, as much as DevOps is bandied about, I am not convinced that most
_developers_ are actually interested in working in an "ideal" DevOps
environment. I have spent most of my career as an IT person supporting
developers, whether that was called DevOps or just being the person in IT the
developers emailed. In most of these roles I have done a lot of things that
the developers just weren't willing to, and even as a "DevOps Engineer" I
continue to view "keeping out of the developer's way" as a primary goal. This
means, for example, that I usually handle most of the tool development around
local (developer workstation) and automated build and test because the
developers just don't want to---ironically, in the eyes of many developers, I
think DevOps means the developers being as uninvolved in operations as
possible.

They're turning to DevOps because they want to get rid of the workload
associated with herding a traditional IT organization, not because they want
to do it all themselves! I don't really blame them either as, as I said, not
many developers really have the skillset to excel with this kind of thing, nor
(and this is more opinion) the inclination to obtain that skillset. There just
aren't that many people out there who care about getting the Kubernetes
cluster to self-heal right or finding the weird performance/stability problem
in the software-defined network, which is why DevOps tends to be split-brained
between "automating operations" and "paying someone else so we don't have to
think about it," which is the general goal to which most cloud providers
aspire.

Ultimately, the goal of all DevOps organizations ought to be to eliminate
themselves by getting things to be so painless and automated that developers
will do it all themselves. But basically no organization signs up for DevOps
with the idea that they are adding workload to the developers, and so at least
initially a dedicated DevOps capacity needs to exist from a practical
perspective. The issues of skillset and desired work characteristics mean that
that capacity tends to stick around. As much as DevOps is bandied about as two
great tastes that taste great together, the reality may very well be that all
DevOps really means is getting the IT resources and the development resources
to talk to each other more often and do enough cross-training to be able to
understand the other's problems, and honestly I think that's fine.

But then I say that as someone who intentionally does not describe myself as a
software engineer because I frankly don't enjoy writing software that much...
and yet part of my job always ends up being troubleshooting the product,
adding tracing and monitoring integrations, etc. I can't complain too much
because I do need the familiarity with the code base to be able to address
developer requests well. Similarly, the developers need the familiarity with
my work to be able to understand how it impacts them and how to engineer for
effective deployment and management, but I wouldn't wish my configuration
management and network diagrams on them.

Or I could sum up the entire thing more shortly: DevOps as an ideal is founded
on the concept that there exists a set of people who want to be evenly
responsible for both the development _and_ the operations. I have not so far
met more than one or two of these people, certainly not enough to staff a
company with. Barring such miraculous hiring, viewing DevOps as getting your
development people and operations people to work effectively together is just
fine.

------
leokennis
Wasn’t the idea of DevOps to put Dev and Ops engineers (two distinct roles) in
one team?

So instead of the Dev team working on code and testing it, and then throwing
it over a silo wal to the Ops team to run it in production, now they
collaborated from the start to in the end ship good quality code?

When was it decided this meant one person had to know two jobs?

~~~
pjmlp
When HR decided that it was the same thing as a systems engineer.

Just like one needs to take care with architecture roles, because for lots of
companies it is just project management with another name.

~~~
icedchai
I applied for an architecture role once. It sounded interesting in email. Once
I got to the phone screen part, they gave me a huge sales pitch, then told me
I'd be working in Word and Powerpoint all day. "This is not a hands on
position."

Uh, no thanks. That's not architecture.

------
Aperocky
I work in a large cloud provider.

> Are they hiring for a single role or a whole team?

YES.

That's right, while the teams might have different responsibilities, but some
remain constant. like provisioning infrastructure, going oncall and solving
tickets, writing your actual software and think about and design the next
iteration.

The expectation for team members is that one should be able to do all that,
not at once obviously, but when needed will rise to the task.

------
busrf
This is a great article. It is really sad how "DevOps" has become just another
way to label the Ops team, or the developer tools team, or the release
managers, without trying to break any silos between the teams...

------
drewcoo
Get good enough at any role and the expectations should and will be broad.
That would be the "crossing" part of "crossing the T." Why exactly does this
article keep saying "DevOps?"

