pushing ever more annoying ideas No images? Click here I am on vacation. This is all the work I intend to do. To Code BEAM & Back AgainI've gone to every Code BEAM Stockholm I have been able to since I started Elixir. I like conferences and the reworked Erlang-focused conference has widened beautifully into a more complex mixture of Erlang, Elixir and occasionally other things. Deploy harderIn my previous piece I wrote about some intricate deployment ideas I have and there is a natural next step if you want to get really BEAM:y about shipping your code. Just do hot code upgrades. Never do a blue-green again. Just ship new code and your app should be none the wiser. I really want to try doing this. I think it would be a terrible idea in terms of return on investment. You take one of the most challenging parts of having a database and the worst thing to get wrong. Schema evolution. And you introduce it to your app. If there is a good ROI on this it is probably related to the amazing processes and discipline you needed to establish to not fuck it up that also lead to a bunch of other upside. Or maybe the state isn't that sensitive and a screwy upgrade isn't so bad. I haven't tried. What makes hot code upgrades challenging and what makes even people who know how they work often opt out of using this massive OTP feature? Well they require a few things:
I don't know how tricky some of these are. I think the dependencies one is probably full of devils because essentially no libraries ship with code_change callbacks for any built-in GenServers. So you'd need to make sure that your app will recover to a sound state if there are a few GenServers crashing and restarting instead of upgrading peacefully. Overall the typical case might end up being akin to "our GenServers all crashed on the old state and then came back fine". Many apps use GenServers for mostly ephemeral stuff and in that regard this might be less annoying than it seems. Overall I think there is more cognitive overhead to reason about a running system that only changes piecemeal than there is for reasoning about a fresh start. So while I'm tempted. If I am going to experiment with deployments, I would likely not go for hot code updates. Then again I've seen people mention it as a big upside and a very fast way to deploy updates. Overall, for the good of most teams I wouldn't recommend adding the challenge of another typ of data migrationto your system. But if you've done it I want to hear about how it went. Should our code upgrades be hotter? Email or poke me on the fedi @lawik@fosstodon.org. Thank you for reading. I appreciate you spending some of your moments on this. |