7 ms·

I've used both and will gladly recommend AWS over Azure: * Azure APIs, tools and services get deprecated often. As soon as 3rd party docs get good and the bad

I've used both and will gladly recommend AWS over Azure: * Azure APIs, tools and services get deprecated often. As soon as 3rd party docs get good and the bad bugs get fixed it will get deprecated. AWS has its share of v2 APIs, but most of the fundamental services are the same for more than 10 years. The new services build on top of the old ones, instead of replacing them. * MS reps will endlessly spam you and every colleague in your org to adopt their latest preview features (gasp! You are not using ML and AKS??); But if you end up trying them you will find that they are half baked and if you get any sort of incident they will ask you to rewrite your app to accommodate them, rather than fixing their own bugs/state. * AWS has great 1st party documentation, and the stability means great 3rd party documentation gets created as well. Azure gets astroturfed "community" docs written by Microsoft employees. Community means that support and official pages link to them, yet Microsoft has no obligation to keep them up to date or take any responsibility of their contents. * I admit I like Azure resource groups (a logical container of resources in an account, required for every resource and simpler than the AWS equivalent). However I don't really miss them when I follow best practices (billing alerts, separate accounts for environments, IAC, tags).

pid-1 4y ago
Azure also has Azure AD, thus first class support for user and app identity. Cognito isn't even close.
- robertlagrant 4y ago
  What does Cognito lack?
  - mooreds 4y ago
    Oh so much. We hear this from our users all the time. Full disclosure, I work for a Cognito competitor, so I'm definitely talking my book here. But our users are not. Here's a summation. * There is only one deployment model, a SaaS offering on AWS. * The user pool and identity pool concepts can be difficult to grasp. * The user interface presented to your customers is inflexible and hard to customize. * You can run Cognito only in the geographies supported by AWS. * Cognito pools are not multi-region. If the AWS region that your pool is in is unavailable, you have few options. * It doesn’t support localization of messages or the user interface. * You can’t backup or export all user data, notably password hashes. * SAML accounts are expensive after you grow beyond the free tier. * Possibly most concerning, Amazon Cognito has been relatively static and has received few recent improvements over the last few years. The console UX got an overhaul in 2021, though. * The customizability of the user interface and workflows are lacking. * Since you can't export your password hashes, if you move to a different provider, you have to reset user passwords or use a drip migration. Here's a funny video from Corey Quinn about Cognito: https://www.youtube.com/watch?app=desktop&v=x70EypnAH1Y&feature=youtu.be https://www.youtube.com/watch?app=desktop&v=x70EypnAH1Y&feat... That said, I've heard rumors they are working on multi-region Cognito (see this vague tweet from an AWS employee: https://twitter.com/sarah_cecc/status/1486346455790985228 https://twitter.com/sarah_cecc/status/1486346455790985228 ) which would absolutely be a game changer. And they have a nice serverless model if you can get by with their functionality and deployment model.
    - wizwit999 4y ago
      #1 make no sense as a criticism of an AWS service, thats true (and the point) of all AWS services (excluding services on Outposts but that's not used casually).
      - mooreds 4y ago
        Agreed that #1 is due to it being an AWS service. There are a number of issues with Cognito that are shared with other AWS services. That doesn't necessarily disqualify Cognito for all situations. But certain auth providers (including my employer, but also many other solutions) can be deployed elsewhere (in other clouds, on-prem, etc).
    - robertlagrant 4y ago
      Hm thanks. I suppose I wasn't so clear as to say "vs Azure AD", which I was really after. But that is also a useful summary for thinking more generally about auth! I guess Azure AD would at least have the same restrictions on deployment, but restricted to Azure regions instead (IIRC Azure AD B2C only has 4 regions globally, although I may be out of date.)
      - mooreds 4y ago
        Ah, did you want to compare it to Azure AD or Azure AD B2C? As you allude to, they are different solutions aimed at different spaces (IAM vs CIAM). I'm less familiar with Azure AD B2C than with Cognito, but from my research and tinkering, Azure AD B2C has similar limits on UX customizability (basically CSS was the only way to change the look and feel when I checked it out), but more flexibility around workflows, using custom policies: https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-overview https://docs.microsoft.com/en-us/azure/active-directory-b2c/... Azure AD B2C wins on pricing (no SAML surcharge, I believe and the per MAU beats Cognito's until you get to 10M users for p1), but, as you'd expect, is less straightforward. As far as regions/availability, I couldn't find a straightforward answer. This: https://docs.microsoft.com/en-us/azure/active-directory-b2c/data-residency https://docs.microsoft.com/en-us/azure/active-directory-b2c/... indicates you can choose one of 4 places to store user data, but it isn't clear to me if there are multiple regions/data centers that apply if you choose, say, France. Cognito's availability story is much clearer.
