Research alternatives to Heroku

[hancush]

Heroku is expensive and just went through a pretty big snafu with its GitHub integration. How has the landscape changed since we identified Heroku as the best platform for deploying containers? Are there better, cheaper alternatives?

Some ideas:

• https://fly.io/
• https://render.com/
• vercel?

First step would be to evaluate these platforms:

• Ergonomics
• Story for deploying dependent services (Postgres, ElasticSearch)
  • Database backups
• Pricing
• Static IP availability
• SSL cert management
• Custom domains

[derekeder]

Hacker news thread on Heroku's plans to end their free tier. includes some links and resources to alternatives: https://news.ycombinator.com/item?id=32594533

[smcalilly]

Render

I tried out Render. Here's an example PR with the changes it took to deploy: https://github.com/datamade/il-nwss-dashboard/pull/48. TLDR: you setup a render.yaml file to declare the app and related services. it's a lot like a docker-compose.yml file. nice and easy.

Here's the live app: https://il-nwss-dashboard.onrender.com/

This PR turned off caching because we need to wire up Redis, which appears easy following their render.yaml blueprints.

Here's a guide on deploying a Django app: https://render.com/docs/deploy-django

Pros/Cons

They make a good sales pitch against Heroku. They also wrote a guide to migrate from Heroku, but this only works if you're using standard Heroku build packs (vs our setup that uses docker).

