31–40 of 188 posts
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.
Most of the article reads like "Programming language X is Turing complete, therefore all other programming languages are pointless."
I think Docker is very useful for beginning developers and for spinning up and trying out services quickly. The barrier for getting started with web development used to be so much higher, even for people on Mac OSX. To setup a rails development environment with a modern JS frontend, you'd have to setup xcode, mysql, redis, a node build pipeline, homebrew, and futz with system ruby vs rails-specific ruby. You'd have t…
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.
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.
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.
Whereas my AWS autoscale group does it for me while I go get me a foo foo drink at $ESTABLISHMENT
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.
Whereas my AWS autoscale group does it for me while I go get me a foo foo drink at $ESTABLISHMENT
This is useful for workloads that need to scale on some metric other than CPU/MEM, e.g. request rate, worker queue length...
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.
Whereas my AWS autoscale group does it for me while I go get me a foo foo drink at $ESTABLISHMENT
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 yet that metal box completely revolutionized shipping.
One thing in particular I wanted to respond to and that is the idea of your container filling up with orphan zombie processes because init is not pid 1. If I understand the issue correctly this can only happen if pid 1 creates child processes and then itself dies/exits. I've never personally seen this issue in four years of working with containers, and since all of our containers now run on k8s they would be restarted if pid 1 exited abnormally or otherwise. I'll be interested to see if any other HN commenters have actually had this problem.
Also re: the supposed absurdity of one process per container... it's just simpler and works more robustly with orchestration. Containers are lightweight, so there's no reason to try to pack a whole system into an image. It's simpler to reason about a composition of containers than a mess of processes running inside a single container, imo.