Hacker News Reader

Comment by leerob | Hacker News Reader

Sounds like Fly is moving to usage-based pricing: https://twitter.com/mrkurt/status/1475310487864848391

This is true, but we aren't going to bill per request. We really can't, since we support arbitrary UDP and TCP services.

I don't really want to promise anything we haven't shipped yet. But my perfect cloud service (a) charges me when VMs are alive and (b) gives me the tools I need to create/remove/stop/start/suspend/resume VMs based on either network activity or metrics.

One flaw of Fly.io right now is that it's relatively expensive to run a side project in 10+ regions. Most apps benefit from 10+ regions, but $50/mo to try it out is prohibitive. We want to make this more accessible.

I actually worry you are undervaluing yourselves. $50 is fine for 10 regions as a data point from where I sit though I wouldn’t object to less

Oh don't you worry. We can extract large sums of money from big companies.

Big places have bet pretty big on docker.

Docker also seems like the quickest option to come out of AWS (ie, ECS or friends) and try fly - so I'd continue chasing a bit of a docker story if you could (even just in docs -> getting going with Docker).

Would love to know what kind of approach you're taking for usage-based. Cold start every time, or some container/criu/VM suspend/resume magic?

Is arbitrary UDP working now?

I don't fault you guys for being a growing startup (we have all been there), but it would be awesome to have a way to flag an issue as "email me when this is fixed so I can come back."

Arbitrary UDP has worked since we launched UDP; it's never had a port filter or anything.

My bad, it was v6 UDP I was thinking of?

I'm a big fan of Fly and have one medium-sized app deployed to it. Just waiting on this specific issue before deploying more: https://community.fly.io/t/allow-non-root-users-to-write-to-...

You're not crazy! We still don't do v6 UDP (there's no good reason for us not to, but it'll be a week of rebuilding a BPF engine while the plane's still in the air, so this task never hits the top of our stack and won't until someone really pressures us on it). Full honesty! That's how we roll on HN. :)

That's such a shame. Would have been a no-brainer for an anycasted authoritative dns setup otherwise.

Hope you get around to it soon!

> charges me when VMs are alive and

You still need that capacity, don't you? You will have to adjust the pricing but i doubt it will cost either of us any less, whether you allocate it.

The nice thing about mapping peoples apps to overpowered hardware is that it flattens bursts. We need capacity for, say, 10% of apps to burst at any given time.

The nice thing about spreading hardware around the world is that we have excess capacity wherever it's dark. If you're doing latency insensitive work like batch jobs, we can schedule it somewhere that would otherwise be idle.

Aggregate capacity is smaller than the sum of the individual apps capacity requirements. So we both benefit.

Can you scale each region based on usage i.e. have a huge server in US or Europe and a tiny one in a market you don't have many users in? fly.io is really an incredible piece of work, I'll probably just default to it as I am a massive Elixir fanboy :-)

As others have said $50 seems a very low starting point but if you can make it cheaper why not, just means you've helped more people onto your service and they will grow with you.

Autoscaling and balancing regions is something we launched with, but it ended up not making much sense. Our load balance sends traffic to the next nearest region when an app is too busy. It's usually better to spread capacity around to lower latency for users, and then eat the additional latency when a region gets overloaded.

In most cases "the next nearest region" is less than 15ms away.

Reply on news.ycombinator.com