3 ms·
> You must not scale servers up and down very frequently then. Indeed we don't. But i don't see why it would be a problem if we did. If you can run a script to
by twic 4y ago
> You must not scale servers up and down very frequently then.
Indeed we don't. But i don't see why it would be a problem if we did. If you can run a script to copy a Go binary to a VM when you scale up, you can run a script to copy a tarball and unpack it. If you're scaling based on a prepared image, then you can prepare the image by unpacking a tarball, rather than copying in one file.
> Wait, so it's not really a single user-visible step. You have one user-visible step to deploy the application server, and a different user-visible step to deploy the JDK.
Oh come on! If that matters to you, change the app deployment script to run the JDK deployment script first. Bam, one step.
> Scaling up and down is much, much simpler with immutable infrastructure patterns
Sure, and as far as i can see, this is completely orthogonal to having a single-file deployment. You haven't made any case at all for why having single-file deployment is valuable here.
- solatic 4y ago> If you're scaling based on a prepared image, then you can prepare the image by unpacking a tarball, rather than copying in one file... as far as i can see, this is completely orthogonal to having a single-file deployment. You haven't made any case at all for why having single-file deployment is valuable here. If you have a prepared image / immutable infrastructure pattern, that image is the single-file pattern. Container images are tarballs. Go isn't actually all that special here, if you compare apples to apples in containerized deployments: either you bake the standard library into the binary (which Go does), or you bake the standard library into the tarball (which the JDK forces you to do). Either way it's a single file.