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 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?
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.