4 ms·
SMB or indie developers are not the first/primary customers for Azure/AWS that they design their application for. Any enterprise will not want any limits becau
by manquer 5y ago
SMB or indie developers are not the first/primary customers for Azure/AWS that they design their application for.
Any enterprise will not want any limits because of spends, they would be lot more pissed if service was pulled because spending cap set by someone sometime in the past is now exceeded. Likely is why such feature is optional not mandatory.
Excess/unexpected billing would be negotiated in typical sales cycle discussions. Making a default hard cap however would result in a lot of senior people are going midnight calls for emergency budget approvals, management would get annoyed by that.
- foobiekr 5y agoI 100% work for a large enterprise and we would absolutely like spending policies in place. After all, we have fixed OPEX budgets planned in advance of the quarter.
- manquer 5y agoHaving a policy is not same as a hard block, you would want spending alerts and escalations and reports, but do you really want a hard block on crossing a limit ? Admittedly I don't have experience working with very many devops /SRE teams, however I have never seen any enterprise vendor relationships were spend is hard capped for b2b sales with centrally managed procurement.
- foobiekr 5y agoYou know, there are alternatives between a sudden total cut off of service and nothing at all. Some mechanism to prevent sudden, large unexpected bills, yes, that’s desired. Notifications are not enough. A lot of people have provided tons of examples of follow ups by vendors in this thread where novel large orders are double checked. AWS could provide any manner of preventative policies and cost controls but they choose not to. Given the choice between blowing 2x past the planned opex and an outage, yeah, there are plenty of applications where the latter is preferable.