In terms of deploying a phoenix application to aws or gcloud, how does hot redeploy work when you use docker? My guess is that when you use docker, it is more of a immutable deployment type strategy and therefore you kind of drop the whole erlang hot code redeploy feature correct? i.e. its a cool feature but if you are going with a docker container it doesn’t make much sense.
(every application is different, every software release is different), however, you are thematically at the same place we have ended up. hot module loading takes some mental cycles, and depending on the changes can really make you dance from an operations standpoint.
Whereas, for alot of normal software upgrades, spinning up a fleet with the new code and flipping the loadbalancer over to the new version is far simpler, and simpler can mean greater stability, confidence and lower cost. Now that aws has per second billing, docker vs ami instances, vs lamda is all a flavor of the same. Leaving the old instances hot for a time also allows a simple rollback in the case of a bad release (it happens).
db schema migrations and changes to core data structures are of course another part of the dance, which is not impossible with hot loading, but certainly more complex.
In a complete reversal, I find hot loading to a huge win in the edit/test/debug cycle on the development side.
