It always depends on your scale. I was at a company that had a month spend in the 6 figures and they wanted to constantly talk. A different company I was at the spend was 3 figures a month, and we couldn't get any help at all, even knowing some internal folks in different areas of the company.
We don't get much spam from Azure reps, but APM/metrics/logs companies like DataDog really are trying hard to schedule free-of-charge "presentations" with our teams. Unless they are faking out MTA headers and mail client details, the mail templates are actually edited and sent from a desktop by an actual sales/advocate/devrel guy. Yuck.
Yes. We found a problem with Azure’s IPv6 support a while back.
It took quite literally months to get the issue escalated to someone who could do anything about it, and as far as I know it’s still broken, although it’s scheduled to be fixed this year. We had to pay for this “support” too. We worked around the problem in the end, but still.
I always dreaded talking to support - AKS would routinely break in weird and ways, and it was always super frustrating waiting for support to fix things that shouldn’t have happened.
We once had an error with Azure MySQL and AKS, where it would just stop dropping packets with basic instance types. Support could never fix it, we ended up just upgrading to standard because that worked.
I will say this - the manager of the team at Azure did comp our upgrade, because they couldn’t figure out why it was happening. I tried very hard to get our project off Azure, but because it was negotiated as part the Enterprise Agreement with Microsoft, it was “free” so the CTO wouldn’t budge. I assume this is how many people end up needing to deal with Azure.
> And if you ever need to actually talk to someone over there, it's a nightmare
I never understand it when I see people say this about Azure. Did you ever try creating a support ticket through the Azure portal? My experience has been nothing but stellar. They respond very fast, they provide very in-depth expert knowledge, and they seem to be quite thorough, escalating any issues if needed. This is my experience with creating tickets for various organizations, both big and small.
I was all in on Azure for years, but once my BizSpark wore off and died I was shocked at how expensive it was to run the most trivial side project or seedling of an idea or non-money making project.
As a .NET full stack web dev for like 14 years, I finally decided to put all my new learnings into just doing static sites on React and trying to figure out some AWS stuff because I wasn't going to try and use .NET on AWS when I had it so fairly figured out on Azure.
For a serial entrepreneur and maker, it just couldn't cut it anymore. Now I do NextJS on Vercel with minimal extra services out of what they provide and I get way faster stuff for free pretty much and I guess I'm no longer the only .NET guy struggling to hold the fort in a big tech community that also thinks .NET is too old or boring or non-sexy.
I still do like Azure better than AWS. The stupid, weird UX is still nicer than AWS. The docs by MS are 1000x better than everything on AWS. I miss MSSQL and the SQL Server Management Studio, but I don't miss the cost for scaling it enough to actually use it for scraping or data processing.
I tried to sell friends on Azure and even got a part time gig from MS themselves to try and help local startups use it, but no one cared or was interested. It just doesn't have that same "standard" or "sexyness" or "built into every new tech" feel to it, so I doubt it'll ever really change or pull ahead in comparison.
I've never used Azure and always use .NET on AWS and have been for the past 5 years. I haven't hit any problem on it so far. .NET is not tied to a specific cloud provider.
.NET is not tied to cloud at all. https://dotnet.microsoft.com/ lists Web, Mobile, Desktop, Microservices, Cloud, Machine Learning, Game Development, Internet of Things.
We use Azure at work and this article hit home hard. As we just have been burned recently by Azure pricing. I am in the same spot as the author: liking Azure but being put off by all the weird stuff sometimes they are doing.
In our case, all we wanted was a static IP in front of an Azure Container Instance. Easy right? Let's put the container in a vNET, place a NAT Gateway in front of it and we are done. However, for some reason NAT Gateway is not supported for Container instances, instead, the official documentation suggests setting up an Azure managed firewall in front of your container that starts at a whopping 600EUR/month. That is a steep price increase from your ~30ish EUR/month for a basic container instance and it doesn't seem to be any other official alternative.
I have opened an issue with the docs team [1] about it and I hope there is another way of doing this that doesn't incur a doubling of our Azure monthly spending.
I don't think azure-docs repo is the right place to ask for help/suggestions as maintainers are not very responsive because their sole job is to push internal docs to public docs. But I understand your frustration.
However, I believe you could have set up "public IP prefix" using azure cli. I do not think you needs a azure managed firewall.
Adding managed firewall just to have edge IP is like saying I want to add a outside patio to my house, sure let's add a security check point for the neighborhood first.
> I don't think azure-docs repo is the right place to ask for help/suggestions as maintainers are not very responsive because their sole job is to push internal docs to public docs.
What place would you suggest? We had bad experience with Azure support we could never fight through on the first support line.
> However, I believe you could have set up "public IP prefix" using azure cli. I do not think you needs a azure managed firewall.
I don't have deep experience in networking stuff on Azure so my understanding can be wrong, but I think "public ip prefix" is just a group of continuous IP addresses what you can reserve. You still need to assign those to something eg a NAT Gateway. As far as I know you cannot assign them directly to an Container Instance.
>> I don't think azure-docs repo is the right place to ask for help/suggestions
This is correct -- The azure docs repo feedback mechanism (using GitHub issues) is primarily for providing feedback on the documentation itself. We try to make this clear via the buttons on the bottom of the page; one is for 'Product Feedback' and the other is for 'Feedback about this page'. I would agree that the distinctions can be blurry, but I see the three categories as:
- Product Support: I need help with a product
- Product Feedback: Product A is missing feature B, and I want you to add it
- Documentation Feedback: The documentation is unclear, has a typo, or the example provided no longer works
For Product support, your best bet is to go through the standard support channel. I'm sorry that you didn't get a better response when you tried contacting support. Do you have paid support? If you're a large customer, you may get a dedicated customer support account manager.
Additionally, there are community forums including https://docs.microsoft.com/en-us/answers/topics/azure-contai... and https://techcommunity.microsoft.com/t5/azure-compute/bd-p/Co... , which can also be used to submit product feedback.
This varies immensely by the product team. If you file a bug on the AAD protocol docs I have a self-enforced SLA of a business day (or less). And a CVP enforced SLA to solve it in 30 days. And I generally love the folks who do file bugs - they're engineers, and usually fairly savvy.
Other teams do get burnt out on docs though, especially when customers use them for abuse or free architecture help. My favorite was someone asking me how to use an Oracle product. I know our branding is confusing but it's not that bad... Is it?
Dear lord, this hits too close home, I've been having nightmares maintaining some Azure infra lately. I'm not a cloud-provider fanboy, they all suck at the end of day, but Azure is the one that deliberately makes my life worse every day.
All those features and no decent integration between them, unless you're a multi billion 100k employee company you'll have no luck with their customer support either.
I had an Azure employee troubleshoot my PG db instance for hours with me, for free, while our total spend was something like $100 a month.
Now, this employee didn't really help, but they were obviously professional and had database experience and didn't act condescending / like they were doing us a favor at all.
They just worked through the issue with me, which was a very pleasant surprise.
> I hope there is another way of doing this that doesn't incur a doubling of our Azure monthly spending
Oracle Cloud Infrastructure provides NAT gateways for free. You pay (low) transit costs, but unlike AWS+Azure (idk about Google) the NAT gateway itself costs nothing, so you don't pay twice for NAT traffic.
All the traffic at these cloud operations gets handled by cloud scale SDN systems. I suspect the actual cost of the few tens of bytes necessary to track a NAT connection is lost in the noise of such platforms. So to my mind the high cost of some of these cloud operator's NAT gateways seems abusive.
Fortunately there is indeed competition that accommodates my view.
Could you not attach it to a subnet, and attach the subnet to a network security group, and then do what's needed in the network security group? Maybe there are regional restrictions that I'm unaware of.
Edit: oh, no, you just need a public ip prefix/address, right?
I have a funny story about Azure. Our company was looking for a cloud provider, and Microsoft sent a couple of salespeople to talk to us about theirs. Their salespeople were very condescending, talking like they'd be doing us a favor by allowing us to become customers and failing to take any of our questions and concerns seriously.
I think it's because we aren't a large corporation in terms of headcount.
In any case, that meeting ensured that no further consideration of Azure would take place, and it's very unlikely that it would be considered in the future.
Dodged a bullet there, I'd say. You can safely assume that google will EOL anything in GCP that you might actually start relying on for business function.
I don't fully agree with parent, and GCP is differently managed compared to other Google products.
That said, the k8s version deprecation policies, mixed with significant changes in cluster setup from times to times you have to keep up with is peculiar. I kind of think this is something we accept when going into k8s, but I'd understand people not at ease with that philosophy.
Looking for a k8s for a hybrid deployment, the contrast was blatant: mention it to a Red Hat sales person and you have people showing up the next week to pitch OpenShift. AWS has a deep story here, same deal. A friend stopped begging the Google rep to pitch Anthos because it was kind of obvious how it'd go if you actually needed support.
This has been my experience. I've dealt with all of the big three cloud providers, and as a big customer. Azure is incompetence, AWS is largely capable and professional (so long as you're big enough to register on their radar), and GCP is just dripping arrogance. GCP is a better platform than Azure, but I would never choose it because dealing with Google reps is a never ending stream of condescension.
When you have an existing stack, the choice is often between adding Cloud or staying on managed/on premise, and not between Azure and AWS/GCP.
As in the article, if you already run Windows servers at scale, going to AWS is possible but won't be your first choice. Microsoft sales people being condescending will basically reflect that situation.
In most other situation I can think of you'll go to Azure only if you can't use the alternatives, so again you're basically at their mercy.
To digress, if you run linux servers with an open source stack, going to Azure will bring you virtually nothing, and will probably be an expensive PITA at every step. In a previous ruby shop we had more empathic dev evangelists walk us through Azure, but we felt like wasting their time as it clearly wasn't a priority to them. Then looking at the price we'd need to drop them as soon the discount prices expire, so it was just a losing proposition for everyone involved. I totally understand how more sales focused employees would weed out shops like us and go look for those who have to stick with them anyway.
> As in the article, if you already run Windows servers at scale
My company does that. We have started moving new things to the cloud, but we took one look at the Windows pricing in the cloud and ran away. And my company is DEEP in Windows.
So I’m not sure Azure really has much of a leg up there. I think the only real benefit they have is their hybrid cloud for people who do use Windows in the cloud as well.
Many salespeople repeatedly visited my previous company, a megacorp. While attendees from our side rarely had any authority to purchase (e.g. engineers not managers), the visitors were extremely enthusiastic in their presentations and demos. I personally felt bad that their efforts wouldn't lead to sales, but they helped boost our self-esteem for the day.
And this is the actual problem. Azure doesn't compete on quality. Microsoft rarely does. They have a few products and a market position that make them the default choice for countless customers. Nobody punishes them for their failings as long as the feature boxes keep being checked, and so the cycle continues.
A previous employer switched everything over to Azure and it was nothing but constant problems and nobody liked it except for the CEO, which meant everyone had to put up with it and nobody had a say.
Teams and Azure DevOps are some of the worst software I've ever used in my life. I've used worse software before, but it was hobbyist stuff written by single developers, and therefore don't really compare fairly.
Azure Pipelines is just slow. I'm not sure even how to fix it.
Checkout stage of our code from Azure Repos easily count for half a minute. Npm install goes for a 1.5 minute with npm cache hit. Total build times are around 20 minutes...
there is an undocumented feature, called zip deploy, if you deploy to an app service. Give it a go, it might just work. I use it to deploy a Python Django website. You need to add a setting in your App Service environment variables.
It took me an escalation from our account manager, to get a good support guy, who informed me of this functionality.
Here is the summary of my support ticket:
WEBSITE_RUN_FROM_PACKAGE” and value as 1.
We performed deployment and it took around 30 secs. We also verified that the app is working fine.
Now you will do some changes and deploy once more to verify end to end pipeline.
Zip deployment is a feature of Azure App Service that lets you deploy your function app project to the wwwroot directory. The project is packaged as a .zip deployment file. The same APIs can be used to deploy your package to the d:\home\data\SitePackages folder. With the WEBSITE_RUN_FROM_PACKAGE app setting value of 1, the zip deployment APIs copy your package to the d:\home\data\SitePackages folder instead of extracting the files to d:\home\site\wwwroot. It also creates the packagename.txt file. After a restart, the package is mounted to wwwroot as a read-only filesystem.
At a previous company I used slack and really liked it. At this new company I joined recently they use Teams and it felt like a ghost town. Nobody online and nobody communicating in public.
The reason is that it’s impossible with the desktop app to browse channels that you’re not a member of, whereas on mobile you can! When I mentioned it to my colleagues they were shocked. This whole time they could have been communicating in other channels and they had no idea they existed. I have no idea if this is a bug, or some kind of admin setting.
There are plenty of other issues with DevOps too. You have to buy in to the whole Microsoft package apparently, and none of the parts are best in class.
Microsoft is hardly unique in that respect. All three of the big cloud providers are like that in some respect, as well as a lot of "enterprise" software. If you have a big enough moat to keep your customers from leaving, there isn't a lot of incentive to improve the quality.
I sat in a market focus group for IT managers. We were universal in our rankings AWS > AZure > Google for cloud services. We also agreed the Google was #1 or #2 technologically, but no one trusted them to be there day after day for the boring stuff
Azure is and will continue to creep into GitHub. Pretty sure my new projects will be on GitLab now just to get a headstart on using who the cutting edge service is a few years from now.
The biggest issue is that I've experienced some of that creep with GitHub Actions. It's a mess, doesn't do what it needs to do and besides "presenting" features/functionality it can't actually do even the basic things a nasty old Jenkins installation in an AWS ASG does.
They practically just copied some Azure CI stuff over (which was obviously written from a completely different perspective/mindset) using a tech stack that is old yet immature when compared to even relatively young products like GitLab CI.
If a company wants to come up with a CI product but can't even get on par with basic nominal GitLab CI features and usability, what's the point...
Azure pipelines is the most verbose and confusing CI tool I’ve had the misfortune of using.
Why does it require so many steps? Why are they so verbose? It feels like writing glorified bash scripts (in which case why am I using a CI tool?) but worse.
If you run workloads in Azure, and you let their default agent run on your images, I'd highly consider you take 30 minutes to skim around this repo: `Azure/walinuxagent`.
Go read through some issues, look at some closed ones, try and skim through the source code. Realize there's two enormous python scripts in the repo, one with "2.0" tacked on the end.
If Azure is somehow not just rebooting/killing VMs that lack the magic handshake, I'd highly recommend dropping the agent.
After all of this news, and what is on display in walinuxagent, do you really want some network-connected agent listening, who's often-most-touted feature is being a persistent backdoor?
"It's tough being an Azure fan." Eh, it's a nice cyclic problem. They have no depth of caring about engineering (hence why Azure is littered with services that are impossible to fully utilize because their own engineers don't understand the how/why of what they're building half the time). Which in turn, along with crap career advancement and constant un-appreciated, unmitigated live-service burnout, is why they can't retain actual Linux talent to save their fucking lives.
As a network engineer writing code to automate aws and azure infrastructure I'm amazed at the number of pitfalls we've had with azure, they just keep popping up. Then the whole basic/standard options for every service. Feels like an order of magnitude higher in complexity for no reason, part of it is the abysmal documentation.
I find this to be a common theme with Microsoft products. I work heavily with SSIS and MS SQL. The Microsoft docs are so convoluted they are borderline useless for learning the products.
Same here, and not even GCP is that bad with the 'release' vs. 'beta' APIs that intermingle constantly.
Most of the time Azure feels like just another 'we have virtual machines and a crappy API' service. Kinda like a pretend-cloud where a lot of products come almost together but never finish. Almost similar to the way Windows and backwards compatibility means you end up with 100 libraries, frameworks, languages and versions all sitting side-by-side and not really working together, just differently in parallel. Not useful for automation at all, which makes it not useful at scale. (Except when scaling means: we want to run windows VMs with AD and go from 10 to 100 and change no parameters at all)
That reminds me of a relatively old twitter thread (that I can't find of course) about systems that have become operating systems and computers upon themselves.
It went something like this:
Code used to be running on a processor, then it ran on an OS on a processor. Then it became on a runtime on an OS on a processor. Then it an abstraction layer was sandwiched in between. Then a filesystem. Then a compatibility layer. Then a database. Then a browser. Then we went and created a runtime in the browser to run code again. We have come full circle.
This probably applies to SharePoint but also the real-time OS on your GPU, the MSSQL database which has its own OS facilities you can run stuff on. Add too many features and the application becomes the very thing we wanted to get away from...
My friend and I have a theory that this is because their docs are written by people so intimately familiar with how MS does things, they can no longer conceive of a situation where someone doesn’t already understand and think in the same way.
It’s like the business equivalent of the “once you understand a monad you can no longer explain it” meme.
It's Microsoft's modern, less-obvious version of EEE.
You sell to the managers and equip them with hollow buzzwords because you know they're gonna override the engineers on every decision anyway. By then, MS has your firm's money and all you can do is deal with it.
I find the problems with Microsoft docs is less how convoluted they are (you kind of get used to the convention at some point - not to say it's good or sensical), it's the fact that Azure documentation is not of the same quality that the WinAPI docs were.
Used to be a function doc would tell you:
1. All the parameters and their types
2. What they did, explained
3. All possible exceptions raised by the function
4. All possible return values
5. Supplementary documentation on the object or structs passed in or passed back
6. Some examples of it in use
Now, the current docs sometimes have examples for Azure CLI/SDK stuff, but there is one convention that drives me bonkers that is as bad now as it ever was.
For examples, often times you'll get the most important part replaced with a [insert your thing here]. The format of the thing you fill in there is often left as an exercise to the reader to intuit or guess.
Writing one good set of docs that are suitable for all users (experts and newbies) is really hard. Structuring complex topics in a logical and progressive manner is also really hard. Having tried to write the docs on a few software projects, I honestly found writing the docs harder than writing the code (though maybe it gets easier with practice).
I find the Azure docs to be decent. They are consistent across services for the most part, so you learn how to work with them after a bit of experience on the platform.
- Customer asks for something trivial to be deployed. I say, "no problem" and start beavering away on a Bicep template or whatever to deploy their stuff.
- I hit some small but showstopper issue with a service that I expected to work, but it doesn't. I open a support ticket.
- Inevitably, it turns out to be some stupid, stupid limitation caused by unfathomable laziness of the Azure developers. No workaround, no mitigation, but we're "working on it" with no ETA offered.
- Literally years later a trivial fix for the glaring issue goes into "PREVIEW" for 9 months, long after the original project was closed. I no longer care...
Networking is especially bad, with endless limitations that make no sense, like:
IPv6 is incompatible with everything. Turning it on for anything anywhere in a vNET will permanently block unrelated features like IPv4 NAT.
But of course, you can't "protocol translate" from IPv6 on the outside to IPv4 on the inside, so you end up painted into a corner.
No bring-your-own-subnet, which means many lift & shift scenarios are impossible (we have customers using a class B pubic range internally).
Azure forces NAT on IPv6, which makes no sense at all.
All Azure PaaS services have firewalls that are IPv4 only.
The built-in firewalls (e.g.: Azure SQL Database) do not support service tags, only CIDRs.
Yes, seemingly trivial changes turns into huge and disruptive changes. Latest one we encountered was that you cannot add more CIDR ranges to a VNET without removing all VNET peering first. The feature for this has been in preview for like 2 years. I mean, AWS doesn't automatically handle this for you, but at least you can solve it easily enough (just use the API to create routes on the other side (their API/boto3 library is just amazing)).
Availability Sets decrease availability, because they force "all or nothing" deallocate-reallocate cycles instead of one-at-a-time changes.
You can't move a VM to a different subscription without also moving the entire vNet along with it. (I bet this worked great in the developer's lab with one test VM.)
You can't move a VM to a different backup resource without deleting all backups, going back years.
VMs can't be rolled back to VM snapshots.
ExpressRoute bandwidth can be increased non-disruptively, but the only way to decrease it is to recreate it -- incurring a ~30 minute outage.
The Activity Log (and most other audit logs) don't log the identity of the administrator that triggered the action about 10-50% of the time, depending on what kind of activities are going on. This makes it 100% useless as an audit log. There is no other way to obtain audits.
Most network resources are Zone Redundant, except for NAT Gateway, which is now required in some scenarios. It's Zonal only, which means you need 3 subnets, one for each zone.
Upgrading an internal load balancer from Basic to Standard cuts off Internet access, for "reasons". I'm told these are "security reasons". Uh-huh...
App Gateway doesn't use a "user-agent" header for its monitors, which makes it incompatible with a surprisingly wide range of CotS software. This includes a bunch of Microsoft Software.
> Inevitably, it turns out to be some stupid, stupid limitation caused by unfathomable laziness of the Azure developers. No workaround, no mitigation, but we're "working on it" with no ETA offered.
This is all microsoft products though. There have been .NET Identity bugs that have been open and acknowledged for multiple years.
Yeah. Azure is a second- or third-tier cloud provider; they are not in the same league as AWS.
AKS suffers, AFAICT, constant API server outages. We tried to escalate into a ticket, but we just get motte & bailey'd between "you're putting too much load on the API server" — okay, what load? how can I see that, control it? — "here is the top consumers" — they're all AKS itself? — "well, there's too much load on the API server" gah! (Yes, we pay for the "SLA".)
You can't add IPv6 anywhere in a vnet, it will break unrelated things. We tried to add a managed PSQL server on IPv4 (b/c IPv6 is not supported): it "failed" (the API call to create it timed out with an internal server error … after 2 hours or so!) because something unrelated in the vnet used IPv6.
ACR has a 20 TiB limit, no way to prune containers, we've had to work around IDK how many 500s, the API is slow as dirt (response bandwidths of ~50 kbps — bits — and their team does not think that's a problem. It can take 10 minutes to enumerate a few megabytes of metadata…) Undelete-able manifests that I guess we will just pay for indefinitely? I feel like I could build ACR on top of Azure Blobstorage and it would be more reliable with better performance…
VMs shipping with buggy kernels. (Support wanted to know what weird thing we were running to hit kernel bugs. "Docker"?) Global outages. Known outages often don't get mentioned on the status page intentionally. I still don't know what the difference between an availability set and a VMSS is.
Everything is in preview. Everything.
Audit logs fail to load some times. Beyond complicated interactions/differences between "service principals", "applications", "enterprise applications". 2FA app now requires authenticating twice, per login, because each tenant acts as a separate yet not separate login. So. much. auth. Role assignments that don't know what principal is being granted permission, b/c ARM & AAD don't do referential integrity.
Docs that are outdated. Requests for updated docs closed without update, because "we don't have the data <from some other internal team, I think, but so?>"?. Docs that describe API calls badly. "foo: the foo query parameter" No docs, at least, that I'm aware of, about what permissions does the API call require. The docs conflate "permission" and "role" (different in Azure) all. the. time. Azure doesn't know what permissions some calls require, and simply says "give it Contributor" (close to all permissions)… and yeah that works but I want to show auditors we're doing PoLP?
Support… The SLA often isn't met, we're assigned reps in China (n.b., this isn't a language barrier problem, it's, how is someone who is literally sleeping during my business hours because that's timezones for you supposed to even meet a support SLA that wants a 8/4/2 hour response? And AFAICT from response times, they're not a night shift…?), the first response is worthless (doesn't answer the inquiry, requests information present in the original request, often isn't technically proficient, etc.), the writing is broken and sloppy. Half the time a simple "reread what you're about to send. Does it solve their problem?"… we literally got a blank email back. We've had tickets where the first response we get is "we haven't heard back from you" because sometimes their responses fail to get linked into the ticket in the portal. They lack any formal bug reporting mechanism, and support is not equipped to handle bugs.
We use Microsoft Azure AD B2C to manage users. AD itself is a nice (for enterprise software), is used all over the place and is pretty stable.
B2C on the other hand is a different story. Every few months we have to roll out a new tenant in our system. Tenants are identified by B2C "applications". Every single time, the new application doesn't work. Every single time the fix involves editing the JSON spec, changing something random (like a "true" to a "false"), saving, and changing it right back again.
Doesn't exactly inspire confidence... we're planning a migration to AWS.
Also, try Googling for documentation related to "Microsoft Azure AD B2C". Almost every shred of internet wisdom is related to AD and not B2C. Even with Microsoft's own documentation you sometimes follow a link from a B2C API reference and find yourself in AD-only land and it isn't obvious. This makes the task of researching features and debugging infuriating.
B2C is the worst product we have ever worked with. Outages on constant basis, an extremely complex XML configuration, translation bugs, unsupported features which are only available in AD but not AD B2C (e.g. M2M), and really bad documentation. We basically had to dive in their github examples and issue tracker to make it work. Do yourself a favor and stay away from it.
I'm surprised Azure still doesn't have any ARM processors to compete with AWS' Graviton instances. It's been nearly a full year since rumors of Azure working on ARM chips (https://www.zdnet.com/article/microsoft-is-designing-its-own...), and going back further it's close to 5 years since they talked up Windows Server on ARM (https://www.techrepublic.com/article/2-years-later-theres-st...) on Azure. Where is any of it though? I can go to AWS right now and spin up multiple different types of ARM processor instances, most of which are cheaper and more efficient for web-like workloads. It's really surprising that Azure hasn't been able to get anything out in all these years.
It's very possible that there just isn't much demand. This is likely for a number of reasons:
- x86 just has better support for the stuff Azure's "enterprise" customers want
- ARM servers are often more expensive to spin up than an equivalently specced x86 option
- PRISM compliance is easier on x86 (half-joking, half not)
I like ARM, and I owned a Rev1 Raspberry Pi when those were cool. But even now, ARM still has yet to make a strong case for existing on the server. And that's before we even discuss architectures like RISC-V that are out on the horizon, much better suited for servers than ARM. I'm not planning on an "ARM revolution" taking place in the next decade unless x86 is critically compromised in some way.
Can you clarify point two? I was under the impression that the wide consensus was for Graviton instances to have significantly better price performance for most workloads. And the current state of arm support is surprisingly good for opensource or linux based server software.
> But even now, ARM still has yet to make a strong case for existing on the server
This is several years out of date: AWS Graviton instances are usually a fairly substantial savings over similar Intel, with AMD in between, and Cloudflare has been reporting rather good numbers as well:
The main reason I suspect Azure doesn't have it is both Windows' legacy x86 hyper-focus (the days where NT ran on half a dozen platforms never really panned out) and a smaller number of managed services. AWS has very popular services like RDS, ElastiCache, ElasticSearch/OpenSearch, etc. where you can simply check a box and wait a couple minutes to see savings, not to mention things like Lambda being only slightly more work for many users, and that's a great way to get volume usage even if the average enterprise IT department is scared to go near it for VMs.
It's not obvious whether AWS internal operation cost of Graviton instance is cheaper than Intel/AMD instance. I believe it's cheaper in AWS scale, but I also think they tactically reduce profit margin for Graviton instances, to negotiate Intel/AMD to cut down price.
There have been multiple consumer ARM Windows products on the market for the last 9 years, I'd say Windows (client, at least) on ARM64 is as solid as its x64 counterpart
I’m aware, but everyone I know who had one of those ended up complaining about software compatibility issues. In the context of Azure, I’d imagine a lot of their customers would be especially risk averse in this regard.
Most of the time they're complaining about not being able to use x86 (in Windows RT's case) or x64 (until recently) pre-existing applications, and there's no native ARM/ARM64 version of said app. In the context of Azure, if someone wants to deploy on an ARM instance, I'd expect them to be able to build a native ARM64 version of whatever they're building.
> In the context of Azure, if someone wants to deploy on an ARM instance, I'd expect them to be able to build a native ARM64 version of whatever they're building.
Have you really had the experience that a large organization has the ability to recompile everything they run? Most will have a lot of code which is provided as binaries by a vendor, and their in-house code almost certainly has dependencies and optimizations which will need to be dealt with & revalidated. No, none of that is unsolvable but it means adoption is much harder than, say, changing an RDS instance type and you'd be taking on all of the support rather than the cloud provider's much larger team.
That's what I referred to in my original comment — in my experience, the average Azure user works at a Windows-heavy enterprise IT shop where those issues would be common. That doesn't mean that I don't expect ARM servers to happen there — Microsoft announced it was coming years ago, after all — but that it's going to be slow since the upfront investment will likely have slower adoption.
Microsoft themselves said the majority of VMs on Azure run Linux, not Windows.
About the ability to recompile, if you can't build ARM software what's the point of using ARM instances? You don't need cross-architecture compatibility like you need it on the desktop version, which is what consumer complain about when talking about Windows on ARM
The point is that it doesn’t matter if you could see a 20% price performance boost if your code doesn’t run on that architecture. If you’re using software which hasn’t been compiled for ARM, you’re not asking your cloud provider for that architecture and they’re not seeing the volume needed to profitably offer it.
I think AWS has successfully been pushing this because they know they’ll see that initial volume from people seeking savings on their own managed services and things like Lambda which are easy to switch, and that will fuel interest in switching other services which require more work.
Do you mean end user as someone other than the buyer of a cloud service? That’s the context I was writing in - I’ve generally found things like https://aws.amazon.com/about-aws/whats-new/2020/10/achieve-u... to be accurate as long as you’re not radically switching instance types.
another team in my org is trying to configure the same but it's been challenge. I don't know specifics but it's taken considerable time to set-up the environment.
My company once took a project on Azure, and ended up giving a 35% cut on our invoices to move to AWS. The bugs I filed while working on that project are still not closed.
It's tough being an AWS fan for that matter too. Aside from the simplest things, every time you need to do something there are huge reams of "documentation" in various stages of decay, and each doc is comprised of dozens of (unnecessarily) manual steps. Error messages are shit, too, and the whole thing has this stench of massive engineering debt and duct tape to it. I was told this stuff was supposed to be built by people who know what they're doing, but apparently not. It's duct tape all the way down it seems like.
Yeah, when I finally switched over to using it from Azure I was shocked at how horrid the docs are. I would have assumed by now they would have been cleaned up, but no, time does not heal these wounds.
Judging from the stories posted here, can you even imagine what the stories from the poor souls working on this would be like, if only they could tell us without violating an NDA? Must be the stuff of nightmares.
Yeah...and if I have to sit through one more week of managers and devs freaking out about lambda cold starts Im probably going to quit tech altogether. It is the most dumb ass broken record. Torture. Read the manual before you write two hundred functions and bet the whole project on fantasies next time.
Don’t know if this is still the case, but I always felt more nickled and dimed on Azure (than AWS). For example, the base SKU for their managed PostgreSQL compatible service did not allow use in a VPC/behind a DMZ. You had to pay substantially more for the mid level SKU. This was not the case with AWS’s equivalent service.
I think what was happening was, if you wanted to make a VM image (which you could then later clone to new instances), it would result in the original VM (i.e., the source of the image) being no longer usable.
I’ve been using Azure since the old portal and it always feels like Microsoft is just checking the box. AWS launches some innovative new service and Azure copies them with a half-as-capable alternative.
We moved EVERYTHING to Teams and ADO (for git, backlog, pipelines) except our actual product is still on AWS. If we didn't have a couple things like encryption, S3 and some fargate usage, we'd probably start fresh on Azure.
Azure is a typical Microsoft product: it doesn't work all that well, but you can get the job done if you just buy more of it (to work around the deficiencies).
From a business perspective, this is brilliant. From a technical perspective it's not awesome, obviously.
The mention of AWS ECS made me curious — does Azure have the equivalent of Fargate, where they manage the host and you only pay for the container's actual usage? The O&M wins on that have been really substantial and I recommend it for anyone who doesn't have sufficiently large scale that the savings will fund an ops team capable of running something like ECS or Kubernetes. One of the reasons why is the challenge of avoiding over-allocated instances — every time I've seen people running AWS ECS/EKS, Google GKE, etc. they've been substantially over-provisioned because someone's always meaning to get around to looking at that but the time never seems to materialize.
Their closest Fargate equivalent is probably Azure Container Instances. I haven't tried it recently but last time I did the startup time was very slow for new containers (5mins+). However that may have improved now.
Yes - and they had limits with EBS, too. It’s not perfect but it’s really handy for cutting out maintenance for a substantial fraction of my tasks which don’t hit the edges.
I find Azure to be expensive. Microsoft is not accountable for service issues and bugs. Support is just a wall of consultants that mostly cannot help and then reach back to actual Microsoft for help (which makes everything really really slow). Garbage.
It's a good article, check it out. It's really just about being a heavy Azure user and considering whether to recommend it to others, with the bulk of the article being a critique of various issues.
270 comments
[ 2.0 ms ] story [ 259 ms ] threadI do appreciate the detailed list of current failings, to add to my own systemic rejection of this system based on their management objectives
you are under an illusion, you are REQUIRED to use it in service of The Company
It took quite literally months to get the issue escalated to someone who could do anything about it, and as far as I know it’s still broken, although it’s scheduled to be fixed this year. We had to pay for this “support” too. We worked around the problem in the end, but still.
We once had an error with Azure MySQL and AKS, where it would just stop dropping packets with basic instance types. Support could never fix it, we ended up just upgrading to standard because that worked.
I will say this - the manager of the team at Azure did comp our upgrade, because they couldn’t figure out why it was happening. I tried very hard to get our project off Azure, but because it was negotiated as part the Enterprise Agreement with Microsoft, it was “free” so the CTO wouldn’t budge. I assume this is how many people end up needing to deal with Azure.
I never understand it when I see people say this about Azure. Did you ever try creating a support ticket through the Azure portal? My experience has been nothing but stellar. They respond very fast, they provide very in-depth expert knowledge, and they seem to be quite thorough, escalating any issues if needed. This is my experience with creating tickets for various organizations, both big and small.
As a .NET full stack web dev for like 14 years, I finally decided to put all my new learnings into just doing static sites on React and trying to figure out some AWS stuff because I wasn't going to try and use .NET on AWS when I had it so fairly figured out on Azure.
For a serial entrepreneur and maker, it just couldn't cut it anymore. Now I do NextJS on Vercel with minimal extra services out of what they provide and I get way faster stuff for free pretty much and I guess I'm no longer the only .NET guy struggling to hold the fort in a big tech community that also thinks .NET is too old or boring or non-sexy.
I still do like Azure better than AWS. The stupid, weird UX is still nicer than AWS. The docs by MS are 1000x better than everything on AWS. I miss MSSQL and the SQL Server Management Studio, but I don't miss the cost for scaling it enough to actually use it for scraping or data processing.
I tried to sell friends on Azure and even got a part time gig from MS themselves to try and help local startups use it, but no one cared or was interested. It just doesn't have that same "standard" or "sexyness" or "built into every new tech" feel to it, so I doubt it'll ever really change or pull ahead in comparison.
In our case, all we wanted was a static IP in front of an Azure Container Instance. Easy right? Let's put the container in a vNET, place a NAT Gateway in front of it and we are done. However, for some reason NAT Gateway is not supported for Container instances, instead, the official documentation suggests setting up an Azure managed firewall in front of your container that starts at a whopping 600EUR/month. That is a steep price increase from your ~30ish EUR/month for a basic container instance and it doesn't seem to be any other official alternative.
I have opened an issue with the docs team [1] about it and I hope there is another way of doing this that doesn't incur a doubling of our Azure monthly spending.
[1]: https://github.com/MicrosoftDocs/azure-docs/issues/81274
However, I believe you could have set up "public IP prefix" using azure cli. I do not think you needs a azure managed firewall.
Adding managed firewall just to have edge IP is like saying I want to add a outside patio to my house, sure let's add a security check point for the neighborhood first.
What place would you suggest? We had bad experience with Azure support we could never fight through on the first support line.
> However, I believe you could have set up "public IP prefix" using azure cli. I do not think you needs a azure managed firewall.
I don't have deep experience in networking stuff on Azure so my understanding can be wrong, but I think "public ip prefix" is just a group of continuous IP addresses what you can reserve. You still need to assign those to something eg a NAT Gateway. As far as I know you cannot assign them directly to an Container Instance.
>> I don't think azure-docs repo is the right place to ask for help/suggestions This is correct -- The azure docs repo feedback mechanism (using GitHub issues) is primarily for providing feedback on the documentation itself. We try to make this clear via the buttons on the bottom of the page; one is for 'Product Feedback' and the other is for 'Feedback about this page'. I would agree that the distinctions can be blurry, but I see the three categories as: - Product Support: I need help with a product - Product Feedback: Product A is missing feature B, and I want you to add it - Documentation Feedback: The documentation is unclear, has a typo, or the example provided no longer works
For Product support, your best bet is to go through the standard support channel. I'm sorry that you didn't get a better response when you tried contacting support. Do you have paid support? If you're a large customer, you may get a dedicated customer support account manager. Additionally, there are community forums including https://docs.microsoft.com/en-us/answers/topics/azure-contai... and https://techcommunity.microsoft.com/t5/azure-compute/bd-p/Co... , which can also be used to submit product feedback.
Other teams do get burnt out on docs though, especially when customers use them for abuse or free architecture help. My favorite was someone asking me how to use an Oracle product. I know our branding is confusing but it's not that bad... Is it?
All those features and no decent integration between them, unless you're a multi billion 100k employee company you'll have no luck with their customer support either.
Now, this employee didn't really help, but they were obviously professional and had database experience and didn't act condescending / like they were doing us a favor at all.
They just worked through the issue with me, which was a very pleasant surprise.
Oracle Cloud Infrastructure provides NAT gateways for free. You pay (low) transit costs, but unlike AWS+Azure (idk about Google) the NAT gateway itself costs nothing, so you don't pay twice for NAT traffic.
All the traffic at these cloud operations gets handled by cloud scale SDN systems. I suspect the actual cost of the few tens of bytes necessary to track a NAT connection is lost in the noise of such platforms. So to my mind the high cost of some of these cloud operator's NAT gateways seems abusive.
Fortunately there is indeed competition that accommodates my view.
Edit: oh, no, you just need a public ip prefix/address, right?
I think it's because we aren't a large corporation in terms of headcount.
In any case, that meeting ensured that no further consideration of Azure would take place, and it's very unlikely that it would be considered in the future.
"Dear Google Cloud: Your Deprecation Policy is Killing You": https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
That said, the k8s version deprecation policies, mixed with significant changes in cluster setup from times to times you have to keep up with is peculiar. I kind of think this is something we accept when going into k8s, but I'd understand people not at ease with that philosophy.
This thread is nightmarish for someone looking to deploy a SaaS with three 9s
As in the article, if you already run Windows servers at scale, going to AWS is possible but won't be your first choice. Microsoft sales people being condescending will basically reflect that situation.
In most other situation I can think of you'll go to Azure only if you can't use the alternatives, so again you're basically at their mercy.
To digress, if you run linux servers with an open source stack, going to Azure will bring you virtually nothing, and will probably be an expensive PITA at every step. In a previous ruby shop we had more empathic dev evangelists walk us through Azure, but we felt like wasting their time as it clearly wasn't a priority to them. Then looking at the price we'd need to drop them as soon the discount prices expire, so it was just a losing proposition for everyone involved. I totally understand how more sales focused employees would weed out shops like us and go look for those who have to stick with them anyway.
My company does that. We have started moving new things to the cloud, but we took one look at the Windows pricing in the cloud and ran away. And my company is DEEP in Windows.
So I’m not sure Azure really has much of a leg up there. I think the only real benefit they have is their hybrid cloud for people who do use Windows in the cloud as well.
And this is the actual problem. Azure doesn't compete on quality. Microsoft rarely does. They have a few products and a market position that make them the default choice for countless customers. Nobody punishes them for their failings as long as the feature boxes keep being checked, and so the cycle continues.
Teams and Azure DevOps are some of the worst software I've ever used in my life. I've used worse software before, but it was hobbyist stuff written by single developers, and therefore don't really compare fairly.
Checkout stage of our code from Azure Repos easily count for half a minute. Npm install goes for a 1.5 minute with npm cache hit. Total build times are around 20 minutes...
It took me an escalation from our account manager, to get a good support guy, who informed me of this functionality.
Here is the summary of my support ticket:
WEBSITE_RUN_FROM_PACKAGE” and value as 1.
We performed deployment and it took around 30 secs. We also verified that the app is working fine.
Now you will do some changes and deploy once more to verify end to end pipeline.
Zip deployment is a feature of Azure App Service that lets you deploy your function app project to the wwwroot directory. The project is packaged as a .zip deployment file. The same APIs can be used to deploy your package to the d:\home\data\SitePackages folder. With the WEBSITE_RUN_FROM_PACKAGE app setting value of 1, the zip deployment APIs copy your package to the d:\home\data\SitePackages folder instead of extracting the files to d:\home\site\wwwroot. It also creates the packagename.txt file. After a restart, the package is mounted to wwwroot as a read-only filesystem.
Article for reference: https://docs.microsoft.com/en-us/azure/azure-functions/run-f...
The problem with Teams is that companies use it to replace Slack, which is much more pleasant to use.
The reason is that it’s impossible with the desktop app to browse channels that you’re not a member of, whereas on mobile you can! When I mentioned it to my colleagues they were shocked. This whole time they could have been communicating in other channels and they had no idea they existed. I have no idea if this is a bug, or some kind of admin setting.
There are plenty of other issues with DevOps too. You have to buy in to the whole Microsoft package apparently, and none of the parts are best in class.
Simple things like being able to sort tables un the web UI have had open issues for years.
They practically just copied some Azure CI stuff over (which was obviously written from a completely different perspective/mindset) using a tech stack that is old yet immature when compared to even relatively young products like GitLab CI.
If a company wants to come up with a CI product but can't even get on par with basic nominal GitLab CI features and usability, what's the point...
Why does it require so many steps? Why are they so verbose? It feels like writing glorified bash scripts (in which case why am I using a CI tool?) but worse.
Go read through some issues, look at some closed ones, try and skim through the source code. Realize there's two enormous python scripts in the repo, one with "2.0" tacked on the end.
If Azure is somehow not just rebooting/killing VMs that lack the magic handshake, I'd highly recommend dropping the agent.
After all of this news, and what is on display in walinuxagent, do you really want some network-connected agent listening, who's often-most-touted feature is being a persistent backdoor?
"It's tough being an Azure fan." Eh, it's a nice cyclic problem. They have no depth of caring about engineering (hence why Azure is littered with services that are impossible to fully utilize because their own engineers don't understand the how/why of what they're building half the time). Which in turn, along with crap career advancement and constant un-appreciated, unmitigated live-service burnout, is why they can't retain actual Linux talent to save their fucking lives.
Most of the time Azure feels like just another 'we have virtual machines and a crappy API' service. Kinda like a pretend-cloud where a lot of products come almost together but never finish. Almost similar to the way Windows and backwards compatibility means you end up with 100 libraries, frameworks, languages and versions all sitting side-by-side and not really working together, just differently in parallel. Not useful for automation at all, which makes it not useful at scale. (Except when scaling means: we want to run windows VMs with AD and go from 10 to 100 and change no parameters at all)
It went something like this:
Code used to be running on a processor, then it ran on an OS on a processor. Then it became on a runtime on an OS on a processor. Then it an abstraction layer was sandwiched in between. Then a filesystem. Then a compatibility layer. Then a database. Then a browser. Then we went and created a runtime in the browser to run code again. We have come full circle.
This probably applies to SharePoint but also the real-time OS on your GPU, the MSSQL database which has its own OS facilities you can run stuff on. Add too many features and the application becomes the very thing we wanted to get away from...
It’s like the business equivalent of the “once you understand a monad you can no longer explain it” meme.
You sell to the managers and equip them with hollow buzzwords because you know they're gonna override the engineers on every decision anyway. By then, MS has your firm's money and all you can do is deal with it.
Used to be a function doc would tell you:
1. All the parameters and their types 2. What they did, explained 3. All possible exceptions raised by the function 4. All possible return values 5. Supplementary documentation on the object or structs passed in or passed back 6. Some examples of it in use
Now, the current docs sometimes have examples for Azure CLI/SDK stuff, but there is one convention that drives me bonkers that is as bad now as it ever was.
For examples, often times you'll get the most important part replaced with a [insert your thing here]. The format of the thing you fill in there is often left as an exercise to the reader to intuit or guess.
I find the Azure docs to be decent. They are consistent across services for the most part, so you learn how to work with them after a bit of experience on the platform.
- Customer asks for something trivial to be deployed. I say, "no problem" and start beavering away on a Bicep template or whatever to deploy their stuff.
- I hit some small but showstopper issue with a service that I expected to work, but it doesn't. I open a support ticket.
- Inevitably, it turns out to be some stupid, stupid limitation caused by unfathomable laziness of the Azure developers. No workaround, no mitigation, but we're "working on it" with no ETA offered.
- Literally years later a trivial fix for the glaring issue goes into "PREVIEW" for 9 months, long after the original project was closed. I no longer care...
Networking is especially bad, with endless limitations that make no sense, like:
IPv6 is incompatible with everything. Turning it on for anything anywhere in a vNET will permanently block unrelated features like IPv4 NAT.
But of course, you can't "protocol translate" from IPv6 on the outside to IPv4 on the inside, so you end up painted into a corner.
No bring-your-own-subnet, which means many lift & shift scenarios are impossible (we have customers using a class B pubic range internally).
Azure forces NAT on IPv6, which makes no sense at all.
All Azure PaaS services have firewalls that are IPv4 only.
The built-in firewalls (e.g.: Azure SQL Database) do not support service tags, only CIDRs.
I could go on and on...
You can't move a VM to a different subscription without also moving the entire vNet along with it. (I bet this worked great in the developer's lab with one test VM.)
You can't move a VM to a different backup resource without deleting all backups, going back years.
VMs can't be rolled back to VM snapshots.
ExpressRoute bandwidth can be increased non-disruptively, but the only way to decrease it is to recreate it -- incurring a ~30 minute outage.
The Activity Log (and most other audit logs) don't log the identity of the administrator that triggered the action about 10-50% of the time, depending on what kind of activities are going on. This makes it 100% useless as an audit log. There is no other way to obtain audits.
Most network resources are Zone Redundant, except for NAT Gateway, which is now required in some scenarios. It's Zonal only, which means you need 3 subnets, one for each zone.
Upgrading an internal load balancer from Basic to Standard cuts off Internet access, for "reasons". I'm told these are "security reasons". Uh-huh...
App Gateway doesn't use a "user-agent" header for its monitors, which makes it incompatible with a surprisingly wide range of CotS software. This includes a bunch of Microsoft Software.
I could go on and on...
This is all microsoft products though. There have been .NET Identity bugs that have been open and acknowledged for multiple years.
AKS suffers, AFAICT, constant API server outages. We tried to escalate into a ticket, but we just get motte & bailey'd between "you're putting too much load on the API server" — okay, what load? how can I see that, control it? — "here is the top consumers" — they're all AKS itself? — "well, there's too much load on the API server" gah! (Yes, we pay for the "SLA".)
You can't add IPv6 anywhere in a vnet, it will break unrelated things. We tried to add a managed PSQL server on IPv4 (b/c IPv6 is not supported): it "failed" (the API call to create it timed out with an internal server error … after 2 hours or so!) because something unrelated in the vnet used IPv6.
ACR has a 20 TiB limit, no way to prune containers, we've had to work around IDK how many 500s, the API is slow as dirt (response bandwidths of ~50 kbps — bits — and their team does not think that's a problem. It can take 10 minutes to enumerate a few megabytes of metadata…) Undelete-able manifests that I guess we will just pay for indefinitely? I feel like I could build ACR on top of Azure Blobstorage and it would be more reliable with better performance…
VMs shipping with buggy kernels. (Support wanted to know what weird thing we were running to hit kernel bugs. "Docker"?) Global outages. Known outages often don't get mentioned on the status page intentionally. I still don't know what the difference between an availability set and a VMSS is.
Everything is in preview. Everything.
Audit logs fail to load some times. Beyond complicated interactions/differences between "service principals", "applications", "enterprise applications". 2FA app now requires authenticating twice, per login, because each tenant acts as a separate yet not separate login. So. much. auth. Role assignments that don't know what principal is being granted permission, b/c ARM & AAD don't do referential integrity.
Docs that are outdated. Requests for updated docs closed without update, because "we don't have the data <from some other internal team, I think, but so?>"?. Docs that describe API calls badly. "foo: the foo query parameter" No docs, at least, that I'm aware of, about what permissions does the API call require. The docs conflate "permission" and "role" (different in Azure) all. the. time. Azure doesn't know what permissions some calls require, and simply says "give it Contributor" (close to all permissions)… and yeah that works but I want to show auditors we're doing PoLP?
Support… The SLA often isn't met, we're assigned reps in China (n.b., this isn't a language barrier problem, it's, how is someone who is literally sleeping during my business hours because that's timezones for you supposed to even meet a support SLA that wants a 8/4/2 hour response? And AFAICT from response times, they're not a night shift…?), the first response is worthless (doesn't answer the inquiry, requests information present in the original request, often isn't technically proficient, etc.), the writing is broken and sloppy. Half the time a simple "reread what you're about to send. Does it solve their problem?"… we literally got a blank email back. We've had tickets where the first response we get is "we haven't heard back from you" because sometimes their responses fail to get linked into the ticket in the portal. They lack any formal bug reporting mechanism, and support is not equipped to handle bugs.
My God, it's full of bugs.
B2C on the other hand is a different story. Every few months we have to roll out a new tenant in our system. Tenants are identified by B2C "applications". Every single time, the new application doesn't work. Every single time the fix involves editing the JSON spec, changing something random (like a "true" to a "false"), saving, and changing it right back again.
Doesn't exactly inspire confidence... we're planning a migration to AWS.
Also, try Googling for documentation related to "Microsoft Azure AD B2C". Almost every shred of internet wisdom is related to AD and not B2C. Even with Microsoft's own documentation you sometimes follow a link from a B2C API reference and find yourself in AD-only land and it isn't obvious. This makes the task of researching features and debugging infuriating.
- x86 just has better support for the stuff Azure's "enterprise" customers want
- ARM servers are often more expensive to spin up than an equivalently specced x86 option
- PRISM compliance is easier on x86 (half-joking, half not)
I like ARM, and I owned a Rev1 Raspberry Pi when those were cool. But even now, ARM still has yet to make a strong case for existing on the server. And that's before we even discuss architectures like RISC-V that are out on the horizon, much better suited for servers than ARM. I'm not planning on an "ARM revolution" taking place in the next decade unless x86 is critically compromised in some way.
This is several years out of date: AWS Graviton instances are usually a fairly substantial savings over similar Intel, with AMD in between, and Cloudflare has been reporting rather good numbers as well:
https://blog.cloudflare.com/designing-edge-servers-with-arm-...
The main reason I suspect Azure doesn't have it is both Windows' legacy x86 hyper-focus (the days where NT ran on half a dozen platforms never really panned out) and a smaller number of managed services. AWS has very popular services like RDS, ElastiCache, ElasticSearch/OpenSearch, etc. where you can simply check a box and wait a couple minutes to see savings, not to mention things like Lambda being only slightly more work for many users, and that's a great way to get volume usage even if the average enterprise IT department is scared to go near it for VMs.
There have been multiple consumer ARM Windows products on the market for the last 9 years, I'd say Windows (client, at least) on ARM64 is as solid as its x64 counterpart
Have you really had the experience that a large organization has the ability to recompile everything they run? Most will have a lot of code which is provided as binaries by a vendor, and their in-house code almost certainly has dependencies and optimizations which will need to be dealt with & revalidated. No, none of that is unsolvable but it means adoption is much harder than, say, changing an RDS instance type and you'd be taking on all of the support rather than the cloud provider's much larger team.
That's what I referred to in my original comment — in my experience, the average Azure user works at a Windows-heavy enterprise IT shop where those issues would be common. That doesn't mean that I don't expect ARM servers to happen there — Microsoft announced it was coming years ago, after all — but that it's going to be slow since the upfront investment will likely have slower adoption.
About the ability to recompile, if you can't build ARM software what's the point of using ARM instances? You don't need cross-architecture compatibility like you need it on the desktop version, which is what consumer complain about when talking about Windows on ARM
I think AWS has successfully been pushing this because they know they’ll see that initial volume from people seeking savings on their own managed services and things like Lambda which are easy to switch, and that will fuel interest in switching other services which require more work.
Every comparison I've seen was cost saving for the datacenter.
Also, lots of stuff doesn't worth with GCC High
That was 4 years ago.
Unnecessarily complex, arcane and frustrating is how I’d describe basically everything we had to do.
The fact that they ship a whole Python runtime is basically the least shocking thing I’ve learnt about Azure.
simply mindboggling
Do you mean like cloning VM A destroys it and creates identical VMs B and C?
From a business perspective, this is brilliant. From a technical perspective it's not awesome, obviously.
Not that that is an excuse for azure of course (or conversely the fact azure does it isn't an excuse for aws).
"fan" is just in the title.