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

401–410 of 435 posts

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

#401

Post by gm-conspiracy »

hennsen wrote: post #378
gm-conspiracy wrote: post #243

Earlier quoted context omitted.

A good sysadmin would not look like they are doing much work (everything is humming along and can self-heal minus physical problems), but a good devops person is constantly busy.

Can you elaborate that? Whats a “devops person” for you and what keeps them busy? And why cant they have systems that hum along self-healingly automated?

Most of the tools of the modern "devops person" are undergoing constant development themselves.

So, not only is there the responsibility of creating this self-healing automated infrastructure, but keeping tools and resume up-to-date, as well.

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

#402

Post by jlgaddis »

twic wrote: post #256
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?

Same problem as making sure your system doesn't lose data when a server dies. Make sure you have enough copies of the knowledge by propagating it between people. Try to have some kind of offline recording (books?) for recovery from a disaster where you lose everyone. Have an idea of how to recover at a business level if you do lose the data forever. The trouble is making sure these plans actually work. This is why Ne…

> This is why Netflix randomly execute some of their employees every month.

I certainly hope this practice doesn't start catching on with other employers.

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

#403

Post by zamber »

bordercases wrote: post #283
kazen44 wrote: post #220

Earlier quoted context omitted.

> 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?

Netherlands

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

#404

Post by Tehchops »

subway wrote: post #97
Tehchops wrote: post #26

Earlier quoted context omitted.

> "These tools don't use the thing I like!" Pretty much. I know several admins who appear to be joining a growing pool of luddites who rail against anything new. They're particularly butt-mad about anyone drawing more salary than them. "DevOps" is their favored totem to direct their ire at. I used to try and convince them otherwise, but it turned out to be a completely futile waste of time. At the end of the day, per…

Also means fat fat contracting gigs for us luddites to clean up after the move-fast-break-shit-gtfo kids.

Hey, if you want to take 18 month stints without healthcare to clean up mis-managed "digital transitions" at places like GE, more power to you ;-)

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

#405

Post by eropple »

zippitydoodah68 wrote: post #306
eropple wrote: post #161

Earlier quoted context omitted.

I disagree that it is the wrong question. "Every other language" doesn't matter because I don't value homogeneity and I think that homogeneity of programming language is a fool's errand. I am comfortable shipping production code in most of the languages in current use; in my estimation, none of the major build systems out there are as opaque or difficult to use correctly as make/shell. (And I am what a current sysadm…

And you are definitely not a sysad or any sort of sysadmin. The core mission of a sysad is to build the best environment possible while restricting that environment. You seem to be the sort of developer that developers love and the sort of sysadmin that gets fired in the first week Just my .02 after two and a half decades. Not to say that you are entirely wrong or your approach doesn't have merit in the new world (es…

Well, you're right, I'm not a sysadmin. I pervasively automate, which often sidelines sysadmins, when it doesn't make them redundant. I write code and I don't touch production machines except in extremity, neither of which apply to most (though by no means all) of the people I know who want to call themselves a sysadmin.

Anyway, the core mission of anybody touching the stack is to enable the business to achieve its goals. Nothing, and I mean nothing, more. "Restricting that environment" is appropriate in some environments, and a number of my clients bring me in to help with that. Facilitating developer velocity--and, yes, developers do tend to like me, because I'm good at this while achieving goals around security and uptime--is appropriate in, probably, more. Pays better, too, even if it shouldn't.

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

#406

Post by zippitydoodah68 »

eropple wrote: post #405
zippitydoodah68 wrote: post #306

Earlier quoted context omitted.

And you are definitely not a sysad or any sort of sysadmin. The core mission of a sysad is to build the best environment possible while restricting that environment. You seem to be the sort of developer that developers love and the sort of sysadmin that gets fired in the first week Just my .02 after two and a half decades. Not to say that you are entirely wrong or your approach doesn't have merit in the new world (es…

Well, you're right, I'm not a sysadmin. I pervasively automate, which often sidelines sysadmins, when it doesn't make them redundant. I write code and I don't touch production machines except in extremity, neither of which apply to most (though by no means all) of the people I know who want to call themselves a sysadmin. Anyway, the core mission of anybody touching the stack is to enable the business to achieve its g…

It's not that sysadmins cannot do the work you are rightfully proud of. If there are two basic things that differentiates your statements from those of a traditional sysadmin it is these.

1. Design. 2. Discipline.

Where these two values are dispensable long term devops and the new world shine through. I've worked in both worlds and the only mistake is assuming one size fits all.

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

#407

Post by JdeBP »

Tharre wrote: post #72
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…

We have 47 half-built over-complicated build systems, because writing build systems is hard. Writing correct Makefiles is also really hard, and good luck debugging them. Make is simple and beautiful for small, self-contained projects without many dependencies, but it does not scale well (and even then it's tricky, see [0][1]). Having 47 different build tools with their own flaws is certainly bad, but they exist becau…

See these discussions, too:

* https://news.ycombinator.com/item?id=15060146

* https://news.ycombinator.com/item?id=15060146

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

#408

Post by nunez »

auslander wrote: post #387
nunez wrote: post #355

I think a lot of stuff that I used to need to know —- OS kernel internals, hardware specifics, relatively deep network knowledge —— is less useful in the age of public cloud, containers and immutable infrastructure. There isn’t really a need to tune a kernel for performance or do deep troubleshooting to root cause OS issues and ensure uptime; if something seems off, kill the machine or container and let auto scaling…

> There isn’t really a need to tune a kernel for performance Maybe, but knowing SElinux, kernel namespaces and syscalls for Docker seccomp profiles are crucial for security, and security is the Next Big Thing. Sad you are getting into management. Lets push to undo that notion that manager is worth more salary than lead engineer. I'm pushing :D

Why is that sad?

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

#409

Post by jchw »

seabrookmx wrote: post #370
jchw wrote: post #121

Earlier quoted context omitted.

A container is basically a glorified chroot, so there is a few things not strictly needed, but I typically use Alpine as a base system, which has a shell, some core utils, and musl libc in just ~5 MB. Since it's on its own layer, it gets deduplicated both in build and at runtime with other Alpine containers (and many Dockerhub images have an Alpine option.) That being said, since Go binaries have no inherent dependen…

> I have indeed made Docker images containing exactly one file To anyone reading this, you need some magic compiler flags in both Rust and GoLang to make sure it's a statically compiled binary (doesn't dynamically link against GNU lib-c). But yes, this is super neat. I also like how it reads in the docker file: FROM scratch ...

Ah yeah, without CGO_ENABLED=0, you'll get a very cryptic error when the ELF binfmt can't find the linker binary...

Never tried it with Rust, but I look to using Rust in the future, so I guess I better find out what the flags are for Rust.

Sidenote: It's often useful to have ca certs and timezone info. At that point it's probably not a bad idea to just use Alpine and apk add those things.

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

#410

Post by auslander »

nunez wrote: post #408
auslander wrote: post #387

Earlier quoted context omitted.

> There isn’t really a need to tune a kernel for performance Maybe, but knowing SElinux, kernel namespaces and syscalls for Docker seccomp profiles are crucial for security, and security is the Next Big Thing. Sad you are getting into management. Lets push to undo that notion that manager is worth more salary than lead engineer. I'm pushing :D

Why is that sad?

Well, you said yourself:

> I start getting into management. That’s a bit saddening

Less one engineer in the world?

Post reply on HN