4 ms·

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,

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.

geggam 8y ago
Whereas my AWS autoscale group does it for me while I go get me a foo foo drink at $ESTABLISHMENT
- joshribakoff 8y ago
  Kubernetes also has auto scale.
- dharmab 8y ago
  You can use one of the two container autoscalers to handle the scaling automatically based on any metric(s) you like, and the cluster autoscaler will scale the ASG as needed :) This is useful for workloads that need to scale on some metric other than CPU/MEM, e.g. request rate, worker queue length...
- merb 8y ago
  sadly it's not cheap to built aws on bare metal.
  - geggam 8y ago
    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 ?
    - merb 8y ago
      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)
dharmab 8y ago
For those who haven't used k8s, note that `--context` and `-n` are mostly of multi-tenant/RBAC cases, so the command is more like `kubectl scale deploy <deployment name> --replicas <number of containers>`
joshribakoff 8y ago
Spinning up 100 nodes kubernetes clusters w/ a single button click across multiple public clouds with Rancher is pretty exciting too. You can scale up your worker pool by clicking on a spinner input in the Rancher UI instead of typing the kubectl commands. Heck, its built right into the Kubernetes GUI as well. Pretty cool.
NightlyDev 8y ago
One could do the same thing with other stuff too. Everything from bare metal to other application containers, and everything in between. I do think that docker is very overhyped, but it does also solve some problems in a good way, even though it also creates new problems.
chx 8y ago
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.
- d4l3k 8y ago
  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 https://stackexchange.com/performance Your average site wouldn't get anywhere near the same performance as them.
  - zbentley 8y ago
    I think GP was pointing out the inefficiencies rife in "cloud scale" architecture these days, not saying that anyone can scale to StackExchange levels on a single instance.
  - chx 8y ago
    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.
    - ghshephard 8y ago
      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 <7 days with VMs, became < 15 minutes with docker/kubernetes. 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 https://github.com/telepresenceio/telepresence.
drc0 8y ago
ok but here you are really advocating kubernetes, not docker.
- ghshephard 8y ago
  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.
mdekkers 8y ago
There is nothing more awesome than seeing, on the fly, your worker pool being scaled out by 100x This was possible, and done, long before kubernetes or docker. The frequent counter-argument I hear is that "kubernetes makes it easy" - which is often espoused by people that don't have to build or manage kubernetes in prod.

geggam 8y ago

Whereas my AWS autoscale group does it for me while I go get me a foo foo drink at $ESTABLISHMENT

joshribakoff 8y ago
Kubernetes also has auto scale.
dharmab 8y ago
You can use one of the two container autoscalers to handle the scaling automatically based on any metric(s) you like, and the cluster autoscaler will scale the ASG as needed :) This is useful for workloads that need to scale on some metric other than CPU/MEM, e.g. request rate, worker queue length...
merb 8y ago
sadly it's not cheap to built aws on bare metal.
- geggam 8y ago
  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 ?
  - merb 8y ago
    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)

dharmab 8y ago

For those who haven't used k8s, note that `--context` and `-n` are mostly of multi-tenant/RBAC cases, so the command is more like `kubectl scale deploy <deployment name> --replicas <number of containers>`

joshribakoff 8y ago

Spinning up 100 nodes kubernetes clusters w/ a single button click across multiple public clouds with Rancher is pretty exciting too. You can scale up your worker pool by clicking on a spinner input in the Rancher UI instead of typing the kubectl commands. Heck, its built right into the Kubernetes GUI as well. Pretty cool.

NightlyDev 8y ago

One could do the same thing with other stuff too. Everything from bare metal to other application containers, and everything in between. I do think that docker is very overhyped, but it does also solve some problems in a good way, even though it also creates new problems.

chx 8y ago

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.

d4l3k 8y ago
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 https://stackexchange.com/performance Your average site wouldn't get anywhere near the same performance as them.
- zbentley 8y ago
  I think GP was pointing out the inefficiencies rife in "cloud scale" architecture these days, not saying that anyone can scale to StackExchange levels on a single instance.
- chx 8y ago
  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.
  - ghshephard 8y ago
    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 <7 days with VMs, became < 15 minutes with docker/kubernetes. 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 https://github.com/telepresenceio/telepresence.

drc0 8y ago

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

ghshephard 8y ago
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.

mdekkers 8y ago

There is nothing more awesome than seeing, on the fly, your worker pool being scaled out by 100x This was possible, and done, long before kubernetes or docker. The frequent counter-argument I hear is that "kubernetes makes it easy" - which is often espoused by people that don't have to build or manage kubernetes in prod.