4 ms·
I really like Erlang and Elixir, but I'm really worried when I see a tech stack that is still trying to figure out deployment and runtime configuration of syste
by dudul 8y ago
I really like Erlang and Elixir, but I'm really worried when I see a tech stack that is still trying to figure out deployment and runtime configuration of systems.
I'm not trying to be inflammatory here. As per many resources such as "Phoenix in Action" deployment is still a major culprit. And Dockyard themselves (one of the major Elixir shops, where McCord works actually) have a full time guy on the payroll to try to solve the problem of runtime configuration.
It just sucks, because these are 2 major concerns of any production-ready stack.
- brightball 8y agoIt’s not so much an issue as it is something they want to make cleaner for new users. If you are coming for a background in other languages, the process doesn’t behave like you’re already used to. So much of the work that Jose and Chris put into Elixir and Phoenix is striking the balance between what’s possible and what the onboarding experience looks like for new users.
- apabepa 8y agoI am not sure what you mean with production-ready here. Erlang has certainly been used in production, not only Whatsapp but also have a lot of production systems in telecom where requirements on up-times etc are pretty high. If you mean that there are no ready made off-the-shelf standard way to handle runtime configuration and deployment I guess it is because the big telcom products usually roll their own per product so it haven't made it into the OTP backlog.
- lemur-dev 8y agoWhile I agree that deployment can still improve, it is mostly because it doesn’t have the same polish as everything else Elixir ships with. In any case, it has already improved considerably over the last year. My first application was deployed to Heroku and it just worked. For AWS, we had to do some research but once we got Distillery running, everything worked without major concerns. And Distillery uses Erlang releases which have been around for decades so we can rely on its stability. Btw, runtime configuration works like a breeze in Distillery 2.0, which is the result of Paul’s amazing work at Dockyard (among other things).
- toast0 8y agoDeployment for Erlang needs to be a lot more flexible than other systems, because you have the opportunity to hotload code as a core feature [1], having your deployment solution invoke code loads is totally scriptable, but seems more likely to want human eyes watching than a traditional push, stop, start cycle. OTP does provide the application construct which is supposed to provide some amount of configuration and start/stop/update support; although my team doesn't use the update support, we just push code and hotload it or stop and start beam depending on the changes. [1] of course, you can hotload code in most languages if you try hard enough, I've done it in C and almost did it in perl; as long as you can load code and get a function pointer at runtime, you should be able to make it work.
- pmarreck 8y agoFor managed deployment (with a free tier) check out https://www.gigalixir.com/ https://www.gigalixir.com/
- rkangel 8y agoFor one datum, as an inexperienced Phoenix user, it took me 1 day to get a Phoenix app deployed and running on Google App Engine flex, including DB and some other details.
- yawaramin 8y agoYeah but an Erlang deployment is roughly equivalent to a Kubernetes deploy (more powerful in some ways), are you similarly worried about the amount of effort it takes to set up a k8s cluster?