6 ms·

Thanks for the feedback! Autoscaling is not yet supported on the platform (but is coming soon). Before autoscaling lands as a feature, insights based alerting w

Thanks for the feedback! Autoscaling is not yet supported on the platform (but is coming soon). Before autoscaling lands as a feature, insights based alerting will also land. You'll be able to setup alerts for scaling events, bandwidth, cpu, memory, and more that can be sent via email or slack.

onion2k 6y ago
My point is that alerts aren't really enough. If I'm asleep or on a plane or something then it could be many hours before I even see an alert, by which time it's probably too late. I'd prefer to be able to set up rules beforehand that prevent an unforeseen bill. If the App Platform doesn't have that feature, and it isn't planned, that's OK but I'd argue that isn't really preventing a surprise bill as the marketing site claims. A warning isn't quite the same as prevention.
- garettmd 6y ago
  Most autoscaling platforms let you define min and max types of restrictions. I assume DO would have the same functionality in their autoscaling.
  - bravura 6y ago
    Correct me if I'm wrong, but AWS doesn't allow you to do hard limits. I was creating a public S3 bucket today and wanted there to be a hard limit, so I couldn't get slapped with a huge AWS bill. Looking at the docs, it appears I can get alerts but not set a hard limit on my billing.
    - user5994461 6y ago
      AWS allow to set limits on autoscaling groups, ECS, EKS. All the things with autoscaling really. If you're worried about billing, S3 is not a great choice. S3 is precisely unlimited storage for enterprise.
      - SahAssar 6y ago
        Saying that something that is billed based on usage is not also able to have it's usage capped seems weird.
- phildougherty 6y ago
  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.
p410n3 6y ago
What good are alerts when I sleep? I usually don't even check my personal mail until I'm done at work. There's a lot that can happen in 16h
- rgbrenner 6y ago
  On AWS I tie high billing threshold alerts with PagerDuty so it wakes me up at night.
  - tupputuppu 6y ago
    Oh man, what a user friendly solution
mariushn 6y ago
We need limits, not alerts. That is, autoscale up to X.
- phildougherty 6y ago
  Thanks for the clarification. We do plan to implement hard limits in the autoscaling feature.
names_are_hard 6y ago
I've said this elsewhere in this thread, but there's a difference between predictable pricing and controlling runaway costs. Predictable pricing means that each month my bill is the same: I'm on a $15 plan, I pay $15 a month. No nickel-and-diming, no hidden fees, life is simple. This is a good thing. Controlling costs means that no matter what happens, my costs will not exceed $x/month. Service might degrade if necessary, but I will not pay for anything above some upper limit. Seems that DO has the former but not the latter, because if things get out of hand (caused by an attack, a bug in my code, going viral) the customer can be stuck with a bill. Alerts do not alleviate this risk. Pricing that is generally predictable does not alleviate this risk. Only a hard cap does. I want a plan that says "you have 250 GB of traffic, after which requests will fail and you'll get an email". You can make it nicer by sending me a warning email at 200GB so that I have time to upgrade my plan if I want.

onion2k 6y ago

My point is that alerts aren't really enough. If I'm asleep or on a plane or something then it could be many hours before I even see an alert, by which time it's probably too late. I'd prefer to be able to set up rules beforehand that prevent an unforeseen bill. If the App Platform doesn't have that feature, and it isn't planned, that's OK but I'd argue that isn't really preventing a surprise bill as the marketing site claims. A warning isn't quite the same as prevention.

garettmd 6y ago
Most autoscaling platforms let you define min and max types of restrictions. I assume DO would have the same functionality in their autoscaling.
- bravura 6y ago
  Correct me if I'm wrong, but AWS doesn't allow you to do hard limits. I was creating a public S3 bucket today and wanted there to be a hard limit, so I couldn't get slapped with a huge AWS bill. Looking at the docs, it appears I can get alerts but not set a hard limit on my billing.
  - user5994461 6y ago
    AWS allow to set limits on autoscaling groups, ECS, EKS. All the things with autoscaling really. If you're worried about billing, S3 is not a great choice. S3 is precisely unlimited storage for enterprise.
    - SahAssar 6y ago
      Saying that something that is billed based on usage is not also able to have it's usage capped seems weird.
phildougherty 6y ago
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.

p410n3 6y ago

What good are alerts when I sleep? I usually don't even check my personal mail until I'm done at work. There's a lot that can happen in 16h

rgbrenner 6y ago
On AWS I tie high billing threshold alerts with PagerDuty so it wakes me up at night.
- tupputuppu 6y ago
  Oh man, what a user friendly solution

mariushn 6y ago

We need limits, not alerts. That is, autoscale up to X.

phildougherty 6y ago
Thanks for the clarification. We do plan to implement hard limits in the autoscaling feature.

names_are_hard 6y ago

I've said this elsewhere in this thread, but there's a difference between predictable pricing and controlling runaway costs. Predictable pricing means that each month my bill is the same: I'm on a $15 plan, I pay $15 a month. No nickel-and-diming, no hidden fees, life is simple. This is a good thing. Controlling costs means that no matter what happens, my costs will not exceed $x/month. Service might degrade if necessary, but I will not pay for anything above some upper limit. Seems that DO has the former but not the latter, because if things get out of hand (caused by an attack, a bug in my code, going viral) the customer can be stuck with a bill. Alerts do not alleviate this risk. Pricing that is generally predictable does not alleviate this risk. Only a hard cap does. I want a plan that says "you have 250 GB of traffic, after which requests will fail and you'll get an email". You can make it nicer by sending me a warning email at 200GB so that I have time to upgrade my plan if I want.