Hacker News Reader

Comment by dexen | Hacker News Reader

Not to pick on Fly (seems nice), but on the trend for containers:

>if you’ve got a Docker container, it can be running on Fly in single-digit minutes.

I used to laugh at the old Plan 9 fortune, "... Forking an allegro process requires only seconds... -V. Kelly". Guess I'm not laughing anymore?

FWIW, performance of components is the barrier to composition in system design and development. You can't compose modules that take seconds to act, and still have something that is usable real-time.

View on HN

Fly runs the contents of the container in a VM. Bring your own runtime in that VM, use kernel sandboxing features, do whatever you want (in linux).

I’m all for the “k8s is not erlang” position, but in fly’s case it seems like the right tool for the job. Fly is much faster than a new EC2 instance.

More info about this in the blogpost Docker without Docker[0]

[0] https://fly.io/blog/docker-without-docker/

You’re remarking on a development time number. Like, the amount of time it’ll take to create your account.

I can see how someone would misunderstand that claim though: the idea of getting up and running on a new hosting provider that quickly seems so unlikely that thinking "well they must be talking about container launch times here instead" is an understandable mistake.

Container launch times are frequently in minutes if we include pulling the images from a repo, which we reasonably should.

In whichever case, that doesn't mean we can't compose them into a performant product as the OP suggests, it just means you run them as daemons so you can amortize the startup cost across many invocations. This isn't specific to containers--we do the same thing for web servers, databases, virtual machines, physical machines etc. Anything with a startup cost that you don't want to pay each time.

Why would you include pulling the container image as something that should be a part of the container launch time? It’s a one time event after a code push.

It's not a one time event, each host that runs a container image needs to pull it at least once. Minimizing pulls is a good optimization but you have to work pretty hard to really cut them down.

fwiw, I moved my prod env from a VPS (at linode) to fly.io twice in one week. Once to try it out and get a feel for what I was getting into and the second time for real. Took about 90 minutes each (plus some thinking time and doc reading). It's a small app without a ton of data to move nor a lot of traffic at this point, so take my experience with a grain of salt.

Oh, you’re right; I’m just clarifying. The perils of trying to fit your whole project into a tiny lead paragraph. :)

"Create your first project in minutes. Create your next project in under 25 seconds."

You missed the mark, mate. The "single-digit minutes" applies to the one-time onboarding process, not cold-start times for a deployed service!

Reply on news.ycombinator.com