pwarner 4y ago
Resource groups seems awesome, and are nice in some ways, but they are sort of this slippery slope that encourage you to put more into a single subscription than you probably should.
- obert 4y ago
  Why “should” one not put services in the same subscription?
  - pwarner 4y ago
    I mean, there is no right and wrong answer I suppose. You can have all the code for your project in one file. Forget a class per file or whatever, maybe it works for you. What I saw is that the more you co-locate in an AWS account or Azure subscription, the higher the bar goes on ensuring your cost reporting and access control are also completely aware of resource group boundaries. You really want to know is that $ for project A or B? You really want to ensure folks on project A have access to their cloud resources, but not project B. You can do that even in AWS, combine them and use IAM to segment things. I think there is just more room for error if you combine. Also I think Azure has some per subscription quota limits and you may not want team A and B competing for them. Again, no right answer, but I know we've done projects to split accounts and have never done one to combine them..
    - epberry 4y ago
      AWS Organizations are actually quite good for this. There's a "consolidated billing" function which puts everything under the same umbrella.
    - obert 4y ago
      I’m quite sure all the scenarios you mentioned can be managed leveraging resource groups and AAD settings. OTOH I can agree that for big engineering groups managing settings can become a challenge. IMO it’s not a matter of correct config, but about a threshold over which a single sub takes more effort to maintain.
  - 4y ago
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
iasay 4y ago
Typical Microsoft. Using their shit is like riding a schizophrenic donkey. I have been burned tens of times over the years and stuck with deprecated products and frameworks that were the official supported way of doing stuff on their platforms.
mathattack 4y ago
The spamming (and outright lying) from MS reps was pretty ridiculous. At a prior employer we couldn’t tell if our rep was clueless or unethical. We raised to three iterations of bosses but his leadership changed annually so he was never held to account. Finally a user revolt caused them to lose an $8mm deal. Even then they reassigned him rather than fire him. I’m impressed that they’ve moved on from being a Windows and Office company but their culture hasn’t caught up.
rurp 4y ago
> if you get any sort of incident they will ask you to rewrite your app to accommodate them, rather than fixing their own bugs/state. As it happens I recently ran into this exact situation with AWS. My team hit a surprisingly low undocumented scale limitation with one of their services. The error message stated that the limit could be increased on request, so I did exactly that. Rather than simply increasing it, they delayed and kept asking to setup a call to talk about how my team could rearchitect our code to work around their limitation. I told them no thanks, finding a way around the limit was not the issue, having to burn time implementing it on our end was. Overall though I do agree with your point. AWS is generally pretty good about handling scale and not breaking older APIs, but there are exceptions.
- mwint 4y ago
  Did they end up raising the limit? Curious what the limit was.
ithkuil 4y ago
How did you obtain the estimate if the azure customers having that problem?
gatvol 4y ago
Hard agree here. AZURE has been playing hard catchup with AWS in terms of feature parity, but scratch the surface of almost any of their services and you will discover shonky, bug ridden implementations (and many things seem to be in perpetual preview) that are more expensive than their AWS analogues.
- jnsaff2 4y ago
  This has been my observation too. AWS started with primitives needed to operate a cloud service. I remember the days of AWS where many features were available via API’s only, no Web Console. Then built higher level services on top of those as customer needs became clearer. Using Azure always felt like that the inside development must be led by marketing team: “here are all the services AWS has, go build them as cheaply as possible from all the existing garbage we have, by yesterday!”
