4 ms·

You've got me curious: what was the single biggest barrier to migration, if you're able to disclose it? I'm guessing it was something proprietary to AWS, like h

You've got me curious: what was the single biggest barrier to migration, if you're able to disclose it? I'm guessing it was something proprietary to AWS, like how they handle serverless or something that couldn't translate over directly, but I'm always eager to learn why a migration from X to Y didn't work.

mi_lk 2y ago
Curious about details too. The parent's conclusion is to write off Azure, but I wonder if it's actually AWS or the way they use AWS that makes it hard to migrate. Or put it in another way, if Mojong were to start with Azure but couldn't manage to migrate to AWS, which provider is the parent going to write off?
- noodletheworld 2y ago
  My experience has certainly been that AWS is both a) more stable, and b) has more migration resources and guides than the reverse. It was easier to go to AWS than to Azure; and I've done both in the past ~4 years. Migrating to AWS was just technical work. Migrating to azure was 'fight unexpected bugs and the fact it doesn't actually work in surprising situations'. The only reason to go to azure was that Microsoft waved a big fat $$$ discount to use their services. Migrating to AWS was a breeze.
  - nosefrog 2y ago
    Yup, the hardest part about migrating to Azure was jumping between all the managed services that work everywhere else but are insanely buggy on Azure. We ended up with the most basic architecture you can imagine (other than AKS, which works great as long as you don't use any plugins) and we're still running into issues. We have a very long list of Azure features and services that we've banned people from using. Just got off a call with someone at Azure today who told us to setup our own NAT gateway instead of using Azure's because of an outage where we made too many requests and then got our NAT Gateway quota taken away for the next 2 hours.
    - cj 2y ago
      To be fair AWS also has quotas on NAT Gateways. Maximum 55k concurrent connections. After that, they make you deploy NAT gateways in other availability zones. And a max throughput of 10 Gbps. I imagine AWS would also tell you to deploy your own gateway if you were running into the 55k concurrent connection limit of managed NAT. AWS tends to be flexible with their quota enforcement in my experience, though.
      - nosefrog 2y ago
        Yea, I don't have a problem with the quota, more that the "out of quota" throttling lasts 2+ hours even after the traffic spike dies down.
    - motorest 2y ago
      > Yup, the hardest part about migrating to Azure was jumping between all the managed services that work everywhere else but are insanely buggy on Azure. Care to point out a concrete example? I've worked with Azure a few years ago and I wouldn't describe it as buggy. At most, I accuse them of not "getting" cloud as well as AWS. For example, the whole concept of a function app is ass-backwards, vs just deploying a Lambda with a specific capacity. That is mainly a reflection of having more years working with AWS, though.
  - patmcc 2y ago
    My experience with AWS is the documentation can be bad/wrong, it can be difficult to find stuff, but the actual services are very solid. It does what you tell it to do. Stuff works. My experience with Azure is that it simply breaks in ridiculous and frankly unacceptable ways, all the time. It's like someone is unplugging network and power cables every couple hours just for fun.
  - motorest 2y ago
    > My experience has certainly been that AWS is both a) more stable, and b) has more migration resources and guides than the reverse. I'm not sure how well founded the stability argument is. I still remember the infamous series of AWS outages that took place a couple of years ago. The fact that AWS invests heavily in vendor lock-in is a problem created by AWS, not their competitors.
    - noodletheworld 2y ago
      … I was scrolling back through the “400 reasons not to use azure” in the OP and off the top of my head I’ve seen a dozen of them personally. You decide if that’s more or less stable than AWS. I’d say the evidence is pretty empirical, but hey, all I can say is my experience was utterly unambiguous. You can argue a lot of things, but hundreds of azure fails in a big giant list is probably one of the tougher ones to go “no, this is fine compared to AWS!” about, imo.
- smackeyacky 2y ago
  The networking is so, so bad in azure. We ran into all kinds of craziness with simple things that kept kicking us in the nuts like port exhaustion between different subscriptions. I quit my last job partly because they were wedded to azure.
amarant 2y ago
This is a couple of years ago, so I fully expect most of the issues we had back then to be fixed by now, but it was definitely Azure that was the problem. We wanted to use their hosted kubernetes solution(I forget the name) and pods would just randomly lose connection to eachother, everything network related was just ridiculously unstable. Host machines would report their status as healthy, but then be unable to start any pods, making scaling out the cluster unreliable. I also remember a colleague I regarded as a bit of a wizard being very frustrated with cosmosdb, but I cannot for the life of me remember what the specific issue was. Our solution was actually quite well written, if I do say so myself, we had designed it to be cloud agnostic, just on the off chance that something like this would happen (there may have been rumours this acquisition would happen ahead of time). But Azure was just utterly unable to deliver on anything they promised, thus the write-off on my part.
- Too 2y ago
  Pods loosing connection to each other is still very very common in azure. To see the positive side of it, it’s a Chaos Monkey test for free. Everything you deploy must be hardened with reconnections, something you should be doing anyway. What’s frustrating is that it happens rarely enough to give the illusion of being stable, making it easy for PM to postpone hardening work, yet often enough to put a noticeable dent in your uptime if you don’t address it. Perfect degree of gaslighting.
  - motorest 2y ago
    > To see the positive side of it, it’s a Chaos Monkey test for free. Everything you deploy must be hardened with reconnections, something you should be doing anyway. Keep in mind that in Azure it's a must-have, whereas everywhere else it's either a nice-to-have or a sign your system is broken.
  - naasking 2y ago
    At that point, aren't you better off actually making your own services regularly disconnect clients so you iron out all of the reconnection bugs?
  - 2y ago

