4 ms·

Sorry, I think I misunderstood what you were saying there. Could you clarify a bit more about what kind of functionality you'd prefer we support in the scenario

Sorry, I think I misunderstood what you were saying there. Could you clarify a bit more about what kind of functionality you'd prefer we support in the scenario you described? A large influx of traffic hits your application while you are unavailable to handle it. If you do not have autoscaling enabled, your application performance could suffer, if you do have it enabled your bill could grow out of bounds. We do plan to let you set min and max bounds for autoscaling once it is implemented. Thanks for your help!

onion2k 6y ago
We do plan to let you set min and max bounds for autoscaling once it is implemented. This is exactly the sort of thing I'm talking about, but for money rather than computing resources or bandwidth. I'd like a feature that where the requirement is effectively "Fall back to a serving sorry-I'm-poor.html instead of the app if the total monthly bill has exceeded $xxx". For a side project I'm more interested in not paying an unexpected bill than getting traffic.
- mrkurt 6y ago
  For what it's worth, we (Fly.io) have this feature, and announced it as part of our launch post on HN. But literally no one has asked us to enable it on their apps. So we never made it self service. I think for most companies, it's better to set the expectation that the service costs money, bursts will cost more money, and then forgive outlier charges once or twice. It's tremendously difficult to compete against the AWS's of the world, putting work into features specifically to minimize how much people spend seems like a good way to fail a company.
  - the_duke 6y ago
    I'd argue that many users that end up with surprise bills are either inexperienced or are deploying something small without giving it much thought. In those cases, the users will either not know or not think about such expense limits. The solution is to set relatively strict limits by default and even occasionally warn users about unused/underutilized resources. But as you said: such features are bad for the bottom line . And I can appreciate the enormous difficulty of competing with the big 3.
    - mrkurt 6y ago
      I think such features create really negative surprises too. People expect their app or service to keep working at almost any scale. Disabling an app that hits a threshold sounds terrible, because most peoples' apps _benefit_ from more (legit) activity and they are delighted to pay the extra fees if things just continue to work. For people who are inexperienced or don't give it much thought, just waiving their overage fees creates a really nice experience. We've had multiple instances of people asking why their bill is so high and being relieved/excited when we explained it and made it go away. People love when we're responsive to problems.
  - nicoburns 6y ago
    > It's tremendously difficult to compete against the AWS's of the world, putting work into features specifically to minimize how much people spend seems like a good way to fail a company. It's also something that people actively dislike about AWS, and thus a good selling point. Albeit it's probably mostly smaller projects that care about this.
    - mrkurt 6y ago
      It sounds like a good selling point but I don't think it works out that way. People dislike a lot of things about AWS and it's still something that almost every technical business spends money on.
  - ufmace 6y ago
    Very interesting that this feature is often demanded in tones of righteous outrage on posts about autoscaling cloud services, yet when actually implemented, nobody has actually set it up.
    - cloverich 6y ago
      > So we never made it self service. I may not underestand parent, but it sounds like its not equivalent to a button next to the auto-scale but more like an email and pre-requisite knowledge that it exists?
      - mrkurt 6y ago
        Yes we advertised it as a feature to all new signups, with a link to request limits. It's not equivalent to a button, the dirty secret is that when people requested it, I planned to put a notification in my calendar to go look at their usage the last day of the month and adjust their bill accordingly. :) We were concerned about spending time on marginal features that didn't actually matter much to people, so we "launched" it without building it to see if anyone cared.
        jon-wood 6y ago
        I’m also not interested in this feature, but do want to say that’s a lovely example of implementing the bare minimum to gauge the value of a feature.
        franey 6y ago
        That was a great MVP plan for that feature! Figuring out what not to build is a great way to save development time.
        SahAssar 6y ago
        I'm not one of your customers but when I have looked at pay-as-you-go services or autoscaling services before I basically don't even consider any that don't allow me to cap the costs per month or similar. So you could perhaps also consider that if it is only marketed when you sign up and not a clearly defined feature some people (like me) will just never sign up at all.
  - Godel_unicode 6y ago
    > putting work into features specifically to minimize how much people spend seems like a good way to fail a company. What a customer-hostile thing to say, never working with you! What if I told you that if you're actually trying to build a relationship with your customers and have them want to do business with you, it's best to focus on solving their problems as opposed to taking as much of their money as possible.
    - mrkurt 6y ago
      > What a customer-hostile thing to say, never working with you! The point is that I'd rather just wave surprise fees than build a bunch of infrastructure to prevent them. From what we can tell, customers almost never have surprise bursts of traffic, but it's something they think about a lot. It's pretty easy to just say "you're not responsible for expenses associated with abuse or attacks or other nasty surprises". The purpose of a metered service is to give people access to tools and features that would be prohibitively expensive otherwise. The trade off is that the expense also grows incrementally.
      - Godel_unicode 6y ago
        Sounds like we agree on what you're doing, we just disagree about whether it's a good approach. I don't want to need to depend on you being in a good mood to waive fees (or more likely, to hope you're not so low on runway that support gets incentives not to waive them until after your next round closes). I don't want to have to guess whether your terms mean what they say, or whether that giant potential bill might magically go away if I incur it and can convince you it was, quote, nasty. I do want to deal with people who have thought hard about how to build their product in a way that I can depend on and reason confidently about, and who treat me like the seasoned adult I am.
        mrkurt 6y ago
        I think you're not a good customer for us? I'm not sure that makes us hostile, or you wrong, but I'm pretty comfy with how we treat our customers (and they seem cool with it too).
  - deleted 6y ago
    [deleted]
