Recently, Cloud Foundry Foundation CEO Sam Ramji made some strong statements against public cloud adoption. Here's a fact check.
Given the significant momentum behind public clouds like Amazon Web Services and Microsoft Azure, it's easy to forget that private cloud providers keep selling into enterprise data centers. Red Hat, for example, is making a tidy business straddling the transitional fence between private data centers and public cloud. So is Cloud Foundry, which led my friend and Cloud Foundry Foundation CEO Sam Ramji to push back on the suggestion that the cloud wars would end with Amazon controlling all.
In his rush to dismantle AWS' infallibility, however, Ramji may have gone too far. So, in the spirit of the "fact checking" that permeates politics, let's review a few of his more contentious statement.
Fallacy 1: Amazon competitors should shun AWS
One of Ramji's first declarations was: "Companies who compete with Amazon and run their digital business on AWS are taking substantial risk." To wit, Ramji insinuates that Amazon "gets real-time indicators of
other companies' activities on AWS."
This simply isn't true. Not even remotely.
AWS is completely separate from Amazon's retail business, and the two operate independently. Indeed, AWS hosts numerous Amazon competitors. In my past conversations with AWS, they have stressed that it's critical for them to consciously enable any company—competitor or not—to use AWS infrastructure to build and run their business.
Netflix, for example, competes very aggressively with Amazon retail in the video and original content space. And yet, they are every bit as important of a customer to AWS as Amazon the retailer is.
Ramji understands this. As someone who worked at Microsoft for years, he knows that this is an essential part of being a platform business: You must be comfortable with competitors operating and thriving on that platform.
Fallacy 2: Regulated industries should be scared of public cloud
To be fair, Ramji didn't say the public cloud is verboten with regulated industries. He told me, "Large companies [and] those in regulated industries...have good reasons to use private clouds in combination with public clouds." In other words, such companies would use public clouds but "have strong motivation to stay away from the public cloud" and so would store their most sensitive data in private clouds (i.e., "data centers" dressed up in fancy cloud language).
This is a little bit true, but increasingly more false than true. Capital One, Nasdaq, FINRA, National Bank of Canada, Pacific Life and a variety of others in regulated industries all use AWS. Additionally, AWS lists a slew of financial services and healthcare customers, and Microsoft Azure also talks such customers through compliance in the public cloud. Capital One went so far as to keynote AWS re:Invent, where the CIO declared, "We can deploy some of our most critical workloads on Amazon."
The key word for Ramji is "some," but for me it's "critical." A few years back the "some" would have been "none" and the "critical" would have been "test and dev." The fact that Capital One is entrusting some of its most critical workloads to AWS today suggests that it will be shifting "some" to "most" in the not-too-distant future as it grows increasingly comfortable with the public cloud.
Which brings us to the last correction on multi-cloud.
Fallacy 3: Enterprise is too complex for one cloud
Ramji cited three reasons that enterprises—particularly large enterprises—should avoid entrapment by a single public cloud vendor. In sprawling organizations, it's unreasonable to assume everyone will settle on the same cloud, particularly because different clouds do different things well, he reasoned. Hence, "Multi-cloud is not a concept, it's an active reality."
All of this is true so far as it goes, but it's non-trivial (read: brutally hard) to architect applications to work across multiple clouds simultaneously or interchangeably. Ramji puts a positive spin on "different cloud strokes for different folks" but the reality is that each cloud provider has made a unique set of decisions and tradeoffs to arrive at their specific set of services, and it is a tremendous feat of engineering to account for the differences, and have an application work well across all platforms.
In other words, developers end up fixated on operational challenges imposed by a multi-cloud approach rather than developing new solutions for customers, thereby eroding the benefits of why a company pursues the cloud in the first place. Also, in many cases, such a model requires regression to the lowest common denominator of functionality and walls the customer off from adopting advanced features and services.
A better model for an enterprise considering a multi-cloud strategy to obtain operational redundancy would be to architect a multi-AZ or multi-region deployment on their public cloud of choice. For example, the geographic separation and utility grid isolation design of availability zones and regions at AWS, Google, or Azure provides an extremely available infrastructure without the headache of designing for multi-cloud.
No comments:
Post a Comment