Yes, of course.

Nope, every time I looked into it, it looked to introduce more problems than it solves. Having a load balancer that drains the connections to the old VM / pod on deploying a new one has worked super stably with complete zero-downtime so far (though it does require slight trickery sometimes f.ex. if you keep a local GenServer state and that controls rate limiting to a sensitive resource you are very likely to temporarily go over the rate limit due to lost state).

Mix, Docker, docker-compose and scripts to check for container / pod readiness & liveness. Also for initial DB setup and seeding (the PostgreSQL official Docker container allows you to drop scripts into a special directory and the DB will execute them all before announcing it’s ready).

Web / API and Telecom. The main one I am working on right now is listening for messages on a broker’s queue (in this case Kafka but we are researching alternatives) and then communicates with SIM cards worldwide.

1. Yes
2. No. It seem to be too easy to shot yourself in the foot (possibly without noticing it) for the usually small amounts of upsides (in my work). Would love to learn more if that’s an incorrect assumption though or if there’s reliable ways to detect issues for someone without extensive experience doing them.
3. Mix to build the release. Systemd and/or docker for running it.
4. Mostly Web, some IoT

1. Yes.
2. No. Would like to but it does seem complicated and not available in releases so didn’t give much more thought.
3. Mix and the release with systemd.
4. Web.