Live data from Hacker News

Ask HN: Who operates at scale without containers?

news.ycombinator.com

221–230 of 446 posts

Re: Ask HN: Who operates at scale without containers?

#221

Earlier quoted context omitted.

Docker is heavier (and more dangerous) because of dockerd, the management and api daemon that runs as root. Actual process isolation is handled by cgroup controls which are already built into the kernel and have been for years. You can apply them to any process, not just docker ones. However, Docker is essentially dead; the future is CRI-O or something similar which has no daemon and runs as an unprivileged user. And…

All the so-called "docker killers" are essentially unfinished products. They don't compare 1:1 to docker in feature set and even if they run as rootless, they still are vulnerable to namespace exploits in the Linux kernel. Though docker runs as root, it's still well protected out-of-the-box for the average user and is a very mature technology.

One of the biggest benefits of k8s for me, back in 2016 when I first used it in prod, was that it threw away all the extra features of Docker and implemented them directly by itself - better. Writing was already in the wall that docker will face stern competition that doesn't have all of its accidental complexity (rktnetes and hypernetes were a thing already)

Re: Ask HN: Who operates at scale without containers?

#222
post #95

Earlier quoted context omitted.

> the rest of the world is improving on those tech Does that matter if the current stack works just fine? Imagine someone who built a calculator app with jQuery javascript 10 years ago, and all it does is add and subtract numbers. You could spend time porting it to Ember, and then migrating to Angular, and then porting it to React, and then porting it to React with SSR and hooks. If the calculator app worked with 15…

The people who are invested in their home-grown solutions are usually pretty bad at doing tech support for them. They enjoy writing code, and it doesn't take long before you've created enough surface area that you couldn't possibly keep up with requests even if you wanted to. Which they don't, because nothing has convinced me of the crappiness of some of my code more thoroughly than watching other people try and fail…

Nice post. I wish I was reading this 6 years ago, but at least I quickly learned to be humble about the quality of my code.

Re: Ask HN: Who operates at scale without containers?

#223
post #6

Earlier quoted context omitted.

At my workplace we use Docker to run services, but there is no container orchestration like Kubernetes. An AMI bakes in some provisioning logic and the container image. Autoscaling does the rest. Even without orchestration, I argue containers are useful. They abstract the operating system from the application and allow you to manage each independently. Much more easily than you'd be able to otherwise, anyway. Plus yo…

I'm in this spot too. It's looks increasingly likely that an orchestration layer is in our near future. But we've got pretty far with this approach.

What factors are causing you at container orchestration as opposed to continuing with your current strategy?

Re: Ask HN: Who operates at scale without containers?

#224
post #65
post #57

Earlier quoted context omitted.

That's a very cool deployment method to just use rsync like that! Simple and very composable. And now I feel self-conscious about my pile of AWS and Docker!

It's 'easy' to do it with rsync and Make as long as you don't have a lot of dependencies. Once you start pulling in dependencies, you have to figure out how to get them installed, hopefully before you roll code that uses them. If the dependencies are small, you can pull them into your source (more or less) and deploy them that way, but that may make tracking upstream harder. (otoh, a lot of things I personally used l…

Just curious, would your deployment method be any different today? If so, how?

Re: Ask HN: Who operates at scale without containers?

#225
post #218

Earlier quoted context omitted.

You already got a few good answers, but I'll echo them: you can do reproducible builds in containers, and nothing's stopping you from using nix inside containers. But you're at the mercy of all the different package managers that people will end up using (apt, npm, pip, make, curl, etc). So your system is only as good as the worst one. I inherited a dozen or so docker containers a while back that I tried to maintain.…

Do your developers run the same Nix packages that you deploy to production? (that sounds like a energy-level-transition in developer productivity and debugging capability, if so)

Yeah, the environment is bit-for-bit identical in dev and prod. Any difference is an opportunity for bugs.

OK, there's one concession, there's an env var that indicates if it's a dev and prod environment. We try to use it sparingly. Useful for stuff like not reporting exceptions that originate in a dev environment.

Basically, there's a default.nix file in the repo, and you run nix-shell and it builds and launches you into the environment. We don't depend on anything outside of the environment. There's also a dev.nix and a prod.nix, with that single env var different. There's nothing you can't run and test natively, including databases.

Oh, it also works on MacOS, but that's a different environment because some dependencies don't make sense on MacOS, so some stuff is missing.

Re: Ask HN: Who operates at scale without containers?

#226
post #126
post #89

Earlier quoted context omitted.

> What works for us is to do the simplest thing that works, then iterate. The older I get, the more often I'm reminded that this un-sexy approach is really the best way to go. When I was younger, I always thought the old guys pushing boring solutions just didn't want to learn new things. Now I'm starting to realize that after several decades of experience, they simply got burned enough times to learn a thing or two h…

Or it could be that you just became old and don't want to learn new things anymore ))

This certainly seems more common. Every time I’ve had to refactor 20 year old cruft it’s been because of engineers with the launch-and-iterate mentality 20 years ago, that stopped caring about the “iterate” part once they gained enough job security.

Re: Ask HN: Who operates at scale without containers?

#227
post #126

Earlier quoted context omitted.

Or it could be that you just became old and don't want to learn new things anymore ))

This is the antivax sentiment of the IT world. It's new! It's shiny! Give me some Ivermectin because I know things other people don't! (Yes, I realize you're probably joking. I'm not, particularly.)

You have it reversed. “I don’t want the new vaccine! Who knows what the long term side effects are!” is equivalent to the technical curmudgeon. The voluntary early trial test group are the bleeding edge tech people. The Ivermectin crowd is the guy that suggests rewriting the backend in Haskell for no good reason.

Re: Ask HN: Who operates at scale without containers?

#228
post #80
post #57

Earlier quoted context omitted.

That's a very cool deployment method to just use rsync like that! Simple and very composable. And now I feel self-conscious about my pile of AWS and Docker!

Containers are just tar.gz files, you know? The whole layers thing it’s just an optimization. You can actually very simply run those tar.gz files without docker involved, just cgroups. But then you’ll have to write some daemon scripts to start, stop, restart, etc Follow this path and soon you’ll have a (worst) custom docker. Try to create a network out of those containers and soon a (worst) SDN network appears. Try t…

You can do a lot with just SystemD today. Would not get surprised if SystemD would eat up Docker too.

Re: Ask HN: Who operates at scale without containers?

#229
post #126

Earlier quoted context omitted.

Or it could be that you just became old and don't want to learn new things anymore ))

Such "new things" are just a big bunch of unnecessary complexity.

Or is cope for a loss of neuroplasticity? Has to be evaluated case by case. “Experience” doesn’t count for much when evaluating new technical tooling. Landscape shifts far too much.

Re: Ask HN: Who operates at scale without containers?

#230

Earlier quoted context omitted.

This is something that even the Docker core team is not entirely clear on (either they understand it and can't explain it, or they don't understand it). The RUN command is Turing complete, therefore cannot be idempotent. Nearly every usable docker image and base image include the RUN command, often explicitly to do things that are not repeatable, like "fetch the latest packages from the repository". This is all befor…

pedantic nit-pick that doesn't detract from your main point: Turing completeness doesn't imply that it can never be idempotent. In fact we'd expect that a particular Turing machine given a particular tape should reliably produce the same output, and similarly any Turing-complete program given the exact same input should produce the exact same output. Turing machines are single-threaded, non-networked machines with no…

Yup, the problem is not that RUN is Turing Complete the problem is that it’s non-hermetic.
Post reply on HN