The Distillery documentation specifically speaks to why releases can still be advantageous, even in the context of a Docker image.
Straight from the horse’s mouth:
That latter bit may make you think that OTP releases aren’t necessary when building with Docker, but they still have considerable value even there: release packages are stripped down, and so produce smaller images; releases are also configured to be automatically set up for distribution, which means they can be easily configured into a cluster, but more importantly they are ready to be remotely administered via remote shell if needed. When deploying source and running via Mix, you have to take extra steps to make sure the node is properly configured for this.
…the application or applications the project defines (and their associated dependencies), are compiled, bundled up together in a single package, and upon startup, loaded and then started in dependency order.
To make this even more explicit, all of your application’s modules are loaded before anything is started, which is not the default behavior for launching with Mix, and that latter approach can introduce one-time delays when a loaded module calls a function on a not-yet-loaded one. The preloaded approach provides more consistent baseline performance in a freshly-launched container.
Anyway, you fundamentally can’t run a project that still depends on Mix to launch, without having the full Elixir and Erlang runtime environment present. This means you’ve got big, inefficient images to sling around, even if a fair amount of the base image can be broadly cached and re-used by the Docker daemon. If you’ve got a highly elastic workload, with underlying hosts coming and going, that cache hit rate can be fairly poor. If you’re using a registry that’s not part of your IAAS provider, such as Docker Hub or Quay, you’ll be paying transit costs on the bytes transferred. If you need to rapidly burst to a higher capacity, you’re at the mercy of the time it takes to pull those hefty images.
A slight adjustment in approach means you can have svelte images that don’t include anything more than what’s necessary for your runtime requirements. With multi-stage builds that have been available in stable Docker releases since 17.05, this is exceptionally easy to accomplish with no external tooling or strange workflows.
A fully-capable image built from a Distillery release on an Alpine base is around 40-60MB total for most of us, while the official Elixir base images are ~90MB for 1.8-alpine and a whopping 1.08GB for 1.8.
I don’t personally think expediency is a worthwhile motive to absorb all of the aforementioned downsides.