phpisthebest 4y ago
>Azure APIs, tools and services get deprecated often This is one of the most shocking things with "new" Microsoft, Microsoft always had the best backwards compatibility, now with Azure and Office 365 is seems they do not give 2 shits about backwards compatibility and breaking changes Every day there seems to be a new breaking change or some API, Powershell Module, Sync Application, or service that is being depreciated often with limited or no drop in replacements Have workflows, automation or systems dependent on the things.... who cares move to the new thing
rendaw 4y ago
* Every time you open a new tab, the new tab loses auth status and needs to re-auth. When I opened tabs for a bunch of VMs I got locked out for hitting the auth endpoints too quickly. Auth happens with a nonce so if you open two tabs, completing auth on the first tab causes the 2nd tab auth to fail so you need to refresh and do it again. * The UI doesn't list any info on VMs, you have to click on each vm to see the details. Going back loses your list filters, etc. * If boot logs get too large they never load in the web UI, you have to dig up the storage path, manually dig through the blob storage UI to locate the file, download it, and look at it with a local editor. * Unlike AWS, they decided it would be better if every resource had a composite ID - subscription, resource group, name. You need to carry these things around together throughout your code. In the Go library you need to pass them to separate calls as separate params, for other things you need to pass them formatted as a URL path (generating the path by hand). * The Azure official Go library shells out to the Python CLI to do saml auth! * The Go library goes 100% against Go paradigms. API calls return a future, which then needs _2_ more calls to wait for and get the result from (WaitForCompletionRef, Result -- rather than just blocking the goroutine), each with errors that need to be checked. One of the two calls seems to be a leaky abstraction working around the fact that Go didn't have generics. * WaitForCompletionRef never returns for a VM if it doesn't boot. So if you have a multi stage boot it'll just hang there. * Their Go library is the epitome of inconsistency. There's at least a handful of different auth methods, and they have like three or four simultaneous generations of library apis (in the same library) that are all incomplete. To this day, constant breaking changes, dep incompatibilities (with their own libraries, with newer/recent older versions of Go). Iterating collections was similarly painful, with multiple "Paginator" object styles each with unique idioms (and dozens of bugs due to not getting the idioms quite right -> skipping pages or ending iteration early, etc). Half of it feels like someone said "We need to be different from AWS so it doesn't look like we're copying them" but since AWS was doing things the best way they had to do things poorly instead. (edit: AWS has tons of issues and I don't want to pretend otherwise, but the comparison to Azure is night and day)
krageon 4y ago
Counterpoint: They're both huge trash. They both have advantages over the other (the API is just better for Azure IMO), but those advantages pale when viewed through the lens of how bad both platforms are. If you can use anything else you should do so. Given that, having a discussion about which is less bad and how isn't very useful. When viewed holistically, they are both bad.
- jokethrowaway 4y ago
  I completely agree. I've been complaining about AWS UX and how they name, split and bill for their services for ages. I'm now on Azure (for no choice of my own) and it's a complete dumpster fire, even worse than AWS. GCloud (which I was on 5 years ago) was the least worse of the big one and it wasn't good either. I've been impressed by DigitalOcean, but it's not a popular choice in large companies. Nobody got fired for recommending AWS, Microsoft or Google. For my own hosting I pick Hertzner simply because it's cheaper and I don't need a UI or services that hold your hands.
- KronisLV 4y ago
  > If you can use anything else you should do so. Honestly, for my personal needs I just use the smaller hosts: Scaleway, Hetzner, maybe DigitalOcean or Vultr. Actually right now I'm using Time4VPS (a regional host) because of some nice yearly discounts. I choose Debian/Ubuntu LTS and install Docker or another OCI runtime and run containers inside of Docker Swarm or Kubernetes (K3s), with something like Portainer or Rancher for graphical management. So in a way, I'm building my own PaaS solution (well, more like launching existing turnkey solutions with minimal to no customization), since I just don't care about getting vendor locked. For example, managed databases are cool, but a PostgreSQL/MariaDB container is pretty close (for my needs) anyways. Fancy load balancers are awesome as well, but most of the time I need little more than Caddy/Nginx/Apache to act as my ingress with Let's Encrypt (DNS-01 challenge or cert directory shared over NFS or soemthing). Updates? Just bump a tag after backup, validate if works, restore if doesn't. Crashes? Automatic health checks and restarts, or maybe notifications to my Mattermost instance/e-mail if I'm feeling fancy. And if I want to migrate elsewhere, I just carry over the bind mount directory, launch the containers with same config there and update DNS records, monitoring, backup config. That's it. That said, self-hosting most of your stuff is great, but lots of people rightfully don't care and don't want to bother gaining that skillset, which is perfectly fine. Use whatever works for you, even managed Kubernetes is a good step to avoid vendor lock if you use containers. Or, you know, use whatever your corporate dayjob setting mandates.
