1. 24
    1. 5

      I like fly, but I think the only fly feature being used here is the ability to turn the machine off and have it automatically come back in when an ssh is next attempted?

      1. 14

        Author here: It’s fun because I’ve also gotten comments saying there’s “too much” fly.io marketing in that article, when clearly your question indicates that there wasn’t enough!

        Halkcyon is right that the fly thing is an excuse to mess with some Rust, but if I had to list the “features” used:

        • Being able to provision a machine close to where I am is a feature - fly gives me Paris, which is 10ms away from me. Linode would give me Frankfurt, Hetzner would give me Falkenstein. Neither supports stopping/starting big instances (to minimize costs) quite the way fly does
        • Being able to push a Docker image which then turns into a VM is a feature. I’m not building an AMI here, I can re-use all the tooling/knowledge/ecosystem around building Docker images.
        • Having the machine up and running in 1 minute the first time, then stopping it, then starting it again in under 1 second is a feature. I’m not even sure the Kubernetes as a Service offerings out there have similar timings. Low-cost VPS providers are more of a “pay monthly / always-on” kinda deal (so getting a big instance there is… pricey)
        • Being able to SSH into any instance even before I’ve successfully set up my own SSH server inside of there is definitely a feature. It does private networking over wireguard seamlessly, I don’t even have to think about it (but I could, if I decided my instance didn’t need a public IP address)
        • The “fly proxy” flyctl subcommand to expose a port locally is a feature. You can do that with SSH too, but you might be deploying images that don’t have SSH servers (if they’re production web apps, hopefully they don’t!)
        • Being able to run strace stuff, io-uring stuff, BPF stuff etc. is a feature
        • In fact, being able to run arbitrary TCP & UDP services is a feature. This is kinda the theme of the article “there’s no fly feature for that, but - you can just run whatever code you want on there, so you can build the parts that are missing”. It’s not a CDN (but you can build a CDN with it).
        • I hinted at volumes, but that’s a feature too - they can be encrypted, or not: your choice.

        The fact that none of this seems particularly surprising may actually be a positive - it’s boring because it all just works fine the first time.

        To re-iterate: my focus there was on Rust: I’ve always wanted to play with io-uring and to show a small example of what eBPF can do, and now it’s done. The example I’ve picked is kinda wonky (although I’m happy with it for day-to-day work) but I can see some folks reading the article and going “wait we could use this to have a geographically-distributed eBPF-powered firewall in front of our application” and that makes a lot more sense, for example.

        1. 1

          Although this is too much but it wouldn’t be fun if it did not go all the way. In anycase, thank you so much for all the stuff that you do :)

      2. 3

        The focus of the article at the start is creating a remote dev environment and goes into the many ways you can facilitate that via Rust/Fly from the naive to the intricate minimizing syscalls using newer tech and async APIs.