I like how they follow the infrastructure as code pattern and take it seriously enough to write about it in their docs. You create a render.yaml file that provisions all the resources. You can have multiple services declared within the yaml file, so it's similar to how docker-compose.yml works. For pipelines, you'd need to create a staging and prod service within the yaml file (i think, i'd be curious for a second opinion/someone to come up with an alternative approach). You can also turn on preview apps that clone your production database whenever a PR is open (which is a slick feature).

Dev experience hasn't reached parity with Heroku, but they're working on it. You can see their roadmap with features: https://feedback.render.com/

Overall this is a promising offering and I bet in a year that it'll be as good, if not better, than Heroku. It was also empowering to be able to easily migrate from Heroku without too much pain, in case of emergency.

Pros

• good docs: https://render.com/docs
• easy deployment integration with github
• cheaper than Heroku for production-grade deployments. pricing: https://render.com/pricing
• can support static sites so we could deploy gatsby apps here too
• managed Postgres
• elasticsearch
• redis
• preview environments
• good feedback when failing to create a new “blueprint” (a blueprint is what orchestrates all of an app's services, kinda like docker-compose.yml)
• http/2
• proxied through cloudflare so render apps get the cloudflare ddos protection
• no scheduled or unscheduled restarts
• zero downtime deploys
• file system not ephemeral
• can use secret files (and not just env variables like heroku)
• "native, fully flexible cron jobs"
• native support for docker
• fully automated and free TLS certificates
• whitelist ip address access for the services, so you could add your home's ip address and connect to the database via pgadmin
• custom domains
• apparently they have static ip addresses: https://feedback.render.com/features/p/enable-native-static-outbound-ips, but it looks like that's offered via the quotaguard static ip service

Cons

• When using docker, there's not yet a "release" script like with Heroku. Currently, this is the worst thing about Render, and potentially a deal breaker. Release commands exists for an app that uses their python environment, but not when the service is docker. I tried a hack to work around this but had trouble — a smarter dev might be able figure this out.
  • Because of this, you have to use the shell to run migrations, load data, etc. And you can't access the shell on the free plan.
  • However, they are apparently planning to add this feature. see:
  • https://community.render.com/t/release-command-for-db-migrations/247/10
  • https://render.canny.io/features/p/release-phase-script
• no CLI (yet, but it's on their roadmap)
• googleability isn’t as nice as “heroku”. “render” is a generic word, plus it hasn’t been around long enough to have as much content for troubleshooting. not much help online when you get stuck. not many stackoverflow issues, etc. but this likely will change with time. the best resource right now is their community forum.
  • this has been a bit frustrating but i've been able to work through issues. this could be harmful to developer happiness for somebody with less experience, or somebody who doesn't like devops
• you have to manually add postgres extensions via a shell session: https://render.com/docs/databases#postgresql-extensions
• no dataclips
• deploys create more noise than heroku in the slack channel but that could prolly be fixed
• all of the services are listed in the dashboard instead of grouped together by app/pipeline (like heroku). this will most certainly get messy with a lot of apps. for example, the list of services in the dashboard looks like:
  • il-nwss-dashboard
  • il-nwss-dashboard-db
  • il-nwss-dashboard-staging
  • il-nwss-dashboard-staging-db
  • etc

[smcalilly]

here's a list with some other alternatives: https://testdriven.io/blog/heroku-alternatives/

another thread: https://news.ycombinator.com/item?id=33077118

[smcalilly]

I've gotten both Fly and Render working.

Next steps:

• [x] answer one question for deploying fly (what happens when you use a premade toml from the cookiecutter? this was a headache when the toml didn't exist and trying to use our custom docker image)
• [x] write up findings for fly
• [x] answer one question for deploying render (release script?)
• [ ] refine render findings
• [x] demo at tea time
• [ ] write up proposal

[smcalilly]

So for fly, I had a lot of trouble getting it to work with our Docker setup. It doesn't want to deploy a new app when it's Django + Docker. Derek and I stumbled into a solution where we tried to build the app from the Docker registry. This didn't completely work since the Docker image isn't registered, but it worked enough to trick fly into creating a new deployment which allowed us to deploy the app from the local Docker image. Showing this process in a demo would be better than words. I think having another developer try would add a fresh perspective.

I've documented part of the issue in a comment on their community forum: https://community.fly.io/t/django-ftyctl-launch-makemigrations-exit-status-1/6776

When comparing the developer experience to Render, Render easily wins. Render has review apps and the deployment story feels more like Heroku because you can connect a GitHub repo. Render does not have CLI, but they're working on it. Fly does have a CLI but this was the source of my problems (however it's open source and we could help improve it for our use case).

In the current state, I could see Fly being very frustrating for a developer, especially somebody who doesn't have much experience debugging these sorts of issues (like myself). This could change over time, especially since I read a Hacker News comment by one of Fly's team members that developer experience is something they're planning to focus on. Likewise, Render will improve with time (see my comment above in my render notes about the deal breaker (no release scripts, but they're planning on it)).

I would consider using Fly if I wanted to deploy a native Python application without Docker, needed a server environment with more configuration control than Heroku or Render (you can easily scale up or down the virtual machines and such), or wanted a powerful platform with high availability across the entire world. Fly's best feature, at the time of writing, is very fast response times in multiple geographic locations without a devops team — this blog post explains some of this. This would be a compelling platform if we needed to deploy an app that would be used across the world (like SFM), though most of our application users are located in the US.

[smcalilly]

At the time of writing, neither Render or Fly are at parity to Heroku, so we're going to let the platforms bake and later reassess moving to one. They are cheaper than Heroku, but the developer experience isn't there yet with our preferred stack (Django, Postgres, Docker).

Render

Render has a DX closer to Heroku, and can support both our preferred Django stack as well as our sometimes-used Gatsby stack. Their docs also claim to have "one click" elasticsearch and redis integrations.

Render cons:

• No release script for apps that are pre-Dockerized
  • this is on their roadmap
• No CLI
  • this is on their roadmap

Fly

Fly has a better ability to configure the machine to an application's needs — it feels more bare metal (in a good way) but easier to use than something like EC2. Plus it has the magic of a global network so your application is speedily served across the world.

Fly cons:

• Doesn't work with our current docker setup, as demo'd to the team. We stumbled our way to a workaround to get an application deployed, essentially tricking the fly CLI into creating a fly.toml. We tried writing our own fly.toml and that didn't work (though this could be user error, but in that case, the developer experience and ease of use is a top priority). Here's a comment about part of the problem in their community forum. I'd be happy to spell out a better bug report if anybody is curious.
• No pipelines/review apps. We'd need to write github actions to do this.

[smcalilly]

We've been using Vercel in the SFM project, is this a replacement for Heroku? Or is it only a replacement for Netlify?

[nikonikoniko]

In my experience, for anything outside of the next.js ecosystem, Vercel is more like Netlify + AWS Lambda together. For JS apps (backend and frontend) It can be a pretty full framework. Hope that helps!