2 ms·

The only part of that article I'd clarify is around deployment and devops best practices. You can deploy Elixir exactly the same as any other language. In some

The only part of that article I'd clarify is around deployment and devops best practices. You can deploy Elixir exactly the same as any other language. In some cases, it just means making a decision that you don't need some of the extra features that are available like hot reloading...which every project doesn't need. You can still use immutable images and take advantage of the built in distributed databases by using mounted block storage if need be. You can use everything out there. Early on figuring out some of the port mappings and how to handle things was more difficult but as far as I've seen, those problems have mature solutions all around now.

sanderjd 9y ago
I'm less interested in what you can do, and more interested in which techniques have emerged (or are emerging) as the best practices. For instance, if I want both hot reloading and deployment on AWS, what's the best way to configure and run this? Etc. Are you aware of any devops-for-Elixir focused resources?
- brightball 9y ago
  The only reason I say that is that every project doesn't need hot-reloading. It's one of those things that is only recommended where you need it. Just think of it in the same way that you don't need every available jar file for a Java project. The capabilities of the system are expansive, but not always called for. Distillery is the main deployment related library out there for Elixir and reduces hot reloads to a an argument on the build. https://github.com/bitwalker/distillery/blob/master/docs/Walkthrough.md#building-an-upgrade-release https://github.com/bitwalker/distillery/blob/master/docs/Wal...
  - KallDrexx 9y ago
    Hot reloading also adds a ton of hidden complexity to your projects, since you essentially have to be very careful about every module boundary (as my understanding is that every time code goes from one external module to another non-OTP module it uses the new version of that new module, and thus any non-backwards compatible signature change will crash the process). You can't really casually support hot reloading and need to fully commit to it, unless you don't care if things fail when you hot reload at which point you might as well just do a full reload and keep confidence in the system.

sanderjd 9y ago

I'm less interested in what you can do, and more interested in which techniques have emerged (or are emerging) as the best practices. For instance, if I want both hot reloading and deployment on AWS, what's the best way to configure and run this? Etc. Are you aware of any devops-for-Elixir focused resources?

brightball 9y ago
The only reason I say that is that every project doesn't need hot-reloading. It's one of those things that is only recommended where you need it. Just think of it in the same way that you don't need every available jar file for a Java project. The capabilities of the system are expansive, but not always called for. Distillery is the main deployment related library out there for Elixir and reduces hot reloads to a an argument on the build. https://github.com/bitwalker/distillery/blob/master/docs/Walkthrough.md#building-an-upgrade-release https://github.com/bitwalker/distillery/blob/master/docs/Wal...
- KallDrexx 9y ago
  Hot reloading also adds a ton of hidden complexity to your projects, since you essentially have to be very careful about every module boundary (as my understanding is that every time code goes from one external module to another non-OTP module it uses the new version of that new module, and thus any non-backwards compatible signature change will crash the process). You can't really casually support hot reloading and need to fully commit to it, unless you don't care if things fail when you hot reload at which point you might as well just do a full reload and keep confidence in the system.