- pwdisswordfish0 6y ago
  If there's any confusion about this, look at nearlyfreespeech.net. You deposit funds (let's say $20) into your account, and as your site consumes resources, it draws from your balance. So $20 is $20. If you set up a crummy low-traffic blog and that $20 lasts four months, then fine. If it lasts two weeks and then there's a surge in traffic, or the server hits some bug that causes it to spiral out of control, then your site gets killed when your balance hits $0. You can set up alerts, but there's a hard limit for how much you can be charged—it's whatever funds you deposited into your account. (Really, that's not even the right way to put it, because you're charged at the moment you deposit them.) This isn't acceptable for everybody—many businesses would prefer to stay up and be billed after-the-fact. But that use cases is already well-served by the industry. (Overserved, really.) The market segment where the alternative situation is the best fit (pretty much every hobbiest who isn't bringing in a single cent off their side project) is extremely underserved. NFSN is the only provider I know of that even offers this.
jacurtis 6y ago
I think he is simply requesting threshold limits. So for example you could set a threshold of 2 - 5 nodes/droplets. This way you will always have at least 2 nodes running, even with zero traffic, because that is the minimum you requested. Likewise the upper bound limit of 5 nodes/droplets would limit the maximum nodes that the service would generate. So it autoscales up until it hits the maximum threshold and stops. Yes, if the app needed more resources than this, due to a spike in traffic, than performance would obviously suffer. But depending on the budget and needs of the project this might be the preferred outcome over incurring unexpectedly high server costs that you are not prepared to handle.
heelix 6y ago
Way to many folks end up with surprise bills. I'd like the option to say - over x dollars cost, shut the damn thing off to the public. Back in the /. days, got a minor project hit by the mass internets and hit with bandwidth charges by the time I noticed.

onion2k 6y ago

We do plan to let you set min and max bounds for autoscaling once it is implemented. This is exactly the sort of thing I'm talking about, but for money rather than computing resources or bandwidth. I'd like a feature that where the requirement is effectively "Fall back to a serving sorry-I'm-poor.html instead of the app if the total monthly bill has exceeded $xxx". For a side project I'm more interested in not paying an unexpected bill than getting traffic.

mrkurt 6y ago
For what it's worth, we (Fly.io) have this feature, and announced it as part of our launch post on HN. But literally no one has asked us to enable it on their apps. So we never made it self service. I think for most companies, it's better to set the expectation that the service costs money, bursts will cost more money, and then forgive outlier charges once or twice. It's tremendously difficult to compete against the AWS's of the world, putting work into features specifically to minimize how much people spend seems like a good way to fail a company.
- the_duke 6y ago
  I'd argue that many users that end up with surprise bills are either inexperienced or are deploying something small without giving it much thought. In those cases, the users will either not know or not think about such expense limits. The solution is to set relatively strict limits by default and even occasionally warn users about unused/underutilized resources. But as you said: such features are bad for the bottom line . And I can appreciate the enormous difficulty of competing with the big 3.
  - mrkurt 6y ago
    I think such features create really negative surprises too. People expect their app or service to keep working at almost any scale. Disabling an app that hits a threshold sounds terrible, because most peoples' apps _benefit_ from more (legit) activity and they are delighted to pay the extra fees if things just continue to work. For people who are inexperienced or don't give it much thought, just waiving their overage fees creates a really nice experience. We've had multiple instances of people asking why their bill is so high and being relieved/excited when we explained it and made it go away. People love when we're responsive to problems.
- nicoburns 6y ago
  > It's tremendously difficult to compete against the AWS's of the world, putting work into features specifically to minimize how much people spend seems like a good way to fail a company. It's also something that people actively dislike about AWS, and thus a good selling point. Albeit it's probably mostly smaller projects that care about this.
  - mrkurt 6y ago
    It sounds like a good selling point but I don't think it works out that way. People dislike a lot of things about AWS and it's still something that almost every technical business spends money on.
- ufmace 6y ago
  Very interesting that this feature is often demanded in tones of righteous outrage on posts about autoscaling cloud services, yet when actually implemented, nobody has actually set it up.
  - cloverich 6y ago
    > So we never made it self service. I may not underestand parent, but it sounds like its not equivalent to a button next to the auto-scale but more like an email and pre-requisite knowledge that it exists?
    - mrkurt 6y ago
      Yes we advertised it as a feature to all new signups, with a link to request limits. It's not equivalent to a button, the dirty secret is that when people requested it, I planned to put a notification in my calendar to go look at their usage the last day of the month and adjust their bill accordingly. :) We were concerned about spending time on marginal features that didn't actually matter much to people, so we "launched" it without building it to see if anyone cared.
      - jon-wood 6y ago
        I’m also not interested in this feature, but do want to say that’s a lovely example of implementing the bare minimum to gauge the value of a feature.
      - franey 6y ago
        That was a great MVP plan for that feature! Figuring out what not to build is a great way to save development time.
      - SahAssar 6y ago
        I'm not one of your customers but when I have looked at pay-as-you-go services or autoscaling services before I basically don't even consider any that don't allow me to cap the costs per month or similar. So you could perhaps also consider that if it is only marketed when you sign up and not a clearly defined feature some people (like me) will just never sign up at all.
- Godel_unicode 6y ago
  > putting work into features specifically to minimize how much people spend seems like a good way to fail a company. What a customer-hostile thing to say, never working with you! What if I told you that if you're actually trying to build a relationship with your customers and have them want to do business with you, it's best to focus on solving their problems as opposed to taking as much of their money as possible.
  - mrkurt 6y ago
    > What a customer-hostile thing to say, never working with you! The point is that I'd rather just wave surprise fees than build a bunch of infrastructure to prevent them. From what we can tell, customers almost never have surprise bursts of traffic, but it's something they think about a lot. It's pretty easy to just say "you're not responsible for expenses associated with abuse or attacks or other nasty surprises". The purpose of a metered service is to give people access to tools and features that would be prohibitively expensive otherwise. The trade off is that the expense also grows incrementally.
    - Godel_unicode 6y ago
      Sounds like we agree on what you're doing, we just disagree about whether it's a good approach. I don't want to need to depend on you being in a good mood to waive fees (or more likely, to hope you're not so low on runway that support gets incentives not to waive them until after your next round closes). I don't want to have to guess whether your terms mean what they say, or whether that giant potential bill might magically go away if I incur it and can convince you it was, quote, nasty. I do want to deal with people who have thought hard about how to build their product in a way that I can depend on and reason confidently about, and who treat me like the seasoned adult I am.
      - mrkurt 6y ago
        I think you're not a good customer for us? I'm not sure that makes us hostile, or you wrong, but I'm pretty comfy with how we treat our customers (and they seem cool with it too).
