4 ms·

I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but

by twic 4y ago

I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1]. That is one step more than deploying a single binary, but it's a trivial step, and both steps are done by a release script, so there is a single user-visible step. The additional pain associated with deploying a tarball rather than a single binary is negligible. It simply is not worth worrying about [2]. But Go enjoyers make such a big deal of this single binary! What am i missing? Now, this post does talk about Docker. If you use Docker to deploy, then yes, that is more of a headache. But Docker is not the only alternative to a single binary! You can just deploy a tarball! [1] We do deploy the JDK separately. We have a script which takes a local path to a JDK tarball and a hostname, and installs the JDK in the right place on the target machine. This is a bit caveman, and it might be better to use something like Ansible, or make custom OS packages for specific JDKs, or even use something like asdf. But we don't need to deploy JDKs very often, so the script works for us. [2] Although if you insist, it's pretty easy to make a self-expanding-and-running zip, so you could have a single file if you really want: https://github.com/vmware-archive/executable-dist-plugin https://github.com/vmware-archive/executable-dist-plugin

simiones 4y ago
Related to [1], I thought modern Java deployment style is to bundle the required modules of the JDK with your app, rather than any concept of a "deployed JDK". As it is, the difficulty of deploying a JDK + your app is much more than a single static binary, Go-style.
- 5e92cb50239222b 4y ago
  It depends on your requirements and environment. With most things I am working on the commands to deploy both look exactly the same: $ rsync -a foo server:/opt/foo $ rsync -a bar server:/opt/bar Can you guess which one is a static binary written in Go, and which one is a directory with a slimmed down JRE produced by jlink + an application jar? For those using containers, there's no practical difference between the two.
