[KronisLV]

> So which cloud provider offers a HARD spend limit?

It still baffles me that this isn't the default. Then again, egress/ingress costs also baffle me, why not just offer capped speed and unlimited bandwidth?

I doubt that i'll ever willingly use a platform that i pay for myself, which can just decide to charge me bunches of money because of my site/app getting DDoS'ed (assuming not all components are fully protected at the edge or something) or suddenly gaining popularity.

In my eyes, such scalability should be opt in (or at least opt out) and by default my apps should just break under the load, much like any self-hosted software would, which may be preferable in some circumstances (e.g. API manages backpressure as best as it can, once request queues fill up, it just gives "503 Service Unavailable" with something like "Retry-After" and any clients/front ends are supposed to show messages to try again later, or automatically retry after a while).

To that end, here's a list of providers that give you such fixed resources (in this case VPSes) and that i personally have used in the past:

• Time4VPS: https://www.time4vps.com/?affid=5294 (currently hosts most of my sites, hence affiliate link)

• Contabo: https://contabo.com/en/

• Hetzner: https://www.hetzner.com/cloud

• Scaleway: https://www.scaleway.com/en/elements/

• Vultr: https://www.vultr.com/products/cloud-compute/

• DigitalOcean: https://www.digitalocean.com/products/droplets/

Of course, some of those also offer managed services, but in my eyes it's far safer to just run MySQL/MariaDB/PostgreSQL/MongoDB/Redis and any other piece of software in Docker (or OCI compatible) containers, as opposed to using something proprietary, even with protocol compatibility. That way, it's also possible to migrate between providers easily, should the need arise.

[redwood]

Would you be comfortable with losing all of your data and going down when the spend limit is hit? That's fundamentally why this is not as simple as you think

[KronisLV]

> Would you be comfortable with losing all of your data and going down when the spend limit is hit?

This doesn't feel to me like a generous enough statement about all of the finer points.

Would i be okay with my servers no longer responding to web requests (or doing so with reduced port speeds with some of the above hosts, e.g. Time4VPS) in case of spending limits being unexpectedly hit? Yes, definitely, since my projects going dark for a bit or slowing down would be preferable to me ending up not being able to pay my rent and having to rely on public outcry about the large bill and the vendor's mood that day towards letting that one slide.

Would i be okay with my servers running out of space and no longer writing new data to any database, merely responding with the appropriate errors instead? Yes, definitely, because that probably signals the fact that for some reason lots of space has suddenly started getting used for no reason, something that happened so fast that i didn't even get to plan the appropriate scaling, once Zabbix would warn me about 80% of the disk being full (or any monitoring tool would have an alert set up for this). This would probably also be yet another sanity check.

Would i be okay with my servers suddenly ceasing to exist and being wiped from existence, for any reason short of excessive abuse complaints or repeated ToS violations? I most certainly wouldn't want this to happen, yet in my experience it has never actually happened - some of the vendors listed allow you to pre pay for the resources you're about to use (e.g. Time4VPS and Contabo), even offering discounts for longer term reservations much like AWS does, without unexpected charges to you like AWS would do. In contrast, some of the other vendors listed allow you to pay based on hourly usage (Hetzner, Scaleway, Vultr, DigitalOcean, at least IIRC), but also won't have unpredictable pricing spikes because of set limits for the most part (ingress/egress charges may still apply, however, a worrying trend in the industry that muddies the waters), if i pay for a 5$ VPS every month, that's what i can expect to pay most months regardless of usage (assuming 100% uptime).

With these factors in mind, my servers being wiped would probably have to happen due to either me misusing those services, or alternatively me failing to pay the bills even with the more predictable pricing structures, which is actually very much like a person's electricity being turned off due to them not paying for it - as unpleasant as that'd be, no surprises there. Personally, i don't subscribe to the belief that managed services with unpredictable billing are the only way to do software nowadays, something that Richard Stallman coined as SaaSS (Services as a Software Substitute) and about which you can read more here: https://www.gnu.org/philosophy/who-does-that-server-really-s...

Alas, as long VPS uptime with predefined resources is the unit of computation that you're paying for, everything else should be fairly simple from there onwards.

[immibis]

