Hacker News Reader

Comment by tomatowurst | Hacker News Reader

How does this compare to AWS Lambda's docker support

Some of the plumbing is similar, but in general:

1. Lambda has runtime constraints and is billed per request

2. Fly Machines are basically just VMs with some magical startup sugar. You can do pretty much anything you want with them, including run for months.

Fly Machines are a partial answer to "how can I build my own Lambda service"?

Do Fly Machines support POSIX/System V shared memory? It is a giant pain in the ass for us because lambda does not implement these shared memory mechanisms which many multiprocessing libraries use to communicate. Makes it hard to utilize multiple lambda cores when running python code. You need to use multiprocessing due to the python GIL, but most of the python multiprocessing IPC uses shared memory.

We managed to hack a solution which uses pipes for IPC but it would be nice not to have to do this.

I haven't tried using shm on Fly, but I don't see why they'd not work.

You could already run multiple processes in a guest vm [0] or run multiple guests vms on the same host [1]. If the guest kernel Fly boots your app into doesn't have required modules, I guess you could consider requesting (nerd-sniping 'em) specifically for those, like so: https://twitter.com/dave_universetf/status/14262218974072422...

[0] https://fly.io/docs/app-guides/multiple-processes/

[1] https://community.fly.io/t/2316

interesting, i was more pointing to the cold startup time on lambda with docker images vs this.

    Deploy App Servers
    Close to Your Users

is there a timeout limit to functions? This piques my interest but I can't tell if fly is a serverless function provider or some way to deploy my docker closest to my user (which is what I am looking for right now)

What guarantee is there in terms of average latency for my users? Is there a looking glass of sort where I can ping/see all the locations where my docker images will be running?

a dedicated 4-core 8gb ram is $124.00/month which is 4~6x more expensive than running on KVM vps so I want to know what I am signing up for

edit: I see the list of locations and it makes me think, aren't I already doing what fly.io is doing? I spin up a VPS instance at one of the locations that is closest to my user. It takes about 30~120 seconds. It's far far cheaper

https://fly.io/docs/reference/regions/

Oh I see! Fly Machines are lower level than what most people use us for. They're designed for people building platforms.

Most people run "apps" on Fly. You control which regions they run in, we load balance to the nearest. We have guides for launching some frameworks here: https://fly.io/docs/getting-started/

The difference between us and a VPS provider is: your app runs in as many of those regions as you want. So does your database, if you're using our Postgres. And we route writes to the appropriate place: https://fly.io/blog/globally-distributed-postgres/

The other difference is probably CPU. The 4 cpu, 8GB RAM instances are 2 dedicated AMD EPYC cores + hyper threads. They're relatively expensive. You may not need them! VPS providers typically run cheaper CPUs and over provision them.

We're shipping shared CPU options with more memory soon. They should be closer to what you see from VPS providers, though still more expensive.

I see, so is it routing requests to a single instance or is it routing it to the nearest instance to the user? How will it scale if there are lot of users in a particular city?

Lambda is fundamentally message oriented, you send an invoke request, lambda will either route the request to an existing warm instance, or will boot a new instance, it processes the request, then once the request is processed it will suspend itself.

Fly VM's are just VM's that can start quickly.

They don't seem to currently support a request/response based VM lifecycle.

If you wanted to use a fly VM in a lambda-like way, seems like you would need to have some kind of proxy to coordinate the work, ie start the VM via the API, have your VM process start a web server, once it's booted, send it a HTTP request, once the request is finished, shut down the VM via the API.

Also seems like fly can't suspend a running process, your process needs to start up every time you start a fly VM.

Lambda will suspend a VM between requests, keeping the process in memory for a few minutes.

Sending a subsequent request to a warm lambda is much faster then booting a lambda from scratch, particularly for JIT based language runtimes.

Reply on news.ycombinator.com