[HN Gopher] Ask HN: How different is AWS/GCP/Azure in everyday work
___________________________________________________________________
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?
Author : michal_kluczek
Score : 52 points
Date : 2024-08-07 15:48 UTC (7 hours ago)
| dingosity wrote:
| 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.
| dangerboysteve wrote:
| I think this reply needs the obligatory link to Steve Yegge's
| Google Platforms Rant.
| devoutsalsa wrote:
| 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.
| ein0p wrote:
| +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.
| antonyt wrote:
| _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.
| hoofhearted wrote:
| 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.
| barkingcat wrote:
| 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).
| CapeTheory wrote:
| 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.
| CharlieDigital wrote:
| 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...
|
| https://itnext.io/aws-vs-azure-vs-google-cloud-for-saas-star...
| j45 wrote:
| Azure has the most Fortune 100-500 clients already with them as
| well I heard.
| chrisweekly wrote:
| I wonder how much of that market penetration stems directly
| from those companies being all-in with Microsoft.
| fragmede wrote:
| Is that Azure or "Azure" aka Microsoft Office 365?
| j45 wrote:
| Azure cloud
| tmsh wrote:
| 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.).
| comprev wrote:
| 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.
| swozey wrote:
| 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
| deathanatos wrote:
| (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 resume 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.)
| devonbleak wrote:
| 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.
| jauntywundrkind wrote:
| 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.
| abhiyerra wrote:
| 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.
| ecshafer wrote:
| 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.
| sam2426679 wrote:
| 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.
| nosefrog wrote:
| 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.
| Spooky23 wrote:
| Or the "I see you have a license compliance issue, buy some
| Azure credits, and all is forgiven."
| llamaLord wrote:
| 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.
| henryfjordan wrote:
| 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).
| diskopanzer wrote:
| 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.
| marmot777 wrote:
| What do people think of openstack in terms of transference of
| knowledge and skills? I realize it's not as scalable as the
| others.
| moltar wrote:
| For me AWS CDK is the biggest differentiator between AWS and
| every other cloud. Once you go true IaC there's no way back.
| greatgib wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-07 23:01 UTC)