6 ms·

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

by leerob 5y ago

mrkurt 5y ago
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.
- mike_d 5y ago
  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."
  - tptacek 5y ago
    Arbitrary UDP has worked since we launched UDP; it's never had a port filter or anything.
    - mike_d 5y ago
      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-stdout-stderr/2993 https://community.fly.io/t/allow-non-root-users-to-write-to-...
      - tptacek 5y ago
        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. :)
        welterde 5y ago
        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!
- onphonenow 5y ago
  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
  - mrkurt 5y ago
    Oh don't you worry. We can extract large sums of money from big companies.
    - onphonenow 5y ago
      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).
- dmw_ng 5y ago
  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?
- xfer 5y ago
  > 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.
  - mrkurt 5y ago
    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.
- andy_ppp 5y ago
  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.
  - mrkurt 5y ago
    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.

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

by leerob 5y ago

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

mrkurt 5y ago

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.

mike_d 5y ago
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."
- tptacek 5y ago
  Arbitrary UDP has worked since we launched UDP; it's never had a port filter or anything.
  - mike_d 5y ago
    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-stdout-stderr/2993 https://community.fly.io/t/allow-non-root-users-to-write-to-...
    - tptacek 5y ago
      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. :)
      - welterde 5y ago
        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!
onphonenow 5y ago
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
- mrkurt 5y ago
  Oh don't you worry. We can extract large sums of money from big companies.
  - onphonenow 5y ago
    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).
dmw_ng 5y ago
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?
xfer 5y ago
> 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.
- mrkurt 5y ago
  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.
andy_ppp 5y ago
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.
- mrkurt 5y ago
  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.