However, unlike AWS, Azure is poor at "big enterprise" as well, which is rather shocking for Microsoft. Their strength has always been that they "know" enterprise and tick all the right checkboxes to make their big fleets of systems work.
Not in Azure!
Several people have pointed out that they suggest rewriting applications to be compatible with their bugs instead of simply fixing the bugs.
I call it the "you" problem. The marketing, documentation, and support staff will all use that word like it means something.
I'm an external consultant for an enterprise org with over 15,000 staff, 300 of which are in IT, not counting several hundred external IT contractors, vendors, service providers, etc...
If I call Azure support to report a bug, they will cheerfully say:
"Please use X instead of Y in your app, then it will work."
To which I want to find a polite way to say: "What the fuck are you talking about? What do you mean 'your' app!? I got this thing dumped in my lap! It's a lift and shift of 10-year-old abandonware! Your marketing assured some other manager here that it would 'just' work! I'm a subcontractor to a contractor with a contract to move this thing to Azure that took 6 months to draft and 3 months to sign, with Microsoft reps involved at every step! There's no going back now. Make. Your. Shit. Work."
For people that downvote random salty anger with no substance, here's one random example:
Azure SQL has literally zero support for database-level locale or time zone options.
None.
Zero. Zip. Nada.
It's permanently set to use US English and UTC time zone. There is no recourse. There's no setting. There is no way to fix this.
The Azure SQL Database Migration compatibility verification tool will not warn you if you use 'legacy' functions like GETDATE(), which assume that the server time zone is set correctly.
The documentation mentions this in passing once, on a page you will only ever see if googling this in a panic at 4:55pm on a Friday after a week of live usage in production... which is when users will finally notice that "sometimes" dates appear to be wrong.
So now your data has had local and UTC datetimes blended together, essentially shredding your data. Too late for rollback. No global setting to fix, no vendor support to update the code, and nobody picked this up in UAT because a few hours of offset is just small enough not to be detected in most cases unless the user happens to enter a record at just the right time (before 10am in our case).
I called Azure Support and they told me that yes, it's broken by design. Azure SQL is designed for use in our future space colonies, where the time zone is UTC, not for the legacy planet-dwellers that failed to "move on".
This was an unmitigated disaster for us, and a lot of sleepless nights for me.
What does AWS do with their RDS for SQL offering? Do they support time zones?
Of course they do: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_...
That's because their programmers are not... well... err... there's just no polite way to say what I think of Azure SQL's development team right now.
Let me put it this way: Microsoft's sales reps have convinced my customers to lift and shift hundreds of individual legacy databases to Azure SQL, and of those I'm betting 90% are quietly shredding their date-related data, causing random glitchy problems.
This is just one example of many like this. It's not that every cloud does it worse. Without exception, what Azure does is always clown shoes compared to what everyone else does, and it's not even possible to convince them to fix it, because they always turn around and say: "No sir, you are wrong, it is designed to be broken!"