3 ms·
> Almost no level of accidental spend is worth creating downtime or data loss in a critical application. That feels like a bit of a red herring — if that was t
by another-dave 2y ago
> Almost no level of accidental spend is worth creating downtime or data loss in a critical application.
That feels like a bit of a red herring — if that was their ethos, then you'd _have_ to choose burstable/autoscaling config on every service. If I can configure a service to fall over rather than scale at a hard limit, that points to them understanding different their use cases (prod vs dev) and customer types (start-up vs enterprise).
Additionally, anytime I've worked for an enterprise customer, they've had a master service agreement set-up with AWS professional services rather than entering credit card info, so they could use that as a simple way to offer choices.
- Terretta 2y agoA service doesn't just "fall over" at a limit. There has to be other machinery to limit it. Given that all your usage and traffic other than that at the limit request should not be gated or limited, why would you want someone else injecting additional complexity and bottleneck risk inline? Determine your own graceful envelope, implement accordingly.
- another-dave 2y agoThe OP was saying that having any spending limit would be antithetical to enterprise usage because it could bring critical services to a halt. My point was, if that's a reason to have unbounded spending, why allow me to spin up a service that can get CPU or RAM bound? > Determine your own graceful envelope, implement accordingly. Which most people do have, but we then also want an "ungraceful" backstop — trains have both a brake and a dead man's switch.