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

71–80 of 435 posts

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

#71

Post by icebraining »

emilsedgh wrote: post #33
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 think the logic is, if we didn't rely on Containers and prebuilt VM's, Hadoop had to be easier to build to be useful.

I think that is the author's logic. Except it's not very logic, since Hadoop (or Bigtop) doesn't use either.

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

#72

Post by Tharre »

megaman22 wrote: post #14
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

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 because of Make's shortcomings. Just saying "make is fine, use it" won't fix anything.

[0] https://cr.yp.to/redo/honest-script.html

[1] https://cr.yp.to/redo/honest-nonfile.html

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

#73

Post by mkirklions »

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…

Can I complain about pre-built VMs?

I swear by the time I figure out my path problems I have 4 folders named /code/

And my working file system is /code/code/index.php

So when I run node.js (to compile my .scss) it messes up the folder pathing and ugh... why cant we do everything on production?

/rant

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

#74

Post by icebraining »

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…

Is puppet one of those tools?

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

#75

Post by kazen44 »

untog wrote: post #69
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…

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

Here we have another fundemental "problem" between dev and ops.

The inherent friction because of different areas of concern.

Dev's want to build fast and create new features, but sadly (even with the whole devops notion) are usually not thinking about viability in production.

Ops people need to keep thing stable, something which is sadly undervalued a lot of times in companies.

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

#76

Post by davexunit »

myWindoonn wrote: post #9

Reproducible build tools are a thing. Try Nix sometime. nixpkgs has, say, Hadoop. nixpkgs can make Docker containers too.

nixpkgs isn't rigorous about reproducible builds. Hadoop is actually a great example of this. They do not build it from source, a prerequisite for calling a build reproducible. Instead, they download the binaries that the Apache project has already built and run patchelf on them to make them work.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

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

#77

Post by kazen44 »

icebraining wrote: post #74
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…

Is puppet one of those tools?

Depends,

heck. I have seem some guys do magic with CFengine and freeBSD.

(freebsd is a nice OS from an ops perspective anyhow, and has a lot more common sense and sane defaults in a lot of places).

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

#78

Post by agentultra »

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 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 the two camps. When your software developers operate independently of your systems engineers and administrators they're forced to make assumptions about infrastructure, operations, and compliance goals. Both teams have the same goals so why are they not on the same team? I think some "old school" system administrators don't realize how costly such communication mistakes are. Getting 6 months into a development project to be told you cannot have a critical piece of infrastructure _for reasons_ is a costly, costly mistake.

Containers are a smart solution to the build problem. Don't build your containers from public, un-trusted images! Build your own images. Run your own, protected, registry. You still have all of the compliance and validation necessary and you don't end up debugging failed builds because one machine out of a thousand is running on some minor shared library version not supported by your software.

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

#79

Post by AlexCoventry »

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…

The author has added an update to the bottom of the post which I think makes his main intended message clearer:

Update: it was pointed out that this started way before Docker: »Docker is the new ‘curl | sudo bash‘«. That’s right, but it’s now pretty much mainstream to download and run untrusted software in your “datacenter”. That is bad, really bad. Before, admins would try hard to prevent security holes, now they call themselves “devops” and happily introduce them to the network themselves!

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

#80

Post by lbenes »

cwyers wrote: post #13
bovermyer wrote: post #8

Earlier quoted context omitted.

I think the author's point was this: "Unless you compile it yourself, you can't trust it."

There are over 2.9 million lines of code in Apache Hadoop alone, not counting dependencies. If you can't trust Apache, you can't trust Hadoop, regardless of whether or not you can compile it yourself.

There are nearly 10 million lines of code in libreoffice, and yet I can and have built it from source just by typing:

1. $ git clone git://anongit.freedesktop.org/libreoffice/core

2. $ apt-get build-dep libreoffice

3. $ ./autogen.sh && make

Just because something has a large code base doesn't mean we shouldn't be able to build it from source ourselves.

Post reply on HN