
You can't just rename your IT Ops team and call it DevOps - gk1
https://www.datree.io/resources/devops-definition
======
systematical
How is such a thin article upvoted? That was basically a verbose tweet.

~~~
insomniacity
Because really you're supposed to click the link in the article and listen to
the interview.

~~~
jessaustin
If TFA contained a transcript it might have been worth an upvote...

~~~
neonate
Looks like there's a transcript here:
[https://softwareengineeringdaily.com/wp-
content/uploads/2019...](https://softwareengineeringdaily.com/wp-
content/uploads/2019/02/SED771-Datree.pdf)

~~~
l0b0
Can we replace the original link with either this or the audio?

------
caymanjim
DevOps is a horribly misapplied term. I recently referred to a client systems
administrator as a "sysadmin", because they were doing sysadmin things:
provisioning and configuring production hardware, networking, backups,
databases, etc. I was chastised by the [much-younger-than-I] CTO, who said he
"hadn't heard the term sysadmin in 20 years" and that they were the DevOps
team.

No, sorry. They were sysadmins. DevOps is valuable role, and I'm glad there's
a focus on supporting developers and their needs, and in empowering developers
to manage their own build and deployment infrastructure. In a larger
organization, having a dedicated person or team working closely with
developers on software build, test, and deployment automation is great.

But if your job is maintaining production hardware, network, operating system,
DNS, SSL certificates, firewalls, backups, etc., then you're a sysadmin. It's
not a pejorative term. In a small organization, or within a team, that may be
combined with a DevOps role. You may even have one person who maintains all
your infrastructure for production and development, and even doubles as a
developer. That still doesn't mean you label the entire role DevOps.

~~~
otabdeveloper4
"DevOps" = "sysadmin that can code scripts".

Whatever your conceit, that's in fact what the term means in practice.

~~~
tuldia
The job description of a sysadmin always required knowing at least one
interpreted and one compiled programming language.

Programming is a subset of skills within the sysadmin role.

~~~
otabdeveloper4
> The job description of a sysadmin always required knowing at least one
> interpreted and one compiled programming language.

You'd be surprised. A large chunk (say, more than 50%) of the sysadmin job
market are guys that can set up a Windows LDAP and/or some Cisco and Wi-Fi
equipment, but no more.

It's why the 'DevOps' moniker was invented, to differentiate the old-school
Unix sysadmins from the LDAP-and-Exchange guys.

------
ldoughty
You also can't just rename your Dev team DevOps...

Ops people come from a background favoring stability, security, and connecting
components.

Developers come from using new and great tools... Writing the connections
between their own systems, and following API docs of their partners.

Ops people usually have less CS training, and developers frequently don't
understand security aspects of running systems or containers. You should merge
the teams, not drop additional responsibility's on one side or the other that
are outside their training/experience

~~~
techops
Please be careful with the prejudices here around the CS knowledge of
operations professionals. As a computer scientist who builds software for
operations automation, I often find that developers work in interpreted or
virtual execution environments and have little understanding of the underlying
execution infrastructure or even the compiled environments that execute their
code. The ops team understands throughput,

I agree that cross-training and shared responsibility for both success and
support are critical for success -- regardless of labels put on people and
teams.

------
cletus
If you can rename "statistics" to "machine learning" and "data analyst" to
"data scientist" [1], I don't see why you can't rename "IT Ops" to "Dev Ops".

[1] If you haven't heard it, there's a joke:

Q: What's the difference between a data analyst and a data scientist?

A: The data scientist lives in San Francisco

~~~
CapmCrackaWaka
The distinguishing factor between those two roles that I have noticed is data
scientists build predictive models and use statistics somehow, while analysts
are relegated to the 'grunt' work like cleaning data, building reports, etc.
Analysts are typically working to become data scientists. I only have 5 years
of work experience at 2 companies, so I'm sure results vary. I make sure not
to make any assumptions when I hear either title, however, I've met
incompetent 'data scientists' and brilliant 'analysts'.

------
oweiler
There is no DevOps role. There is no DevOps team. Devs doing Ops != DevOps.
DevOps is about tearing down silos (Dev and Ops), not creating new ones.

~~~
levythe
I'm glad I'm not the only one who thinks like this. Every time I read someone
referring to, "a DevOps," I wonder what they think they're referring to. No
one person is going to be everything you need for effective development and
operations combined outside of small, extremely focused scope. DevOps is about
avoiding the, "Just throw it over the wall," mentality, not making one person
handle the whole thing.

~~~
dvtrn
>I wonder what they think they're referring to

This and

>DevOps is about avoiding the, "Just throw it over the wall," mentality, not
making one person handle the whole thing.

