5 ms·

PaaS is also always more expensive than IaaS (which as GP said is always more expensive than I not-aaS). They're charging you more for the convenience of `flyc

by OJFord 4y ago

PaaS is also always more expensive than IaaS (which as GP said is always more expensive than I not-aaS). They're charging you more for the convenience of `flyctl region add lhr` or whatever it is vs figuring out the routing & VPCs for example in AWS yourself. It's not all roses though, I find the docs a bit lacking (good on networking - bad on security & storage) and the price of that convenience (aside from literal price) is that it is limiting - as soon as you think 'well I just want a very simple firewall/security group wall' or 'what's the equivalent of allowing only this x to y with an IAM policy', nope, can't do it.

thegeomaster 4y ago
I know that, but I've never understood the PaaS model of just slapping X% on top of the underlying cloud cost. It just invites customers to migrate to the underlying cloud once they're big enough to hire and sustain a dedicated devops team and setup something like k8s. Surely the amortized costs of the Fly.io platform don't scale linearly with the power of the VMs you rent from them. A 64GiB server won't be twice as expensive to maintain as a 32GiB one. So why not create a model that e.g. consists of a cost per VM/autoscaling group/etc plus whatever the VMs cost? I'm genuinely interested, I could very well be missing something.
- mrkurt 4y ago
  The costs of the VMs scale linearly. The bigger they get, the more additional capacity we need to be able to launch on demand ones. It's not just RAM, though, our physical servers have a consistent ratio of RAM/CPU/disk available. You're basically just buying slivers of hardware we've already paid for. That said, our pricing isn't far off of AWS. They have much better economies of scale than we do, and can afford to do Graviton, but you get pretty close horsepower per dollar for comparable instances.
OJFord 4y ago
Also, just for the record, I'm the sort of person that really dislikes magic command lines, I don't want docs that tell me do fly this or that. I want it to be possible in the web console (almost nothing is) and via the Terraform provider (glad it exists but frankly it's an alpha/WIP) and for parity vs the CLI in docs. I used it in above comment as a shorthand for the fact that such an API/functionality exists that you can just say to Fly.io (whether via CLI or ~better~ other means) 'hey stick this in a second region too'.
- yencabulator 4y ago
  This phrasing of command-lines as magic is weird to me, with an obviously different background. I'd consider a command-line example more explicit in what it is doing than either a 5-step walkthrough of the web UI, or Terraform. flyctl is a reasonably simple GraphQL client. They haven't really documented the GraphQL API (see e.g. https://fly.io/docs/app-guides/custom-domains-with-fly/#graphql-api-notes https://fly.io/docs/app-guides/custom-domains-with-fly/#grap... for one slice of it), but that's all flyctl does.

by OJFord 4y ago

thegeomaster 4y ago

I know that, but I've never understood the PaaS model of just slapping X% on top of the underlying cloud cost. It just invites customers to migrate to the underlying cloud once they're big enough to hire and sustain a dedicated devops team and setup something like k8s. Surely the amortized costs of the Fly.io platform don't scale linearly with the power of the VMs you rent from them. A 64GiB server won't be twice as expensive to maintain as a 32GiB one. So why not create a model that e.g. consists of a cost per VM/autoscaling group/etc plus whatever the VMs cost? I'm genuinely interested, I could very well be missing something.

mrkurt 4y ago
The costs of the VMs scale linearly. The bigger they get, the more additional capacity we need to be able to launch on demand ones. It's not just RAM, though, our physical servers have a consistent ratio of RAM/CPU/disk available. You're basically just buying slivers of hardware we've already paid for. That said, our pricing isn't far off of AWS. They have much better economies of scale than we do, and can afford to do Graviton, but you get pretty close horsepower per dollar for comparable instances.

OJFord 4y ago

Also, just for the record, I'm the sort of person that really dislikes magic command lines, I don't want docs that tell me do fly this or that. I want it to be possible in the web console (almost nothing is) and via the Terraform provider (glad it exists but frankly it's an alpha/WIP) and for parity vs the CLI in docs. I used it in above comment as a shorthand for the fact that such an API/functionality exists that you can just say to Fly.io (whether via CLI or ~better~ other means) 'hey stick this in a second region too'.

yencabulator 4y ago
This phrasing of command-lines as magic is weird to me, with an obviously different background. I'd consider a command-line example more explicit in what it is doing than either a 5-step walkthrough of the web UI, or Terraform. flyctl is a reasonably simple GraphQL client. They haven't really documented the GraphQL API (see e.g. https://fly.io/docs/app-guides/custom-domains-with-fly/#graphql-api-notes https://fly.io/docs/app-guides/custom-domains-with-fly/#grap... for one slice of it), but that's all flyctl does.