pushing ever more annoying ideas

No images? Click here

I am on vacation. This is all the work I intend to do.

 

Hot code upgrades

If you want to start coming to grips with how Erlang/Elixir can do hot code updates I think you'll find this and this article useful. Castle seems like a great library for helping actually do it.

More on Hot Code Upgrades in a moment.

     

    To Code BEAM & Back Again

    I'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.

    Help me share it? Mastodon, Twitter, LinkedIn

    Thumbnail of me with caption "Is one day of conference worth travelling for?"

    Watch it on YouTube

     

    Deploy harder

    In 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:

    • Versioning your internal GenServer APIs
    • Writing migrations in the form of GenServer.code_change callbacks
    • Writing tests for those code migrations
    • Coordinating how apps and releases should update (appups and relups)
    • Shipping updated code in case of a restart
    • Handling upgrades affected by updated dependencies

    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.

     
     

    This is an email from Underjord, a swedish consultancy run by Lars Wikman.

    Everything else is found at underjord.io

    You signed up for this newsletter and confirmed the subscription. If you want to stop receiving it. Just use the link below.

    Preferences  |  Unsubscribe