mi_lk 2y ago

Curious about details too. The parent's conclusion is to write off Azure, but I wonder if it's actually AWS or the way they use AWS that makes it hard to migrate. Or put it in another way, if Mojong were to start with Azure but couldn't manage to migrate to AWS, which provider is the parent going to write off?

noodletheworld 2y ago
My experience has certainly been that AWS is both a) more stable, and b) has more migration resources and guides than the reverse. It was easier to go to AWS than to Azure; and I've done both in the past ~4 years. Migrating to AWS was just technical work. Migrating to azure was 'fight unexpected bugs and the fact it doesn't actually work in surprising situations'. The only reason to go to azure was that Microsoft waved a big fat $$$ discount to use their services. Migrating to AWS was a breeze.
- nosefrog 2y ago
  Yup, the hardest part about migrating to Azure was jumping between all the managed services that work everywhere else but are insanely buggy on Azure. We ended up with the most basic architecture you can imagine (other than AKS, which works great as long as you don't use any plugins) and we're still running into issues. We have a very long list of Azure features and services that we've banned people from using. Just got off a call with someone at Azure today who told us to setup our own NAT gateway instead of using Azure's because of an outage where we made too many requests and then got our NAT Gateway quota taken away for the next 2 hours.
  - cj 2y ago
    To be fair AWS also has quotas on NAT Gateways. Maximum 55k concurrent connections. After that, they make you deploy NAT gateways in other availability zones. And a max throughput of 10 Gbps. I imagine AWS would also tell you to deploy your own gateway if you were running into the 55k concurrent connection limit of managed NAT. AWS tends to be flexible with their quota enforcement in my experience, though.
    - nosefrog 2y ago
      Yea, I don't have a problem with the quota, more that the "out of quota" throttling lasts 2+ hours even after the traffic spike dies down.
  - motorest 2y ago
    > Yup, the hardest part about migrating to Azure was jumping between all the managed services that work everywhere else but are insanely buggy on Azure. Care to point out a concrete example? I've worked with Azure a few years ago and I wouldn't describe it as buggy. At most, I accuse them of not "getting" cloud as well as AWS. For example, the whole concept of a function app is ass-backwards, vs just deploying a Lambda with a specific capacity. That is mainly a reflection of having more years working with AWS, though.
- patmcc 2y ago
  My experience with AWS is the documentation can be bad/wrong, it can be difficult to find stuff, but the actual services are very solid. It does what you tell it to do. Stuff works. My experience with Azure is that it simply breaks in ridiculous and frankly unacceptable ways, all the time. It's like someone is unplugging network and power cables every couple hours just for fun.
- motorest 2y ago
  > My experience has certainly been that AWS is both a) more stable, and b) has more migration resources and guides than the reverse. I'm not sure how well founded the stability argument is. I still remember the infamous series of AWS outages that took place a couple of years ago. The fact that AWS invests heavily in vendor lock-in is a problem created by AWS, not their competitors.
  - noodletheworld 2y ago
    … I was scrolling back through the “400 reasons not to use azure” in the OP and off the top of my head I’ve seen a dozen of them personally. You decide if that’s more or less stable than AWS. I’d say the evidence is pretty empirical, but hey, all I can say is my experience was utterly unambiguous. You can argue a lot of things, but hundreds of azure fails in a big giant list is probably one of the tougher ones to go “no, this is fine compared to AWS!” about, imo.
smackeyacky 2y ago
The networking is so, so bad in azure. We ran into all kinds of craziness with simple things that kept kicking us in the nuts like port exhaustion between different subscriptions. I quit my last job partly because they were wedded to azure.

amarant 2y ago

This is a couple of years ago, so I fully expect most of the issues we had back then to be fixed by now, but it was definitely Azure that was the problem. We wanted to use their hosted kubernetes solution(I forget the name) and pods would just randomly lose connection to eachother, everything network related was just ridiculously unstable. Host machines would report their status as healthy, but then be unable to start any pods, making scaling out the cluster unreliable. I also remember a colleague I regarded as a bit of a wizard being very frustrated with cosmosdb, but I cannot for the life of me remember what the specific issue was. Our solution was actually quite well written, if I do say so myself, we had designed it to be cloud agnostic, just on the off chance that something like this would happen (there may have been rumours this acquisition would happen ahead of time). But Azure was just utterly unable to deliver on anything they promised, thus the write-off on my part.

Too 2y ago
Pods loosing connection to each other is still very very common in azure. To see the positive side of it, it’s a Chaos Monkey test for free. Everything you deploy must be hardened with reconnections, something you should be doing anyway. What’s frustrating is that it happens rarely enough to give the illusion of being stable, making it easy for PM to postpone hardening work, yet often enough to put a noticeable dent in your uptime if you don’t address it. Perfect degree of gaslighting.
- motorest 2y ago
  > To see the positive side of it, it’s a Chaos Monkey test for free. Everything you deploy must be hardened with reconnections, something you should be doing anyway. Keep in mind that in Azure it's a must-have, whereas everywhere else it's either a nice-to-have or a sign your system is broken.
- naasking 2y ago
  At that point, aren't you better off actually making your own services regularly disconnect clients so you iron out all of the reconnection bugs?
- 2y ago