←back to thread

DigitalOcean App Platform

(pages.news.digitalocean.com)
646 points digianarchist | 4 comments | | HN request time: 0s | source
Show context
onion2k ◴[] No.24698869[source]
Like all DigitalOcean products, the App Platform provides predictable, easy-to-understand pricing that allows you to control costs to prevent surprise bills.

I can't see any features listed that enable me to control costs to prevent surprise bills. If a site got submitted to HN and hugged to not-to-death-because-it-autoscales then I'd wake up to a bunch of alerts and massive outbound bandwidth bill. I don't want that. I want something that stops that happening.

replies(3): >>24698927 #>>24700146 #>>24700352 #
phildougherty ◴[] No.24698927[source]
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.
replies(4): >>24699014 #>>24699023 #>>24699668 #>>24718319 #
onion2k ◴[] No.24699014[source]
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.

replies(2): >>24699078 #>>24699110 #
phildougherty ◴[] No.24699110[source]
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!
replies(3): >>24699221 #>>24699275 #>>24699681 #
onion2k ◴[] No.24699221[source]
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.

replies(2): >>24699292 #>>24704108 #
mrkurt ◴[] No.24699292[source]
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.

replies(5): >>24699883 #>>24699884 #>>24700298 #>>24700511 #>>24703935 #
1. Godel_unicode ◴[] No.24700511[source]
> 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.

replies(1): >>24701511 #
2. mrkurt ◴[] No.24701511[source]
> 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.

replies(1): >>24703040 #
3. Godel_unicode ◴[] No.24703040[source]
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.

replies(1): >>24703252 #
4. mrkurt ◴[] No.24703252{3}[source]
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).