18
Elixir in Production: Statuspal
In this article, we’re interviewing Eduardo Messuti, the founder & CEO of Statuspal, a tool for creating beautiful, hosted status pages.
We talk about his project, which Elixir libraries and frameworks have been useful for Statuspal, and what developers should take in mind when launching their own Elixir SaaS project.
Statuspal enables companies to communicate incidents and maintenance in an effective and proactive manner, with little management required thanks to its integrated monitoring and powerful automations.
I (Eduardo Messuti) started working on Statuspal back in 2017 as a side project when I realized more and more companies were starting to build their own status pages in order to communicate their system status (companies like Github, Heroku and Twitter), so I thought that other companies would need them too.
As the Heroku status page was my favourite one design-wise, I decided to build Statuspal following a similar design. To this day, you can see the similarities.
Where do you use Elixir in your stack? How big of a part of the Statuspal codebase is written in Elixir?
We use Elixir as our backend language and for rendering our HTML templates everywhere in Statuspal. So far, we have three main applications:
- One monolith Phoenix app that serves the status pages and admin site. The status pages get heavily cached through ETS as well as with NGINX reverse proxy.
- One microservice that’s our monitoring agent, which uses a Supervisor and GenServer to manage the monitoring checks.
- Another microservice we use to send transactional emails through SMTP servers using Oban to process the email delivery.
At the beginning of 2017, I decided to build an MVP for Statuspal. I had heard of Elixir and Phoenix, and how they were inspired by Ruby and RoR, but improved on its shortcomings like concurrency and performance, at the same time the fact that it was a functional programming language sounded appealing as I had been meaning to try a functional language for a while.
I was able to put together a functional prototype relatively quickly, and I was impressed by Elixir’s performance. I got away with deploying it to a $5/month DigitalOcean droplet running in production without any caching for at least the first two years.
We use Oban for background job processing, and we couldn’t be happier. It’s extremely easy to setup as it uses Postgres as its backend, so there is no need to add any external dependencies like Reddis.
It’s also very powerful and feature-rich. We’re currently using it for sending notifications, but we’ll soon start replacing other custom-made GenServer based background jobs, thus simplifying our codebase.
We heavily use HTTPoison for interacting with external services. Elixir doesn’t have as many libraries as Ruby, so there’s not always a mature client library for every service. HTTPoison allows us to quickly build a client for any service – we can have the endpoints we need put together in a module in a few minutes.
We also use Trans to power our multi-language capabilities, which has made our life easier and our customers very happy since they can seamlessly communicate in multiple languages.
We did have some issues at the beginning, mostly due to Elixir and/or Phoenix still being in the process of maturing, like the fact that Phoenix Contexts were introduced (which required some big refactors) or the deprecating of Models in favour of Schemas.
Another pain point at the beginning was no clear way of creating and deploying releases. We tried Edeliver for a while and ended up bringing more problems than solutions, so we ended up using dockerized deployments and are happy with it.
Companies that heavily rely on online services (e.g. SaaS, IT services, cloud and hosting), companies with technical customers (like developer tools) and Education institutions benefit greatly from having a status page with Statuspal.
These are some of the kinds of companies that will realize sooner than later that they need a way to reliably and effectively communicate about incidents and maintenance.
We have a big vision for Statuspal – we want to continue improving and closely listening to our customers until we’re the number one status page provider and beyond.
Statuspal currently covers the Incident Communication part of Incident Management, and we’re pretty good at it. Looking at the future, we want to expand into the other stages, like incident response, until we close the gap and cover the whole lifecycle.
We also plan to further our monitoring offering, our customers already love us for our simplicity, and many use our integrated monitoring that let’s them quickly automate their status reporting, so we plan to continue improving it and make it more feature rich. Doing this while keeping its simplicity is tricky, but we’re up to the challenge.
I’d say go for it, especially if you have large concurrency and performance needs, Elixir is a great option, and if you have a Ruby background, you can quickly become productive with it (and you’ll love it!), more so now than a couple of years ago.
I’d also suggest if you’re starting with a small team, using a PaaS like Heroku or Gigalixir is a great option instead of rolling your own server, it’ll save you a lot of time in the long term. When I started with Statuspal, these options were not as mature for Elixir, but nowadays they work wonders – we’re using Heroku for one of our microservices.
I would like to thank Eduardo for the interview and wish him the best of luck with Statuspal! If you want to check out the project, you can visit their website.
If you want to read more stories like this, be sure to check out our Elixir in Production tag – we have plenty of interviews there. And don’t forget to follow us on Twitter, Medium, or Dev to receive updates about new articles on Elixir and functional programming.
18