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

281–290 of 435 posts

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

#281

Post by tapoxi »

user5994461 wrote: post #176
brightball wrote: post #160

Earlier quoted context omitted.

Would be interested to get your opinion on Puppet/Ansible/Chef/CFEngine/SaltStack

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…

I love SaltStack, its more of a python framework for managing systems over ZeroMQ than it is pure configuration management. Compared to Ansible it's more complex but faster, reactive, and significantly more flexible. I'd highly recommend it over Ansible for larger environments. For smaller ones, it depends on if the steeper learning curve is worth it.

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

#282

Post by w4tson »

ebiester wrote: post #41
megaman22 wrote: post #14

Earlier quoted context omitted.

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

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.

And while you’re at it can you make it idempotent when building sub artifacts which inputs haven’t changed.

And can it do it all incrementally in parallel too please because enterprise shops tend to have a ton of code

Oh and it would be really nice if you could make it so if someone else somewhere in the org has compiled that thing then could we just use their computed binary to save the time compiling locally.

THANKS!

;)

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

#283

Post by bordercases »

kazen44 wrote: post #220
scurvy wrote: post #194

Earlier quoted context omitted.

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

What country?

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

#284

Post by w4tson »

mcguire wrote: post #175
untog wrote: post #69

Earlier quoted context omitted.

> But I just don't understand why we have to have 47 half-built over-complicated build systems > Everyone repeat after me. I don't mean to pick on you specifically here because this attitude comes up a lot. In short, a lot of people are doing a thing, a thing that you aren't familiar with, and your gut reaction is to say "everyone: stop doing that, and do what I say!". Wait a second and consider that maybe there is a…

" Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out. " Have you considered that perhaps the previous commentor is familiar with the other tools? Or perhaps that the large number of developers have str…

If the previous commenter was familiar was familiar with 47 build tools and has discounted a lot of them as extraneous. Is he advocating building an npm module with make? What about a jar? Nuget package? Cargo module?

Its seems more likely that they’re frustrated about the sheer amount to learn and they probably know make quite well.

But there are real advantages to these tools. There’s a lot of vanity libraries out there but not many vanity build tools.

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

#285

Post by acheron »

mcguire wrote: post #187
Joeri wrote: post #61

Earlier quoted context omitted.

Many of these are tools which download code dependencies from package repositories and integrate them into a codebase or build. Make doesn’t do that, even configure doesn’t do that.

Anyone remember the days when you didn't want to do that?

Days like today? As someone who is often working on machines with no network access, I vastly prefer build and deployment processes that don't need to go download crap.

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

#286

Post by acheron »

nova22033 wrote: post #158

>And since nobody is still able to compile things from scratch Is is true that we had better security when we had to "compile everything from scratch" whatever that means? Did people compile the OS from scratch?

Did people compile the OS from scratch?

...yes. https://www.freebsd.org/doc/en/books/handbook/makeworld.html

P.S., make sure you have a spare couple days before running make buildworld on a 150 MHz Pentium.

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

#287

Post by titanomachy »

AlexCoventry wrote: post #255
phaedrus wrote: post #246

Earlier quoted context omitted.

I once worked at a company which separated IT into 3 teams: developers, DB-sysadmin (ops), and QA (who also managed deployments). Releases were supposed to go in a waterfall model from the Dev group -> QA group -> Ops. QA wanted Dev to submit Word documents for each release with blanks to be filled in with server names. However Ops was so distrustful of Dev that it was not enough for them to lock us out of Prod using…

I have trouble imagining the incentives driving Ops in that conversation.

The easiest way to ensure the stability of the systems that you own is to prevent anyone from changing things on them.

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

#288

Post by devonkim »

AlexCoventry wrote: post #255
phaedrus wrote: post #246

Earlier quoted context omitted.

I once worked at a company which separated IT into 3 teams: developers, DB-sysadmin (ops), and QA (who also managed deployments). Releases were supposed to go in a waterfall model from the Dev group -> QA group -> Ops. QA wanted Dev to submit Word documents for each release with blanks to be filled in with server names. However Ops was so distrustful of Dev that it was not enough for them to lock us out of Prod using…

I have trouble imagining the incentives driving Ops in that conversation.

Devs hardcoding things in their software in a rush making the software tougher to deploy and operate causing greater incident rates and therefore page-outs. Devs interested in greater resilience and stability in their software should be opting for dependency injection of pretty much every damn thing in the world around them whether it’s a network service or file system location. Otherwise, presume that it can go away at any time. A common pattern among developers trying to save time that costs more in the long run is to hardcode a path to an executable. A simple /use/local/bin/ buried in an infrequent job that is installed on developer machines but never in prod is all it would take to cause an incident in prod that costs the company millions. I say this both as someone that has written this and had to fix others committing the same error in their code and QA passing it along.

Ops tends to be where the brunt of technical debt is truly buried. Bad code is one thing but seeing the code in action with real world data is a different beast altogether.

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

#289

Post by alekratz »

spiderjerusalem wrote: post #149
ex_amazon_sde wrote: post #63

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes be…

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 very real concern. We have a thing called a "bus plan" for all of our tech employees (6 of us - small non-tech company). It basically attempts to cover everything that we would need to know if one of us gets hit by a bus.

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

#290

Post by dijit »

kazen44 wrote: post #183
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…

> Not sure about SaltStack. Never had the opportunity to try. I'd be a bit worried though on the long term prospect because I don't think they have much backing or user base. saltstack is a well thoughout solution in my opinion. It makes more logical sense and is less of a mumbled mess then either chef or puppet and has miles better performance then ansible. I know quite a few shops who use it. Its definitly smaller…

I use salt. Multiple thousands of machines. I feel like I've barely scratched the surface of what it can do with it. I wrote some custom utilities for it. Added some functionality to handle physical deployments of an OS with redfish (the new iLO/iDRAC api).

Salt is not without warts but its definitely worth checking out.

Post reply on HN