Live data from Hacker News

Docker Considered Harmful (2016)

catern.com

161–170 of 188 posts

Re: Docker Considered Harmful (2016)

#161

Sure. I "just" have to go read man pages for days to understand 20 different commands. "Just" use several commands to isolate my not-a-container. "Just" use debootstrap (or not on different distros!), or actually maybe "just" use nix and guix. And "just" carefully use several btrfs-subvolume commands (or not if you want aufs, zfs, or something else!). And "just" a few more things after that - maybe "just" use systemd…

Exactly.

I fail to see how having to understand the internals of Linux containers and writing custom C programs is easier than writing a Dockerfile and running docker build.

Re: Docker Considered Harmful (2016)

#162
post #75
post #52

Earlier quoted context omitted.

I am absolutely sure there are usecases for that. But the truth is, most websites will happily run on a single dedicated machine you rent for a few hundred dollars. (OK, two, so you have a hot spare, if you so fancy.) This fact often gets overlooked despite even Stackexchange tweeted once or twice they could run their site with a single DB server. But: cloud! Kubernetes! Hype. Meh.

Stack exchange has spent an obscene amount of time optimizing their infrastructure for efficiency on dedicated known hardware. Their DB instances also have 1.5TB of ram. You're not getting that for a few hundred dollars. https://stackexchange.com/performance Your average site wouldn't get anywhere near the same performance as them.

Let's unpack my statement because it might have been too dense.

1. Almost all websites can run on a single dedicated server.

2. This is true for even something as big as Stackexchange which most sites are not.

3. If your site is indeed smaller than SE then that server is likely to be a few hundred dollars a month.

Also: getting a 512GB RAM server for 5-700 USD or so is definitely possible these days. But, again, most sites won't need anywhere near that. Based not only on information and belief ;) but first hand experience I sincerely doubt most sites would need more than 64GB.

Re: Docker Considered Harmful (2016)

#163
post #44
post #38

Earlier quoted context omitted.

sadly it's not cheap to built aws on bare metal.

And you think k8s is simple to run on bare metal ? To care and maintain ? Do you understand the kernel tuning and routing Google does to avoid the NAT hell you are going to run into when you manage k8s on your own ?

I actually run 3 small bare metal clusters in production.

Maintain is basically just a `kubeadm upgrade` on all nodes + reboot (easily scriptable), after some updates get announced. OS Upgrades are done through container-linux-update-operator.

NAT is not a problem if you are below or equal to 50 nodes. Not sure if you run into problems if there are more nodes, thought. Also BGP+metallb is quite good.

(P.S.: openstack uses NAT heavily as well. and IPVS for k8s should fix most problems if you are running into problems)

Re: Docker Considered Harmful (2016)

#164
"Wordpress Considered Harmful"

Why not host your own blog with Bootstrap?

...

Every tool trying to simplify or standardise something will inevitably be met with critisism from someone saying: 'but it's not hard, you just do ', completely missing the point.

Re: Docker Considered Harmful (2016)

#165

Sure. I "just" have to go read man pages for days to understand 20 different commands. "Just" use several commands to isolate my not-a-container. "Just" use debootstrap (or not on different distros!), or actually maybe "just" use nix and guix. And "just" carefully use several btrfs-subvolume commands (or not if you want aufs, zfs, or something else!). And "just" a few more things after that - maybe "just" use systemd…

Then "just" figure out how to run all of these commands over the network so that you could connect several hosts together.

Then "just" fix all of the bugs and holes in the security of this implementation.

Docker _is_ by itself a bunch of shell scripts managed by a networked daemon.

Re: Docker Considered Harmful (2016)

#166
post #120

This article is ignoring the benefits of standardization. Let's compare it to some other "unnecessary" thing, actual containers: You can put stuff on ships without them, but turns out that once you start using them, just the fact that everything is standardized gives you insane benefits. Of course you could reimplement each part of Docker differently. Of course it's not magic. Nothing is magic about a metal box, and…

That's a nice metaphor, but it's still not at all certain that Docker is the standard solution. We've had Linux for 20 years and we still don't have a single standard package manager; Docker's been around for 5 years and it's already been abstracted over by systems like Kubernetes, making Docker itself less and less relevant. What is certain is that systems like Debian and Fedora are not going away. Your Docker image…

> and it's already been abstracted over by systems like Kubernetes, making Docker itself less and less relevant.

But k8s still uses the same concepts used with docker-style 'containers', with registries, layered, isolated filesystem, separate networking, ... all in one box.

