Elixir deployments: our data on what the community needs
We asked the Elixir community what they consider key when planning a deployment; here’s what we found.
At the start of February we outlined a process for basic deployments of Elixir applications on AWS. There were a few holes in this, particularly around some of the shinier Elixir features, but before proceeding with tackling these we wanted to get a sense of what features the community felt were most important.
We set up a short survey, asking 3 questions we thought relevant to the subject, in an attempt to answer this. We left this open for 1 month, and thought our findings might be of interest to the community at large.
Full disclosure: I am not a data scientist, and haven’t done any real statistics work since school. Others may feel better qualified to analyse this data, or ask questions which are more useful gauges of our hypotheses. We’ve linked the raw responses at the end of the post.
Here at Mint, we’re big fans of Elixir. We’re aware that deployment is sometimes painful, through our own experience, and through talk we’ve heard in the wider community.
With this in mind, we set out to test the following:
- Auto-scaling with clustering is more likely a must-have than either auto-scaling or clustering, in isolation.
- Most Elixir developers don’t much care about managing resources in a deployment target themselves. They simply want something that works out of the box.
- Most developers just want a straight forward
git push remote mastertype deployment command to handle releasing a new version of their app.
Respondees were self-selecting: having found and chosen to read the blog post, they went on to fill out the survey with no promise of a reward. Given this, it seems reasonable to assume anyone responding has a fair interest in Elixir already.
We used 3 questions to test our hypotheses:
- Which features would you consider a “must have” when planning a deployment?
- How much control do you need over the resources you are running your application on?
- How much control do you need over the deployment of your app?
We kept the survey open for 28 days, from the 9th February, to 9th March. We had an overall total of 107 responses over this period.
Which of these features would you consider a “must have” when planning a deployment?
The features we identified as being potential must-haves when deploying Elixir are all roughly equal in terms of demand; with ~41–46% of users selecting each.
The use of these features likely depends upon the app (not all applications will need any/all of them), so perhaps this is not surprising. We found it interesting that none stood out though.
How much control do you need over the resources you are running your application on?
Over 2/3 of responses indicated they didn’t care to manage the resources their application is deployed to, as long as it supports Elixir’s key features. The minority who prefer more control is sizeable, however.
How much control do you need over the deployment of your app?
In hindsight, we think this question isn’t very useful. As long as a deployment solution can be hooked into by other services, the user will have control over this anyway.
Looking at these results, and comparing them with our initial hypotheses, we’ve made the following conclusions:
Equal interest in proposed “advanced” features
We supposed that distribution with auto-scaling would be the most in demand here, but in fact, there is no stand out. This suggests perhaps we’d be better off investing in one of the simpler items first, if weighing up the demand vs time spent.
Most just want hosting that works
This was in line with our expectations; we feel that most interest in Elixir is from developers who want to focus on writing code, not on configuring servers and deployments.
Deployment process question was not great
The answers here were fairly balanced, but ultimately we think it was a bad question. You could easily be in a position where you wanted both cases to be true: if you currently use a CI platform and deploy to Heroku, this would be the case.
Based on our conclusions above, we think either hot-code reload or auto-scaling would be the primary candidates for where to invest time next, if looking to extend our stack in terms of features.
We also think there’s space to try simplifying this process further. While the template in the last post goes some way towards simplifying a deployment, there is still lots of manual work that makes mistakes likely. Perhaps this could be made simpler for other developers, through a PaaS-style interface?