shill fly.io

Signed-off-by: Xe <me@christine.website>

1 files changed, 108 insertions, 0 deletions

diff --git a/blog/fly.io-heroku-replacement.markdown b/blog/fly.io-heroku-replacement.markdown
new file mode 100644
index 0000000..eba9208
--- /dev/null
+++ b/blog/fly.io-heroku-replacement.markdown
@@ -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>