10 ms·

I'm so glad Fly exists. Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request. That's

I'm so glad Fly exists. Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request. That's fine for a lot of use cases, but the unit economics of the per request pricing model means it's really hard to operate a predictably sustainable (i.e. profitable) business without also charging our customers on a usage basis, or enforcing limits on usage, neither of which is ideal for maximizing engagement as incentives are no longer aligned. Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests, and gives us freedom to serve as much traffic as we can min-max onto those resources, like we could with traditional cloud compute. This provides much better unit economics for many kinds of applications, at the cost of having to manage the scaling ourselves. But because the option exists, we can make this tradeoff on a case-by-case basis, which is so much better than if all we had was "serverless" stuff at the edge and had to choose between just low latency across the globe vs good unit economics.

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.
rmbyrro 5y ago
Serverless pricing model doesn't have to be transferred to your customers. If you know them well and their usage patterns, you can predict with confidence how much each customer will cost you. With granularity to the level of a feature or even a particular action. This allows for extremely precise and safe unit economics planning. I couldn't be happier with this benefit from serverless. In a server-based infra you have many fixed costs: servers themselves, unused capacity, and your time to maintain it, which is certainly expensive, since it competes with attention to the product or maybe sales and customer support.
- ipaddr 5y ago
  If your server administrator doubles as your sales person maybe but for most companies these are different roles and you need someone to manage your fly.io account/docker image or your aws account. Sales, customer support, legal, marketing should be affected. If you are a one man show that's a different conversation.
- hdjrudni 5y ago
  Kubernetes on DigitalOcean scales pretty well.. fixed monthly cost. If I run out of capacity I just add an extra node or switch to more powerful nodes. Kubernetes takes care of provisioning the nodes. Google APIs OTOH... I went from $0/month to $450 the next because of their stupid per-unit pricing and hidden API calls.
mooreds 5y ago
For a company that says it makes it super easy to deploy a container image and mentions that all you need to do "Write your code, package it into a Docker image, deploy it to Fly's platform"[0], they sure have a dearth of documentation on how to deploy an existing docker container. I am not sure if I'm missing something or what, but here's where I looked: * googled 'docker fly' and a blog post that references docker but as far as I can see doesn't have instructions on deploying docker images shows up[1]. * their getting started guide[2], called a 'speed run' which has all kinds of CLI commands but doesn't actually show how I'd pick a docker image. * their quickstart docs[3], which outline how to deploy all manner of applications, except for, you guessed it, an existing docker image. * scanned the menu of their docs, and didn't see anything. I really want to like this service, as we have (at $CURJOB) an app packaged as a docker image that it'd be awesome to set up to run on Fly.io, especially with the multi-region postgresql. What the heck am I missing? Can I just not read? Do I just need to install the CLI and all shall be made clear? 0: https://fly.io/docs/introduction/ https://fly.io/docs/introduction/ 1: https://fly.io/blog/docker-without-docker/ https://fly.io/blog/docker-without-docker/ 2: https://fly.io/docs/speedrun/ https://fly.io/docs/speedrun/ 3: https://fly.io/docs/getting-started/ https://fly.io/docs/getting-started/
- mrkurt 5y ago
  You know, you're not really missing anything, we just don't connect the dots very well. Install CLI, run `fly launch` in a directory with a Dockerfile, and it should just work. Most of our users don't start with a Docker image though, they start with Phoenix. What you're seeing is a little bit of indecisiveness in how we target the docs.
  - mooreds 5y ago
    Thanks! I'd rather run with a defined image, is there a way to do that? Here's the image: https://hub.docker.com/r/fusionauth/fusionauth-app/tags https://hub.docker.com/r/fusionauth/fusionauth-app/tags (supports ARM or x86). Edit: https://news.ycombinator.com/item?id=30019258 https://news.ycombinator.com/item?id=30019258 shows, I think, how to do that.
