A couple of years back, I was working at Mojang (makers of Minecraft).
We got purchased by Microsoft, which of course meant we had to at least try to migrate away from AWS to Azure. On the surface, it made sense: our AWS bill was pretty steep, iirc into the 6 figures monthly, we could have Azure for free*.
Fast forward about a year, and an uncountable amount of hours spent by both my team, and Azure solutions specialists, kindly lent to us by the Azure org itself, we all agreed the six figure bill to one of corporate daddy's largest competitors would have to stay!
I've written off Azure as a viable cloud provider since then. I've always thought I would have to revaluate that stance sooner or later. Wouldn't be the first time I was wrong!
When I worked at Jet, a shopping website trying to compete with Amazon, we obviously did not want to give money to Amazon, so we used Azure.
For the most part it was just fine, until we started using CosmosDB (then called DocumentDB).
DocumentDB, in its first incarnation, was utterly terrible. The pricing was extremely hard to predict, so we would end up with ridiculous bills at the end of the week, the provided .NET SDK for it was buggy and horrible, but the very worst part was the WebUI appeared to be directly tied to your particular instance of CosmosDB.
Why is this bad? Because if you under-provisioned stuff for your database, it might start going slow, and it would actually lag the web interface you would use to increase the resources! We got into situations where we had to turn off the entire application, just to bump up the resources for Cosmos. It felt like it was a complete amateur hour from Microsoft.
My understanding is that Cosmos has gotten a lot better, but man that left a sour taste in my mouth. If I end up getting some free credits or something, maybe I'll give Azure another go but I would definitely not recommend it right now.
A team in my org worked with Jet for 2+ years to help y’all scale.
It was interesting seeing the biweekly status updates, they basically all started with “This is how Jet.com broke Azure core services this week”.
As much as it sucks, this was a deliberate strategy all the way from Satya - every employee knew Azure was a joke, but the only want to actually fix shit was to get internet scale customers to break it daily and weekly.
> My understanding is that Cosmos has gotten a lot better
For some values of "better", I guess. Performance is still terrible, their data visualization/inspection tools are shameful, their SQL dialect is finicky and has no error reporting beyond "something is wrong with the input value", and their official Python SDK has a race condition bug that can silently clear out your documents when under heavy load.
I used to work at a Cosmos-heavy house and I would utter "fucking Cosmos" around 15 times a day.
> My understanding is that Cosmos has gotten a lot better, but man that left a sour taste in my mouth.
A couple of years ago I stumbled upon a Azure project which started off using the old timey Cosmos DB. Looking at the repository history from those days, I saw a bunch of Entity Framework configurations and navigations and arcane wizardry that would take an engineer months to really figure out.
Then there was an update to CosmosSDK, and all that EF noise was replaced by single CRUD operations that took the unserialized object, id and partition key as input. That's it.
Worlds of difference, and a simple key-value query takes ~10ms to do.
> Because if you under-provisioned stuff for your database, it might start going slow, and it would actually lag the web interface you would use to increase the resources!
What the ever loving heck... seriously?! Why wouldn't this be a control plane API that reconfigures a data plane?!
Your story reminds me of when Microsoft acquired Hotmail in the '90s and they tried migrating from FreeBSD & Solaris onto Windows NT/IIS. Having the world's largest email service running on the Windows stack would have been a huge endorsement. It took years until they were successful.
The 90s were the dark ages of cloud computing. It was the age of system administrator, desktop apps, Usenet, and the start of the internet as a public service. At the time concepts such as infrastructure as code, cloud, and continuous deployment, were unheard of.
AWS, which today we take for granted, was launched on 2002, and back then it started as a way to monetize Amazon's existing shared IT platform.
Of course migrating anything back then was a world of pain, specially when it's servers running on different OSes. It's like the rewrite from hell, that can even cover the OS layer. Of course it takes years.
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.
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.
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?
I literally cannot log in to it after it was forcefully migrated to Microsoft. Microsoft doesn't recognize my computer as not-a-bot. Something to do with being Linux, I imagine.
Oh you guys finally managed!? Cool to hear! I guess Azure must've gotten better then, back when I was there, the conclusion was that Azure simply wasn't mature enough to host Minecraft yet.
Again, this is a while ago: I remember when I started we were just starting to replace the old yggdrasil servers with the new micronaut based system which I think is still in use today?
I still remember that application fondly as the best architectured piece of software I've ever worked on. I hope all is well!
is it because there are features that AWS provides to you that are not available in GCP, or just the fact that setting up exact replicas of processes is hard for migrations like these?
That highly depends on what services your're using.
We migrated from AWS to GCP in 2016/2017 (mostly VMs and related stuff, CloudFront, etc - no lambdas) and it was pretty painless and everything worked smoothly until the end of that company.
Yep, sounds like my experience. Years ago, we migrated of Rackspace to Azure, but the database latency was diabolical. In the end, we got better performance by pointing the Azure web servers to the old database that was still in Rackspace than we did trying to use the database that was supposedly in the same data centre.
I kicked up a stink and we migrated everything to AWS in under a week.
When my day job used Azure we had the misfortune of using their managed Postgres instance, the latency of which was _appalling_.
We raised support tickets, which were mostly closed to the tune of “seems fine to us”. They seemed to think 20-30ms for a basic Postgres query, which for the same schema, data and hardware was <7ms on RDS.
Interesting, because until now I have the same opinion in reverse.
Each case is a special case how everything gets configured, but between Azure, GCP, AWS and IBM clouds, the ones with smoother experience on my case, have been on Azure, based on Java and .NET technologies.
And we also have our share of support tickets across all of them.
Now Azure back in its early days, 2010 - 2016 was kind of ruff, maybe this is the timeframe you're referring to?
> Fast forward about a year, and an uncountable amount of hours spent by both my team, and Azure solutions specialists, kindly lent to us by the Azure org itself, we all agreed the six figure bill to one of corporate daddy's largest competitors would have to stay!
Being tied to AWS and being unable to shake off a huge bill is not a trait of its competitors. It's a trait of AWS, and stresses the importance of not picking them as your cloud provider.
Also, I think it's unbelievable that a monthly 6-figure invoice charged to a company already with cloud engineers in their payroll is not justification enough to shift their workload elsewhere.
Low 6 figures is just a dev. If a team of 5 devs has to work on the problem for 5 years, then it will pay for itself in 25 years. Likely beyond any planning horizon of a company with yearly performance evaluation cycles.
Do you think it would be any different/better if you had to migrate to GCP (for example)?
Do you think it was the migration itself or the services on Azure?
Having worked with all three, there's certainly things that suck about all of them but I've found aws "most reliable" but also seems to have a large amount of disparate services needed to do things that were simpler on Azure.
GCP was pretty meh, but depends on what services you used.
Azure is a good choice for .net and sql server (azure sql or whatever it is now) but in but sure a service built for aws is going to "just work" on Azure (or vice versa).
after using AWS and Azure extensively AWS seems to be quite well engineered by some very smart people. The isolation between regions is extremely good and the Availability Zone model is quite effective in making very reliable systems if you are willing to pay the cost of inter-AZ data transfer. My company has an Active Directory controller in 3 different AZs
Azure is a mess designed by smart people with no time and little budget. Azure flat out lies about the AZs they have by claiming two halved of one data center is two AZs
That's okay, Microsoft will rename it to something else and completely change the admin UI and APIs next week. It will now be called Dynamics CoPilot OneAI 365 for Business OneCloud.
We frequently joke that it is reasonable to assume that all MS Executives actually rename their own children (at least once) as soon as the child reaches an age of two years.
And I'm really feeling all this right now, helping someone with something that is now completely different than how it was three months ago, and does not match any documentation that shows up in search results, though I'm sure there's a link to the actuall correct KB article that is only mentioned once in a forum post. At least I get to bill for this work.
In my experience (worked for organizations that used everything from on-prem server racks, to Linode to AWS to Azure), complaints about cloud infrastructure are proportional to managed service usage. I rarely hear teams that largely rely on virtual machines (perhaps with a managed RDBMS) complain. They do have to maintain a little extra scripting, but that's a minor inconvenience compared to battling issues and idiosyncrasies of managed services.
I'm sure it's gotten better now but back in 2016 provisioning VMs in Azure took so long that we joked that every time you provision an instance a Microsoft engineer gets in a car to buy the server.
Reminds me of how my Swiss bank doesn't support transfers outside business hours. I have to imagine when I click "send" in the UBS app, some guy named Hans-Ueli receives a tape printout and goes into the basement to move some silver pieces from one drawer to another.
It's okay. We are forced ( by our client, who has forgotten to update it's it since 2005 ) to start several clients in a pipeline. Startup is less than a minute, going from zero to a full resource group with two VMS and ancillary resources.
If everyone in this thread shitting on Azure is going off how it worked in 2016 the comments here make a lot more sense. I know Microsoft bad still lingers in online communities but I have to say I’m surprised hackernews is still this anti Microsoft. In my experience, both Azure and AWS have their issues, it’s not like AWS is some perfect offering but you’d think that based on the comments.
I'm a little confused by this post. Obviously it's easier to maintain a plain VM than managed services. That's why people are paying a lot more money to the cloud providers for managed services, so they don't have to do it themselves. What you're saying is that this is essentially a pointless endeavor? I don't think this statement is entirely uncontroversial, since managed services are the main reason for many companies to migrate to cloud.
Using managed services is not a pointless endeavor – they can save you a lot of time (and therefore money).
Unless you need to switch providers, at which point it may take more time to adjust for differences in how those managed services operate.
Managed services are absolutely not the main reason for moving to the cloud. Companies do it for the flexibility that comes with renting the real estate/energy/hardware instead of owning it.
I've never seen a managed IaaS that saved time. It is marketed as something that can free you from hiring ops people, but you will absolutely need to hire some supplier relations people to deal with it. (And contract optimizers, and internal PR to deal with the fallout.)
It's different for fully featured SaaS. It's a matter of the abstracted complexity vs. interface complexity ratio that is so common for everything you do in software.
It's easier for the provider to maintain a VM provision. It's supposed to be easier for the customer to maintain managed services, but that's often debatable.
cloud services are great when they work. but in case something isn't you have no way to debug anything except maybe restarting the service if it's even possible.
we had one customer that needed IPsec tunel to vpc where production servers were living, we didn't want to maintain such setup just for single customer so we check Aws offerings. and look at that they have managed IPsec solution, great.
until client called that tunel is down and solution wa that they need to restart it on their end to resume connection. why? you can enable some logging to S3 but according to them everything should work. what we should do next?
but even if you stick to just ec2 thing can go weird. our recent incident: ec2 instance stopped responding but ASG didn't replace it, any action on it throwers error that instance is not running but it was in running state.
I wish I could better help my org see that. Luckily my boss agrees with me, but he's not in full control. Between the vendor lock-in, and the _almost but not quite api compatibility_ with OSS... I just dread as more teams adopt it.
Azure's anti competitive conduct is also the reason that AWS stopped lowering prices.
Before 2014 or so, AWS would periodically reduce prices on major services passing on falling technology costs.
Azure didn't like that, so they aligned their prices to AWS's, matching immediately the same discounts on the same service.
This is a form a predatory pricing, because the goal is to kill the incentive for competitors to reduce prices, by denying them market share gains when they do.
I really wanted to like Azure because of how well it integrated with the rest of my tools, but I kept getting hit with VM availability limitations and UX quirks. I've never had issues getting machines in AWS, or feeling like my actions were taking effect.
I've also waffled several times on the Azure FaaS offering. I am now firmly and irrevocably at "Don't use it. Run away. Quickly.". The experience around Azure Functions is just too weird to get comfortable with. Getting at logs or other binary artifacts is a gigantic pain in the ass. Running a self-contained .NET build on a blank windows/linux VM is so easy it doesn't make sense to get in bed with all this extra complexity.
Ugh, yes. Lack if availability of resources in whichever region i happen to need them.
Also, things that break automation, like calling back to say your sql server is up and running when in fact it’s not ready for another 20 minutes. I am half sure the terraform time_sleep was written specifically to counter azure problems.
You missed the perfect middle ground between serverless and mouse-configuring an IIS VM: Azure App Services. It's the same service function apps are using once they advance beyond the trivial function and require longer runtimes or no spinup delay.
App Services takes some getting used to, but it's a locked down Win Server/IIS container with built in FTPS, self-healing healthcheck endpoints, deployment by pointing to a repository, auto-scaling options, and a 99.95 SLA.
A few years back, it was a bit of a dog performance-wise, but the modern CPUs have been no problem for a 2+ vCPU, Premium level SKU. Pricier than a VM, but dealing with security and updates for a webserver VM is a ton of work.
We bought a company hosting on Azure. They used hosted Postgres and are hosting .NET services on Windows. Small infra, in range of 2-3 hundreds cores and 1T memory.
Every few days M$ randomly shuts down random instances for maintenance, disconnects network for >10 minutes.
Migrated off hosted Postgres because performance was tragedy - now their India-based expert led us to use different volumes type and after instance restart database didn’t start up because of I/O latency. Expert don’t want to meet for 3 straight days now, because he is busy. RCA (half pager, written probably by some LLM) says it’s not their fault, but charts says different story.
The only thing they crash GCP and AWS with is dashboard that loads everything so quickly... sad you can’t run e.g. making 2 similar network operations in parallel because they will fail or take 10x the time they would take when run one after another.
Of all the paas providers Azure have the worst abstractions and services.
In general I think it’s sad that most buy in to consuming these ”weird” services and that there’s jobs to be had as cloud architects and specialists.
It feeds bad design and loose threads as partners have to be kept relevant.
This is my take on the whole enterprise IT field though!
At my little shop of 30 so developers, we inherited an Azure mess, built abstractions for the services we need in a more ”industry standard” way in our dev tooling, and moved to Hetzner after a couple of years.
A developer here knows no different, basically - our tooling deals with our workflows and service abstractions, and these shouldn’t change just because new provider.
1/10-th of the monthly bill, and money partly spent on building the best DX one can imagine.
Great trade-off, IMO!
Only two cases come to mind for using big cloud:
- really small scale: mvp style
- massive global distribution with elasticity requirements.
Two outliers looking at the vast majority of companies out there.
I believe any Azure user might be able to compile their 100 reasons to not use Azure, and the same will be true for most big pieces of software.
Even as someone that had minimal exposure to other clouds, I could easily see how Azure user experience lags due to the lack of proper care.
The amount of pages with a filter bar that will not work properly until you remember to click the load more should clearly be zero at this point, this is an objectively bad pattern that existed for years and should be "easy" to fix. But the issue will probably never be prioritized.
The fact is that unless tackling those issues are part of the organization core values or that they are clearly hitting their revenue stream, they won't be fixed. Publicity and visibility of those issues will always be crucial for the community of users.
I work in both AWS and Azure and let me tell you, one thing I absolutely love about Azure is their portal. It’s like AWS 2.0 where all the cloud cruft is abstracted away and all that is left is the knobs you actually need to turn, and how they relate to one another.
I love me some AWS, but my god every time I have to dive into an unfamiliar environment and try and reverse engineer how everything connects - I need a drink afterwards.
I’m having a really hard time believing you are serious. The one time I tried out azure for a few days the portal was absolutely painful. Every click would take 5-10 seconds for a response. Sometimes basic settings change actions would take 2+ minutes of watching an Ajax spinner. How can anyone enjoy working like that???
Sure, the UI is sluggish, but at least you don't have to move through three different "services" to find the routing table that your VM is using.
AWS UIs are generally snappy and smartly designed individually, but they are horrendously organized at the general level. AWS is built as if you are exploring a relational DB containing your resources, instead of a deployment tree.
Your VM doesn't have a NIC in AWS, it has a foreign key to your entire VPC's NIC table, which lives in the VPC service, not the EC2 service. And then your NIC doesn't have an associated subnet, it has a foreign key to the subnet. And then when you get to the subnet table, you look up the routing tables table, and finally in the routing tables table, you'll find the settings for the routing table. This all works through following links, but the constant context switching and tabs upon tabs that AWS UI requires are extremely unpleasant for me at least to use. I'll take Azure's sluggish UI that organizes all of this in one-two pages instead of four any day.
I think OP is trying to differentiate between Azure APIs, which are unbelievably slow and horrible, and the UI design itself - the layout, the font, how one screen will flow to another screen, what links to what, how it would be laid out in a tool like Figma.
Azure's APIs are atrociously slow. Azure's UI design is pretty nice. There's not much the UI designers can do about their API colleagues.
must be a paid troll, no self respecting intelligent engineer would find the Azure portal good. it’s horrible ux, really convoluted and complicated, very unintuitive, horizontal scroll is a joke when the web scrolls vertically, tiny fonts making everything hard to read and screens overloaded with so much shit and yet they managed to not put on the screen the main thing that developers would care about. it’s a complete joke
I know we're talking about AWS and Azure here, but had to add that fwiw, the M365 admin interface(s) are so bad it practically feels like a prank. In other words, it's as though someone is purposely making them as chaotic as possible to what end I can't even guess.
This comment reads like rage bait (I am not saying your opinion is "invalid" or you're lying). I've never meant anyone who likes the Azure portal lol, even people who live inside of the Azure ecosystem hour by hour.
The Azure portal has some nice ideas - in theory, being able to divide stuff into "resource groups" works a lot better than the AWS approach of "divide resources that should be isolated from each other into separate sub-accounts".
In practise, even the good ideas are implemented poorly.
My experience too, I could never find anything even if I know it's there, and I was told by my boss to use it. I stand there for a half hour, credit card in hand, then go to AWS where the equivalent can be located by mortals. It's like they don't want anyone's business.
Yeah I don’t get this thread at all. I’ve used both fairly extensively and while Azure’s dashboard is still a pain in the ass, it’s better than AWS by a mile usability wise. Not to mention, Microsoft clearly puts time and money into their documentation, while AWS docs have always sucked.
>> Microsoft clearly puts time and money into their documentation
I am quite surprised to hear someone say this. MS documentation has a horrible reputation that is well-deserved and and in my direct experience the docs for Azure are much like any other MS docs (incomplete, out-of-date and poorly organized -- usually all three at once)
this has been consistent with my experience. the top down hierarchical approach in azure is unmatched in aws to this day. an aws accountnis a loose connection of resources across regions. if youre in an unfamilar account, youll spend some time really figuring out where everything lives first.
Readit News
A couple of years back, I was working at Mojang (makers of Minecraft).
We got purchased by Microsoft, which of course meant we had to at least try to migrate away from AWS to Azure. On the surface, it made sense: our AWS bill was pretty steep, iirc into the 6 figures monthly, we could have Azure for free*.
Fast forward about a year, and an uncountable amount of hours spent by both my team, and Azure solutions specialists, kindly lent to us by the Azure org itself, we all agreed the six figure bill to one of corporate daddy's largest competitors would have to stay!
I've written off Azure as a viable cloud provider since then. I've always thought I would have to revaluate that stance sooner or later. Wouldn't be the first time I was wrong!
For the most part it was just fine, until we started using CosmosDB (then called DocumentDB).
DocumentDB, in its first incarnation, was utterly terrible. The pricing was extremely hard to predict, so we would end up with ridiculous bills at the end of the week, the provided .NET SDK for it was buggy and horrible, but the very worst part was the WebUI appeared to be directly tied to your particular instance of CosmosDB.
Why is this bad? Because if you under-provisioned stuff for your database, it might start going slow, and it would actually lag the web interface you would use to increase the resources! We got into situations where we had to turn off the entire application, just to bump up the resources for Cosmos. It felt like it was a complete amateur hour from Microsoft.
My understanding is that Cosmos has gotten a lot better, but man that left a sour taste in my mouth. If I end up getting some free credits or something, maybe I'll give Azure another go but I would definitely not recommend it right now.
It was interesting seeing the biweekly status updates, they basically all started with “This is how Jet.com broke Azure core services this week”.
As much as it sucks, this was a deliberate strategy all the way from Satya - every employee knew Azure was a joke, but the only want to actually fix shit was to get internet scale customers to break it daily and weekly.
For some values of "better", I guess. Performance is still terrible, their data visualization/inspection tools are shameful, their SQL dialect is finicky and has no error reporting beyond "something is wrong with the input value", and their official Python SDK has a race condition bug that can silently clear out your documents when under heavy load.
I used to work at a Cosmos-heavy house and I would utter "fucking Cosmos" around 15 times a day.
A couple of years ago I stumbled upon a Azure project which started off using the old timey Cosmos DB. Looking at the repository history from those days, I saw a bunch of Entity Framework configurations and navigations and arcane wizardry that would take an engineer months to really figure out.
Then there was an update to CosmosSDK, and all that EF noise was replaced by single CRUD operations that took the unserialized object, id and partition key as input. That's it.
Worlds of difference, and a simple key-value query takes ~10ms to do.
Yes, it's worlds of difference.
What the ever loving heck... seriously?! Why wouldn't this be a control plane API that reconfigures a data plane?!
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
The 90s were the dark ages of cloud computing. It was the age of system administrator, desktop apps, Usenet, and the start of the internet as a public service. At the time concepts such as infrastructure as code, cloud, and continuous deployment, were unheard of.
AWS, which today we take for granted, was launched on 2002, and back then it started as a way to monetize Amazon's existing shared IT platform.
Of course migrating anything back then was a world of pain, specially when it's servers running on different OSes. It's like the rewrite from hell, that can even cover the OS layer. Of course it takes years.
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.
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?
Some more game-oriented technologies of course have helped in the years since though.
Edit: AWS -> Azure :)
Can I have my Mojang account back?
I literally cannot log in to it after it was forcefully migrated to Microsoft. Microsoft doesn't recognize my computer as not-a-bot. Something to do with being Linux, I imagine.
Or, can I get a refund?
Again, this is a while ago: I remember when I started we were just starting to replace the old yggdrasil servers with the new micronaut based system which I think is still in use today?
I still remember that application fondly as the best architectured piece of software I've ever worked on. I hope all is well!
Did you mean Azure?
We migrated from AWS to GCP in 2016/2017 (mostly VMs and related stuff, CloudFront, etc - no lambdas) and it was pretty painless and everything worked smoothly until the end of that company.
I kicked up a stink and we migrated everything to AWS in under a week.
We raised support tickets, which were mostly closed to the tune of “seems fine to us”. They seemed to think 20-30ms for a basic Postgres query, which for the same schema, data and hardware was <7ms on RDS.
Each case is a special case how everything gets configured, but between Azure, GCP, AWS and IBM clouds, the ones with smoother experience on my case, have been on Azure, based on Java and .NET technologies.
And we also have our share of support tickets across all of them.
Now Azure back in its early days, 2010 - 2016 was kind of ruff, maybe this is the timeframe you're referring to?
Being tied to AWS and being unable to shake off a huge bill is not a trait of its competitors. It's a trait of AWS, and stresses the importance of not picking them as your cloud provider.
Also, I think it's unbelievable that a monthly 6-figure invoice charged to a company already with cloud engineers in their payroll is not justification enough to shift their workload elsewhere.
Do you think it was the migration itself or the services on Azure?
Having worked with all three, there's certainly things that suck about all of them but I've found aws "most reliable" but also seems to have a large amount of disparate services needed to do things that were simpler on Azure.
GCP was pretty meh, but depends on what services you used.
Azure is a good choice for .net and sql server (azure sql or whatever it is now) but in but sure a service built for aws is going to "just work" on Azure (or vice versa).
Azure is a mess designed by smart people with no time and little budget. Azure flat out lies about the AZs they have by claiming two halved of one data center is two AZs
it was around 2007 (I'm not that old!)
> Founded in 1996 by Sabeer Bhatia and Jack Smith as Hotmail, it was acquired by Microsoft in 1997 for an estimated $400 million
Wrong decade, they really did acquire Hotmail in the 90's.
But the documentation and every other reference to it will retain the old name.
Unless you need to switch providers, at which point it may take more time to adjust for differences in how those managed services operate.
Managed services are absolutely not the main reason for moving to the cloud. Companies do it for the flexibility that comes with renting the real estate/energy/hardware instead of owning it.
It's different for fully featured SaaS. It's a matter of the abstracted complexity vs. interface complexity ratio that is so common for everything you do in software.
we had one customer that needed IPsec tunel to vpc where production servers were living, we didn't want to maintain such setup just for single customer so we check Aws offerings. and look at that they have managed IPsec solution, great.
until client called that tunel is down and solution wa that they need to restart it on their end to resume connection. why? you can enable some logging to S3 but according to them everything should work. what we should do next?
but even if you stick to just ec2 thing can go weird. our recent incident: ec2 instance stopped responding but ASG didn't replace it, any action on it throwers error that instance is not running but it was in running state.
"But it's easier!" ... yeah, we'll see...
Before 2014 or so, AWS would periodically reduce prices on major services passing on falling technology costs.
Azure didn't like that, so they aligned their prices to AWS's, matching immediately the same discounts on the same service.
This is a form a predatory pricing, because the goal is to kill the incentive for competitors to reduce prices, by denying them market share gains when they do.
I've also waffled several times on the Azure FaaS offering. I am now firmly and irrevocably at "Don't use it. Run away. Quickly.". The experience around Azure Functions is just too weird to get comfortable with. Getting at logs or other binary artifacts is a gigantic pain in the ass. Running a self-contained .NET build on a blank windows/linux VM is so easy it doesn't make sense to get in bed with all this extra complexity.
Also, things that break automation, like calling back to say your sql server is up and running when in fact it’s not ready for another 20 minutes. I am half sure the terraform time_sleep was written specifically to counter azure problems.
App Services takes some getting used to, but it's a locked down Win Server/IIS container with built in FTPS, self-healing healthcheck endpoints, deployment by pointing to a repository, auto-scaling options, and a 99.95 SLA.
A few years back, it was a bit of a dog performance-wise, but the modern CPUs have been no problem for a 2+ vCPU, Premium level SKU. Pricier than a VM, but dealing with security and updates for a webserver VM is a ton of work.
But the Windows containers have more features. I stuck with them for quite a number of websites.
Significantly cheaper than a VM as you noted just based on maintenance that would otherwise be required.
Migrated off hosted Postgres because performance was tragedy - now their India-based expert led us to use different volumes type and after instance restart database didn’t start up because of I/O latency. Expert don’t want to meet for 3 straight days now, because he is busy. RCA (half pager, written probably by some LLM) says it’s not their fault, but charts says different story.
The only thing they crash GCP and AWS with is dashboard that loads everything so quickly... sad you can’t run e.g. making 2 similar network operations in parallel because they will fail or take 10x the time they would take when run one after another.
Run, don’t use.
In general I think it’s sad that most buy in to consuming these ”weird” services and that there’s jobs to be had as cloud architects and specialists. It feeds bad design and loose threads as partners have to be kept relevant.
This is my take on the whole enterprise IT field though!
At my little shop of 30 so developers, we inherited an Azure mess, built abstractions for the services we need in a more ”industry standard” way in our dev tooling, and moved to Hetzner after a couple of years.
A developer here knows no different, basically - our tooling deals with our workflows and service abstractions, and these shouldn’t change just because new provider.
1/10-th of the monthly bill, and money partly spent on building the best DX one can imagine.
Great trade-off, IMO!
Only two cases come to mind for using big cloud:
- really small scale: mvp style
- massive global distribution with elasticity requirements.
Two outliers looking at the vast majority of companies out there.
Even as someone that had minimal exposure to other clouds, I could easily see how Azure user experience lags due to the lack of proper care.
The amount of pages with a filter bar that will not work properly until you remember to click the load more should clearly be zero at this point, this is an objectively bad pattern that existed for years and should be "easy" to fix. But the issue will probably never be prioritized.
The fact is that unless tackling those issues are part of the organization core values or that they are clearly hitting their revenue stream, they won't be fixed. Publicity and visibility of those issues will always be crucial for the community of users.
I love me some AWS, but my god every time I have to dive into an unfamiliar environment and try and reverse engineer how everything connects - I need a drink afterwards.
AWS UIs are generally snappy and smartly designed individually, but they are horrendously organized at the general level. AWS is built as if you are exploring a relational DB containing your resources, instead of a deployment tree.
Your VM doesn't have a NIC in AWS, it has a foreign key to your entire VPC's NIC table, which lives in the VPC service, not the EC2 service. And then your NIC doesn't have an associated subnet, it has a foreign key to the subnet. And then when you get to the subnet table, you look up the routing tables table, and finally in the routing tables table, you'll find the settings for the routing table. This all works through following links, but the constant context switching and tabs upon tabs that AWS UI requires are extremely unpleasant for me at least to use. I'll take Azure's sluggish UI that organizes all of this in one-two pages instead of four any day.
and
> The one time I tried out azure for a few days the portal was absolutely painful.
conflict with each other. Here's what you sound like:
"I don't believe you because I have very little experience in something and it doesn't comport with that."
Azure's APIs are atrociously slow. Azure's UI design is pretty nice. There's not much the UI designers can do about their API colleagues.
In practise, even the good ideas are implemented poorly.
I am quite surprised to hear someone say this. MS documentation has a horrible reputation that is well-deserved and and in my direct experience the docs for Azure are much like any other MS docs (incomplete, out-of-date and poorly organized -- usually all three at once)