5 ms·

> 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 t

by ethbr0 4y ago

> 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.

metadat 4y ago
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.
- ethbr0 4y ago
  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.
  - jokethrowaway 4y ago
    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.
- markmark 4y ago
  Meh, Microsoft is enormously different than they used to be. They still might not be what you want, but they aren't the same.
wjnc 4y ago
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.
- robertlagrant 4y ago
  Might be worth comparing them with other cloud providers rather than niche supplier software.
  - wjnc 4y ago
    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.)
    - robertlagrant 4y ago
      Hah from what I understand Azure ML might be late, but it is not great :D
iasay 4y ago
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.
- grogenaut 4y ago
  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".
  - iasay 4y ago
    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.
    - ghuntley 4y ago
      See https://isdotnetopen.com https://isdotnetopen.com
      - iasay 4y ago
        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.
  - tremon 4y ago
    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 :/

by ethbr0 4y ago

metadat 4y ago

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.

ethbr0 4y ago
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.
- jokethrowaway 4y ago
  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.
markmark 4y ago
Meh, Microsoft is enormously different than they used to be. They still might not be what you want, but they aren't the same.

wjnc 4y ago

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.

robertlagrant 4y ago
Might be worth comparing them with other cloud providers rather than niche supplier software.
- wjnc 4y ago
  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.)
  - robertlagrant 4y ago
    Hah from what I understand Azure ML might be late, but it is not great :D

iasay 4y ago

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.

grogenaut 4y ago
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".
- iasay 4y ago
  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.
  - ghuntley 4y ago
    See https://isdotnetopen.com https://isdotnetopen.com
    - iasay 4y ago
      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.
- tremon 4y ago
  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 :/