mbrodersen 4y ago
This is a general problem with Microsoft and not just Azure. You can’t rely on anything new that Microsoft has released in the last 1 to 2 years. And especially anything that they are heavily promoting. They naively seems to think that rewriting something that ALREADY WORKS with a half-baked unproven new technology is a good way to invest developer salary $. How naive is that? Remember Silverlake? Remember Microsoft trying to pretend that C++ is dead for years and being forced to back flip because strangely companies out there did not rewrite their proven 10 million line C++ applications in C#? Microsoft in general has zero clue on what is important to the companies using Microsoft tech. What matters to mature developers and companies is stability. Being able to rely on a tech for decades without having to throw out millions of $ to rewrite everything using the latest wet dream tech generated by Microsoft.

pid-1 4y ago

Azure also has Azure AD, thus first class support for user and app identity. Cognito isn't even close.

robertlagrant 4y ago
What does Cognito lack?
- mooreds 4y ago
  Oh so much. We hear this from our users all the time. Full disclosure, I work for a Cognito competitor, so I'm definitely talking my book here. But our users are not. Here's a summation. * There is only one deployment model, a SaaS offering on AWS. * The user pool and identity pool concepts can be difficult to grasp. * The user interface presented to your customers is inflexible and hard to customize. * You can run Cognito only in the geographies supported by AWS. * Cognito pools are not multi-region. If the AWS region that your pool is in is unavailable, you have few options. * It doesn’t support localization of messages or the user interface. * You can’t backup or export all user data, notably password hashes. * SAML accounts are expensive after you grow beyond the free tier. * Possibly most concerning, Amazon Cognito has been relatively static and has received few recent improvements over the last few years. The console UX got an overhaul in 2021, though. * The customizability of the user interface and workflows are lacking. * Since you can't export your password hashes, if you move to a different provider, you have to reset user passwords or use a drip migration. Here's a funny video from Corey Quinn about Cognito: https://www.youtube.com/watch?app=desktop&v=x70EypnAH1Y&feature=youtu.be https://www.youtube.com/watch?app=desktop&v=x70EypnAH1Y&feat... That said, I've heard rumors they are working on multi-region Cognito (see this vague tweet from an AWS employee: https://twitter.com/sarah_cecc/status/1486346455790985228 https://twitter.com/sarah_cecc/status/1486346455790985228 ) which would absolutely be a game changer. And they have a nice serverless model if you can get by with their functionality and deployment model.
  - wizwit999 4y ago
    #1 make no sense as a criticism of an AWS service, thats true (and the point) of all AWS services (excluding services on Outposts but that's not used casually).
    - mooreds 4y ago
      Agreed that #1 is due to it being an AWS service. There are a number of issues with Cognito that are shared with other AWS services. That doesn't necessarily disqualify Cognito for all situations. But certain auth providers (including my employer, but also many other solutions) can be deployed elsewhere (in other clouds, on-prem, etc).
  - robertlagrant 4y ago
    Hm thanks. I suppose I wasn't so clear as to say "vs Azure AD", which I was really after. But that is also a useful summary for thinking more generally about auth! I guess Azure AD would at least have the same restrictions on deployment, but restricted to Azure regions instead (IIRC Azure AD B2C only has 4 regions globally, although I may be out of date.)
    - mooreds 4y ago
      Ah, did you want to compare it to Azure AD or Azure AD B2C? As you allude to, they are different solutions aimed at different spaces (IAM vs CIAM). I'm less familiar with Azure AD B2C than with Cognito, but from my research and tinkering, Azure AD B2C has similar limits on UX customizability (basically CSS was the only way to change the look and feel when I checked it out), but more flexibility around workflows, using custom policies: https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-overview https://docs.microsoft.com/en-us/azure/active-directory-b2c/... Azure AD B2C wins on pricing (no SAML surcharge, I believe and the per MAU beats Cognito's until you get to 10M users for p1), but, as you'd expect, is less straightforward. As far as regions/availability, I couldn't find a straightforward answer. This: https://docs.microsoft.com/en-us/azure/active-directory-b2c/data-residency https://docs.microsoft.com/en-us/azure/active-directory-b2c/... indicates you can choose one of 4 places to store user data, but it isn't clear to me if there are multiple regions/data centers that apply if you choose, say, France. Cognito's availability story is much clearer.

pwarner 4y ago

Resource groups seems awesome, and are nice in some ways, but they are sort of this slippery slope that encourage you to put more into a single subscription than you probably should.

