
It Was Never About Ops - michaelbiven
http://biven.org/it-was-never-about-ops
======
stonogo
It's fun to watch people learn the systems administration trade, but it's a
little disheartening to watch them conclude -- incorrectly -- that proper
systems administration is some kind of software engineering job.

Is this why Silicon Valley is allergic to the phrase 'systems administrator'?
Ops, Devops, SRE... so many phrases to describe various jobs which all, when
executed successfully, converge upon the same set of tasks, and the same
approaches to them, that has been labeled 'systems administration' for thirty
years or more.

What is the motivation behind this trend?

~~~
user5994461
> Is this why Silicon Valley is allergic to the phrase 'systems administrator'

There is no need for 'systems administrator' in the Silicon Valley.

The systems administrators are the guys who buy the desktop computers, setup
windows, and kinda manage the active directory.

DevOps/SRE names exist because the tech scene had to stop the confusion
between the hardcore linux admins who can code and the dude who can setup your
desktop computer. The first is needed in dev companies mostly located in the
tech hubs, the second is needed in most companies all around the world. The
two have very little in common.

~~~
stonogo
> DevOps/SRE names exist because the tech scene had to stop the confusion
> between the hardcore linux admins who can code and the dude who can setup
> your desktop computer.

If that confusion existed in any otherwise-competent organization, it was only
in the valley. I was a systems administrator before any of "SRE," "DevOps," or
"linux" came to be, and I don't think anyone has ever confused me for tech
support.

~~~
sk5t
Most of the working Windows system administrators I have met could not code
their way out of a wet paper bag (but a majority could code their way into
one). If you've been unlucky enough to work on a "managed" workstation, their
near-total unawareness of optimization, state, and exception handling is why
your Windows login script takes 10 minutes to crunch away.

~~~
flukus
To be fair, windows scripting is pretty limited. Then you have powershell
which is way to bloated for quick and dirty things.

~~~
sk5t
Most of the nasty Windows scripts I've seen were VBScript, used to bludgeon
about various WMI providers and to launch unfortunate executables. I don't
think the language was much of a hindrance on its own, but it did nothing to
repel stupidity.

Several years on, I still don't know what to think about Powershell, it's
basically .NET + pipelines + some discoverability aids, not terrible in
concept but I will probably go on ignoring it for the rest of its life.

------
empthought
> In short you can …

> 1\. Expect services to grow at a non-linear rate.

Why would you expect this?

~~~
13NNq9e01P6A
My reading was not that you can expect to be a unicorn and grow to Facebook
proportions, but that your Growth Model is non-linear. What I mean by that is
when your growth occurs, it occurs sharply.

~~~
empthought
Yeah no, the online banking site for e.g. chase.com isn't going to get non-
linear or "sharp" growth. Nor is their internal project time reporting system.

------
awinter-py
> Scale your people by giving them the time and space to focus on scaling your
> products.

This rings true.

------
joesmo
Couldn't agree more. If you have a monolith, you can probably get away doing
dev ops as long as you don't grow too much. We have a handful of microservices
and trying to keep up with the ops work has been hell, though part of that is
due to AWS's tools. And this is without even a growing user base, just a
growing app base. Burn out is definitely a problem in either case.

~~~
majewsky
This is interesting. I've had a lot of people on the internet tell me that a
monolith must become unmaintainable at some point, and the only way to keep it
serviceable is to break it up into microservices.