this are why it's now part of my interview process when I'm interviewing for a
new role "how does your company/team define DevOps?" and I listen very closely
for things that sound like 'over the wall-Ops'. Admittedly having the fortune
at this point in life to be quite judicious about the answers given.

Ostensibly, if I'm applying for a 'DevOps' role, I shouldn't _have_ to do this
if the job description is written well enough, yet even then this has become a
learned behavior even when coming across the rare well-articulated job req.

------
at_a_remove
I had this happen to me from the other end. I was the lone programmer (and my
title reflected that). After a new hire, I was told that I was some kind of
engineer because my title had changed to that and that we are now DevOps,
hooray! Not coincidentally, this was to be my final awful Agile experience.

The thing is, I am not gifted in the area of system administration. I am not
too shabby at it in Windows, quite pathetic in Linux, but being a sysadmin was
a role I had escaped for a _reason_. And suddenly I am back in it. I am a very
low-tooling programmer. Just let me stick my hands in the data and go away. I
have great respect for people who are system administrators but it is a job
where my talents lie below my meager skills, and my inclination far below
that.

Meanwhile, the _true_ system administrators, who had been doing that for quite
some time, had been denied the actual title for some time, were going to be
moved over just as ... bodies, I guess, to elsewhere. All just ... DevOps now
or whatever.

What a trainwreck.

------
briffle
Of course not, you need to install Jira as well, so your now Agile..

I was going to use a sarcasm tag, except that is pretty much what my last
employer did...

~~~
sonofgod
I've had "here is an install of Jira, go play" with no configuration done or
any admin existing too.

My greatest achievement in that job was making production a git repo so that
we could regards against production before pushing. A sufficiently low bar
you'll trip over it.

------
SideburnsOfDoom
My recent experience in interviewing candidates is that they have all heard
the word "DevOps" but what they understand by it is highly variable, and
ranges from from a way of working, to a build pipeline in Azure to ... yup, a
renamed Ops team.

It's pretty sad.

~~~
user5994461
It's a pretty good progression from before.

The most common name used to be sysadmin. That could be development or
operations or anything down to running a Windows Active Directory or HelpDesk.

At least with DevOps, there is no doubt that it's about Linux systems and
automation.

~~~
SideburnsOfDoom
> At least with DevOps, there is no doubt that it's about Linux systems and
> automation.

Is that what you understand by the term "Devops" ? That "it's about Linux
systems" ? Really??

That definition is a new one on me, and you very much should doubt it since
"it's about Linux systems" is neither necessary nor sufficient. The confusion
is even worse than I thought.

