forked from cadey/xesite
parent
7a3d64fec1
commit
2432b5a4fc
|
|
@ -0,0 +1,108 @@
|
||||||
|
---
|
||||||
|
title: "Fly.io: the Reclaimer of Heroku's Magic"
|
||||||
|
date: 2022-05-15
|
||||||
|
tags:
|
||||||
|
- flyio
|
||||||
|
- heroku
|
||||||
|
vod:
|
||||||
|
twitch: https://www.twitch.tv/videos/1484123245
|
||||||
|
youtube: https://youtu.be/BAgzkKpLVt4
|
||||||
|
---
|
||||||
|
|
||||||
|
Heroku was catalytic to my career. It's been hard to watch the fall from grace.
|
||||||
|
Don't get me wrong, Heroku still _works_, but it's obviously been in maintenance
|
||||||
|
mode for years. When I worked there, there was a goal that just kind of grew in
|
||||||
|
scope over and over without reaching an end state: the Dogwood stack.
|
||||||
|
|
||||||
|
In Heroku each "stack" is the substrate the dynos run on. It encompasses the AWS
|
||||||
|
runtime, the HTTP router, the logging pipeline and a bunch of the other
|
||||||
|
infrastructure like the slug builder and the deployment infrastructure. The
|
||||||
|
three stacks Heroku has used are named after trees: Aspen, Bamboo and Cedar.
|
||||||
|
Every Heroku app today runs on the Cedar stack, and compared to Bamboo it was a
|
||||||
|
generational leap in capability. Cedar was what introduced buildpacks and
|
||||||
|
support for any language under the sun. Prior stacks railroaded you into Ruby on
|
||||||
|
Rails (Heroku used to be a web IDE for making Rails apps). However there were
|
||||||
|
always plans to improve with another generational leap. This ended up being
|
||||||
|
called the "Dogwood stack", but Dogwood never totally materialized because it
|
||||||
|
was too ambitious for Heroku to handle post-acquisition. Parts of Dogwood's
|
||||||
|
roadmap ended up being used in the implementation of Private Spaces, but as a
|
||||||
|
whole I don't expect Dogwood to materialize in Heroku in the way we all had
|
||||||
|
hoped.
|
||||||
|
|
||||||
|
However, I can confidently say that [fly.io](https://fly.io) seems like a viable
|
||||||
|
inheritor of the mantle of responsibility that Heroku has left into the hands of
|
||||||
|
the cloud. fly.io is a Platform-as-a-Service that hosts your applications on top
|
||||||
|
of physical dedicated servers run all over the world instead of being a reseller
|
||||||
|
of AWS. This allows them to get your app running in multiple regions for a lot
|
||||||
|
less than it would cost to run it on Heroku. They also use anycasting to allow
|
||||||
|
your app to use the same IP address globally. The internet itself will load
|
||||||
|
balance users to the nearest instance using BGP as the load balancing
|
||||||
|
substrate.
|
||||||
|
|
||||||
|
<xeblog-conv name="Cadey" mood="enby">People have been asking me what I would
|
||||||
|
suggest using instead of Heroku. I have been unable to give a good option until
|
||||||
|
now. If you are dissatisfied with the neglect of Heroku in the wake of the
|
||||||
|
Salesforce acquisition, take a look at fly.io. Its free tier is super generous.
|
||||||
|
I worked at Heroku and I am beyond satisfied with it. I'm considering using it
|
||||||
|
for hosting some personal services that don't need something like
|
||||||
|
NixOS.</xeblog-conv>
|
||||||
|
|
||||||
|
Applications can be built either using [cloud native
|
||||||
|
buildpacks](https://fly.io/docs/reference/builders/), Dockerfiles or arbitrary
|
||||||
|
docker images that you generated with something like Nix's
|
||||||
|
`pkgs.dockerTools.buildLayeredImage`. This gives you freedom to do whatever you
|
||||||
|
want like the Cedar stack, but at a fraction of the cost. Its default instance
|
||||||
|
size is likely good enough to run the blog you are reading right now and would
|
||||||
|
be able to do that for $2 a month plus bandwidth costs (I'd probably estimate
|
||||||
|
that to be about $3-5, depending on how many times I get on the front page of
|
||||||
|
Hacker News).
|
||||||
|
|
||||||
|
You can have persistent storage in the form of volumes, poke the internal DNS
|
||||||
|
server fly.io uses for service discovery, run apps that use arbitrary TCP/UDP
|
||||||
|
ports (even a DNS server!), connect to your internal network over WireGuard, ssh
|
||||||
|
into your containers, and import Heroku apps into fly.io without having to
|
||||||
|
rebuild them. This is what the Dogwood stack should have been. This represents a
|
||||||
|
generational leap in the capabilities of what a Platform as a Service can do.
|
||||||
|
|
||||||
|
Even more critical is that every app gets its own static IP address that you can
|
||||||
|
use for IP based firewall rules. This is something that was straight up
|
||||||
|
impossible in Heroku due to Heroku being a reseller of AWS, but since fly.io
|
||||||
|
owns their own infreastructure and IP space, they can do this with ease. Your
|
||||||
|
applications can be reached on a predictable IP and they will have outgoing
|
||||||
|
connections with the same IP.
|
||||||
|
|
||||||
|
<xeblog-conv name="Numa" mood="delet">This is amazingly useful when dealing with
|
||||||
|
well-intentioned but outmoded security teams at companies you are integrating
|
||||||
|
with that insist that you absolutely must have a static IP for a service. No
|
||||||
|
more having to make ad-hoc SSH proxies or use some shady HTTP proxy as a
|
||||||
|
service. You just make connections and they just work.</xeblog-conv>
|
||||||
|
|
||||||
|
The stream VOD in the footer of this post contains my first impressions using
|
||||||
|
fly.io to try and deploy an app written with [Deno](https://deno.land) to the
|
||||||
|
cloud. I ended up creating a terrible CRUD app on stream using SQLite that
|
||||||
|
worked perfectly beyond expectations. I was able to _restart the app_ and my
|
||||||
|
SQLite database didn't get blown away. I could easily imagine myself combining
|
||||||
|
something like [litestream](https://litestream.io) into my docker images to
|
||||||
|
automate offsite backups of SQLite databases like this. It was magical.
|
||||||
|
|
||||||
|
<xeblog-conv name="Mara" mood="happy">If you've never really used Heroku, for
|
||||||
|
context each dyno has a mutable filesystem. However that filesystem gets blown
|
||||||
|
away every time a dyno reboots. Having something that is mutable and persistent
|
||||||
|
is mind-blowing.</xeblog-conv>
|
||||||
|
|
||||||
|
Everything else you expect out of Heroku works like you'd expect in fly.io. The
|
||||||
|
only things I can see missing are automated Redis hosting by the platform
|
||||||
|
(however this seems intentional as fly.io is generic enough [to just run redis
|
||||||
|
directly for you](https://fly.io/docs/reference/redis/)) and the marketplace.
|
||||||
|
The marketplace being absent is super reasonable, seeing as Heroku's marketplace
|
||||||
|
only really started existing as a result of them being the main game in town
|
||||||
|
with all the mindshare. fly.io is a voice among a chorus, so it's understandable
|
||||||
|
that it wouldn't have the same treatment.
|
||||||
|
|
||||||
|
Overall, I would rate fly.io as a worthy inheritor of Heroku's mantle as the
|
||||||
|
platform as a service that is just _magic_. It Just Works™️. There was no
|
||||||
|
fighting it at a platform level, it just worked. Give it a try.
|
||||||
|
|
||||||
|
<xeblog-conv name="Cadey" mood="enby">Don't worry
|
||||||
|
[@tqbf](https://twitter.com/tqbf), fly.io put in a good showing. I still wanna
|
||||||
|
meet you at some conference.</xeblog-conv>
|
||||||
Loading…
Reference in New Issue