x0x0 4y ago
I'm taking the same crazy pills. We did this deployment pattern with a jar in, like... the early 2000s? It's trivial (well, maybe an annoying couple hours to config, but it's a config once and then done) in maven to build a megajar and add every single thing you need into one large jar. All resources, dependencies, etc. And then deployment is, indeed, an rsync.
stanleydrew 4y ago
Your footnotes basically invalidate your argument. You aren't just deploying a tarball, you also have to deploy the java runtime and make sure it's compatible with your application. I agree that Go fans make too much of the single binary feature, but it does seem easier than your deployment process. Of course your process is easy for you because you built it to fit your needs. But if you imagine a new developer who has no experience deploying either Java or Go applications, and consider what's easier to deploy without any previous knowledge or automation, I think you might agree the Go deployment options are simpler.
- layer8 4y ago
  > you also have to deploy the java runtime and make sure it's compatible with your application. That’s not much of a problem in practice though. The JDK is just a tarball as well. You can even combine it with your application tarball into one! (With the drawback that now you have to create one combined tarball per target platform.)
smallerfish 4y ago
We also install the JRE separately, but each app is a single executable (by Java) jar, which stands up a jetty instance when run. We also add a yml for configuration. It's a much better packaging & deploy story than frontend code or python.
- ed25519FUUU 4y ago
  Java comes the closest of any of the languages to Go’s static binary.
  - ihateolives 4y ago
    .Net? You can cross-compile self-contained binary and just drop it on the server.
solatic 4y ago
> Deployment comprises copying the tarball to the server You must not scale servers up and down very frequently then. > both steps are done by a release script, so there is a single user-visible step... we do deploy the JDK separately 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. Look, there's a reason why this way is old-fashioned. If you bought the server outright (i.e. running on-prem/colo), and so it represents a sunk cost, and the usage is all well within the ceiling of what that server is capable of providing, then sure, that's an eminently reasonable setup. If that server is humming along for several years, and electricity/data center costs are cheap, you're probably even saving money. But in most cloud-first architectures, if you're not scaling down on low-usage times, you're wasting money. Scaling up and down is much, much simpler with immutable infrastructure patterns, and it's much simpler to just replace the entire image - whether that's a VM, or a container, or something else - rather than replacing just the application.
- 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.
ardit33 4y ago
twic, you just made the op's point. I too miss the days where you can just ssh/ftp a file, and boom, it was live. (this was usually a php file back then). It is such a great feeling to be able to know whats going on at every step. With increased complexity, so has the deployment process in general. The java steps you described where the beginning of more complex deployments back then (1999-2001) And, yes, I agree with the author in this case. Golang, makes it super simple to deploy a web service.
lenkite 4y ago
There are also some advantages towards the tarball jar encapsulating multiple jar approach - some cloud platform Java buildpacks superbly optimize the deployment process by only sending the differential jars - sometimes just the differential classes - which makes deployment 2x-3x faster than Golang single big bang executable approaches. In our company which leverage both Java microservices and Golang microservices - the Java app deployment is much faster!
ed25519FUUU 4y ago
Without any prior knowledge you can run my little go program on your computer. Can that be said about your program with other people?
- twic 4y ago
  If you are distributing a tool to desktops, and not via a package manager, then i agree that the single binary is a genuine advantage. There are ways to get similar results with Java, packaging code and a JVM into a single file, but they aren't as simple. But the original post we're discussing, and my comment on it, was about deploying to servers.

by twic 4y ago

simiones 4y ago

Related to [1], I thought modern Java deployment style is to bundle the required modules of the JDK with your app, rather than any concept of a "deployed JDK". As it is, the difficulty of deploying a JDK + your app is much more than a single static binary, Go-style.

5e92cb50239222b 4y ago
It depends on your requirements and environment. With most things I am working on the commands to deploy both look exactly the same: $ rsync -a foo server:/opt/foo $ rsync -a bar server:/opt/bar Can you guess which one is a static binary written in Go, and which one is a directory with a slimmed down JRE produced by jlink + an application jar? For those using containers, there's no practical difference between the two.

x0x0 4y ago

I'm taking the same crazy pills. We did this deployment pattern with a jar in, like... the early 2000s? It's trivial (well, maybe an annoying couple hours to config, but it's a config once and then done) in maven to build a megajar and add every single thing you need into one large jar. All resources, dependencies, etc. And then deployment is, indeed, an rsync.

stanleydrew 4y ago

Your footnotes basically invalidate your argument. You aren't just deploying a tarball, you also have to deploy the java runtime and make sure it's compatible with your application. I agree that Go fans make too much of the single binary feature, but it does seem easier than your deployment process. Of course your process is easy for you because you built it to fit your needs. But if you imagine a new developer who has no experience deploying either Java or Go applications, and consider what's easier to deploy without any previous knowledge or automation, I think you might agree the Go deployment options are simpler.

layer8 4y ago
> you also have to deploy the java runtime and make sure it's compatible with your application. That’s not much of a problem in practice though. The JDK is just a tarball as well. You can even combine it with your application tarball into one! (With the drawback that now you have to create one combined tarball per target platform.)

smallerfish 4y ago

We also install the JRE separately, but each app is a single executable (by Java) jar, which stands up a jetty instance when run. We also add a yml for configuration. It's a much better packaging & deploy story than frontend code or python.

ed25519FUUU 4y ago
Java comes the closest of any of the languages to Go’s static binary.
- ihateolives 4y ago
  .Net? You can cross-compile self-contained binary and just drop it on the server.

solatic 4y ago

> Deployment comprises copying the tarball to the server You must not scale servers up and down very frequently then. > both steps are done by a release script, so there is a single user-visible step... we do deploy the JDK separately 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. Look, there's a reason why this way is old-fashioned. If you bought the server outright (i.e. running on-prem/colo), and so it represents a sunk cost, and the usage is all well within the ceiling of what that server is capable of providing, then sure, that's an eminently reasonable setup. If that server is humming along for several years, and electricity/data center costs are cheap, you're probably even saving money. But in most cloud-first architectures, if you're not scaling down on low-usage times, you're wasting money. Scaling up and down is much, much simpler with immutable infrastructure patterns, and it's much simpler to just replace the entire image - whether that's a VM, or a container, or something else - rather than replacing just the application.

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.

ardit33 4y ago

twic, you just made the op's point. I too miss the days where you can just ssh/ftp a file, and boom, it was live. (this was usually a php file back then). It is such a great feeling to be able to know whats going on at every step. With increased complexity, so has the deployment process in general. The java steps you described where the beginning of more complex deployments back then (1999-2001) And, yes, I agree with the author in this case. Golang, makes it super simple to deploy a web service.

lenkite 4y ago

There are also some advantages towards the tarball jar encapsulating multiple jar approach - some cloud platform Java buildpacks superbly optimize the deployment process by only sending the differential jars - sometimes just the differential classes - which makes deployment 2x-3x faster than Golang single big bang executable approaches. In our company which leverage both Java microservices and Golang microservices - the Java app deployment is much faster!

ed25519FUUU 4y ago

Without any prior knowledge you can run my little go program on your computer. Can that be said about your program with other people?

twic 4y ago
If you are distributing a tool to desktops, and not via a package manager, then i agree that the single binary is a genuine advantage. There are ways to get similar results with Java, packaging code and a JVM into a single file, but they aren't as simple. But the original post we're discussing, and my comment on it, was about deploying to servers.