Speaking as somebody who bought in to the Elixir hype early on and who has now been using it in anger, at scale, for over a year…
…releases solve problems that people don’t actually have. Real issues I think the Elixir core team is unaware of or actually ignoring:
Reproducible builds aren’t actually that important for most web apps beyond what mixfiles already support
Hot-upgrading of code doesn’t always work anyways, and just kicking over the server is the time-honored way of solving that in the web dev world. You’ve got multiple servers and do cutover deploys anyways, right? Right?
The “blessed” way of using distillery/exrm involves an intermediate build step, where you pack up and maybe copy around your build between systems. This is slow, and moving around a 100MB tarball is not a great look.
Running git checkout production && mix deps.get && MIX_ENV=prod mix phx.server actually works, and is relatively fast.
The tooling for the remote console is possible without their elaborate build setup, I believe.
I enjoy the language, but the community seems to be really fond of overengineering.
EDIT:
Just to be clear: Erlang and all are great systems, especially for embedded or slow-change stuff. For web work, though, where you have a lot of change happening, you want to be able to do things quickly, and sitting on your hands while a deploy chugs is not a good use of developer time.
Also, the compile time for a moderately-sized Phoenix project is garbage. >:(
EDIT2:
Also Phoenix picking brunch over webpack is slow and not good for real apps. >:(
It isn’t over-engineering when the engineering (OTP releases) is already done :)
What is the intermediate step of copying around a 100MB tarball you are referring to? You get a much smaller install with a release because it doesn’t include all of Erlang and Elixir, only the libraries necessary for running. Docker images for 2 different Erlang projects i have are 16MB and 30MB.
Outside of a docker image those tarballs provide the same ease of deployment and size as a Go binary.
I don’t need a bulldozer to dig a sandcastle, even if we already know how to make bulldozers. :)
It’s possible our release pipeline is a bit goofed up (it’s inherited, and other folks on the team are v. committed to the “Elixir Way” of doing things, regardless of how much more annoying it is), but if you keep the server version of Erlang/Elixir in sync you don’t even have to ship a release–much less deal with the clowncar of docker.
Then again, I think most devs just don’t want to think about ops and don’t want to spend time properly caring for and feeding servers!
EDIT: And to be clear–I’m not saying you’re doing anything wrong…if it works for you, it works. It just doesn’t work for us, and it’s a constant thorn in my side.
Oh, meant to say you are right about hot-upgrading. It is mostly a waste of time. Few use it and even fewer need it. It is great if you need it. With environments like kubernetes catching on it will likely be misused less.
And you don’t have to include erts in the release, it just makes deployment simpler.
It is true some will always prefer source checkout, build, run. And that will be fine for a hell of a lot of projects. But I still think releases provide an (ultimately) easier and more consistent deployment artifact.
The issue is the tooling needs to make getting to that artifact simpler. I hope this effort makes that the case :). It was my goal with rebar3 and it integrating relx instead of relying on reltool, and with this new push from bitwalker and the core Elixir team may be we’ll end up with some improvements to OTP as well.
Speaking as somebody who’s run Elixir in production/anger, at scale, for over two years…
…I like these plans but I don’t think they address the biggest current pain points for deploying Elixir apps.
Releases absolutely do solve real problems:
Having a single artifact to deploy is convenient. If 100MB is too big for you, stash your releases in whatever blob store is closest to your servers (e.g., store in S3 for servers in EC2).
Hot-upgrading of code works for about 95% of my deploys, and it means I don’t drop websocket connections. I cache stuff in server RAM, so having a user stick to a server is good for my service.
The heart heartbeat monitor works very well. I won’t run without it. It’s helped us recover from temporary or isolated outages much faster.
bin/myapp remote_console is good for the times when you need to debug something really nasty, live.
The actual pain points I’ve experienced:
Autoscaling in a way that is compatible with hot upgrades. For this, we hacked Edeliver to pull its list of production hosts from an aws CLI command that matches on some AWS tags, configured Edeliver to store releases in an S3 bucket, and configuring each server to grab the latest S3 release and run it at boot time. This works well.
Deploy automation. For this, I wrote a fairly simple tool called derp on top of Edeliver, to execute a given command for or on each server in succession. It works but not well enough to fully automate; deploys are still executed by an engineer.
Slow compiles. No solution here yet.
If you thought compiles were slow, add Dialyzer to your CI tests. Mitigations have been proposed. But this has nothing to do with releases.
Speaking as somebody who bought in to the Elixir hype early on and who has now been using it in anger, at scale, for over a year…
…releases solve problems that people don’t actually have. Real issues I think the Elixir core team is unaware of or actually ignoring:
git checkout production && mix deps.get && MIX_ENV=prod mix phx.serveractually works, and is relatively fast.I enjoy the language, but the community seems to be really fond of overengineering.
EDIT:
Just to be clear: Erlang and all are great systems, especially for embedded or slow-change stuff. For web work, though, where you have a lot of change happening, you want to be able to do things quickly, and sitting on your hands while a deploy chugs is not a good use of developer time.
Also, the compile time for a moderately-sized Phoenix project is garbage. >:(
EDIT2:
Also Phoenix picking brunch over webpack is slow and not good for real apps. >:(
It isn’t over-engineering when the engineering (OTP releases) is already done :)
What is the intermediate step of copying around a 100MB tarball you are referring to? You get a much smaller install with a release because it doesn’t include all of Erlang and Elixir, only the libraries necessary for running. Docker images for 2 different Erlang projects i have are 16MB and 30MB.
Outside of a docker image those tarballs provide the same ease of deployment and size as a Go binary.
I don’t need a bulldozer to dig a sandcastle, even if we already know how to make bulldozers. :)
It’s possible our release pipeline is a bit goofed up (it’s inherited, and other folks on the team are v. committed to the “Elixir Way” of doing things, regardless of how much more annoying it is), but if you keep the server version of Erlang/Elixir in sync you don’t even have to ship a release–much less deal with the clowncar of docker.
Then again, I think most devs just don’t want to think about ops and don’t want to spend time properly caring for and feeding servers!
EDIT: And to be clear–I’m not saying you’re doing anything wrong…if it works for you, it works. It just doesn’t work for us, and it’s a constant thorn in my side.
Oh, meant to say you are right about hot-upgrading. It is mostly a waste of time. Few use it and even fewer need it. It is great if you need it. With environments like kubernetes catching on it will likely be misused less.
And you don’t have to include erts in the release, it just makes deployment simpler.
It is true some will always prefer source checkout, build, run. And that will be fine for a hell of a lot of projects. But I still think releases provide an (ultimately) easier and more consistent deployment artifact.
The issue is the tooling needs to make getting to that artifact simpler. I hope this effort makes that the case :). It was my goal with rebar3 and it integrating relx instead of relying on reltool, and with this new push from bitwalker and the core Elixir team may be we’ll end up with some improvements to OTP as well.
Ill add you had more details about perceived failings in this comment which I found interesting.
Speaking as somebody who’s run Elixir in production/anger, at scale, for over two years…
…I like these plans but I don’t think they address the biggest current pain points for deploying Elixir apps.
Releases absolutely do solve real problems:
heartheartbeat monitor works very well. I won’t run without it. It’s helped us recover from temporary or isolated outages much faster.bin/myapp remote_consoleis good for the times when you need to debug something really nasty, live.The actual pain points I’ve experienced:
awsCLI command that matches on some AWS tags, configured Edeliver to store releases in an S3 bucket, and configuring each server to grab the latest S3 release and run it at boot time. This works well.derpon top of Edeliver, to execute a given command for or on each server in succession. It works but not well enough to fully automate; deploys are still executed by an engineer.Thanks for the comment! What are you all using Elixir for? What sort of load?