Hacker News Reader

Comment by ethbr0 | Hacker News Reader

> Azure APIs, tools and services get deprecated often

My experience with "new" Microsoft is that they're still learning how to play nice with others.

Not in that they don't want to, but that they're objectively bad at it, because it's not something they're institutionally used to doing.

"Old" Microsoft was "We build what we want, how we want, at the pace we want, and we produce some very polished final docs, and you use what we built how we expect."

Continually iterating on externally facing services owned by a small team, and consumed in arbitrary ways by third parties, is a very different model than the above. We'll see if Microsoft can re-org to the challenge.

View on HN

They’re the same asshats. With a thin layer of marketing veneer over the top, telemetry underneath all floating on a vat of poor testing, poor delivery and poor quality.

I had a defect open for 9 years on connect that affected 20,000 users. Couldn’t pay them to fix it even as a gold partner. Now they just abandon all their shit in GitHub instead and sell you a subscription to be served up ash and beer dregs while reminding you that they love Linux and open source while trying to get leverage and replace whole chunks of it with their bananas ecosystem.

Edit: must be lunch time at MSFT. Downvote flurry.

I think it's more that your comment is 95% salt and 5% substance an so isn't adding much to the conversation. More details like the connect issue and less "ash and dregs".

I will write up the 30 years of using MSFT stacks and OS up at some point. That’ll be 100% substance. But the salt will have to remain.

If you want to see the real MSFT check out the dotnet team handling of the customer demands to remove telemetry. This is on GitHub issues. Or was if they haven’t reorganised all the repos again thus backing up the other schizophrenic donkey comment.

See https://isdotnetopen.com

Well that was an interesting read and entirely unsurprising.

I would never consider building a new product on .Net. It’s an insane proposition at this point.

Well, to give just one example: zip deploys (code) to azure functions always return 200 OK, regardless of whether the deployment actually succeeded. To know if the deployment succeeded, you need to use a second API (the kudu mgmt api) to access the text logs, and scan the text logs for errors. Due to our CI infrastructure, we do multiple deploys per day, and I can tell you that most of our deployments require 2-3 attempts to deploy successfully. We have a whole salt mine of workarounds like that in our deployment infrastructure.

It's been that way for years. Every now and then, they pull another Microsoft on top of this. The latest that I remember is that even after successful deployment, the function would actually not get activated until you polled its existence using the Az cli tools. We hit that one because we used the Powershell Az module, and of course the cli tools and powershell exercise different code paths :/

Oof. I've come to despise Kudu for these kinds of reasons. We ended up ditching direct zip deployments and now do Docker images, which get pulled automatically using the webhook on the container registry. It is far more reliable and also far easier to integrate into a devops pipeline.

Hi tremon. I work for the Azure Functions team. Sorry for the trouble. This should not happen. We should be giving you a proper response code when the deployment fails. It looks like you are using the sync version of the API but just double checking if you are using the sync or async version ? If you are using the async version then in that case we do return a 201 immediately and then you can use the status url to poll for the status. I would like to dig in and figure out what's happening here.

