Sure, sure. You’re totally “all in” on cloud. You and everyone else, right? Well, no. As we’ve covered multiple times, as hot as cloud is right now, it’s still a teeny, tiny fraction of overall IT spending, no matter what anyone says. But let’s say, just for argument’s sake, that you’re actually not all in on cloud. Not yet, anyway. You’re just starting to think about moving those mainframe applications to your cloud of choice.
This prompts a question: which is your cloud of choice? Which one should be?
It’s easy to get duped into thinking that each of the big three clouds (Amazon Web Services, Microsoft Azure, and Google Cloud) is essentially the same. After all, each offers storage, compute, databases, etc. But peel aside such superficial similarities and you find that their respective fundamental reasons for being are completely different, and that plays out in dramatic differences in the types of services they offer and how they support customers. All this may change which cloud you opt to use for a particular application.
Different strokes for different ops and engineering folks
I used to work at AWS, and another former employer was a big Azure customer. I’ve never been a direct customer of Google Cloud’s, but my company partners with them, as well as with AWS and Microsoft. Despite this familiarity and years of analyzing each of these cloud providers for InfoWorld, it’s still not immediately obvious to me how the clouds differ at the macro level, even if I can appreciate when an enterprise should pick Google BigQuery over Amazon Redshift, or vice versa.
So I asked Twitter for help.
Some of the responses were funny, but many were deeply insightful as to the different approaches of each cloud leader. One of the most popular responses came from Tyler Treat, a managing partner at Real Kinetic. Treat pithily positions each cloud in three quick bullets:
- ”AWS: Cloud platform designed from the lens of an ops person
- GCP: Cloud platform designed from the lens of a software engineer
- Azure: Cloud platform designed from the lens of a corporate IT person”
In an awesome blog post, Treat goes into more detail, albeit focused on the philosophical differences between two of the three (AWS and Google Cloud). He writes that operations engineers may prefer AWS because “it provides all of the low-level primitives ops folks love, like network management, granular identity and access management (IAM), load balancers, placement groups for controlling how instances are placed on underlying hardware, and so forth.” If this sounds like “a traditional on-prem buildout, just in someone else’s data center,” you’re not far off, he says.
Google Cloud, by contrast, comes “from the angle of providing the best managed services of any cloud.” It’s highly opinionated, given its early platform-as-a-service start with Google App Engine, which won’t be everyone’s preferred approach, but if you’re a software engineer, Google Cloud may obviate or minimize the need for a traditional ops team, according to Treat.
Lak Lakshmanan, formerly of Google Cloud, confirms Treat’s theory, suggesting that “AWS is about choice and SLAs,” which means “you can build pretty much anything you want, and the individual pieces will be rock solid.” What seems less great, however, is that “integration of the whole is your problem. This poses a problem for software developers.” For years, analysts and interested onlookers such as RedMonk’s Steve O’Grady have speculated that AWS would increasingly abstract away some of this complexity with more of a solutions approach, but thus far there’s some smoke but little fire to substantiate what customers increasingly clamor for: solutions. (“Yes, we know you have 1.2 billion services, AWS, but we just want to build a fraud-detection application.”)
Google Cloud, Lakshmanan goes on, “is about ease of use—a few robust products that integrate robustly for the most popular needs across all scales.” This is great so long as you stick with Google’s opinionated approach. If not, be warned. “If you are building something offbeat, it will be frustrating,” says engineer Clint Byrum: “GCP is neat and orderly, pretty much one way to solve any problem, which means it is great for 90% of problems and pretty frustrating for the 10%.” For all these reasons and despite those issues, Lakshmanan concludes, “Software developers [and] data scientists love it.”
One of these things is not like the others
And what about Azure?
Ant Stanley, who has used all three cloud providers in his consulting practice, finds much to like about each but hints that Azure is perhaps the one that adheres most doggedly to its Windows past. This can be a criticism, but it’s also a source of strength. Microsoft has spent decades making IT folks very happy. If Azure is a way of continuing that trend, it’s hard to suggest this is bad strategy or bad technology. Matt Gillard, who also consults using the different clouds, notes that Azure is very focused on enterprises and government, both of which run lots of Windows.
Miles Ward, CTO of SADA, a leading Google Cloud partner, also chimes in. Azure, he argues, is great for companies where “IT leads tech” within the company and the company may be at the beginning of its cloud journey (meaning that “little of what you have is cloud/SaaS today”). Add to this the not-so-software-related-but-still-relevant consideration of needing “aggregated negotiation and multiyear deal structure to simplify for the CFO,” and Azure makes a lot of sense. In these and other comments, Azure comes across as the cloud that starts with the IT decision-maker in mind and then backs into the technology.
11.2 Capital’s Pramod Gosavi expresses this another way: Azure is great if you want to “supplement on-prem” resources. If you’re in Microsoft’s shoes, isn’t this where you’d start, too? Helping existing Windows customers find their way to the cloud? The real question is whether Azure appeals to companies beyond the Windows ecosystem. In my experience, the answer is increasingly yes, partly because Microsoft brings the solution focus to customers that AWS has been challenged to do.
But let’s not pick sides—there’s not really a reason to do so. After all, companies nearly always run more than one cloud, and increasingly do so intentionally (aka multicloud). Each of the clouds is selling at a frenetic pace, with tens of billions in customer commitments to spend that have yet to be burned down through customer use. However, it does pay to understand how each cloud approaches its business, to better tune those philosophical underpinnings to your own company’s cloud needs.
Copyright © 2022 IDG Communications, Inc.