obert 4y ago
Why “should” one not put services in the same subscription?
- pwarner 4y ago
  I mean, there is no right and wrong answer I suppose. You can have all the code for your project in one file. Forget a class per file or whatever, maybe it works for you. What I saw is that the more you co-locate in an AWS account or Azure subscription, the higher the bar goes on ensuring your cost reporting and access control are also completely aware of resource group boundaries. You really want to know is that $ for project A or B? You really want to ensure folks on project A have access to their cloud resources, but not project B. You can do that even in AWS, combine them and use IAM to segment things. I think there is just more room for error if you combine. Also I think Azure has some per subscription quota limits and you may not want team A and B competing for them. Again, no right answer, but I know we've done projects to split accounts and have never done one to combine them..
  - epberry 4y ago
    AWS Organizations are actually quite good for this. There's a "consolidated billing" function which puts everything under the same umbrella.
  - obert 4y ago
    I’m quite sure all the scenarios you mentioned can be managed leveraging resource groups and AAD settings. OTOH I can agree that for big engineering groups managing settings can become a challenge. IMO it’s not a matter of correct config, but about a threshold over which a single sub takes more effort to maintain.
- 4y ago

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

iasay 4y ago

Typical Microsoft. Using their shit is like riding a schizophrenic donkey. I have been burned tens of times over the years and stuck with deprecated products and frameworks that were the official supported way of doing stuff on their platforms.

mathattack 4y ago

The spamming (and outright lying) from MS reps was pretty ridiculous. At a prior employer we couldn’t tell if our rep was clueless or unethical. We raised to three iterations of bosses but his leadership changed annually so he was never held to account. Finally a user revolt caused them to lose an $8mm deal. Even then they reassigned him rather than fire him. I’m impressed that they’ve moved on from being a Windows and Office company but their culture hasn’t caught up.

rurp 4y ago

> if you get any sort of incident they will ask you to rewrite your app to accommodate them, rather than fixing their own bugs/state. As it happens I recently ran into this exact situation with AWS. My team hit a surprisingly low undocumented scale limitation with one of their services. The error message stated that the limit could be increased on request, so I did exactly that. Rather than simply increasing it, they delayed and kept asking to setup a call to talk about how my team could rearchitect our code to work around their limitation. I told them no thanks, finding a way around the limit was not the issue, having to burn time implementing it on our end was. Overall though I do agree with your point. AWS is generally pretty good about handling scale and not breaking older APIs, but there are exceptions.

mwint 4y ago
Did they end up raising the limit? Curious what the limit was.

ithkuil 4y ago

How did you obtain the estimate if the azure customers having that problem?

gatvol 4y ago

Hard agree here. AZURE has been playing hard catchup with AWS in terms of feature parity, but scratch the surface of almost any of their services and you will discover shonky, bug ridden implementations (and many things seem to be in perpetual preview) that are more expensive than their AWS analogues.

jnsaff2 4y ago
This has been my observation too. AWS started with primitives needed to operate a cloud service. I remember the days of AWS where many features were available via API’s only, no Web Console. Then built higher level services on top of those as customer needs became clearer. Using Azure always felt like that the inside development must be led by marketing team: “here are all the services AWS has, go build them as cheaply as possible from all the existing garbage we have, by yesterday!”

phpisthebest 4y ago

>Azure APIs, tools and services get deprecated often This is one of the most shocking things with "new" Microsoft, Microsoft always had the best backwards compatibility, now with Azure and Office 365 is seems they do not give 2 shits about backwards compatibility and breaking changes Every day there seems to be a new breaking change or some API, Powershell Module, Sync Application, or service that is being depreciated often with limited or no drop in replacements Have workflows, automation or systems dependent on the things.... who cares move to the new thing

rendaw 4y ago