- deleted 6y ago
  [deleted]
pwdisswordfish0 6y ago
If there's any confusion about this, look at nearlyfreespeech.net. You deposit funds (let's say $20) into your account, and as your site consumes resources, it draws from your balance. So $20 is $20. If you set up a crummy low-traffic blog and that $20 lasts four months, then fine. If it lasts two weeks and then there's a surge in traffic, or the server hits some bug that causes it to spiral out of control, then your site gets killed when your balance hits $0. You can set up alerts, but there's a hard limit for how much you can be charged—it's whatever funds you deposited into your account. (Really, that's not even the right way to put it, because you're charged at the moment you deposit them.) This isn't acceptable for everybody—many businesses would prefer to stay up and be billed after-the-fact. But that use cases is already well-served by the industry. (Overserved, really.) The market segment where the alternative situation is the best fit (pretty much every hobbiest who isn't bringing in a single cent off their side project) is extremely underserved. NFSN is the only provider I know of that even offers this.

jacurtis 6y ago

I think he is simply requesting threshold limits. So for example you could set a threshold of 2 - 5 nodes/droplets. This way you will always have at least 2 nodes running, even with zero traffic, because that is the minimum you requested. Likewise the upper bound limit of 5 nodes/droplets would limit the maximum nodes that the service would generate. So it autoscales up until it hits the maximum threshold and stops. Yes, if the app needed more resources than this, due to a spike in traffic, than performance would obviously suffer. But depending on the budget and needs of the project this might be the preferred outcome over incurring unexpectedly high server costs that you are not prepared to handle.

heelix 6y ago

Way to many folks end up with surprise bills. I'd like the option to say - over x dollars cost, shut the damn thing off to the public. Back in the /. days, got a minor project hit by the mass internets and hit with bandwidth charges by the time I noticed.