Docker was just a big nudge in the direction of democratising scalable cloud infrastructure/application stacks. Yes it can be used for other stuff, but that's what it's extremely good at.

Re: Docker Considered Harmful (2016)

#167
post #143
post #58

Docker wins because it's easy to use and becomes a de-facto standard. The author misses that completely. I get it, you can do "manually" the same things as docker when you're a good system administrator. You'll come up with your own unique solution to most problems addressed by docker. Regardless of the fact that it'll probably be specific to a single linux distribution, you probably won't have anyone interested in i…

> Docker wins because it's easy to use. > The author misses that completely. That's inconsistent with what the article says right in the introductory paragraph: > Docker is genuinely more complex and harder to use than the alternatives. > I'm recommending them because they are simpler to learn and use. You may disagree with their relative ease, but it's disingenuous to say that the author misses that. > You'll come u…

That's bullshit. To start a docker container, you don't need to mount a layered filesystem image - nevermind figure out a way how to create and reuse it, you don't need to know all nitty-gritty details of creating network interfaces, private networking, port forwarding with NAT, cgroups, and a ton of other details that are simply not important to get an application running. Docker does that for you.

If you would have to get read all man pages for every single tool you'd have to get familiar with just to figure out how a custom "not invented here" system works - you'd be in for a treat...

Re: Docker Considered Harmful (2016)

#168
post #107

Earlier quoted context omitted.

> One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations. Vagrant does this, too. Sure, it runs a VM, but so does Docker.

Vagrant runs a VM per app . Sometimes more. Big difference.

Well, a VM per sensible unit of configuration management the user is supposed to choose. An "app" is a very slippery concept.

Re: Docker Considered Harmful (2016)

#169
post #52

Docker by itself probably doesn't make any sense to an engineer until they get a chance to see kubernetes in action. There is nothing more awesome than seeing, on the fly, your worker pool being scaled out by 100x by nothing more than kubectl --context k8s-uw1a-gcp -n customerx scale deploy someapp_worker --replicas 100 to make you appreciate what docker can do for you.

I am absolutely sure there are usecases for that. But the truth is, most websites will happily run on a single dedicated machine you rent for a few hundred dollars. (OK, two, so you have a hot spare, if you so fancy.) This fact often gets overlooked despite even Stackexchange tweeted once or twice they could run their site with a single DB server. But: cloud! Kubernetes! Hype. Meh.

Having a worker pool in the first place, with carefully automated agents that magicically begin working when spawned, makes the complexity of managing their launch almost negligible.

Re: Docker Considered Harmful (2016)

#170
post #146

Plus one for the scathing and unapologetic criticism of Docker. I'm admitedly pretty inexperienced with Docker, but I feel like everything I've read on it seems to have virtually nothing bad to say about it, so it's nice to hear an opposing opinion. That being said, this also feels like a "Get off my lawn" type of rant from an experienced devoloper who is stuck in their ways, and/or has a little bit too big of an ego…

> Maybe Docker is just reinventing the wheel...

Docker is way more than that, and he's completely ignoring the bigger picture, and many people seem to be missing that. It's importance is not limited to "my little server" - it's the concepts that matter - not the technological details. Docker standardised a set of concepts, which have been adopted at a rapid pace for a reason. It's no accident big corporations like RedHat Google, Microsoft, Amazon are jumping on Kubernetes (which uses the docker concepts, and massively extends them), for cloud deployments, it's the future.

It enables a standard way to quickly deploy and configure applications in a relative standardised way, and democratised doing this at cloud-scale. Sure you can use it locally and for smaller-scale, but that was never that hard, although it made it easier and faster too in some situations.

I'm a devops/sysadmin guy that introduced docker to quite a few developers, and most were very hesitant and sceptical at the beginning. But once they saw the power of what docker can do for them, that attitude quickly changed - and a lot went overboard with it initially (as did I in the early days I must admit).

Stuff the devs especially loved was the fact that with a single command, they could launch the entire application stack of whatever project they were working on locally, and with another command stop or destroy it. Database servers, amqp/rabbitmq/..., reverse proxies with path rewriting, ... One person had to maintain the docker-compose config, all the others just did 'docker-compose up -d'. It also allowed them to easily add dev supporting services like mailhog, that fakes an SMTP server, where they could visualise the emails they sent in a webui, add a chaos monkey for testing, ...

For ops it also made stuff easy - the "works on my machine" virtually disappeared or at least was very quick to fix. Configuration and deployment was clear and straight-forward, even if eventually it wasn't deployed on docker.

Post reply on HN