Turbocharge Your Heroku Apps with New Turboku

fly.io

2 points·mwcampbell··4 comments

I normally wouldn't submit a marketing-focused post like this here, but there's one technical detail in here that I find interesting: the launcher web app spawns a VM to run flyctl. I wonder, why not simply include flyctl in the web app container and spawn a subprocess?

The build executes untrusted code and temporarily authenticates with your fly.io and Heroku accounts, so we need a sandbox for isolation. Our Elixir app launches ephemeral VMs using our Machines API so it can offload that can of worms.

Ah, makes sense. Have you folks considered open-sourcing that Elixir app? It would be instructive as an example of how to start a potentially long-running one-off task with the Machines API and monitor its progress.

Edit: Also, I'm just generally curious about the Machines API; it doesn't seem to be documented (yet). The blog post mentioned that launching the VM takes about 2 seconds. Is this startup time proportional to the size of the container image?

It's unlikely we'll open source the Elixir app, most of it isn't that interesting. But extracting the machine code into an example app is a good idea! Until then, here's a prototype go proxy that launches suspended machines when requests come in: https://github.com/superfly/machine-proxy

We'll be baking that into our proxy soon so we can handle lambda-type workloads.

Image size impacts the cold startup time since it gets fetched and converted into a rootfs before launching. Caching speeds up subsequent launches. Once a machines is created, it can be stopped and resumed, which is _much_ faster. I don't remember the numbers, but it's in the several hundred ms range.

We'll have more to share soon.

Reply on news.ycombinator.com