4 ms·
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
by mrkurt 4y ago
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"?
- tomatowurst 4y agointeresting, 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/ https://fly.io/docs/reference/regions/
- mrkurt 4y agoOh 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/ 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/ 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.
- tomatowurst 4y agoI 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?
- __turbobrew__ 4y agoDo 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.
- ignoramous 4y agoI 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/1426221897407242246 https://twitter.com/dave_universetf/status/14262218974072422... [0] https://fly.io/docs/app-guides/multiple-processes/ https://fly.io/docs/app-guides/multiple-processes/ [1] https://community.fly.io/t/2316 https://community.fly.io/t/2316