What a disaster
-
So I want to do a pro bono job for a small bridge club, I set up what I thought was a free Azure account, a whole bunch of free services including sql server, great I thought just what I am looking for. Check the usage after a few days development and all looks good 3% used. The I get a bill for $700 the next month, do you think there is any way to dispute the bill, nope, just a chatbot and we all know how helpful they are. I obviously did something wrong with the subscription but there seems to be no way to find out what caused the bill. I wonder if I can get the CC to cancel the charge?
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
I know I'm a bit late, but the first rule for Cloud services is: add a notification about estimated costs. I do the same for a customer using some free Azure services with a pay-as-you-go subscription, where the only paid service are a few SQL Server. Never paid more than 70€, using a few Sql server, Application Insights, storage, etc.
-
So I want to do a pro bono job for a small bridge club, I set up what I thought was a free Azure account, a whole bunch of free services including sql server, great I thought just what I am looking for. Check the usage after a few days development and all looks good 3% used. The I get a bill for $700 the next month, do you think there is any way to dispute the bill, nope, just a chatbot and we all know how helpful they are. I obviously did something wrong with the subscription but there seems to be no way to find out what caused the bill. I wonder if I can get the CC to cancel the charge?
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
The only disaster here is why in the first place you would ever use a monopolistic, ultimately centralized and therefore non-scalable service, architected with an ancient and flawed for this purpose technology (SQL). Let me guess: expediency and convenience. What goes around, comes around.
-
The only disaster here is why in the first place you would ever use a monopolistic, ultimately centralized and therefore non-scalable service, architected with an ancient and flawed for this purpose technology (SQL). Let me guess: expediency and convenience. What goes around, comes around.
Non-scalable? How? I've had no problem scaling.
-
So I want to do a pro bono job for a small bridge club, I set up what I thought was a free Azure account, a whole bunch of free services including sql server, great I thought just what I am looking for. Check the usage after a few days development and all looks good 3% used. The I get a bill for $700 the next month, do you think there is any way to dispute the bill, nope, just a chatbot and we all know how helpful they are. I obviously did something wrong with the subscription but there seems to be no way to find out what caused the bill. I wonder if I can get the CC to cancel the charge?
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Kiss your money goodbye. I have to tell you that I have hundreds of Azure accounts with more than one subscription, and this is the biggest item I make my techs look at. When you add a Resource, mind what subscription you put it in. You are required to use a CC (unless you are direct bill, CSP), but you should FIRST READ all documentation about it and how to apply your subscription. It allows for you to have benefits from Non-Profits and complete the functionality by paying, direct or CSP1 or CSP2 lowering your cost. At least Azure always had resources and resource groups to lump up your charges and you can add TAGS to do your reconciliation. Not the same with Amazon where they hide items after you remove a resource, and you cannot remove them until you call them and 3 months later you get the charges dropped. Good luck!
-
Non-scalable? How? I've had no problem scaling.
There is more than one way to look at scalability where the typical way is linear (Big O(n)). But this leaves out another important factor, the centralized SQL/RPC's dependence on single-enterprise industries here called server farms. There is a probability and lifetime associated with these enterprises. GE and IBM have lasted a long time but both companies are fractions of their former sizes. The same is true for server farm enterprises. Just a wild guess but I'd say there is a 50% chance that Microsoft's Asure will collapse within 10 years. Same goes for AWS, Google and Apple. I might be wrong as much as an order of magnitude, but it is indisputable that single-enterprise centralized server farms' existence is a non-negligible factor. So when I say non-scalable, I am combining superficial linearity that the RPC/SQL algorithm suggests (O(n)), with their fallibility (fx, O_p(0.5) over fx 10 years). Then from that perspective, the current set of server farms is not scalable. And I haven't even considered other even very real factors like security with respect to facility centralization. Note that, when I say failure, I don't mean existential failure (ie, breaks down completely). I mean failure like for example, the enterprise's price keeps climbing losing more and more customers. Or attacks increase and the company fails to fix the problems in a timely manner if ever. Etc.
-
There is more than one way to look at scalability where the typical way is linear (Big O(n)). But this leaves out another important factor, the centralized SQL/RPC's dependence on single-enterprise industries here called server farms. There is a probability and lifetime associated with these enterprises. GE and IBM have lasted a long time but both companies are fractions of their former sizes. The same is true for server farm enterprises. Just a wild guess but I'd say there is a 50% chance that Microsoft's Asure will collapse within 10 years. Same goes for AWS, Google and Apple. I might be wrong as much as an order of magnitude, but it is indisputable that single-enterprise centralized server farms' existence is a non-negligible factor. So when I say non-scalable, I am combining superficial linearity that the RPC/SQL algorithm suggests (O(n)), with their fallibility (fx, O_p(0.5) over fx 10 years). Then from that perspective, the current set of server farms is not scalable. And I haven't even considered other even very real factors like security with respect to facility centralization. Note that, when I say failure, I don't mean existential failure (ie, breaks down completely). I mean failure like for example, the enterprise's price keeps climbing losing more and more customers. Or attacks increase and the company fails to fix the problems in a timely manner if ever. Etc.
Your argument might be believable if Azure's hardware underlying the "cloud" were static. But, like any remote site, cloud or not, the hardware is upgraded as needed. That changes the calculation since newer hardware will improve in speed, reliability, and quantity, and as it has for decades, lower in capital cost. Since you did not mention that your definition of scalability has little to do with the commonly used definition, it is natural that readers will take the usual definition. You also overlook the competitive factor in keeping prices down. Price pressure generally results in a compensating rise in ingenuity that lowers costs. If you do not like the cloud providers, you might find a better argument than something this.
-
Mycroft Holmes wrote:
I wonder if I can get the CC to cancel the charge?
Probably not. If you set up a paid account accidentally, then the charge is a legitimate charge. Trying to cancel it via the CC might be considered fraud. Your only hope is to find some human who can cancel the charge (sob story - church, accidentally used paid azure account, etc.).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
the charge is not legitimate. Here we have a techie intelligent person who has no idea how this happened, cannot get support or a person, and there is no way to stop the charges. That is fraud, not his dispute. This is just typical bullshit from Microsoft and other large companies. See FTC Takes Action Against Adobe and Executives for Hiding Fees, Preventing Consumers from Easily Cancelling Software Subscriptions | Federal Trade Commission[^] Now, I'm in the USA, and one bright area we have is the ability to dispute CC charges. I don't know how it works out of the US. This crap goes on all the time where you are magically subscribed to something, cannot cancel it, and this is your only recourse. I had Apple TV for a while (Masters of the Air, terrible series, just yuck), and after the series was done, cancelled it. And cancelled it. And cancelled it again, and again. Finally disputed all of the charges and magically it all went away. This is why I NEVER use my debit card for anything on line. If I need cash, that's the only time it comes out of my wallet. If I am making an online purchase that might be a subscription or whatever, I create a VIRTUAL card number, limit the amount on it, give it an immediate expiration date, and now I'm protected. I have not looked into apple pay or google pay or the like, but I would be VERY careful with their t's and c's considering how easily they could change them.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Yeah, Azure support is the worst. Of course, the default is free support which is, indeed, limited to chatbots and FAQs. When you're on a paid support plan things get marginally better. You get a human, but they're not necessarily smarter than chatbots :sigh: As for your charges, you creating a paid Azure subscription without knowing how things work isn't reason to cancel charges I'm afraid. But $700, wow and how? :omg: I've been working with Azure for years and I haven't had such bills, can't even imagine how you got that with "normal" usage :omg: I got a $300 surprise a few months ago when someone created a serverless SQL Server and then proceeded to check it every few minutes :doh: Your costs are specified in the Azure invoice and on the overview in your subscription. In your subscription, you can also specify quotas and alerts to avoid such errors in the future.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
"As for your charges, you creating a paid Azure subscription without knowing how things work isn't reason to cancel charges I'm afraid." Respectfully disagree.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Your argument might be believable if Azure's hardware underlying the "cloud" were static. But, like any remote site, cloud or not, the hardware is upgraded as needed. That changes the calculation since newer hardware will improve in speed, reliability, and quantity, and as it has for decades, lower in capital cost. Since you did not mention that your definition of scalability has little to do with the commonly used definition, it is natural that readers will take the usual definition. You also overlook the competitive factor in keeping prices down. Price pressure generally results in a compensating rise in ingenuity that lowers costs. If you do not like the cloud providers, you might find a better argument than something this.
There is no doubt that Big Tech will continue to shore up against competition and keep pouring resources into their model in the hopes that their "anything can fly if you give it enough power" model/belief has no limits. Noone really believes that, though. My point was to critique the assumption that nothing will happen that will upend the centralized model probably within the not-too-distant future, fx, <10 years, which, if true, puts a big hole in the linear-scalability-only prediction model.
-
There is no doubt that Big Tech will continue to shore up against competition and keep pouring resources into their model in the hopes that their "anything can fly if you give it enough power" model/belief has no limits. Noone really believes that, though. My point was to critique the assumption that nothing will happen that will upend the centralized model probably within the not-too-distant future, fx, <10 years, which, if true, puts a big hole in the linear-scalability-only prediction model.
I think you over-exaggerate the issue when it comes to hardware as the cause. I do agree there might be something that causes many current customers to shift back to using their own sites, though. Cloud vendors rely on the Internet and private telecommunication trunks being stable and nearly 24x7x365. All it takes is a determined, organized, enemy like the ChiComs, Russia, or Iran to use hidden terrorists to covertly and physically disrupt communication nexuses. That is low tech, easy in and out, and only needs to be in a varying set of remote locations. Inconsistent TCP/IP connections, or worse, high latency connections, would cause disruptions to business that would negatively affect revenue and/or net profit. Then they would look to bring their systems back in-house where access by the company users is a private, physically local, network. Just a few such low tech attacks on nodes where Internet communication lines have junctions or are exposed enough, primarily rural areas, would be enough to scare enough cloud customers away and significantly drop cloud revenue below what is necessary to sustain cloud operations profit. A wise cloud vendor should already have an internal project to package their cloud software for those wanting a private, collocated, cloud. Intelligent enough to discover what is there on the network, and prompt the installer on what they can install under the license. But are any cloud vendors smart enough to see that market now and over the next 10 years?
-
I think you over-exaggerate the issue when it comes to hardware as the cause. I do agree there might be something that causes many current customers to shift back to using their own sites, though. Cloud vendors rely on the Internet and private telecommunication trunks being stable and nearly 24x7x365. All it takes is a determined, organized, enemy like the ChiComs, Russia, or Iran to use hidden terrorists to covertly and physically disrupt communication nexuses. That is low tech, easy in and out, and only needs to be in a varying set of remote locations. Inconsistent TCP/IP connections, or worse, high latency connections, would cause disruptions to business that would negatively affect revenue and/or net profit. Then they would look to bring their systems back in-house where access by the company users is a private, physically local, network. Just a few such low tech attacks on nodes where Internet communication lines have junctions or are exposed enough, primarily rural areas, would be enough to scare enough cloud customers away and significantly drop cloud revenue below what is necessary to sustain cloud operations profit. A wise cloud vendor should already have an internal project to package their cloud software for those wanting a private, collocated, cloud. Intelligent enough to discover what is there on the network, and prompt the installer on what they can install under the license. But are any cloud vendors smart enough to see that market now and over the next 10 years?
I don't see "on-premises" as a general option for a future disgruntled enterprise customer. I know that the binary choice of one vs the other is the current way of thinking. But actually, when you think about 'cloud' and 'local' in their limiting cases (ie, all cloud vs all local), then compare the two, you only really have somewhat of a case to go on-prem if you are a huge enterprise since the other limiting case is a single human being doing computing with himself, like playing cards on a PC. But even for large enterprises, detailed connections with the outside world are just as imperative as they are for a small business or even individuals doing anything on the computer. The above is true and will remain true, in my opinion, as long as the case for individual human beings doing computing remains impractical regarding establishing sets of durable end point to end point connections with the outside world. From this scenario the cloud is merely a kind of a superfluous man-in-the-middle. But that discussion is too far away from the OP's disaster shout-out.
