Ask HN: How different is AWS/GCP/Azure in everyday work | Hacker News Reader

Ask HN: How different is AWS/GCP/Azure in everyday work

I've almost exclusively been working with GCP for years, with very few occasions when I've created some resources in AWS (I'm managing infra using terraform).

When looking a job now, it's very common that I'm rejected before TI because I wasn't working with AWS. Is it really so fundamentally different from GCP or any other cloud provider for that matter? I have a wild feeling that 80-90% of the products all cloud providers offer are same toys but with different names and integrations mechanisms. There are surely some quirks that are exclusive for a specific cloud provider, but is it really that many to stifle your performance?

View on HN

If you say "I barely know AWS, we mostly used GCP", that will be a turn off for anyone screening for heavy AWS experience. If you say "we use the cloud extensively & 100% of our infrastructure the made extensive use of AWS and GCP using a multi-cloud solution", you'll be fine.

A recruiter won't know the difference unless they really ask, and I seriously doubt they will.

If an engineer or engineering manager asks, ask them what problem they are trying to solve using AWS and then tell them how to solve it. If your answer is good enough, you won't have any problems.

+1. Early screening is basically just grep for the right verbiage. As a rule, recruiters are not technical. Some of your interviewers also won’t be technical, might also be worth keeping that in mind.

I have been running a DevOps agency for the last 8 years and while each Clouds basically offers the same things at this point the two things that always trip me up are networking and IAM.

Some things I noticed as I have done work on AWS, Azure and Google in terms of IAM:

  - Azure seems to have so many different types of IAM permissions it is sort of hard to get your head across each one as they seems to be imported from Azure, Active Directory, etc. 
  - Google differentiates between service accounts and user accounts which takes a bit of getting used to as each is different and the specific service policies that need to be granted are much harder to figure out than AWS.
  - AWS now has three different IAM configurations including IAM, AWS IAM Identity Center, and roles. The complication is that AWS was not built with the Google nomenclature of projects in mind so it is a weird add on that causes all sorts of weird issues.

In terms of networking:

  - AWS for me the simplest to grok but I have also been doing it for the longest so there may be a bias here. Everything is tied to a VPC. It also seems that AWS provides the lowest level primitives for networking versus the other providers which tend to abstract away quite a bit.
  - Google's VPC (i.e network) is global across all regions which is nice for data locality as you can use the same VPC and put subnets across regions.
  - Azure is similar to AWS but does seem to have a lot of hidden features that you need to read the docs to enable espcially around AKS+video streams.

IAM is the biggest miss that all of the cloud providers suck at. I think Google's is the best, but it really isn't a great experience. This seems like something that is so critical it should be rock solid and extremely clear, but too often I see things that get into these weird situation that's hard to predict exact access rules.

I’ve done lots with AWS and really only ever used GCP to configure Google SSO. I was really surprised by how much button clicking is required in GCP vs. AWS. In AWS, you create the root account, provision a service account, and then all AWS resources are managed through terraform. In GCP, you have to verify a domain via CNAME records, etc., in order to create a root account, and then manipulate the organization policy to provision the service account. While you can create the IAP brand within terraform (as long as you use the root account and not the service account), you can only externalize the brand by clicking buttons in GCP. Laughably, there is an open issue/ticket from more than a decade ago requesting a programmatic way to externalize a brand.

> Everything is tied to a VPC

bzt

Really good answer in terms of how they "feel" to use.

Just one note, since there's a design decision Google and AWS made differently that feels nice but makes availability more precarious:

> "Google's VPC (i.e network) is global across all regions which is nice for data locality as you can use the same VPC and put subnets across regions."

It's also not uncommon seeing your entire global footprint go down when there's a network plane issue.

AWS — for the longest time — was fanatical about keeping services uncoupled across regions, leading to far fewer "global" outages.

Sadly, many customers complained, wanting services to be cross region, instead of having to replicate environments across regions. Fifteen years in, AWS is accommodating, allowing you to build services that span a couple regions and go down if either region is down.

If uptime is critical to you, in AWS leverage at least 3 AZs in each of at least 2 regions, and be sure you're using region-only services or a cross-region service that's really single region with a consistency scheme. You'll stay online through most regional issues.

Also note that the three define "region" quite differently. The AWS definition generally includes a variety of availability and resilience constraints, such as at least 2 AZs with enough physical separation to survive local physical outages. Looking closely comparing across them, you'll find AWS's resilience story is more stringent, the other two are somewhat more oriented to putting a pin on the map and call things regions that may be more like single POPs (points of presence).

All that said, it's becoming "less true" in both directions, as large customers complain when any two CSPs don't work similarly. The "voice of the customer" is asking for feature parity rather than exploiting the differentiation.

From our point of view, they're still differentiated enough a firm should consider using each for what it's best at, say AWS for lego blocks, Azure for business integration, and Google for scale-out analytics feeding ML/AI. Again, each is trying to shore up what the others already have in their DNA, but it's harder to copy something when it hasn't been your in-house bread and butter or you didn't invent it.

We moved everything to Azure. Still mad about it because things in general don't work on Azure lol. Especially networking features. Avoid any feature that sounds even a little complicated to develop, because it probably doesn't work. Even basics like the CDN have showstopping bugs that Azure blames on Chrome for some reason (update an Azure blob and access it via a cdn, it will fail ~1% of the time).

I hope the DOJ investigates Azure next, because I can't believe such a garbage platform would get to 2nd place without an abuse of Microsoft's monopoly power. Specifically, using their office product monopoly to create a cloud monopoly by signing 365 discounts with customers that require all cloud services used by those customers to be on Azure.

Or the “I see you have a license compliance issue, buy some Azure credits, and all is forgiven.”

The amount of bugs in Azure that break genuinely critical parts of the workflow (like... We're talking, the ability to run a deployment on their K8's PaaS at all) which they seem to be totally fine with not fixing for long periods of time genuinely amazed me when we were trying to use them.

Or how Entra ID (Azure AD) breaks silently damn near daily and just spectacularly blows up several times per year.

Also avoid or approach with extreme caution anything that's "In Preview," which will feel like just about everything (or it did when I used Azure heavily in 2020/2021). Unless you like extremely limited documentation, unresolved GitHub issues or some of the most complicated-looking .NET exception stacks you've ever seen.

AWS: C/C++

Azure: C#

Google Cloud: TypeScript

---

GCP is by far the easiest to use, IMO. AWS is the most mature and the most "powerful" but also the most complicated. The core pieces are largely similar at a 1000 foot level, but there are a lot of differences when you look closely at the capabilities of the congruent pieces and how they are operated.

One example that really stands out for me is how AWS handles serverless containers (ECS Fargate) versus Google Cloud Run. Both nominally fit the same needs (not really because Fargate doesn't scale to 0), but because of AWS's more "legacy" platform, working with ECS Fargate is slower and more complicated (IMO) than Google Cloud Run which is literally "throw a container here and run it". AWS Copilot CLI is a way to mitigate this, but because it still fundamentally deploys CloudFormation, it always feels clunky compared to GCP.

Another example is how GCP seemingly has HTTP built-in to many of the different services. For example, in AWS, if you want a timer driven job that hits an endpoint, you'll need to send an event to a Lambda to push an HTTP request. In GCP, you'd use Cloud Task Queues, Pub/Sub, or Cloud Scheduler -- all of which support HTTP-based targets without the need to deploy a Function. Simplifies the overall design of the system, IMO.

I almost see it as a kind of second mover advantage where GCP and Azure had an opportunity to learn from AWS and build certain things more ergonomically and with less low-level finagling required to get it to cover the 90% use case.

I wrote a two part series on this specifically focused for startups:

https://itnext.io/aws-vs-azure-vs-google-cloud-for-saas-star...

Azure has the most Fortune 100-500 clients already with them as well I heard.

I wonder how much of that market penetration stems directly from those companies being all-in with Microsoft.

most of it.

Is that Azure or "Azure" aka Microsoft Office 365?

Azure cloud

There's a lot of edge cases. Since we spend so much time in this part of the tech stack compared to 10-15 years ago, I think it'd be similar to knowing Java v. C++ 10-15 years ago. There's a lot of devil in those details (what was: what's your opinion on template metaprogramming in C++? Or how do you optimize garbage collection in Java? Or do you know Effective Java v. Effective C++? -- is now, how do you deal with cold starts in AWS Lambda? How do you represent infrastructure as code in a nimble way? When you're setting up a load balancer what kind of things get stuck? How do you ensure blue/green deployments are optimal?) If this part of the stack weren't so complicated for many sets of applications would there not be companies like Vercel that attempt to abstract these layers and make a lot of money on top of that? So yes the general patterns are similar. But everything about the implementation is different. And there are smooth parts (with ML colabs etc in GCP) in one, and smooth parts in others (QuickSight, OpenSearch integration, AWS SDK once you understand the building blocks, etc.).

From my experience, Google works but service are badly finished at the edge. It is lien them being constantly in Beta, having users as beta testers. But works well enough for the most common cases.

Azure is the worst. No one in his sane mind would have a reason to go there. Seriously. Things does not work regularly without a good reason. Randomly. Even their own administration portal randomly crash, randomly fail to apply changes, consume a lot of memory in your browser. Have stupid rough edge everywhere. Like it is cloud but still you can't "migrate" a webapp install to another plan or region. Just impossible. You have to manually copy it. And by manually I mean that it is not even good at exporting a complete config like yaml or json to reload it somewhere else.

Azure as so much business just because they give free credits or pay consulting for customers to switch, and also have managed to have big corporation to sign contracts with them. The one that use office 365.

And when you are a dev or manager in such a big corp, it is easy to request a subscription with the corp account that requesting the company to contract with AWS. So you go with the flow to get the job done.

AWS is the nice in between between the 2. They have services that are rarely upgraded with better features but have a lot of services that just work correctly mostly. And administrating your account through the interface or code logic is basically guaranteed to work.

Azure works well enough when Microsoft's footing the bill!

If you have an understanding of basic computer science, full-stack development, and the type of different services required to run an app; then you should be fine if you have experience with one versus the other.

Each cloud provider has their different features and quirks, but their underlying services are pretty much the same when it comes to managed servers for computing, data storage, caching, queuing, notifications, email, network policy, etc.

Basically what I am saying is that if you have a deep understanding of AWS or GCP, what each service does, and how billing works; then it just comes down to what each provider names their service, such as RDS or S3.

If you are trying to jumpstart your career with AWS and already have a deep understanding of GCP, then watch some quick AWS cloud practitioner guides on YouTube. If you feel comfortable enough with what they are talking about, then you can go take the cloud practitioner certification test in person next week and add that certification on your resume for less than $200.

I've worked with and on GCP and with AWS for at least 15 years combined. I've worked with Azure maybe 10-15 times and am almost completely lost by its interface each time. Whether that's just inexperience or their UX I couldn't tell you. AWS has some frustrating UX. GCP is the simplest comparatively.

I don't have a real solid reason why, maybe I'm just the lack of comfort/experience but I have no interest working with any Azure environment. Maybe I just don't have / need to learn another since I can always find work using those. You will absolutely find less GCP jobs than Aws or Azure.

SRE w/ about 20 years exp in cloud/distsys/datacenters

The foundations which underpin each cloud provider are essentially the same. I've worked mostly with AWS and was thrown into Azure/GCP in $currentJob.

The learning curve was small with only really the "resource grouping" and resource-billing relationship being different.

For me, google cloud is the worst because their documentation is terrible. And i think their docs are bad because their permission system is bad.

For example, some services require more permissions than documented in the docs; those permissions are documented in some random document you have to find.

The service account thing is a prime example. WTF is it and if I already have the oauth scope granted why do I need it? Answer: because you do.

Trying to get least perm in GcP is an exercise in futolity. Once it works don't fuck with it.

In AWS the structure of permissions is generally super simple; services, actions, permissions. In AWS the magic is knowing which API calls fall under which permission. And generally the graph for your configuration is similar (and templatable).

I avoid Google Cloud at all costs because I need at least a week to get something to work with their perms. Oh, did I mention their docs suck?

I'd equate it to running RHEL Vs Ubuntu, but with the difficulty stepped up a notch or two. If you understand what is happening at a conceptual level you can change between providers and be productive - but there are going to be pitfalls which might lead you to doing things sub-optimally. For day-to-day usage I think the differences are trivial enough, but at a higher level (account Vs project setup) the differences are more pronounced.

As a predominantly AWS person looking at the others, GCP seems relatively lacking in polish but with some nice features I wish AWS would steal. Azure on the other hand looks like a shiny turd; all of the bits I expect from AWS seem to exist and are presented in a familiar way, but closer inspection reveals that I definitely don't want to get involved in using them.

The failure modes are quite different in my opinion.

While they each offer similar services and management techniques/interfaces, where an expert in AWS differ from you is when things go wrong. I'd absolutely want a person who knows AWS to handle a production failure across multiple regions and available zones - no offense to your knowledge base, but a person knowing how to recover from GCP errors is going to be out of their comfort zones in building / recovering from massive AWS failures.

It's like backups - only in the recovery do you know whether your initial backup worked. I wouldn't want to find out after the fact that an engineer I hired who had GCP experience didn't know how to design a system to recover from a catastrophic AWS error.

And these days, the cloud is just another person's computer, so errors and failures are going to happen - best be prepared.

Best way you can prepare yourself is to get some AWS experience! Spend a bit of money or use educational credits to build yourself mini clusters, and just see how to fail them, and how to interact with the management plane during an AWS outage (it's not hard to find an AWS outage - it happens on US East every few months or so).

For me AWS CDK is the biggest differentiator between AWS and every other cloud. Once you go true IaC there’s no way back.

I'm surprised that more comments aren't mentioning this. I've recently moved from a stack managed by AWS CDK to one managed by Pulumi on GCP and the difference is stark. The building blocks that AWS provides allow spinning up complex services with relatively minimal configuration. The pulumi code required to create a simple GCP cloud run service with IAP behind a load balancer is literally hundreds of lines.

Plus GCPs documentation is far far worse than AWS's.

Just want to throw out there that AWS has a lot of "free tier" offerings that are perfect for practicing in case you feel you need more experience for interviews.

EC2, RDS, ECS, ECR, SQS, Dynamo, all the big names are free for long enough to get your bearings.

I spent some time after college while I was job-hunting playing with the free tier and I think it helped a lot in interviews.

But also if you came to an interview and used the "wrong" cloud provider I would not hold that against you in the slightest unless we really really needed some specific experience for some reason (not likely).

It's similar enough. I've worked with GCP and AWS for a while. GCP, in my opinion, has a better developer experience: Cloud Run makes it super simple to deploy containers, either as services or batch jobs. AWS's equivalent service - ECS with Fargate - is a bit more complex to configure. The real quirks are in the cloud provider specific services... like DynamoDB.

I was certified in all three CSPs a few years ago. The things we do for money. :)

Not very different in the macro, from my limited experience. Lots of little differences in the micro.

I'd invest time in getting an AWS Solutions Architect Associate cert, as this will help you sound competent enough in AWS to land a job where you'll learn more about it anyway.

I have found that platforms are almost always compared to AWS as it is the most mature. Azure still doesn't have complete feature parity with AWS, and GCP doesn't yet have feature parity with Azure or AWS. So in terms of importance to know, its AWS>Azure>GCP. Not all apps need all that AWS can do, but AWS by far has the worst UX of any of them IMHO. For APIs, DigitalOcean would be the contender to beat. They have beautiful APIs.

From my experience AWS is the worst to work with. Even friends from huge software houses say that if client want AWS they know they'll need x3 resources to work with this project. Azure is slow with all actions but works and with GCP I had the best experience.

If I was hiring a full-timer to join our team, and we were an AWS shop, I would be open to hiring someone with a predominantly GCP background as long as they were really good at GCP. Because then of course they can also get good at AWS.

IMHO the recruiting side is over-indexing on very specific technologies rather than personal skills/capabilities (oh, you are a C# expert, great, mind learning Java?). To fight that you could make your resume more buzzword compliant - do a small project in AWS, write a blog post or create a YouTube or TikToc about the differences/similarities, and do a couple of certifications.

Depends on the position and appetite for re-training you. In some cases I have the luxury of being able to do something like that for the right candidate. In some cases I need someone that can more immediately be up to speed and jumping into things to add value.

More concretely, in my experience hiring folks that would be focused on working with EKS, folks that have GKE experience can mostly pick up EKS easily. Folks with AWS experience working on GCP IaaS and hybrid networking or vice versa those folks need to mostly re-learn everything because they're pretty wildly different.

Is it really so fundamentally different from GCP

No, they're all mostly the same on a fundamental level. If you're familiar with any of the big three, you're far ahead of someone who has never used public cloud before when learning a new one. Nonetheless, some employers won't want to eat the cost of getting you up to speed.

Employers I've been exposed to tend not to care which public cloud you've used, just that you're familiar with how cloud works overall.

Fundamental no but mechanically yes. GCP is more abstracted IMHO so you are in some areas "higher" level, AWS has lots of super deep stuff like all those policy configurations for IAM, etc. are VERY different. You are already ahead of the game because you are using Terraform and not vendor locked in to something like Cloudformation

As a developer? Not getting hired over this would be a red flag.

AWS is the type of thing you pick up on the job as needed.

I'd love to jump in here. Azure is easily the most unreliable frustrating and disappointing experience I have had. It has a nice UI but everything breaks, grants takes forever to propagate, and it is designed with terrible limitations. Additionally they force opt you in to many unneeded services, make it a pain to disable. They force castrate open source offerings to force you into their funnel. 10/10 bad experience. Unstable.

AWS was great but IAM needs simplification.

Mirroring what many others have said, Azure is often broken and generally frustrating to use. Performance is also often _quite bad_ and there will be frustrating network limitations based on seemingly unrelated configurations. For example, we discovered that we could nearly double the download speeds to our webservers (downloading from Azure storage even) by upgrading to a beefier SKU. This may sound reasonable on the surface, but we were seeing speeds of only ~10Mb/s, often less. Even now, we see extremely slow download speeds and it is dependent on time of day - slowest during peak business hours and faster in the dead of night. I understand network congestion, but this just seems completely absurd when we're talking about servers that both exist within the same Azure region - likely in the same DC - having worse download speeds than I get from my $5 DigitalOcean droplet to my house.

Azure storage is absolute hot garbage.

What do people think of openstack in terms of transference of knowledge and skills? I realize it’s not as scalable as the others.

(I've worked with GCP, AWS, and Azure. And reach hardware. And Rackspace. …)

> When looking a job now, it's very common that I'm rejected before TI because I wasn't working with AWS. Is it really so fundamentally different from GCP or any other cloud provider for that matter?

It's idiotic to reject someone for this reason. You should be, in the interview, getting at whether the person understands the fundamental aspects underneath the services: do you understand the basics? It'd vary depending on the service, but the basic ideas of a service translates pretty well between clouds. If you've used S3, GCS (GCP) or Blobstore (Azure) are not going to be hard to figure out for you. What's important in a hire is that they're not rigid in their mental model; when you approach a new service, you need to approach it as "vaguely like S3", but not "new service == S3". Each of them have their own quirks, as you note. But "that many to stifle your performance?" … no.

But résumé screeners looking for particular keywords do exist, unfortunately. As someone else in the thread notes, if you're in a conversation with those, and you get "Do you have experience with S3?", you're not obligated to answer the question exactly as it is posed. "I have experience with cloud-based blob-storage systems similar to S3" is a positive answer, but still truthful about the experience, and might very well satisfy the person you're talking to.

While I know all 3 major clouds now (and then some) … for each of those, I obviously could not have known it when I started the job that taught me it. Which is why it's moronic to not hire someone simply for not using that service specifically; that means nobody would ever learn that service, doubly so for costly paid clouds providers like these (this isn't some FOSS DB I can run at home on a laptop and learn). (Or more pointedly, such a company does not want to invest in training employees, and expects other companies to do that, for them, for free, and that's a red flag as to their culture, IMO.)

In the couple months I dealt with Azure I found it ridiculous & annoying that there were two subtly different auth patterns, and different services would arbitrarily accept only one or the other.

It felt like I was trying to use two totally separate clouds that happened to share the same web front-end. Incredible turn off.

But yeah, otherwise kind of just whatever, worked. What little time on spent on GCP was fine, usually felt better polished a bit but occasionally some flows would be a little surprising/unexpected or unsupported. Lots of time in AWS, it just is what it is, is ok, pretty so so web console.

I'm very curious about those auth patterns that are different. Are you talking of managed identities?

> 80-90% of the products all cloud providers offer are same toys

Yeah, but there are typical quirks, edge cases, gotchas, details where the devil hangs out. If you want, this is the surface area where you can specialize.

YMMV.

I came the other way.

I started with AWS a couple decades ago. I was lucky 'cause I worked at Amazon and there was always a friend-of-a-friend inside the organization which could put me in touch with someone who understood what the system was doing. Documentation in the early days was bad. We learned to reverse-engineer what was happening underneath the interface abstractions. Kind of a sh***y experience, but if you banged your head against the wall enough times, you were able to figure it out.

Then a whole bunch of AWS people left to go work on Azure. It's not that Azure was made exclusively of AWS people, but you can definitely see some AWS fingerprints all over Azure. The abstractions and interfaces are similar.

GCP seemed to be a different creation, exporting different abstractions. Starting with account creation. How do you create an account? AWS is pretty straight-forward. GCP has several different (undocumented) account types you have to understand before you can complete account creation. Or, you can just guess and pick one at random. AWS Lambdas (for instance) are pretty straight-forward to create. You create the lambda via a command line interface, a {java|javascript|python|c#} program or via the console. It is an entity you identify with a ARN/URI and do things to it. GCP seems to have different ways to identify GCPs (is it an index? is it a name? is it a URL? is it a URI?) and the answer to how to do things was always "you write a python program to do that." (Not so much because there was only a Python SDK, but because there were only Python code examples.)

AWS docs weren't the best in the world, but they were easy to find. And they documented the underlying objects that exported methods / abstractions to modify those objects' state. It was often mildly confusing what you were looking at (abstract, HTTP API or JavaScript SDK) but it was pretty straight-forward to work it out. Over time the AWS docs improved slowly.

Azure interfaces and docs seemed to follow AWS pretty closely.

Getting back to the GCF example. It's well known Lambdas are bits of code you write smushed into a container with the lambda runtime and deployed on a lightweight container. If you REALLY want to know, you can find out if two of the containers are running in the same VM, but you're sort of warned against it. GCF on the other hand... is it running in the same container? maybe. is it running in the same context? answer unclear. ask again later.

It seemed to me the GCF guys wanted to make things a bit more abstract and herd programmers away from assumptions that are easy to make on AWS Lambdas or Azure Functions. And I think that mentality pervades GCP; It's a bit more abstract while AWS and Azure expose more concrete interfaces (until it doesn't in which case you have to ask your TAM to find an engineer who can send you copies of the documentation about an interface they haven't documented publicly.)

It may sound like I'm down on GCP. I'm not really. But it *did* seem to "feel" very different from what I was used to over on AWS and Azure. Smart developers shouldn't have a problem moving from one to another, but when I moved from AWS to GCP, there was a month or two where I wasn't especially productive because I assumed it (GCP) behaved the same way as AWS and when I learned it didn't I had to spend time researching and recoding.

Seems like getting a no or low cost account on AWS, Azure and GCP is pretty straight-forward. Maybe doing a project on AWS and Azure to demo your mad skillz (and to learn how they're different) would be a good idea. That way you could put an AWS project on the resume and it won't be a lie.

Maybe what I'm saying is... yeah... under the hood it's all pretty similar, but the interfaces are different enough that you can take a productivity hit until you learn how they're different. As for me... if someone could demonstrate competence in one, I'm confident they could pick up the others without too much of a delay. I would eat the cost of an engineer having to read manuals and write test code to figure out a new environment if they were reasonably smart and worked well with others.

I think this reply needs the obligatory link to Steve Yegge's Google Platforms Rant.

My technical focus is on the operation of custom appliances in various (cloud) environments. Therefore, please bear in mind that I have a very limited view of the various functionalities in the cloud environment. The advantage is that I have basically performed the same task in all three environments.

tl;dr: Azure is crap, GCP is mid, AWS is best

Core problems in Azure: 1) opaque IAM policies 2) Slow, unresponsive and bloated frontend 3) Basic tasks such as reboot sometimes take forever 4) When using the azure cli tool, you have completely unusable response times, sometimes simple tasks such as adding or removing IPs to NICs take up to 3 minutes 5) Documentation mostly useless 6) Installation of some bloated Windows tools (e.g. waagent) on Linux appliances (can certainly be avoided, but is probably activated by default, known Microsoft foolishness) 7) Some Microsoft peculiarities also lead to such strange problems that the ssh login is sometimes not possible for 10-40 minutes after a restart of the sshd

I started in Azure and worked with it for about a year, then I worked with AWS for the first time and was thrilled. The syntax of the CLI tool is intuitive and the frontend reacts to CLI commands within seconds. Everything is well documented and I was able to find helpful resources for almost every error I encountered. And by helpful I mean that I had to read ONE article to solve the problem. No comparison to hours of research for any Azure problems.

Google is definitely not bad, especially things like automated network configuration were easier in my experience, but I find the front end more confusing. Overall though, the experience is comparable to AWS.

My only advice: Don't use Azure. I regularly have to suppress the urge to take a bath with my toaster after having to work with it.

Realistically speaking AWS and GCP are not that different and anyone who has 5 years experience in one can quickly pick up the other. But teams will often go with the person who has experience in the stack they use, just because it's an easier way to weed through the stack of 300 resumes. Hiring is broken mostly because of reliance on resumes.

Reply on news.ycombinator.com