Comparing AWS, GCP and Azure: 10 Analogies in Plain English
NOTE: This is a transcript of my latest YouTube walk-thru-the-woods, in which I compare the top 3 cloud providers. If you’re not the reading type, you can see it here.
———————
Good morning. So this morning we're gonna do a comparison of the three major cloud providers. That's Amazon's AWS, Google's GCP, and Microsoft Azure. And you know what? Let's just kick it off.
We're gonna do it all with analogies, 10 of them.
Analogy #10: faster horses. It's a, it's a quote we've all heard attributed to Henry Ford that he never actually said. You know, "If I had asked people what they wanted, they would've said faster horses."
It's a quote used by everyone who has ever written anything about innovation, and I actually love it for all the wrong reasons. I love it because some clever writer-- not Henry Ford-- came up with it only to learn that the super-rich can also rob you after death through misattribution. [Meh-Heh.]
So what does the faster horses analogy have to do with the cloud?
Every company in the world is at an inflection point. Do they stick with their horses, their traditional software delivery methods, their traditional investments in building and maintaining data centers? Or do they purchase a Model T? Henry Ford's first mass-produced car.
Nearly every startup now begins its life as cloud-native because it's easy and fast when you start with nothing. And almost every reputable company of any size really is at least dabbling in the cloud.
And while this faster horses analogy doesn't help you differentiate between the top three providers, I started with it because it does help you to differentiate between them and your old way of building and deploying tech.
I'm not even talking engineering CI/CD, pipeline automation. CI/CD stands for continuous integration, continuous delivery. Essentially continuous deployment is what it really stands for. It's an acronym in in engineering, but put engineering aside, I'm I'm talking politics.
How does that differentiation, this faster horses analogy, play out in the real world? Well, if a large public company's leadership, their CEO. CIO, etc..., needs to signal to their clients or their investors that they're tech forward, innovative, fast moving, making seemingly substantive investments in their tech footprint, then the cloud is an easy signal.
Not because it's actually substantive. We, we'll get into that. Not because it's necessarily cost effective. We'll get to that too, and definitely not because it's easy to migrate to the cloud. It's not. Full stop. It's an easy signal because clients and some investors, have in large part bought into the narrative that the cloud is the future.
I don't blame them. It lacks a little tech sophistication and depth, but I also don't expect non-technical laypeople to understand the meaning of data ingress and egress. Google those words if you don't know what I'm talking about. The cloud had its moment in the sun and that moment was long enough that it picked up political credibility. Recognizing that is a good start.
It's no longer in the media buzz hype cycle unless someone calls it, CloudGPT which means that it got over the hump of shiny new object and is now more of a boring utility.
Okay, analogy #9: the apple and the tree.
If you're not familiar with the expression the apple doesn't fall far from the tree, it's often used to describe how children tend to inherit the characteristics of their parents. You know, the good ones. Most people don't apply biological metaphors to business, but one of my favorite books of all time really is Geoffrey West's Scale. The full title is Scale: The Universal Laws of Life, Growth, and Death in Organisms, Cities, and companies.
So I tend to think about companies as though they're living organisms. That if you look at their cultures, you'll see striking similarities between the parent and the child. And it doesn't even have to be between the, the parent company and the child company like Amazon-AWS. It can be between the parents' culture and the products that they're producing and the philosophy underneath it.
Anyway, let's apply the analogy. AWS is a child of Amazon who has always, as a parent, wanted to be the "Everything Store." it's right on their logo, that little arrow between A and the Z. And if it's in AWS's DNA and it is, they're going to offer the broadest selection of software and hardware options and services. They do.
That's the everything in in everything for everyone. As for the everyone part, AWS is also like its parent in that it offers the widest support in terms of industries, advertising and automotive-- the A's-- to consumer packaged goods, education, energy. Their support is alphabetical all the way down to telecom and travel.
If there were an industry out there started with a Z, like the zoological industry, they'd support it. The catch is that AWS has a ton of customers of every size. That's the W in AWS-- stands for web-- and most AWS clients are small to mid-size companies, which means that the aspects of Amazon's culture like customer centricity-- they're known for that-- well, that poses a interesting scalability challenge, right? AWS has some 200+ services and new services are created regularly and released early so client feedback can help shape it. By the way, I feel obligated to say that the listening to clients' part is, it's not exclusive to Amazon and AWS, but what their agility is. They grew up with the idea of two pizza teams and they deserve the credit.
Anyway next: Microsoft Azure's parent. The king of, would you like fries with that? They're deeply embedded in almost every enterprise from brands everyone knows like Outlook and Excel to services that only nerds know, like Active Directory (AD), which if you're not a nerd, is why Microsoft will always own identity.
Microsoft, the elder grew up culturally learning how to leverage their size and weight. The old Microsoft went so far is to be anti-competitive, and I say the old Microsoft because it's, it's a new Microsoft now. And their strategy will never fully shake how Grandpa ran it. Azure, the child is never going to have the breadth or depth of services that AWS has, but Microsoft knows its enterprise clients better than AWS ever will.
So their sales pitch will correctly identify that you're eating a hamburger and you know, would you like fries with that? And finally GCP (not S) a child of Google. The parents got super rich early, decided to buy every PhD on the market without realizing that narrow specialization makes them the best of the fewest number of things.
So if AWS is, is the A to Z and Azure is any letter that pairs well with what we've already sold you. Then GCP (I blame the S on sunstroke) is an amazing letter q, an unbelievable letter W. You get the point. They-- like their parents-- do data and analytics better than everyone else. Plus they have the cool factor politically.
Amazon is respected in the enterprise. The image of the Agile entrepreneur. Microsoft is seen as, you know, wearing Dad jeans proud of their dad bod, but Google is quiet luxury.
Okay, next analogy #8: any color as long as it's black. Another Henry Ford gem. The actual quote from Ford's co-written "autobiography." Yeah... "co-written" is rich-person-speak for "biography." The quote: "any customer can have a car painted any color that he wants, as long as it's black." We've all heard the quote. My guess is that that line was Ford's standard joke at dinner parties. My other guess is it always got laughter cuz you know, power.
So which of the three players is the black Model T? AWS. Not from a feature function standpoint. Mind you. They're A to Z. We covered that. They're the black Model T because you take what they give you and you don't complain. AWS lawyers are notoriously honey badgers. They just don't give a shit. To be fair, they can't change their terms and conditions, you know, for every, everyone on the planet. If they changed it for every company that wants their special legal terms, AWS couldn't offer A to Z at the prices that they do. Take banking as an example. Right. Does AWS want their business? Absolutely. And every bank grew up with expensive white shoe lawyers that forced indemnification clauses on every vendor. They could swing that-- you know-- "power" around because banking tech vendors were dependent on them to survive. Not so much with AWS. It's actually kind of funny to watch the interactions between banking lawyers and AWS lawyers-- complete honey badges. Yeah. Don't waste our time. We're not changing our terms. We'll probably own you in 10 years.
It's refreshing, actually.
Compare that to Microsoft's-- you know-- enterprise lawyers: chummy, friendly. We'll bend over backwards for you. Azure's not a black Model T if we're gonna talk about Microsoft, it offers probably like the six most popular colors that year. Just enough superficial variability to make their customers feel special.
You know, like, oh, we pick the red Model T cuz it's faster. Mm. Neh. And that's the two.... Oh, GCP. There's GCP, which asks the age old question, do you even need a car or do you need this amazing muffler? It isn't just silent, it pumps out magic. Plus, we're cool.
Okay, moving on. Analogy #7: crack monopolies.
Ask any reputable drug dealer and they'll tell you: there's no point in reducing the price of crack once you've cornered the market. There's a whole tribe of cloud specialists who want to protect you from future monopolistic practices. Mind you, AWS has reduced prices 150 times since its launch. In 2006. Their crack's been getting cheaper.
Microsoft's a funny one on this. They're a lot like IBM used to be. There's something called an MSA, a master services agreement. Think of it less like a contract-- which is what it is-- and more like a thick book of all your now free choices at their buffet. Microsoft dominates in the enterprise because they're fast and loose with their MSAs.
If you're not using something in there on page 37, they'll remove it and replace it with something that you're mildly interested in. The drug analogy here is that they're a gateway drug or they hope to be. Their fingers are crossed that you'll get so hooked on pot, that you'll move on to cocaine, which you know, comes from a Dad's understanding of drugs.
Microsoft would be happy to sell crack, by the way. They just don't have any, if, if you don't believe me, check out how much they paid for ChatGPT the latest crack. Which by the way, stops being cool when your dad's selling it.
And then there's Google. They don't sell crack, but their meth is blue.
Before we jump from all these drug analogies, let me acknowledge a couple more things for all the people who are advising you to skate to a multi-cloud strategy, and if you don't know what that is, it's, it's when you design software, so it's intentionally agnostic to which cloud it sits on. Don't buy the multi-cloud rhetoric when you-- when someone you know starts to talk multi-cloud because of potential price gouging that might come from a monopolistic practice in the future, remind them that we never needed to do that pre-cloud when there were monopolistic practices are plenty. 10 years ago, if you were in the market for a CRM, you wouldn't think "Geez, what if Salesforce figures out that I'm addicted and raises their prices? Let's also buy Microsoft Dynamics. That'll show them." Here's a trite truism about the software business: it's all about continuous rebirth, reinvestment. Got something that's three years old? Time to replace it. Software is dead. Long lift software.
So here's my prediction on your need to be cloud agnostic. We'll never get down to one cloud provider because as Microsoft has so fondly learned, there will always be adjacent sales to the cloud.
It's never about the hamburger. It's about upselling the fries. And the apple pie. All cloud providers get that. That's why IBM and Oracle and your Uncle Bob are all offering cloud services. They know they can't compete feature for feature with the big three, but they have fries to sell.
We need more food analogies in the world.
Oh, here's another one.
Analogy #6. Over time, all cookies will taste like Oreos. That's my way of saying that all companies are client-centric. It's not just Amazon and all client needs-- over time-- are the same. You know, the, it's Juneteenth today. So I've been thinking about that MLK quote about "the arc of the moral universe is long, but it bends towards justice?"
Well, the arc of the commercial universe is long, but it bends towards bland. The arc of the cloud universe is long, but it bends towards commoditization. Way to ruin a national holiday, Hood.
Anyway... picking between the big three based on feature function is a waste of time. We're at a moment in history where we're just trying to pick between different railroads and railroad barons, and over time they're all just Amtrak.
If you really like some AWS feature, tell your Azure rep or just wait. If you really like some GCP data and analytics feature, tell your Snowflake rep. Tell your Palantir rep. Those are Google's real competitors, not Amazon and not Microsoft. Point here is that the markets have a way of taking the shine out of anything new because anything one person can do with software, anyone can do with software. It just needs to pay well or pay enough.
So...
What should you care about, if not feature function? Five answers and they're our next five analogies.
Analogy #5: the horse in the back seat. Remember the first analogy? Faster horses and how you have to choose between the old way of developing software, the horse and the new way the car, the cloud, right?
Essentially. Well, unless you upskill all your software engineers and architects-- and I'm not even talking about your infrastructure people-- unless you upscale your software folks and encourage them to use the services on the cloud, especially the open source offerings, they're just going migrate low hanging fruit-- apps that are not central to your business, your core, your legacy messes.
You know the ones that need serious modernization. Junior cloudy, minimally modify their, their pre-cloud code. They containerize it with Docker, Kubernetes-- push it out and do a victory lap, which oddly enough is lauded in large enterprises because they don't know any better and. And it gets mocked by younger, faster cloud native companies, which it deserves to be.
So instead of committing to responsible car ownership, those engineers, the ones in the most, you know, huge enterprises out there-- they're pushing the horse into the backseat. Visualize that. Think about the smells.
Quick example, and this is the one time in the video that I'm gonna get nerdy. Aside from, you know, mentioning Docker and Kubernetes with no explanation whatsoever. If you're not a nerd, Google those by the way. Docker: khaki pants from the Gap-- Kubernetes are Forever 21's version. There. Don't say you didn't learn anything.
Anywho... there are a lot of signals that you've pushed your old horse into the backseat, but here's a simple one. Does your application use your clouds serverless offering? If you're on AWS, does it use Lambda?
If you're on Azure, does it use cloud functions, GCP cloud functions? And that's just one example. Quick second gauge. How much of your cloud stack is open source? The question is not, are you using open source? Everyone is. It's how much of your stack is it anyway? Enough nerd talk.
A a question that's worth a side note: whose responsibility is upskilling your engineers with cloud skills? If you Google that generic question, every page will give you the same lame HR answer. Quote: "Upskilling and re-skilling," according to Google "are the responsibility of both companies and employees alike." I call bs.. That might have been true when companies gave employees employment for life, but when corporate culture redrew that contract to be about at-will employment, when they regularly purge their bottom performers, the people most in need of upskilling, well, they lost the right to say that upskilling and re-skilling are the responsibility of both companies and employees alike.
It's just the employer's responsibility. Period. The management team's responsibility. Period. And it's hard because if you're not paying market prices and everyone thinks they are and they're wrong, your upskilled cloud engineers, will jump. That's how you know that they're, that you're not paying market prices: your attrition rates.
If I'm an engineer and I make the time to learn while still doing 100% of my day job, I owe nothing to the firm that exposed that training to me. I actually think companies tend to act a little too entitled-- while, while they encourage learning because it's self-serving-- they don't clear time for employees to upskill.
If that's your learning strategy, your engineering workforce will take a decade to become cloud ready. And this is aimed mostly at me. There's no point. I've said it to myself a million times. There's no point to predicting more rain unless you're helping build the ark. So let me propose an effective alternative.
Hide your learning strategy in a giant Trojan horse called Legacy Modernization. As you decompose the monolithic systems that are at the core of your business, make sure that the cloud is the only place they can land. Make sure that they're not stuffing the horse in the back seat. Do that, and you'll understand the huge difference between getting to the cloud and getting business value out of it.
Next... analogy #4: a fool with a tool. A couple of years back we did a bakeoff between two product two, two companies slash products for our next generation CRM platform: customer relationship management. It was a company called Sales something. I forget what, and another one called Micro something.
I don't remember again. The sales one was clearly the more mature platform. Hell, the micro one was their old non-cloud product in its first iteration in the cloud. And what do we know about first iterations? Hmm. Thumbs down. Okay. Most companies doing that due diligence would've gone with sales-something. We went with micro-something because the former had a reputation for being hard to work with, and the latter was humble, pleasant, not salesy.
Reminds you of, you know, Your dad. The point: feature function isn't as important as the people and the mindsets that you get to work with. So how does that relate to the three cloud offerings? Well, I'd say the most important consideration in choosing one of those three comes down to two words, developer support, because a fool with a tool is still a fool.
And I say that with a lot of love for my engineers. On this front, AWS and Azure outpace GCP. AWS leads because their solution architects are the only ones of the three companies who are not paid a sales commission, and that's a great way to encourage them to do what's right for the customer and think about the relationship in the long term.
Azure is a very close second because enterprises are their bread and butter. And being as big as they are, they know better than anyone how slow and stupid large orgs can be. So empathy driven support. I don't think any of the big three are getting it right. We're talking about three companies that can and do burn cash to maintain market position.
A lot of cash. They make investments in the companies that buy their services, but I've yet to see an investment made by any cloud provider to get all, and that's the right word, A L L, all their clients, engineers, cloud certified. That's a missed opportunity. If every engineer at your company was Azure certified-- because Microsoft made that investment-- let's just say your company wouldn't be multi-cloud. That's for sure, but all the investments in training and support that the big three make as far as I know, are to train and support the five to 10% of engineers in a company who are, you know, lucky enough to work on cloud migrations. Digital transformation needs everyone upskilled.
Okay, the next two analogies speak to who outside of your software engineers desperately need to change how they, how they work-- you know, once not if you head to the cloud. I say once, not if, because politics makes it inevitable. At some point you're gonna head to the cloud.
Analogy #3: let's use this knife to pry it out.
That's a reference to the greatest scene in movie history. Will Ferrell's Talladega Nights. I'll link to the clip below, but if if you haven't seen it, you have to promise not to keep watching it over and over again. Who does that scene remind me of? Every cybersecurity person I've ever met. "There's a knife in your leg.
Let's get it out. Let's pry it out with this other knife." And it's worse because with, with like 99% of the cases they come to you with, there's no knife in your leg. There's just the threat of you sticking it in there. Right. There's a potential knife in your leg. Let's use this real knife to pry it out.
So, so let's talk cloud and cybersecurity. Is the cloud safe? Yes, it's infinitely safer than your legacy data centers. It wasn't a while back, but there were enough Ricky, Bobby requests from from clients, and the big three listened. Does it mean you'll sleep like a baby when you move to the cloud? Of course not.
The bad guys will find you there. And they will still attack you. The attack vectors will be newer and all three cloud providers, AWS, GCP, and Azure will work side by side with you to keep you safe. There are a lot of legs out there, and a lot of knives, so that job will never be done.
Analogy #2: why is your water bill $3.2 million? Probably cuz you got a leaky pipe. And the problem is bad enough that it's created a whole new field. Remember DevOps? Well, the cloud has birthed a new discipline called FinOps-- short for financial operations. It's a management practice that promotes shared responsibility for an organization's cloud computing infrastructure and costs.
Yes. Now it's super easy to use an API to scale up your infrastructure like super easy, like, and scale it up like crazy. But if you don't remember to scale it the hell back down when you don't need it, you will hate your life and you'll post your water bill on the web. The way David Hansen did. He's the CTO of 37 Signals- the folks who who own Basecamp. He got an eye watering cloud bill, $3.2 million last year, which breaks down to, you know, about a quarter million dollars a month. That was AWS by the way, $759K of that was just for compute, EC2 and EKS services. Them's some leaky pipes. And it ain't just 37 Signals.
Think Groupon, Dropbox, a whole lot of companies, public and private who prefer to eat that loss in the dark.
And the final analogy, analogy #1: my theory of general relativity. The two most useless words when giving tech advice are, it depends. I should know. I resemble that remark. If you read anything that compares cloud offerings, there is an almost religious zeal to NOT recommend one.
It depends. Are you a Microsoft shop? Go with Azure. It depends. Are you a startup? AWS! It depends. Do you have low self-esteem? GCP... or pick up smoking? They're both cool. Is it worth wasting your time watching meaningless YouTube videos where the influencer doesn't actually take a stand? It depends. No, it doesn't.
Let me talk about some cons to lessen your fears about the big three-- to lessen your fears that you've spent, what, 40 minutes with me? Only to get the same lackluster advice you'll get from a person courting you for consulting work.
AWS can be complex. It'll overwhelm your engineers. Even the smart ones, I didn't talk about this, but leaky pipes aside, their pricing can be higher for certain services, not GCP level high like GCP's Spanner offering-- which is worth every cent-- but AWS can cost you.
Plus unless you're a cloud first, thinker and designer. You will miscalculate how much your cloud adventure will cost. So all those CIOs who claim they're going to save money by moving to the cloud, they're way over their skis.
GCP has a smaller range of services compared to AWS and Azure. But if you're seriously considering them as your cloud provider, I hope your primary need is data and analytics.
Think TensorFlow PyTorch, et cetera. Again, I didn't talk about this, but their Big Query product is better than anything Snowflake has or any custom product that Palantir would build or anything that Databricks will pitch you.
And Azure, whose sales line should be: "You already use us. Why not use more?"
Their offering is less flexible compared to AWS and GCP, and I didn't talk about this, but some of their services are not as user-friendly as their competitors, but Microsoft is like a dad, man. They're pleasant, aiming to please. Just point out the stuff you don't like and give them a chance to fix it.
Let me wrap this up... by maybe reframing the conversation in a way that might blow your mind. I think when we think about the cloud, we all lay out the spectrum from "do it yourself" at one end to "let others do it for you" at the other. And hopefully that spectrum is correlated to your thinking about your business's core competency.
Whether your cookie business should also grow data center expertise; whether you as a bank should be building your own proprietary LLM models, which is really exciting now. But you know, wait a year. My two word cloud provider advice, especially if you lean towards the let others do it for you, is simply go SaaS: software as a service.
Let them-- your software as a service providers-- worry about where their infrastructure sits. As I've said a million times, the world of software is no longer about build versus buy. It's integrate, integrate, integrate. So go SaaS and spend your internal engineering resources on world class glue to connect your various SaaS offerings.
Integrate, integrate, integrate. AWS, Azure, GCP -- hell let's also add Alibaba, Oracle, IBM-- they're all good choices. If, and this is two big ifs. One. Your engineers are upskilled. All of them-- meaning that you're actively making that investment, not just offering, you know, Pluralsight and hoping that your engineers realize that you'll fire them if they don't study up on their nights and weekends.
And two, if you have the courage to modernize your core business capabilities, your legacy crap with a cloud first mindset, the courage to choose modernization over whatever your salespeople think will land them their next sale.
Hope you got something out of this.