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.
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.
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.
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.
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.
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.
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.
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.
If you want controllable costs and you don't want people using your service because interest explodes, then just stick to a regular droplet, no?
The entire point of this is that if usage explodes, you want to pay to support that usage. That's the entire feature.
(Also, HN frontpage traffic isn't that much -- it's a few requests per second at most, not thousands per second.)
The only scenario I can imagine where this would be a genuine concern would be if you were subjected to a (D)DoS-type attack. But in that case you still want legitimate users to get through, so you really need a separate DoS-protection layer which is totally orthogonal to this.
Am I missing something?
If you're worried about billing, S3 is not a great choice. S3 is precisely unlimited storage for enterprise.
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.
If your droplet isn't using all of it's resources (CPU, RAM, DISK), they are able to oversell their capacity.
Why would that be true? I thought the point of a PaaS was getting a Platform - as a Service. I don't interpret that to mean having no control or limits on potential costs. To me a PaaS is about not wanting to manage a the metal or infra under the app. Which i don't think is misguided or inaccurate.
To look at it differently: I am a customer to someone. I am a customer who wants to buy a product that manages all of the infra for my application. I also have a limited budget, and the notion of an unlimited budget is an instant no for me.
Call the XaaS whatever you like, but my motivation is clear. Maybe DO doesn't want me as a customer (if what you say is true about PaaS), but i think there's opportunity there for a new XaaS.
There's a difference between load balancing of shared resources and (what I believe must be) deliberately deceptive practices. A customer-centric company would send an email to notify you of this kind of over-charging.
It's premeditated and dispicable.
The pricing model for App Platform seems antithesis to that, though, which is interesting. DO is becoming more like AWS/GCP with every feature release, which I don't necessarily find to be a good thing.
Nothing was deployed. Zip, zero, zilch resources were used month-on-month. My fault, yes, but naively I assumed if this was the case, billing would automatically drop to zero.
Whilst I bought access to X servers but had no way to remove the charge associated with that without contacting customer services when I decided X=0, permanently.
I mean, really? I have no problem with PAYG or PAYG to a capped amount, but PAYG for a fixed amount regardless of whether or not the resources are actually deployed is disingenuous at best.
This is like leasing a car, leaving it parked, and then complaining you have to pay the lease.
You don't complain that you were charged $200 for renting a parking space and never using it, no reason for this to be different for servers.
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.
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.
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.
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.
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.
My guess is that people who are interested in controlling costs are also not getting enough value from auto scaling services. So we're already not attracting those folks, and offering a cost control feature isn't enough to get us over the hump.
Not even considering something like AWS with a bazillion types of services, say you have a cloud hosting service that runs nothing but auto-scaling clusters of servers billed by the hour. So I set a cap on costs but not cap on scaling up and turn it loose. It gets a hug of death from something, scales to the sky, does serve all of that traffic fine, but burns through my monthly cost cap in an hour. Oops, now it's down entirely for the next 3 weeks or whatever. Does anybody in the world who's willing to pay for hosting something actually want that? I have to doubt it.
On the other hand, capping the scaling size by number of hosts sounds pretty reasonable. Set a cap at say 2x your normal peak traffic. You get a hug from something, it hits the cap. Most of your extra traffic gets errors or really slow responses, but your service stays up, even when the traffic dies down. Your monthly costs are a bit higher than usual, but manageable. That sounds like a much better result to me.
That doesn't even get into stuff like, oh hey we dropped your DB server because you hit your cost cap early and it costs money to keep it running and to create a new backup too, hope you don't miss that data too much!
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.
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.
If for some convoluted reason this is wrong, then you guys really need to reconsider how you're presenting your prices and to lay out exactly what those convoluted reasons are, because Fly's pricing page certainly tells people that trying to match DigitalOcean's $5 plan is going to cost 10x on Fly.