[dmitriid]

For all that to work you will need:

- to understand exactly what your app is doing

- to understand exactly what Erlang/Elixir releases are doin

- to understand exactly how cod upgrade works

- to understand exactly or very damn well how to make the system handle those 1 million connections

- to understand exactly how to handle all the things you wrote about

And then, and only then will you be able to "think about being able to deploy without forcing all X million to try to reconnect at the same time."

There are no magic bullets.

[brightball]

Eh...it’s basically a 1 line command with distillery. Another for the rollback capability.

It’s pretty magical. There’s a reason people love it.

Certainly, don’t use it if you don’t need it...it introduces extra complexity...but if you do it’s really hard to beat.

[cryptica]

Having to support two different versions of the Elixir service during the rollout period is risky...

What if something goes wrong during the rollout? For example, if you change the database schema or upgraded your database engine or changed your back end authentication approach, it can break the old code. Then how will you know whether it's a problem with the old code or new code if many nodes are running both?

[brightball]

Those are things you have to account for in any zero downtime deploy situation though. It’s mostly minor changes in how you roll out schema changes.

[dmitriid]

I was mostly listing things you need for Erlang. Elixir, thankfully, hides a lot of things away in much friendlier packages.

That said, even with Distillery, if something goes awry, you'll need to know the warts behind the magic :)