I actually gave a talk recently on our hosting journey for Elixir. The TL;DR is that we started on Heroku, went to Gigalixir, and then finally landed on AWS. I’d definitely recommend using a combination of ECS for running the Elixir service and then using RDS for the DB. It’s a great set up and we’re super happy with it.
I run PG in several sites and as of yet, none of them have required me to tweak my PG configuration. I’ve also not heard people complaining that PG is poorly optimised out of the box, just the opposite - that it’s so stable and efficient coming from DBs like MySQL
Perhaps if you’re running on tight hardware it might need tweaking, but on a dedicated server, I just can’t see it being an issue tbh.
I agree that it depends on what’s on the server - though even then you can do things like Raid arrays for contingency, off-server backups, etc. If you felt you really had to set up something like barman there are lots of online guides that would help.
99% of the things I have learned about servers is via such guides and forum posts
I think that’s a large part of it too - if you loathe it then don’t do it I don’t mind it, I quite like it because I feel as though I’m more in control of what I can do and don’t feel as restricted.
I run PG in several sites and as of yet, none of them have required me to tweak my PG configuration.
The fact you haven’t done it doesn’t mean your systems wouldn’t run better with time spent doing it though it just means they don’t run poorly enough for you to care.
Perhaps if you’re running on tight hardware it might need tweaking, but on a dedicated server, I just can’t see it being an issue tbh.
It’s actually the opposite. The default config is targeted at non-dedicated setups with limited memory availability. Most of the changes I make on a new postgres server involve calculating the optimal settings for the available memory(upwards), and modifying linux settings to improve handling of stuff like swap space(db throughput death).
though even then you can do things like Raid arrays for contingency, off-server backups, etc. If you felt you really had to set up something like barman there are lots of online guides that would help.
Yup, but now you’re managing multiple servers, or testing that your contingency stuff actually works regularly when instead you could pay $50/month and have someone else do that for you.
I like getting my hands dirty with my OSs/services. But for my side project, I was looking out for the cheapest solution. It’s currently residing with Gigalixir while in development (on the free tier). One thing that has been nice is being able to concentrate my efforts on my code, rather than think (too much) about servers, databases and backups.
Now that things are moving on (read: I’m reaching the 10,000 row limit) I’m thinking about my next move. Currently, I plan to use Cloud SQL on Google Cloud directly. As far as I understand, Gigalixir and Cloud SQL can run in the same zone, so the latency will be similar (if not the same) as my current solution.
Last time I checked, that’ll increase my costs from 0 to roughly $US9 per month. If my side project ever grows (in number of users) I intend to move to a paid plan for my app server on Gigalixir
Having said all that, I think if the above option wasn’t available to me, I might roll my own server (to reduce cost)
Just Heroku-ing the whole thing, even though I’d lose some BEAM-y goodness by doing so
@landric Would a distillery/docker deployment on Heroku be an option?
My guess is your 3rd option is a mix-based deployment using Heroku’s buildpacks, which is not how Elixir code should be deployed imho… You would have a 100% BEAM compatible binary, plus the peace of mind not to have to deal with managing instances!
mix is a development tool, it was not meant to run code in production! Building releases directly from mix is actually an ongoing effort by the Elixir core team…
It takes at max 1h to setup a release with Distillery when you have a little knowledge of Docker.
Add a Mix Config Provider to the recipe and you get a real Twelve-Factor binary that can run anywhere, thus on Heroku since it supports Docker deployment.
@landric Would a distillery/docker deployment on Heroku be an option?
mix is a development tool, it was not meant to run code in production! Building releases directly from mix is actually an ongoing effort by the Elixir core team…
Theoretically? But Docker is just a whole other thing for me to learn. Could I take the time? Sure. And I’d be interested to hear more about the practical (as opposed to… philosophical? Not trying to be perjorative, jut not sure I have the right word) benefits of Distillery → Docker → Heroku vs. just using the Elixir Buildpack to run the app with mix.
There are a few documented limitations in Phoenix’s Deploying on Heroku guide, which might not be relevant to your project. Running an Elixir project in production using the language development tool is clever, but not what was meant to be.
This thread from 2017 actually explain it better than I could ever do :
But above all, I like the self-contained, isolated nature of the release. You won’t pickup some unexpected module from somewhere else (e.g. mix app is not included in OTP release, so less chances of invoking Mix.env at runtime), and you can easily run multiple different systems (services) with different versions of Elixir/Erlang.
I also agree that the cost is marginal. But even if it takes longer to properly setup your own build and deployment, it’s a one-off cost. Pay the price once, reap the benefits many times
Keep in mind this thread is almost 2 years old! Distillery 2.0 was officially released last August and simplified the setup by a full order of magnitude. Especially the ENV handling that is now almost as simple as System.get_env/2 with mix configurations.
Unlike source code, which requires that you have the build tools, fetch dependencies, and compile a new version (which may differ from the last time it was compiled, due to different tools or dependency resolution resolving newer versions of your deps), OTP releases disconnect development and deployment in such a way that you only need to build the artifact once, and can then deploy it many times; rather than build the artifact each time.
You may want to check out Gigalixir for a heroku-like experience (more heavy on command line) but tailored for elixir. I’ve had good luck with it so far. Based on google cloud by default but I believe that’s flexible.