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

Docker Considered Harmful (2016)

catern.com

Post reply on HN
Print view View original

181–188 of 188 posts

Re: Docker Considered Harmful (2016)

#181

Post by koffiezet »

mdekkers wrote: post #176
koffiezet wrote: post #170

Earlier quoted context omitted.

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

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. Do you know the history of Kubernetes? And really, Kubernetes uses "Docker Concepts"?

> Do you know the history of Kubernetes?

Yes I do. Sure it originated from Google and was built with inspired by their internal stack (borg) and a ton of their experience. For a good while though, there was still competition in the form of Mesos/Swarm and unclear what platform would get the upper hand, but k8s emerged as the clear winner here - and in the last year or so - everybody jumped on it.

> And really, Kubernetes uses "Docker Concepts"?

I don't really understand what your problem with that statement would be?

Re: Docker Considered Harmful (2016)

#182

Post by pxc »

quacker wrote: post #140

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…

That alternative tools have their own learning curves (which generally compare unfavorably to Docker's, which is exceptionally gentle) and that you have to make decisions about how to fit them together is a very valid and relevant point.

But it struck me that all of your 'just's really didn't seem like a big deal to me.

I set up a Nix installation on a separate BTRFS subvolume on a Debian-based system that I got as a multimedia PC for my uncle as a gift a few weeks ago. I also had to replace the default initial ramdisk image generator with another one to get the subvolume mounted early enough for systemd to automatically launch services that lived on the Nix subvolume on first boot.

It really didn't seem like that big of a deal for me. Each piece of it was just a small step away from a background of Linux administration knowledge I built up as a teenager when I used to distrohop and play around for fun.

All of this is to say that a difference in background is likely behind this gap of perceptions.

Someone with a background in ops is likely invested in traditions that have different strengths and weaknesses than the approach that Docker offers. For people in positions like that, approaches that are perhaps more involved but preserve more of the virtues of those traditional toolsets may seem like a smaller leap than the one to containers.

You've used the word 'just' here to highlight what to you seem unreasonable levels of difficulty or required background knowledge, which makes sense. But couldn't I just as well say that Docker advocates would have us 'just' abandon the very notion of shared libraries, 'just' try to get by without actually knowing how to build or verify our dependency chains, 'just' grab binaries from strangers on the net, 'just' download gigabytes of binary data to perform builds, 'just' virtualize Linux on macOS in order to use software that runs natively on it, etc.?

At the same time, for things like microservices development, Docker also makes some serious demands on time and knowledge, e.g., 'just' refactor all of your legacy services so they can be safely started in any order or 'just' learn Kubernetes so that your can initialize services in order of dependencies.

Re: Docker Considered Harmful (2016)

#183

Post by ghshephard »

chx wrote: post #162
d4l3k wrote: post #75

Earlier quoted context omitted.

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…

The heavy uses of Docker in my (limited) experience are enterprise stacks with their 15+ components per application and many worker threads that they use to speed up ETL/Parsing/Analytics. Essentially Docker/VMs have replaced the thousands of servers that used to reside in corporate data centers, with the benefit now being that developers can launch those same complex Application stacks with little effort on their laptop.

What used to be a 30+ day procurement process became You can also do things that you would have never even considered doing prior to Docker - like run the application stack in the cloud, but launch one of the components (still in the same deployment) - on your laptop using tools like https://github.com/telepresenceio/telepresence.

Re: Docker Considered Harmful (2016)

#184

Post by ghshephard »

drc0 wrote: post #86
ghshephard wrote: post #24

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.

ok but here you are really advocating kubernetes, not docker.

Sure - but Kubernetes (and many other things) are enabled by Docker. To overuse the Metaphor, containers in shipping weren't a big deal until Container Ports/Cranes/Ships/Trucks came along - we say that "Containers" revolutionized transport as a short hand for all those systems that were built on them.

Re: Docker Considered Harmful (2016)

#185

Post by andrewguenther »

true_tuna wrote: post #85
andrewguenther wrote: post #81

Earlier quoted context omitted.

Three years in and this hasn't happened. Our dev team also does ops and we've found that Docker has improved things markedly. But feel free to keep spreading your FUD.

I’d love for this to be true. Have you had anyone come in and do an audit? I find crazy stuff when I show up at No Ops shops and poke around.

We've done two audits now, only minor items

Re: Docker Considered Harmful (2016)

#186

Post by andrewguenther »

geggam wrote: post #84
andrewguenther wrote: post #81

Earlier quoted context omitted.

Three years in and this hasn't happened. Our dev team also does ops and we've found that Docker has improved things markedly. But feel free to keep spreading your FUD.

Curious... What is your setup ? AWS ? GCP ? ... managed k8s or you running it ? Outsourcing your operations and pretending the problem is cured by docker is just a bit silly.

Docker on EC2. We had been running bare on EC2 before Docker using a homegrown chroot solution.

Re: Docker Considered Harmful (2016)

#187

Post by titanomachy »

mmt wrote: post #149
zbentley wrote: post #127

Earlier quoted context omitted.

> I've tried and failed a couple times to make Debian packages. That's a real problem. Distributions have really dropped the ball here (to varying degrees). But there's a big difference between "Docker is $distribution_package_manager done right!" and "Docker at least sucks less than the alternatives". The tradeoff when packaging via Docker is often in integration with other facilities provided by the OS. Some of the…

> But others are there for a reason: how to integrate with init systems, standard directory locations, shared cache locations, or (god forbid) desktop/windowing systems? Having tried (and succeed) many times in making Debian packages, I can attest to the value of these "hassles" and ones like them. Much of the value is just in making sure one thinks about that whole breadth of issues and how they'll affect your envir…

I hadn't thought of it that way. Thanks for the explanation.

Re: Docker Considered Harmful (2016)

#188

Post by quacker »

pxc wrote: post #182
quacker wrote: post #140

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…

That alternative tools have their own learning curves (which generally compare unfavorably to Docker's, which is exceptionally gentle) and that you have to make decisions about how to fit them together is a very valid and relevant point. But it struck me that all of your 'just's really didn't seem like a big deal to me. I set up a Nix installation on a separate BTRFS subvolume on a Debian-based system that I got as a…

This is a very late reply, but anyway...

> It really didn't seem like that big of a deal for me. Each piece of it was just a small step away from a background of Linux administration knowledge I built up as a teenager when I used to distrohop and play around for fun.

> You've used the word 'just' here to highlight what to you seem unreasonable levels of difficulty or required background knowledge, which makes sense.

I mean, it's great that it's easy for you. And it would be great if everyone at my office conveniently had this same kind of the prerequisite knowledge. But the reality is, most don't. And the worse reality is, most don't enjoy having to learn extra tools on top of the rest of the things they need to know for their job.

Docker is one extra thing to learn. It is easier to learn for the majority of developers that don't have, or don't care to have, any Linux admin background. It is a cross-platform solution and has good adoption in the industry, which means I can probably use Docker at one company, and go to another company and use the same Docker.

> But couldn't I just as well say that Docker advocates would have us 'just' abandon the very notion of shared libraries

Why should I want shared libraries though, given I have containers? I can get an update out by rebuilding an image and rolling the container. Immutable infrastructure is a good thing.

> 'just' try to get by without actually knowing how to build or verify our dependency chains, 'just' grab binaries from strangers on the net, 'just' download gigabytes of binary data to perform builds,

Gigabytes is a gross exaggeration for Docker images, but this applies to almost any package manager. Why is a package in a Debian repository (or similar) any better from a trust perspective than an image in Docker repository? Neither of the package/image maintainers are usually authors of the software.

If you need/want to, you can run your own docker registry, where you only upload self-built images, which completely removes all your trust concerns. You could probably even build docker images with nix.

Post reply on HN