* Every time you open a new tab, the new tab loses auth status and needs to re-auth. When I opened tabs for a bunch of VMs I got locked out for hitting the auth endpoints too quickly. Auth happens with a nonce so if you open two tabs, completing auth on the first tab causes the 2nd tab auth to fail so you need to refresh and do it again. * The UI doesn't list any info on VMs, you have to click on each vm to see the details. Going back loses your list filters, etc. * If boot logs get too large they never load in the web UI, you have to dig up the storage path, manually dig through the blob storage UI to locate the file, download it, and look at it with a local editor. * Unlike AWS, they decided it would be better if every resource had a composite ID - subscription, resource group, name. You need to carry these things around together throughout your code. In the Go library you need to pass them to separate calls as separate params, for other things you need to pass them formatted as a URL path (generating the path by hand). * The Azure official Go library shells out to the Python CLI to do saml auth! * The Go library goes 100% against Go paradigms. API calls return a future, which then needs _2_ more calls to wait for and get the result from (WaitForCompletionRef, Result -- rather than just blocking the goroutine), each with errors that need to be checked. One of the two calls seems to be a leaky abstraction working around the fact that Go didn't have generics. * WaitForCompletionRef never returns for a VM if it doesn't boot. So if you have a multi stage boot it'll just hang there. * Their Go library is the epitome of inconsistency. There's at least a handful of different auth methods, and they have like three or four simultaneous generations of library apis (in the same library) that are all incomplete. To this day, constant breaking changes, dep incompatibilities (with their own libraries, with newer/recent older versions of Go). Iterating collections was similarly painful, with multiple "Paginator" object styles each with unique idioms (and dozens of bugs due to not getting the idioms quite right -> skipping pages or ending iteration early, etc). Half of it feels like someone said "We need to be different from AWS so it doesn't look like we're copying them" but since AWS was doing things the best way they had to do things poorly instead. (edit: AWS has tons of issues and I don't want to pretend otherwise, but the comparison to Azure is night and day)

krageon 4y ago

Counterpoint: They're both huge trash. They both have advantages over the other (the API is just better for Azure IMO), but those advantages pale when viewed through the lens of how bad both platforms are. If you can use anything else you should do so. Given that, having a discussion about which is less bad and how isn't very useful. When viewed holistically, they are both bad.

jokethrowaway 4y ago
I completely agree. I've been complaining about AWS UX and how they name, split and bill for their services for ages. I'm now on Azure (for no choice of my own) and it's a complete dumpster fire, even worse than AWS. GCloud (which I was on 5 years ago) was the least worse of the big one and it wasn't good either. I've been impressed by DigitalOcean, but it's not a popular choice in large companies. Nobody got fired for recommending AWS, Microsoft or Google. For my own hosting I pick Hertzner simply because it's cheaper and I don't need a UI or services that hold your hands.
KronisLV 4y ago
> If you can use anything else you should do so. Honestly, for my personal needs I just use the smaller hosts: Scaleway, Hetzner, maybe DigitalOcean or Vultr. Actually right now I'm using Time4VPS (a regional host) because of some nice yearly discounts. I choose Debian/Ubuntu LTS and install Docker or another OCI runtime and run containers inside of Docker Swarm or Kubernetes (K3s), with something like Portainer or Rancher for graphical management. So in a way, I'm building my own PaaS solution (well, more like launching existing turnkey solutions with minimal to no customization), since I just don't care about getting vendor locked. For example, managed databases are cool, but a PostgreSQL/MariaDB container is pretty close (for my needs) anyways. Fancy load balancers are awesome as well, but most of the time I need little more than Caddy/Nginx/Apache to act as my ingress with Let's Encrypt (DNS-01 challenge or cert directory shared over NFS or soemthing). Updates? Just bump a tag after backup, validate if works, restore if doesn't. Crashes? Automatic health checks and restarts, or maybe notifications to my Mattermost instance/e-mail if I'm feeling fancy. And if I want to migrate elsewhere, I just carry over the bind mount directory, launch the containers with same config there and update DNS records, monitoring, backup config. That's it. That said, self-hosting most of your stuff is great, but lots of people rightfully don't care and don't want to bother gaining that skillset, which is perfectly fine. Use whatever works for you, even managed Kubernetes is a good step to avoid vendor lock if you use containers. Or, you know, use whatever your corporate dayjob setting mandates.

mbrodersen 4y ago

This is a general problem with Microsoft and not just Azure. You can’t rely on anything new that Microsoft has released in the last 1 to 2 years. And especially anything that they are heavily promoting. They naively seems to think that rewriting something that ALREADY WORKS with a half-baked unproven new technology is a good way to invest developer salary $. How naive is that? Remember Silverlake? Remember Microsoft trying to pretend that C++ is dead for years and being forced to back flip because strangely companies out there did not rewrite their proven 10 million line C++ applications in C#? Microsoft in general has zero clue on what is important to the companies using Microsoft tech. What matters to mature developers and companies is stability. Being able to rely on a tech for decades without having to throw out millions of $ to rewrite everything using the latest wet dream tech generated by Microsoft.