ignoramous 5y ago
> Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request. Workers Unbound is $1 for ~6.6M requests (+ runtime at $0.0000015 per sec / $12.5 for 1M GB-sec). That's super cheap considering free egress, which brings me to... > Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests... Fly.io may not meter requests anymore, but they continue to meter egress, even between your VMs in the same region [0]. Usage-based price model is everywhere, like it or not. [0] https://community.fly.io/t/do-traffic-over-6pn-within-the-same-region-count-towards-egress-bandwidth/3023 https://community.fly.io/t/do-traffic-over-6pn-within-the-sa...
- mrkurt 5y ago
  We don't bill for internal Postgres bandwidth anymore. Bandwidth in general is a good point though. No one _actually_ offers unlimited bandwidth. We haven't figured out how to be transparent about bandwidth costs AND check that box for people yet, though.
  - nerdyadventurer 5y ago
    Is pricing page updated according this news, seems not to me? Can I please also know how PG clusters are run at the edge? Docs is not very informative about how things work under the hood(ie. infrastructure / deployment).
  - gfd 5y ago
    > No one _actually_ offers unlimited bandwidth. Isn't cloudflare's whole shtick about not having egress fees? https://blog.cloudflare.com/workers-now-even-more-unbound/ https://blog.cloudflare.com/workers-now-even-more-unbound/
    - mrkurt 5y ago
      Cloud Flare's model is to give you "unlimited" bandwidth with restrictions on how you can use it. If you do any kind of volume you quickly get a call from a sales person who wants to sell you enterprise. And then you end up paying a relatively high per-GB price as one big enterprise contract. They're reasonably transparent about this, and I think it's fair. It's just not how I prefer to buy services. At no point will we call you up and try to get you to spend more money to keep doing what you're already doing.
cxr 5y ago
> it's really hard to operate a predictably sustainable (i.e. profitable) business [... with other providers]. Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests, and gives us freedom to serve as much traffic as we can min-max onto those resources, like we could with traditional cloud compute The praise on the subject of predictability is interesting, given perennial concerns about uncapped vs capped usage charges (with any cloud provider), but esp. in light of past Fly-specific comments that "putting work into features specifically to minimize how much people spend seems like a good way to fail a company". <https://news.ycombinator.com/item?id=24699221 https://news.ycombinator.com/item?id=24699221>
- mrkurt 5y ago
  We ended up shipping a "cap your costs" feature, we just did it with prepaid credits. If you buy prepaid credits instead of adding a credit card to your account, we can't bill you more than you've prepaid. The downside is that you have to prepay $25 to use anything at all. My comment could have been better. Our business model is predicated on making it cheap to use services and easy to incrementally scale up. We probably won't build features to cap usage of things directly, but it makes total sense to deactivate apps when credits run out.

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.

rmbyrro 5y ago

Serverless pricing model doesn't have to be transferred to your customers. If you know them well and their usage patterns, you can predict with confidence how much each customer will cost you. With granularity to the level of a feature or even a particular action. This allows for extremely precise and safe unit economics planning. I couldn't be happier with this benefit from serverless. In a server-based infra you have many fixed costs: servers themselves, unused capacity, and your time to maintain it, which is certainly expensive, since it competes with attention to the product or maybe sales and customer support.

ipaddr 5y ago
If your server administrator doubles as your sales person maybe but for most companies these are different roles and you need someone to manage your fly.io account/docker image or your aws account. Sales, customer support, legal, marketing should be affected. If you are a one man show that's a different conversation.
hdjrudni 5y ago
Kubernetes on DigitalOcean scales pretty well.. fixed monthly cost. If I run out of capacity I just add an extra node or switch to more powerful nodes. Kubernetes takes care of provisioning the nodes. Google APIs OTOH... I went from $0/month to $450 the next because of their stupid per-unit pricing and hidden API calls.

mooreds 5y ago

