Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

Post reply on HN
Print view View original

211–220 of 435 posts

Re: The sad state of sysadmin in the age of containers (2015)

#211

Post by user5994461 »

Karrot_Kream wrote: post #181
user5994461 wrote: post #176

Earlier quoted context omitted.

CFEngine is basic text manipulation, it's not comparable to the rest. Puppet and Chef was the first generation. I wouldn't recommend. All the companies and people I know using Chef migrated away from it after many disasters. Nowadays, it's only mentioned in interviews to find out if candidates have real world fire fighting experiences. Ansible is good. Used that for managing hundreds of machines at multiple jobs (som…

> Ansible is great. Used that for management hundreds of machines at multiple jobs. It's been bought by RedHat, it's well maintained and I think it will have the brightest long term future. A lot of folks I know have been bitten by Ansible's performance (Ansible has a central master that runs recipes on each node, rather than having nodes "pull" from a central master).

I believe you are talking about Ansible tower, the paid tool from RedHat that gives a centralized server.

Ansible is not centralized. It configures servers with SSH and can operate from any user or host who has ssh access.

Re: The sad state of sysadmin in the age of containers (2015)

#212

Post by avar »

eropple wrote: post #177
colanderman wrote: post #169

Earlier quoted context omitted.

> I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). You can use Ruby in Make. I don't know Ruby but here's some Python: SHELL = python .SHELLFLAGS = -c .ONESHELL: .DELETE_ON_ERROR: foo.txt: bar.json import json with open('$ (Caveat: I've never actually tried this at scale.) You can even use different languages for different recipes with per-recipe variable settings.

Ha, that's a neat trick! Trouble is, for either Python or Ruby it becomes tricky due to stuff like dependency management. You'll have to `bundle exec make` to get sane library paths for Ruby or `pipenv run` for Python, etcetera etcetera. At that point I think you might as well just use a language-native one. Great pull, though.

The GP does this via a neat hack, but you can also do this in a much more understandable fashion by simply having the body of every Makefile rule start out by shelling out to some script in your favorite language.

I think you're (understandably) misinformed about what Makefiles do because you've run into some bad ones. The thing they're doing is managing a N-level deep dependency tree in a declarative way. So if A->B->C you can run something to generate C, then B can run, and finally A, and this can all be done in parallel for hundreds of files.

On the individual rule level this is really simple, e.g. just turning a .c file into a .o file, then finally some rule that depends on all *.o being generated creates a program out of them.

The language-native ones are usually much worse. They're easier to use at the outset because they don't make you create this dependency graph, but that also means that they can't run in parallel on your N cores, and they usually suck at incrementally updating the build.

Re: The sad state of sysadmin in the age of containers (2015)

#213

Post by setquk »

scurvy wrote: post #194
spiderjerusalem wrote: post #149

Earlier quoted context omitted.

What fascinates me about this is, and sorry for being morbid, but what happens when y'all die? Does knowledge of the lower levels of the stack go away with your generation, or will there be enough of us young ones picking the important stuff up?

It's a legit concern. There was a NANOG panel about this exact thing. I believe the quote was, "Take a look around. We're all old and greying. We have a severe pipeline problem." And then much to AWS' dude's dismay, the topic shifted towards blaming cloud services because no one takes the time to learn how any of this works any more. Want to guarantee your child's future employment? Don't just teach them to code (the…

I’m going to teach my children how to navigate the world of insane Harry-Potter-esque rules which all IaaS/PaaS platforms enforce upon you. They will become software language lawyers and be masters of the electric Disney dollar.

You know like “ahh don’t call the messaging endpoint more than 800 mega-milli-times per mega-nano-second or it will cost you three bazillion CPU credits, but only on three and a half cores which will starve all your instances, issue an invoice and proceed to melt your credit card.”

Re: The sad state of sysadmin in the age of containers (2015)

#214

Post by commandlinefan »

rdsubhas wrote: post #21

As a "major theme", the author takes: > Consider for example Hadoop. Nobody seems to know how to build Hadoop from scratch. It’s an incredible mess of dependencies, version requirements and build tools. And as the major introduction to the blog post: > I’m not complaining about old-school sysadmins. They know how to keep systems running, manage update and upgrade paths. Huh? Old-school sysadmins know how to keep syst…

I've seen this brewing for a while, and getting worse and worse. Back in the 80's and 90's, there were developers who would code their own sorting or hashing routines rather than linking in some external library to handle this "solved" problem. The perjorative term "Not Invented Here" (NIH) grew to describe those developers and they were shamed into reusing code whenever there was code to reuse. And in some cases (like sort routines), it makes perfect sense. However, NIH accusations have grown to "if there's something vaguely similar to what you're writing, you must use it, even if that involves more custom coding to artificially bend it to the case at hand than you would have developed in the first place", culminating in things like the completely empty, useless (but enormous) Spring "framework" or, to a lesser extent, things like Angular that sort of do some things, but create far more problems than they solve (and definitely add more development overhead than they remove).

Re: The sad state of sysadmin in the age of containers (2015)

#215

Post by voltagex_ »