For the PowerShell Az issue as well - it would be good to know what command you were using/what you were trying to do. We dont support deployment of code using the Functions PowerShell Module (https://www.powershellgallery.com/packages/Az.Functions/4.0....). Did you deploy using AZ CLI and then using the PowerShell Module ?

You can either share your Function App info here by using this method: https://github.com/Azure/azure-functions-host/wiki/Sharing-Y...

or just email me at anirudhg at microsoft.com and I will look into this.

Thanks again for using Functions.

Do you have any plans for “easy auth” (that’s what MS support called it despite it not being called that anywhere in the Azure UI or documentation) with azure functions or at least not allowing people to try to set up auth for azure functions when according to your internal support AD-B2C “easy auth” is not compatible?

BTW I just want to say that functions kinda work aside from the above issue, but having to write a boot-loader that handles auth, kinda defeats the purpose. Or is it just that AD/B2C is so bad even your support guys don’t know how to set it up? Tried this about 12 months ago so maybe it’s changed in that time but fuck me dead getting auth to work with functions was a pain in the ass and made me swear I’d never touch another azure project again. I don’t think the problem is with Azure Functions per say, every interaction with AD/B2C at every org I’ve worked for that used Azure has been a monumental disaster of poor documentation and excessive complexity. You need a true expert in auth to work with it and even then they will spend half their working life swearing. The auth offerings from Google and AWS just work.

AD/B2C is also the biggest problem with teams (I just can’t log in on my machine as I’ve too many accounts for it not to get in a tizzy). I can’t even play minecraft cross platform because of it.

We don't perform the zip push manually, we use the AzureFunctionApp pipeline task. What that uses under the hood, I can't tell.

  - task: AzureFunctionApp@1
    inputs:
      appType: functionApp
      deploymentMethod: runFromPackage

This task always succeeds. Whether that is because it's using the async API and ignoring the status url or because of different reasons is beyond my control. All I can tell is that with regular occurrence, the wwwroot will contain the file 'FAILED TO INITIALIZE RUN FROM PACKAGE.txt' instead of the actual deployed code (web.config will show "503 Site Unavailable: Could not download zip").

Our retry code repeats the same push using Publish-AzWebApp, which is sync FAFAIK (and regularly fails the same way as the pipeline task). We don't use AZ CLI at all. As long as Microsoft keeps updating both the CLI and Powershell modules, we expect them both to be equally supported.

Thanks for the details. Will let you know what we find.

Hello tremon,

I am the PM working on Azure Functions Deployments. Thank you for sharing your experience. We are currently investing in improving our deployment flows via Azure DevOps and this is a known issue. There are two aspects here - one is to address the not so optimal user experience that sets an incorrect expectation of "success" and second to actually provide more visibility into errors that cause deployment failures. I have prioritized the former to go out as part of the next DevOps release and will be happy to help you with the latter if you can create a support ticket with more details so we can investigate further. Please feel free to email me with any additional feedback on sokulkar at microsoft.com. Again thank you for your valuable feedback and usage of Azure Functions.

I can add some salt on azure web apps. I routinely get "everything is wonderful" answers from their weird admin guis, for services that I observe cannot reach their database or even start up. Unless I operate azure from the commandline, the ui is questionable.

AWS also actively work on reducing wastage on behalf of their customer and pass them back. Ther instance pricing have reduced some 30+ times I beleive.

> Couldn’t pay them to fix it even as a gold partner.

People complain about the old MS, but it used to be if you paid enough things got fixed. Cough up enough money and you'd get a direct line to the lead developer of whatever product you were having an issue with.

When I first joined MS back in ~2006 I got to witness this first hand, a high value customer had a problem with some C++ code and MS provided a translator and put the customer in contact with the compiler team.

The issue with "metric driven development" is that if something doesn't move the needle, it isn't addressed. What the #s don't show is that the sum total of small annoyances lead to massive customer unhappiness.

> while reminding you that they love Linux and open source while trying to get leverage and replace whole chunks of it with their bananas ecosystem.

Many of the senior/principle devs at MS now grew up reading /. and hating the MS of the 90s. The culture there is massively different, both for better and for worse. 1990s MS had huge documentation teams and tested the living daylights out of all code before it hit customers. The massive doc teams were laid off during the '08 recession and AFAIK never hired back (at least not in the incredible # they used to be), and after Google/Facebook scared MS with "move fast and break things", MS got rid of their testers as well (as has the entire industry), so now the code isn't as reliable.

>Edit: must be lunch time at MSFT. Downvote flurry.

>Please don't post insinuations about astroturfing, shilling, bots, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

>Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html

My firm is investing quite a lot of money / time / effort in our Azure infrastructure for relatively large and complex models (financial models with up to 10k cores; nothing very fancy just lots math and lots of customers). Our engineers are capable, they seem happy with the stack and we actually get pretty solid support from Microsoft. We ran into several Azure-specific bugs in the last few years which get timely triage, quick fixes within hours and solutions within weeks. We’re probably overpaying and have been Microsoft-centric for the decade I’m with the firm, so the local relationship is probably excellent. All in all it’s a lot more affordable than the license fees for niche supplier software we were using before. Point being it’s relative cost and engineer satisfaction that matter more than the last few million in costs.

Might be worth comparing them with other cloud providers rather than niche supplier software.

Part of our experience away from vendor specific tooling was building a team that could handle the transition. It started with perhaps 2 or 3 engineers doing PoC’s. Then an architect came on board with Azure experience. Things went from there. We’re now at about 40 engineers working for / with about 100 actuaries / quants. I know the lead architect has theoretical vendor neutrality in scope, but the aspect of successful teams working in the MS ‘package’ is alluring as well. We don’t need to squeeze the last drop - the projects are already successful both in financial and human terms. End of the day a business always has vendor risks. It’s about picking the cost-risk-reward structure that fits. All in all MS serves us well.

(We do have healthy laughs about the internal accountmanager for MS always chasing the latest and greatest. Virtual desktops, Azure ML and such. The lead architect mentioned luckily decides on the stack, not our sales reps.)

Hah from what I understand Azure ML might be late, but it is not great :D

There is no "old" or "new" microsoft. Time and time again they've shown us they are still the same old thing. Company DNA is what it is. Uber also falls into this category.

Don't let yourself be fooled by the same trick repeatedly.

Or we could accept that huge enterprises have a lot of institutional inertia, and real change plays out over a decade+.

Or as the quip goes: culture doesn't change until the previous generation retires or dies.

Huge enterprises are big enough they don't care about you.

You need to pick right sized providers so that you'll get decent service.

Relying on Google, AWS or Microsoft and not paying them millions means they won't give a crap about you.

Meh, Microsoft is enormously different than they used to be. They still might not be what you want, but they aren't the same.

Reply on news.ycombinator.com