For a company that says it makes it super easy to deploy a container image and mentions that all you need to do "Write your code, package it into a Docker image, deploy it to Fly's platform"[0], they sure have a dearth of documentation on how to deploy an existing docker container. I am not sure if I'm missing something or what, but here's where I looked: * googled 'docker fly' and a blog post that references docker but as far as I can see doesn't have instructions on deploying docker images shows up[1]. * their getting started guide[2], called a 'speed run' which has all kinds of CLI commands but doesn't actually show how I'd pick a docker image. * their quickstart docs[3], which outline how to deploy all manner of applications, except for, you guessed it, an existing docker image. * scanned the menu of their docs, and didn't see anything. I really want to like this service, as we have (at $CURJOB) an app packaged as a docker image that it'd be awesome to set up to run on Fly.io, especially with the multi-region postgresql. What the heck am I missing? Can I just not read? Do I just need to install the CLI and all shall be made clear? 0: https://fly.io/docs/introduction/ https://fly.io/docs/introduction/ 1: https://fly.io/blog/docker-without-docker/ https://fly.io/blog/docker-without-docker/ 2: https://fly.io/docs/speedrun/ https://fly.io/docs/speedrun/ 3: https://fly.io/docs/getting-started/ https://fly.io/docs/getting-started/

mrkurt 5y ago
You know, you're not really missing anything, we just don't connect the dots very well. Install CLI, run `fly launch` in a directory with a Dockerfile, and it should just work. Most of our users don't start with a Docker image though, they start with Phoenix. What you're seeing is a little bit of indecisiveness in how we target the docs.
- mooreds 5y ago
  Thanks! I'd rather run with a defined image, is there a way to do that? Here's the image: https://hub.docker.com/r/fusionauth/fusionauth-app/tags https://hub.docker.com/r/fusionauth/fusionauth-app/tags (supports ARM or x86). Edit: https://news.ycombinator.com/item?id=30019258 https://news.ycombinator.com/item?id=30019258 shows, I think, how to do that.

ignoramous 5y ago

> Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request. Workers Unbound is $1 for ~6.6M requests (+ runtime at $0.0000015 per sec / $12.5 for 1M GB-sec). That's super cheap considering free egress, which brings me to... > Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests... Fly.io may not meter requests anymore, but they continue to meter egress, even between your VMs in the same region [0]. Usage-based price model is everywhere, like it or not. [0] https://community.fly.io/t/do-traffic-over-6pn-within-the-same-region-count-towards-egress-bandwidth/3023 https://community.fly.io/t/do-traffic-over-6pn-within-the-sa...

mrkurt 5y ago
We don't bill for internal Postgres bandwidth anymore. Bandwidth in general is a good point though. No one _actually_ offers unlimited bandwidth. We haven't figured out how to be transparent about bandwidth costs AND check that box for people yet, though.
- nerdyadventurer 5y ago
  Is pricing page updated according this news, seems not to me? Can I please also know how PG clusters are run at the edge? Docs is not very informative about how things work under the hood(ie. infrastructure / deployment).
- gfd 5y ago
  > No one _actually_ offers unlimited bandwidth. Isn't cloudflare's whole shtick about not having egress fees? https://blog.cloudflare.com/workers-now-even-more-unbound/ https://blog.cloudflare.com/workers-now-even-more-unbound/
  - mrkurt 5y ago
    Cloud Flare's model is to give you "unlimited" bandwidth with restrictions on how you can use it. If you do any kind of volume you quickly get a call from a sales person who wants to sell you enterprise. And then you end up paying a relatively high per-GB price as one big enterprise contract. They're reasonably transparent about this, and I think it's fair. It's just not how I prefer to buy services. At no point will we call you up and try to get you to spend more money to keep doing what you're already doing.

cxr 5y ago

> it's really hard to operate a predictably sustainable (i.e. profitable) business [... with other providers]. Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests, and gives us freedom to serve as much traffic as we can min-max onto those resources, like we could with traditional cloud compute The praise on the subject of predictability is interesting, given perennial concerns about uncapped vs capped usage charges (with any cloud provider), but esp. in light of past Fly-specific comments that "putting work into features specifically to minimize how much people spend seems like a good way to fail a company". <https://news.ycombinator.com/item?id=24699221 https://news.ycombinator.com/item?id=24699221>

mrkurt 5y ago
We ended up shipping a "cap your costs" feature, we just did it with prepaid credits. If you buy prepaid credits instead of adding a credit card to your account, we can't bill you more than you've prepaid. The downside is that you have to prepay $25 to use anything at all. My comment could have been better. Our business model is predicated on making it cheap to use services and easy to incrementally scale up. We probably won't build features to cap usage of things directly, but it makes total sense to deactivate apps when credits run out.