user5994461 wrote: post #211
Karrot_Kream wrote: post #181

Earlier quoted context omitted.

> Ansible is great. Used that for management hundreds of machines at multiple jobs. It's been bought by RedHat, it's well maintained and I think it will have the brightest long term future. A lot of folks I know have been bitten by Ansible's performance (Ansible has a central master that runs recipes on each node, rather than having nodes "pull" from a central master).

I believe you are talking about Ansible tower, the paid tool from RedHat that gives a centralized server. Ansible is not centralized. It configures servers with SSH and can operate from any user or host who has ssh access.

Yeah but when you run a playbook it's running from a single machine which is calling out via SSH

Re: The sad state of sysadmin in the age of containers (2015)

#216

Post by wmf »

user5994461 wrote: post #211
Karrot_Kream wrote: post #181

Earlier quoted context omitted.

> Ansible is great. Used that for management hundreds of machines at multiple jobs. It's been bought by RedHat, it's well maintained and I think it will have the brightest long term future. A lot of folks I know have been bitten by Ansible's performance (Ansible has a central master that runs recipes on each node, rather than having nodes "pull" from a central master).

I believe you are talking about Ansible tower, the paid tool from RedHat that gives a centralized server. Ansible is not centralized. It configures servers with SSH and can operate from any user or host who has ssh access.

Yeah, any user or host singular. Execution of a playbook is driven by one machine which can be a bottleneck.

Re: The sad state of sysadmin in the age of containers (2015)

#217

Post by ebiester »

mcguire wrote: post #151
ebiester wrote: post #41

Earlier quoted context omitted.

I've written a makefile from scratch. My challenge to you: I want a makefile that has 20 third party dependencies and can be built on osx, linux, and windows. I can do this within an hour with gradle, ant, or maven. The ecosystem doesn't exist for this in make, and anything I could come up with to make it possible would end up being a tool that would look like automake and the monstrosity that it entails.

" I can do this within an hour with gradle, ant, or maven. " For something that isn't JVM-based?

Certainly not for all but the most trivial cases, but I'd use the language's build tools.

The industry has moved to language-specific build tools and ecosystems, and the article and is complaining about this in part, no?

Re: The sad state of sysadmin in the age of containers (2015)

#218

Post by [deleted] »

cookiecaper wrote: post #123
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

The thing is that any separation in the roles in ineffective. Things shift around some if you embed an ops guy into the dev team directly, but it doesn't resolve the core problem. This applies to DBAs as well as ops or any other software-side segmentation as well. The core problem is that there are "ops guys" and "dev guys". That creates conflicting incentives, even within the same team. It creates tension and a dyna…

[deleted]

Re: The sad state of sysadmin in the age of containers (2015)

#219

Post by toomuchtodo »

sudosteph wrote: post #166
loteck wrote: post #23

The clearest explanation of why this happens is at the end: Before, admins would try hard to prevent security holes, now they call themselves “devops” and happily introduce them to the network themselves! 1) The merging of devs into the sysadmin role was a product of: the work of sysadmins (particularly systems change control and security compliance) not being valued in our culture. 2) Devs delighted to be free of th…

I feel like there has always been a contingent of sysadmin / ops folks who preferred the "Better to ask for forgiveness than permission" model. They still hate when things break, (so not quite fans of developers with a "move fast and break things" philosophy) but they care more about big picture improvements and ease of upkeep than enforcing any particular process. Detecting problems and being able to roll back is ty…

> It makes sense that these types naturally gravitated towards the devops models. I'm really not sure where this leaves the more compliance-minded systems folks though.

Working for profitable businesses where stability is valued over velocity.

Re: The sad state of sysadmin in the age of containers (2015)

#220

Post by kazen44 »

scurvy wrote: post #194
spiderjerusalem wrote: post #149

Earlier quoted context omitted.

What fascinates me about this is, and sorry for being morbid, but what happens when y'all die? Does knowledge of the lower levels of the stack go away with your generation, or will there be enough of us young ones picking the important stuff up?

It's a legit concern. There was a NANOG panel about this exact thing. I believe the quote was, "Take a look around. We're all old and greying. We have a severe pipeline problem." And then much to AWS' dude's dismay, the topic shifted towards blaming cloud services because no one takes the time to learn how any of this works any more. Want to guarantee your child's future employment? Don't just teach them to code (the…

> Teach them how to build networks and truly understand network protocols.

I don't know how the situation is in the US, but in my country network engineering is actually quite a popular field of study. (we have college level education in network engineering).

The one thing that stands out though is that it's mostly done by youngsters who have either sysadmin experience, or worked in IT before that. Almost everyone who comes from high school goes into Software Engineering.

I think this is mainly because networking is quite an invisible field so to speak. Many people don't even know your job exists, and many young people only see the shiny hip side of it. (being Software Engineering).

Being good at network engineering is hard, especially once you get past entry level work and actually start being responsible for designing large-scale networks. Mainly because building a network is a major financial investment where garuanteeing performance is hard without either a ton of experience, or a shitton of lab time.

this kind of work pays very, very well though.

Post reply on HN