Comment by wolvoleo
17 hours ago
One of the things I find about AWS is that every service UI feels different. It's like every service was designed by a totally different team.
For all its flaws at least Azure has consistent UI.
17 hours ago
One of the things I find about AWS is that every service UI feels different. It's like every service was designed by a totally different team.
For all its flaws at least Azure has consistent UI.
You need to understand history for this. It's because of the famous "Bezos API mandate memo" https://chrislaing.net/blog/the-memo/. It was 2002, nobody was doing anything close to that.
You could argue now that that's no excuse anymore given it's one of the most valuable companies in the world, but that would dismiss the fact they have other priorities than a complete UI overhaul for consistency, and that rewrites are very dangerous, for instance people are already used to the UX pitfalls in the console, it's the devil they know, and changing that will be upsetting to the vast majority of users.
So there you have it. You know what you are getting into, AWS is a behemoth and it's 2026. Don't use the console like it's 2010. Use IaC for any nontrivial work, otherwise you only have yourself to blame.
I understand how this came to pass (I didn't know it before so thanks for the insight!)
But as a customer I absolutely hate working with AWS tech. Their stuff is a mess and I feel like I shouldn't have to get my head around their idiosyncracies. I prefer Azure even though Microsoft is a terrible company to work with. I find the AWS people and attitude a lot nicer but their services are a mess. If I do something new I prefer using Azure despite having to work with Microsoft.
Microsoft is not a "trusted partner" wanting the best for you, they're always trying to screw you over in favour of selling some new crap to your boss. Always that stupid sales drive, whereas the people from AWS are very focused on building success together. But still, their tech is just so bad unless you spend all your days working with it and really become an expert on what they offer. That's not tech, just corporate servitude. And I've always avoid that position, I don't want my career tied to some big brand name. I don't want to be "the AWS expert" or "the MS expert".
But I have to say I hate cloud (and "the world according to big tech") in general, and it's one of the reasons I'm not really involved in server infrastructure anymore these days. I'll gladly automate but not with their tooling, I prefer something more open and not tied to specific vendors. But I rarely work with that now. So yeah when that happens I'm making a one-off unicorn and figuring out all the Infra as code stuff is not worth it.
I'm right there with you, don't get me wrong. Choosing a cloud provider is like choosing the lesser of many evils. We are, however, coming to a point where k8s is viable for most workloads, so it's less complex today to spin up a project with cloud mobility in mind than it was 10 years ago if you plan it right.
> It's like every service was designed by a totally different team.
Yes, by design.
Conceptually this improves velocity and reduces the blast radius of failure.
In practice, everything depends on IAM, S3, VPC, and EC2 directly or indirectly, so this doesn't help anywhere near as much as one would think.
Azure and GCP have a split control plane where there's a global register of resources, but the back-end implementations are split by team.
That way the users don't see Conway's Law manifest in the browser urls... as much. (You still do if you pay attention! In Azure the "provider type" is in the path instead of the host name.)
> Conceptually this improves velocity and reduces the blast radius of failure.
Hm yes but I hate working with it as a customer because it is so confusing. Everything works differently and there is a lot of overlap (several services exist that do the same thing). It seems like an amateurish patchwork.
I understand it has benefits to have different teams working on different services but those teams should still be aligned in terms of UX and basic concepts.