As long as you are paying by the minute for server time and by the byte-hour for storage, running out of money means you don't get any more minutes or any more byte-hours. No more server time means your servers just vanish into the ether. It doesn't mean they start returning error pages of being unable to write to the database.

They don't reach into your servers and meddle with your nginx configuration. They don't shrink your disk volumes to the amount that's already in use. That wouldn't be possible.

[KronisLV]

> As long as you are paying by the minute for server time and by the byte-hour for storage, running out of money means you don't get any more minutes or any more byte-hours.

Exactly, that's why I said that being able to prepay for a month ahead (or a similar period) is a good thing, as is anything else that makes billing predictable (such as no auto scaling).

> No more server time means your servers just vanish into the ether. It doesn't mean they start returning error pages of being unable to write to the database.

Come to think of it, that's probably the case for most people out there who just use one account/card for all of their resources.

What i described is indeed possible with a tiered approach: alotting most of your funds to keeping the DBs alive with all of your data and whatever is left apart from that for the more dynamic components - VPSes that work as load balancers or others that host your APIs.

Of course, the ways to achieve something like that are plentiful, for example, multiple accounts with different virtual cards (which may or may not be allowed), using multiple different service providers for different parts of the system (e.g. if one has better storage plans and latency isn't an issue, for example, data centers in same country), using multiple service providers for redundancy (hard to do for most DBs, easier for container clusters) or even using functionality provided by the platforms themselves (which may or may not exist when it comes to billing, even though DigitalOcean had a pretty lovely way of grouping resources into projects).

Come to think of it, that's probably a space that could use a lot of improvements.

> They don't reach into your servers and meddle with your nginx configuration. They don't shrink your disk volumes to the amount that's already in use. That wouldn't be possible.

This isn't even necessary. If platforms allowed me to say: "Here's a bunch of API nodes that I'll give up to X$ for the following month and here's another DB node that I'll prepay in full with Y$ for the following month" then none of the other multi-cloud deployment strategies or tiering would even need to be considered.

If we want to consider situations with auto scaling or other types of dynamic billing, then we should also be able to say something along the lines of: "For those API nodes with my preconfigured init script, i want at least Z instances available with the given funds, whereas any remainder can be used up for autoscaling up to W total nodes. Thus, if the alotted funds run out, it all will return to the prepaid/reserved minimum of Z instances for the rest of the billing period."

AWS Lambda can charge you for usage at sub second resolutions and yet neither they nor other cloud platforms provide good resource prioritization solutions or fine grained billing limits, doing just alerts at best? I'm not sure why that is, but until things change, we'll just have to live with workarounds. Technically some of that would already be possible with something like Reserved Instances on AWS (https://aws.amazon.com/ec2/pricing/reserved-instances/), but that's still not granular enough IMO. Then you'd just have RIs and "everything else" as opposed to resource groups with spending limits.

Furthermore, if my Time4VPS server runs out of bandwidth, I'm not expected to pay more, the port speed just goes down until the end of the prepaid billing period. That's the sort of simplicity that's one of the best current options, with minimal hassles. And if i ever can't afford to renew 10 API servers, then I'll just get 5 or whatever amount i can afford.

More platforms should be like that, maybe at a day/hour/... resolution, though and with APIs that allow us to decide ourselves how often we want to renew services and for what periods, like a few clever scripts online that you can find for turning off AWS/other service instances when not in use. Currently any fine grained controls that you want on those platforms would have to be done programmatically, but it's not like you could easily manage ingress/egress costs that way.

[redwood]

I think your line of thinking is rooted in the assumptions that these cloud services use the fact that they don't do what you describe as a ploy to make more money. Instead it's that they choose to invest in other kinds of functionality; while the concepts you describe are certainly possible to build, they are specifically demanded by a narrow subset of the market which makes them difficult to prioritize

[KronisLV]

That's perfectly fair, then.

I'll simply use services that fall more in line with what i want and i urge others to do the same, to better suit their needs and avoid the possibility of some very unpleasant financial circumstances down the road, at least as far as personal projects are concerned. Hence the list of some lovely providers in the post above.

They'll simply continue to work with their current approaches to billing, missing out on the 0.01% (read: humorous made up figure to not create the impression that i believe that huge platforms should work like i expect them to, my ego isn't that huge) or so of additional income that they'd get by catering to all of the people like me in the world. That's the beauty of a (mostly) free market - supply and demand.