Live data from Hacker News

It Was Never About Ops

biven.org

41–50 of 53 posts

Re: It Was Never About Ops

#41

Earlier quoted context omitted.

> 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 yo…

The guy that sets up your laptop is an IT tech, not an SA. The SA is the hardcore linux admin who can code. From my perspective, and SRE is a SE that focuses entirely on back end performance and reliability, in order to support the SAs. DevOps is a term used by management to justify cost-savings by avoiding hiring someone to ensure system reliability, consistency, safety, and integrity.

Maybe in places that started well: I have no doubt that there have always been people out there that were doing system administration and could code.

The places where I have seen DevOps become popular are those that completely separated programming keeping servers running, and where the people keeping said servers running were incapable of doing even mild automation. Places where rebooting a non-db server requires making a request 3 weeks in advance, and being OK with 4 hours of downtime.

In those environments, those people that are called system administrators are very low productivity, can't help you with a performance problem if their life depends on them, and are easily replaceable with shell scripts. It's in those environments where DevOps and enterprise cloud migrations are popular: The developers might not be experts in scalability or in getting great uptime, but at least they can get something done. Ultimately this gives management an excuse to lay off all the sysadmins that don't know what /proc is, and make technical decisions based on Gartner reports.

Again, that doesn't mean that everyone that has the title of sysadmin in the world can't code or is unproductive: This is not a judgement on the value of a good SA. I am just trying to open a window to a world that many developers get to see, but few good SAs notice, because there's no way in hell a good SA would work in said companies for long.

Re: It Was Never About Ops

#42
post #40
post #37

Earlier quoted context omitted.

DevOps is not about automation of Ops work. DevOps is about replacement of Ops with code.

Can you clarify the difference between your first and second statement? Isn't replacing Ops with code just automating Ops work?

Difference is thin, as between "automatic", "fully automatic", "intelligent" or "smart" systems. Or as between "programmer", "developer", "software engineer".

Ops team may create an automatic solution, e.g. script to call with parameters and a runbook. DevOps will create fully automated solution, without need for a runbook.

By definition, DevOps is developer, (an one who uses Agile techniques, such as automated test cases, CI, source control systems, ticket management systems, etc.), who is able to do Ops tasks with code.

Re: It Was Never About Ops

#43
post #39
post #36

Earlier quoted context omitted.

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.

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

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.

Re: It Was Never About Ops

#44
post #42
post #40

Earlier quoted context omitted.

Can you clarify the difference between your first and second statement? Isn't replacing Ops with code just automating Ops work?

Difference is thin, as between "automatic", "fully automatic", "intelligent" or "smart" systems. Or as between "programmer", "developer", "software engineer". Ops team may create an automatic solution, e.g. script to call with parameters and a runbook. DevOps will create fully automated solution, without need for a runbook. By definition, DevOps is developer, (an one who uses Agile techniques, such as automated test…

You have a different definition than I do. I'll copy-paste Wikipedia since it matches my understanding:

> DevOps is a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

DevOps certainly does not mean that Dev has to do Ops now, too, although it's frequently misunderstood as meaning that, and IMO that usually leads to a lot of tears in the long run.

Re: It Was Never About Ops

#45

Earlier quoted context omitted.

It's not just about that role, it's more about the interface between the people responsible for running the code and the people responsible for writing it, and to what degree each should be able to do the other's job. Just throwing shit over the wall isn't any good either.

If you need to do backend and front end ("full stack"), know devops, know cloud primitives, know database fundamentals, know document storage (Elasticsearch), what are you going to actually be good at? Not much. You can't have both depth and breadth of knowledge, unless you're doing unhuman levels of cocaine and never sleeping.

There is a remarkable difference between "knowing Elasticsearch" and being able to debug it when shit hits the fan in the middle of the night.

Re: It Was Never About Ops

#46
post #14

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.

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.

Re: It Was Never About Ops

#47
post #42

Earlier quoted context omitted.

Difference is thin, as between "automatic", "fully automatic", "intelligent" or "smart" systems. Or as between "programmer", "developer", "software engineer". Ops team may create an automatic solution, e.g. script to call with parameters and a runbook. DevOps will create fully automated solution, without need for a runbook. By definition, DevOps is developer, (an one who uses Agile techniques, such as automated test…

You have a different definition than I do. I'll copy-paste Wikipedia since it matches my understanding: > DevOps is a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. DevOps certainly does not mean that Dev has to do Ops now, too, although it…

«DevOps» term originated from conference named «DevOps»: http://www.jedi.be/blog/2009/12/22/charting-out-devops-ideas...

Wikipedia quotes description of tne conference, not a description of DevOps role. However, if you read carefully original article, you will see that main idea was to close gap between ops and dev team by bringing dev techniques, such as Agile, to ops team. So, DevOps IS developer with Ops knowledge.

Re: It Was Never About Ops

#48

> In short you can … > 1. Expect services to grow at a non-linear rate. Why would you expect this?

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.

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.

Re: It Was Never About Ops

#49
post #11

Earlier quoted context omitted.

A lot of people doing software have some sysadmin experience, and a small company probably doesn't have enough work for a full time sysadmin. And a part time sysadmin won't work because you need on-call.

Well, except they don't really have sysadmin experience. They set up a server for their development environment once, and because of that, they get turned into the company sysadmin. So they set up the companies production environment, and the lack of experience shows. Multiple single points of failure, inadequate (if at all) backups, poor network design, etc. One favorite situation I ran into: a database server with…

One of the first questions I ask techs I'm considering bringing on to help is if RAID is a backup. If I see them physically cringe at the thought, I know they've got potential.

Re: It Was Never About Ops

#50
post #32
post #29

Earlier quoted context omitted.

The people who take care of internal user systems are IT. IT may have sysadmins, but a sysadmin is not necessarily IT.

That's his point I think? That there is a way to differentiate the different skill sets of different admins.

"The systems administrators are the guys who buy the desktop computers, setup windows, and kinda manage the active directory."
Post reply on HN