Move parser subdomain hosting off of Heroku
aaronpk opened this issue · comments
Moving this conversation from willnorris/microformats#24 Will Norris set up the Go parser website to be deployed from Fly.io instead of Heroku.
Before we commit to moving the rest to Fly.io, I'd like to get a sense of the pricing. (I'm sure whatever it is will be cheaper than Heroku, but still would like to confirm!)
We would also like to discuss redirecting the .io domains to *.microformats.dev. Moving the hosting is a good opportunity to do this, since we can set up the new sites whenever without disrupting the existing ones.
It's hard to estimate pricing without knowing how much traffic these sites get. Fly does a really good job of scaling resources to zero, so it's very easy for low-traffic sites to cost nothing. They don't technically have a free tier in the way that Heroku did. Instead, the charge for everything, but if the total ends up being less than $5/month, they just don't bill you.
As an example, I run my personal website, client.webfinger.net (which is the backend for https://webfinger.net/lookup/), and a personal DNS server for my tailnet, and I've never been charged yet. Admittedly, I also don't run analytics on any of these sites so don't know what kind of real-world traffic that is.
A shared-cpu machine with 256mb of ram (which is what I typically use for everything, since they all tend to have very small memory footprints) is about $2/month if it runs non-stop. I would guess that most of these parser sites sit idle most of the time.
They are not super high traffic sites, they definitely are idle most of the time. Is this going to be the kind of thing where they take a few seconds to spin up when they get a request? I ran in to one test site on fly.io that would throw a bad gateway error on the first few requests until the backend was finally spun up, which is not a great user experience.
I guess that ultimately depends on what's in the container. Fly rebuilds the containers as firecracker VMs, which have really fast startup time (they were originally developed for AWS Lambda). If we find that some languages are too slow to start, we can configure those to always stay on.
Also, to be clear, I don't really care all that much where we host. I've just been using Fly for a couple of years for personal projects and have been really happy. They really seem to have filled the hole that Heroku left. We have used them a bunch of small projects at Tailscale and have gotten to know the team, partially because they are also doing a lot of interesting things with wireguard and sqlite. But we could also just as easily leave things on Heroku, move to AWS Lambda, GCP Cloud Run, or anything else. I think the biggest thing is having some automation to keep the parser sites up to date.