6 ms·
It Was Never About Ops
- stonogo 10y agoIt'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?
- toomuchtodo 10y ago[removed]
- CodeMage 10y agoIn my humble opinion, based on my humble work experience, this trend has not originated with overconfident engineers, but rather with cost-cutting managers.
- toomuchtodo 10y agoI removed my comment because it painted with an overly large brush.
- draw_down 10y agoIt'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.
- toomuchtodo 10y agoIf 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.
- draw_down 10y agoOf course, I was just speaking to why this is happening, not my grand scheme for how this should all work. Personally I would ideally like to just commit code and be done with it. Being on-call sucks.
- cmdrfred 10y agoI think you can be good at all those things, just not at 23.
- flukus 10y agoEven if you're good at all those things, can you imagine keeping up in all those areas?
- majewsky 10y agoThere is a remarkable difference between "knowing Elasticsearch" and being able to debug it when shit hits the fan in the middle of the night.
- stonogo 10y agoThis is a common answer which presumes that all businesses are development companies, or that they are development companies which are legally allowed this interplay between the programming team and the production team. There are places (places with a lot of money on the line) that do not fall into these categories, and yet the solutions are not so different. I'm just intrigued by the level of effort Silicon Valley is willing to exert to avoid recognizing this -- or even admitting that it's possible.
- yarou 10y ago> Is this why Silicon Valley is allergic to the phrase 'systems administrator'? Ops, Devops, SRE... Titles are a good way for management to increase responsibilities for an employee, without having to pay them more.
- pgwhalen 10y agoThat's funny, I would say the exact opposite is more often the case.
- vacri 10y ago> Is this why Silicon Valley is allergic to the phrase 'systems administrator'? '系统管理员' ('xìtǒng guǎnlǐ yuán') I'm thinking of doing the traditional anglo thing and getting a tattoo of chinese characters I'm not really familiar with. I'll tell people that it means "fiery heart of the tiger" or "blessed heaven spirit" or somesuch... :)
- toast0 10y agoA 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.
- Baeocystin 10y agoIt's a niche. It's how I earn my living. I work for small companies that don't have enough daily work to keep someone like me around, but they can pay me a retainer to be on call when Something Bad™ happens. It's actually pretty fun to have an ear in a wide variety of businesses, you wind up learning a lot outside of the technical world.
- ryhamz 10y agoI suppose the natural question to ask here is if one thinks it is actually possible to be truly "on call" at multiple places simultaneously. Is the extent of your agreement service within a day or something shorter/longer?
- Baeocystin 10y agoIt depends on how much they are willing to pay. For most, they pay enough to get a phone call within the hour during normal business hours, an email response within the day, and a 24-hour window if something happens on-site that requires my physical presence instead of remoting in. I do have a couple of clients that pay quite a bit more for a call-and-fix any time guarantee, but I only offer that level of service to businesses where 1: there is at least one person on their regular staff who is technically competent enough I can walk through more advanced issues and they will understand how to follow instructions, and 2: I'm the one that built out their network, so I know the gritty details. For the times when the shit hits the fan in two places at once, I have friends who do similar work, and there are a couple of guys I can call to cover if needed. Obviously they get most of the money from these instances, but the customer stays happy, and I get larger monthly residuals than I could otherwise take care of, so everybody wins.
- 10y ago
- unethical_ban 10y agoBeing a good sysadmin in 2016 requires a skill in programming. The ability to write apps and services that interact with your infrastructure's APIs is necessary to automate all the toil we've done since the beginning. (See google's SRE book) As I have more control over hiring decisions on my team, an inability to use any programming language effectively (bash, python, perl, /anything/) would disqualify someone from a job in sysadmin or information security.
- jvehent 10y agoBeing a good sysadmin in 1996 and 2006 also required skills in programming. Sysadmins who don't code have always been limited in their career evolution. The same is true for developers who don't know anything about operations. The focus on automation, and it being called DevOps, is simply an evolution of the work of sysadmins. The same way devs evolved toward TDD and other modern programming techniques.
- DanielBMarkham 10y agoThe focus on automation, and it being called DevOps, is simply an evolution of the work of sysadmins. I believe you have this exactly backwards. The problem is that we keep silo'ing everything and inventing new buzzwords and half-assed tech. We can split things into smaller pieces quicker than we could ever staff up. Nothing has changed since the 80s. The only thing that's different now is that instead of programming in one little pond of a language, now everything you do is programmable. That doesn't mean you need 47 specialists. It means you need to get really good at managing and limiting complexity. We don't want to split off and evolve roles into newer and even more specialized roles. This is the thing that made deployment and updating so whacked to begin with. </rant>
- lisivka 10y agoDevOps is not about automation of Ops work. DevOps is about replacement of Ops with code.
- Others 10y ago
- user5994461 10y ago> 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.
- rhizome 10y agoThe people who take care of internal user systems are IT. IT may have sysadmins, but a sysadmin is not necessarily IT.
- flukus 10y agoSince when was the dude who can setup your desktop a sys admin? That would be tech support.
- nickpsecurity 10y agoA major, Fortune 100-500 firm in my area had many of their Win7 machines rolled out over the network by a guy that knows nothing about networking, can't tell cache from RAM unless explicitly marked, and calls me for basic, tech support on occasion. That it worked out fine with basic automation in place supports your assertion. ;)
- lisivka 10y agoDevOps is not a Ops at all. DevOps is a developer, who writes code to do tasks which are often done manually by Ops team. E.g. installation, configuration, assigning, recovery from failure, upgrade, migration to new version of database, etc.
- empthought 10y ago> In short you can … > 1. Expect services to grow at a non-linear rate. Why would you expect this?
- 13NNq9e01P6A 10y agoMy 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 10y agoYeah 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.
- joesmo 10y agoCouldn'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 10y agoThis 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.
- awinter-py 10y ago> Scale your people by giving them the time and space to focus on scaling your products. This rings true.