~~~
user5994461
Are you trying a joke on Linux vs Unix? in reference to companies using
Solaris or FreeBSD maybe? (there aren't many left of those).

All the DevOps roles I've ever seen are Unix based. In my experience sysadmin
roles were more likely to be a windows administration or a helpdesk role than
that.

I think it's pretty good devops got split into a distinct title. It's not a
great experience walking into a sysadmin interview only to find out they are
looking for an exchange administrator.

~~~
SideburnsOfDoom
> Are you trying a joke on Linux vs Unix?

No, I'm saying the the DevOps ideas have nothing to do with OS choice. You
could use them in linux or Windows or in any other OS; or you could ignore
them in linux or Windows or any other OS.

------
rospaya
Oh, another person telling the world what devops means.

If we take the 50 thousand or so other blog posts about the definition of
devops and glue them together - it means whatever you want. Ops teams doing
some code, devs building CI/CD infrastructure, whatever.

~~~
SideburnsOfDoom
> another person telling the world what devops means....- it means whatever
> you want.

I think that devops (like agile) will have a definite meaning, but uncovering
that is mostly a process of examining the early history of it - who first used
it and when? The definitions used, the problems that it aimed to solve, and
the methods used to solve them.

However, like "agile" it can and often is abused to mean everything and
nothing. This does not make it inherently meaningless, though.

------
supercommand
Cloud engineer. Network engineer. Software engineer.... I’ve never heard of
medstudents calling themselves doctors, why do cs students/grads get a pass?

Up next chefs will be food engineers, tailors will be clothing engineers, and
because I changed the oil in my Toyota once, I’m now a Toyota engineer;
specializing in fluids.

Words mean literally nothing anymore (ha). Titles in tech are hilarious at
almost every level, especially from the outside looking in.

~~~
klodolph
This argument gets rehashed in HN pretty often. When I just worked in ops or
support my job title had the word “technician” in it. When I was designing
systems my job title had the word “engineer” in it, even if I also had ops
duties. As far as I can tell this is a regional thing, where certain
jurisdictions have laws that regulate who can call themselves engineers, just
like certain jurisdictions have laws about who can call themselves
hairdressers. That doesn’t stop people on HN from thinking that for some
reason, we can all agree on a definition for “engineer”, even though we have
regular disagreements about the definition about almost every other word in
the English language.

“DevOps” is at least ill-defined from the very start, so if we have arguments
about what “DevOps” means, at least I can learn something.

------
utopian3
I've met many smart people from large enterprises who said, "I'm the DevOps
[guy|team|person]" with a straight face. Generally, I believe they know it's
wrong, but their leadership didn't, and they were just eager to move the
needle a little bit that they accepted.

------
Ididntdothis
Maybe people shouldn’t get stuck up that much about words. Unfortunately they
are so it’s smart to attach yourself to the currently fashionable title. If
you do something with dev tools call yourself “devops”. If you run a few
database queries better call yourself “data scientist “. And if your current
buzzword falls out of favor then don’t change your work but find a new
fashionable label.

It’s an unfortunate state of the industry that we put value and prestige into
ill defined labels.

------
mindcrime
Yep. Similar notion applies with "Agile" \-- you can't just throw out all
requirements analysis, up-front design, and architecture work, and say "We're
Agile". But people do it all the time, because they're enthralled with the
buzzword and not the actual _meaning_ behind the buzzword. Same applies for (
Agile | Devops | $WHATEVER). And the sad thing is, this in turn devalues the
original idea and causes a backlash where people throw the baby out because
somebody crapped in the bathwater.

~~~
DataWorker
It’s how tech and capitalism interface. The $whatever is actively marketed,
the profits are arbitrage between the true value of the thing and the
perception of the value. Since that value perception is easy to manipulate
with network effects, and true innovation much more difficult, we then become
stagnant. Maybe this is why we don’t see much productivity for the past
several decades. Productivity gains are never realized because the tech stays
constant while perceptions are maneuvered for profit. One reason China may
win; less respect for IP.

------
soneca
Interesting, in my last company the team themselves thought DevOps was not a
role, but more a responsibility that should be shared among all devs and they
renamed themselves _" Production Engineering"_.

They said it was admittedly not the best, clearest of the names, but the
important thing is that DevOps should be shared, not owned. As a dev, it made
a lot of sense to me

~~~
phlakaton
> They renamed themselves "Production Engineering"

That jibes with my experience, where there has generally been one or more
groups that build and maintain infrastructure to enable dev teams to build,
deploy, monitor, etc. But what do you call it? It's not a DevOps role per se,
nor really an Ops role, but it enables DevOps. We called it Platform, but said
we were hiring DevOps engineers.

In short: it's a mess. :-)

~~~
SideburnsOfDoom
That role /team is real, especially in larger orgs, and a better name for it
is "platform" / "platform team" / "platform engineering" not "DevOps".

If you must call it "DevOps", it is "Devops enablement team", i.e. supplying a
platform to enable dev teams to better Develop, build, deploy, monitor,
Operate what they make, themselves - enabling others to do DevOps by supplying
tools.

See:

[https://martinfowler.com/articles/talk-about-
platforms.html](https://martinfowler.com/articles/talk-about-platforms.html)

[https://www.thoughtworks.com/radar/techniques/platform-
engin...](https://www.thoughtworks.com/radar/techniques/platform-engineering-
product-teams)

[https://hackernoon.com/how-to-build-a-platform-team-now-
the-...](https://hackernoon.com/how-to-build-a-platform-team-now-the-secrets-
to-successful-engineering-8a9b6a4d2c8)

------
gk1
Hard to believe (or maybe not?) there's still ambiguity around "DevOps" so
many years after its introduction.

And with ModelOps, DevSecOps, AIOps, GregOps, and GitOps recently entering the
lexicon brace yourself for lots of confusion and "xOps explained" articles
ahead.

By the way, one of those xOps isn't real, but who can even tell?

~~~
sonofgod
I'm assuming it's GregOps, because GreggsOps is HugOps with bonus vegan*
sausage rolls. :P

* vegan optional

~~~
PascLeRasc
It's actually been going by GregoryOps lately.

------
esotericn
Role names in most software companies that I've worked at and know of are
almost completely arbitrary.

They're useful if you have an organization that pays a specific rate for a
specific job title, and they're useful in a hierarchical sense (e.g. managers,
CTOs, etc). That's about it.

I install and maintain servers and desktops, databases, run backups, build
infrastructure, source control servers, do low level programming, high level
programming, frontend, backend, ... etc, it's too long to even enumerate.

As far as I'm concerned that's just being a (non-junior) software developer.
It's all ultimately the same thing with different names to me, barely anywhere
really needs people who are at the forefront in a tiny niche (i.e. _real_
specialists).

You can call me whatever you want as long as you're paying the bills.

------
thrower123
DevOps, like most IT fads, is just trying to get more blood out of the stone
and avoid letting anyone specialize in anything. That's obviously not the
original intent, but it's what happens.

------
azaras
IT fashion:

out: DevOps

in: SRE

~~~
fteem
Check this out:
[https://www.youtube.com/playlist?list=PLIivdWyY5sqJrKl7D2u-g...](https://www.youtube.com/playlist?list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj)

------
jasoneckert
The sad reality in most organizations today is that buzz words are applied to
existing jobs to make it look like progress. So yes, apparently you _can_
rename your IT Ops team to DevOps and brag about "how you engaged your teams
to move to a DevOps focus to better align them with company values while
leveraging the low-hanging fruit within today's shifting economy" during an
executive management meeting.

------
rhoyerboat
Agreed, but, perhaps, as a management strategy, it may help some teams
transition. Since after all, for folks with careers in manual provisioning,
devops truly is a new frame of mind.. swapping words in titles around is just
part of operations development? :)

------
purplezooey
_"...not about hiring a 'DevOps guy'"_

Yet, this is one of the most common scenarios I've seen. "Oh, this guy/gal
started devops at Xyz company.".

------
kazinator
DevOps means "the build and continuous integration system is so complicated,
it needs dedicated people who have software dev credentials".

------
jacobsenscott
Wait, nobody ever named a team "IT Ops".

------
idclip
Or call technical customer support Devops. Which also contains the Ops team,
which has recently been renamed Devops.

------
farisjarrah

        > You can't just rename your IT Ops team and call it DevOps 
    

Sure you can. Companies can and will do whatever they want. It may not be
semantically correct, but it definitely wont stop anyone. Just go on indeed
and look up "DevOps jobs" and you'll see many companies who have done just
that.

------
iio7
I'm so sick of all this hyped up bullshit!

Someone who administers systems is a system administrator and someone who
develops is a programmer.

And in my 30+ years in the business I haven't seen a single BSD or Linux
system administrator who couldn't also program in C or some other language.

------
dopylitty
Of course not. You also need to lay off your entire testing team and rename
the IT Ops team DevTestOps.

------
avtomer
Super interesting and relevant. Thanks!

------
rubyfan
At public corporations (especially regulated) there are confounding factors
that make DevOps a farce. For example audit, a point of view that IT is a cost
center, and the non technical management decision making that go along with
the previous challenge the spirit and proper execution to get DevOps right.
But in reality DevOps is a symptom of a larger issue - functional reporting
structures and goal misalignment.

Audit - the idea that your developer doesn’t have access to production systems
and data is a challenge to DevOps. The idea that one person codes and one
deploys can be a challenge. Some organizations like management visibility and
an audit trail to prove it - this can challenge automation and frequent
deployment. This is not just a DevOps issue, audit expectations for business
requirements and QA signoff can be just as bad. Admittedly some of the audit
rules are relics of the past but the need to be addressed in order for DevOps
practices (and really for agile teams to be agile.

In organizations where IT is a supporting function of the business there is a
view point that it’s a cost center only and doesn’t produce value and should
be cost controlled and managed to ultimate efficiency. I’ve reminded CIOs that
the work the IT team does is not “a factory” as they sometimes insist on
calling it - no one in technology that I’ve ever met (except management)
really wants to think they work in a factory.

The efficiency mindset rank orders roles with QA and analysts at the bottom,
devops slightly higher, developers relatively high, architects at the top of
the skilled food chain and management of course at the top. To some degree
these functions can be centralized so they can be optimized and made
efficient. Centralizing typically means you work for management rather than a
particular business mission. Your job is to make management look good and keep
everything running smoothly (remember you work in a factory). Management
generally looks good when quality is achieved at a lower price point. Along
with that tends to be a higher level of off shoring at the lower end of the
skill rank where larger numbers means more efficiency at lower cost. Here lies
the problem - the premise of DevOps is that the role is integrated in the
team. When DevOps is a function reporting to management then their goals
aren’t aligned to the development team. They might not even sit with the team
and they might have their own orders. They might be in a 12-20 hour time zone
offset.

To me the larger issue is management structures aligned by function instead of
business. This leads to misalignment if goals and ultimately lack of
integration in functions. It’s a bigger problem than DevOps and it’s a bigger
problem than IT. I think the companies that get management reporting right
will win in the end. I am curious to see how Google and Amazon respond to
these issues at their scale. The pizza team doesn’t work when everyone has
different goals.

------
peteretep
*shouldn’t

