How to Compete With AWS

“So in war, the way is to avoid what is strong, and strike at what is weak.” – Sun Tzu

In January of 1969 – some seven months before the crew of the Apollo 11 mission would be the first to walk on the moon – the Department of Justice of the United States filed an anti-trust suit against IBM, the company’s role in that endeavor notwithstanding. It alleged, among other things, that the company had monopolized “interstate trade and commerce in general-purpose digital computers.” The case would drag on for another 13 years, before being withdrawn in 1982 due to a “lack of merit.”

There is no question that in 1969, IBM was dominant and widely viewed as unassailable. By some accounts, it enjoyed better than 70% marketshare for enterprise hardware. A little over a decade later, however, even competitors allowed the case was “pretty much an historical curiosity,” because the industry was moving beyond the mainframes that IBM dominated to PCs.

This was, ironically, a development made possible by IBM itself.

• The first step was the company’s decision on June 23, 1969 to decouple software from hardware – a decision spurred in part by the January 1969 suit mentioned above. IBM’s decision to reduce its antitrust attack surface had the unanticipated side effect of creating the software industry as we know it today.
• The second was the decision by the company in 1980 to outsource large portions of its late entry into the PC space, most obviously the operating system. For that they turned to a little known company called Microsoft to develop what would come to be called PC-DOS, which was in turn based on software they licensed from another little known company called Seattle Computer Products. In this deal, Microsoft established that IBM’s contract was non-exclusive, and it could sell the operating system to third parties.

Microsoft had perceived, of course, what hardware-focused IBM could not: that software could have value, value over and above that of the hardware it ran upon. It rode this realization to then unprecedented financial heights for a technology company.

The Redmond software giant, in time, missed its own markets. First the internet, in spite of Gates’ best efforts. Then mobile, which it ceded to another dominant player in Apple. It appeared to miss the cloud as well, in the early years, but subsequently recovered and positioned itself well as will be discussed shortly.

There are at least two lessons to be learned from these examples.

• First, that technology companies that seem unbeatable and are expected to dominate the landscape forever do not.
• Second, that the market competition did not arrive head on: Microsoft did not outcompete IBM in the mainframe market any more than Apple outcompeted Microsoft in the desktop and server operating system markets.

All of which brings us back to Amazon and the epigraph at the top.

At Amazon’s annual re:Invent show in November, one rival executive posed a question, one that has been asked before of other dominant suppliers: will they dominate the market indefinitely? Can anyone realistically compete with their market traction?

History’s answer to this question is conclusive: just as the sun rises and sets, empires rise and fall.

But that’s in the abstract. In more concrete terms, in the here and now, how would one best compete with Amazon Web Services? One stratagem comes to us from the Art of War, a military strategy manual – arguably the military strategy manual. Written, at least in theory, by the Chinese general Sun Tzu at some point during the Eastern Zhou dynasty, the text has been popular for decades in a wide variety of contexts ranging from business to sports, to the point that its mention borders on cliché. But for the same reasons the text is prized in those diverse settings, Sun Tzu’s aphorism above offers perhaps the best counsel for would be AWS competitors – counsel that most have ignored thus far.

During the apex of both IBM and Microsoft’s dominant cycles, there were a host of would be competitors that attempted to take the two companies on by meeting them where they were strongest. This was either a bet that a given competitor could produce a significantly superior alternative (e.g. Amdahl) or by providing a roughly comparable product differentiated by lower prices or other mechanisms (e.g. OpenOffice.org). The difficulty with this approach is that customer inertia is enormously difficult to overcome. Competitive products can’t just be moderately better or lower cost, they have to be exceptionally so. And even in cases where this is true, it’s often insufficient to materially change buying behaviors which are influenced by external factors such as bundling, enterprise licensing agreements, employee experience and training and so on.

It is notable that of the dominant technology players that have been disrupted, none have yet succumbed to competition outcompeting them in a market that they had near-monopoly or monopoly control over.

All of which suggests, then, that AWS’ real competition is not going to come from a business that is simply providing the same services that Amazon is, but better, cheaper or both. As broad as AWS’ portfolio is, however, and considering the rate at which new services arrive, what area(s) can plausibly be argued to be outside of the companies current functional mandate?

Where is AWS strong, in other words, and where are they weak?

Most of AWS’ competitors historically, and certainly the ones remaining in the field today, have attempted to follow in the company’s infrastructure primitives strategy, the above lesson notwithstanding. None have come close to equalling the pure volume of services offered by Amazon, but with customers demanding primitives such as compute, storage, managed database services and more, Google, Microsoft and others have hastened to provide them.

Cognizant that customer inertia serves the first mover, the aspirants to AWS’ throne talk less of replacing than of complementing it as an alternative supplier. From keeping AWS in check for customers who have no wish to be beholden to a single technology supplier to diversifying their infrastructure for reliability purposes, non-AWS cloud providers are pushing for a world in which multiple cloud suppliers coexist. This explains why multicloud has stolen hybrid cloud’s thunder, the latter of which still languishes as an ill-defined and misunderstood catchall. It also explains why AWS Marketing is reportedly allergic to the mere mention of multicloud.

As much as becoming a credible alternative supplier to AWS is a viable, large business in its own right, however, it is by definition not going to yield the outsized returns that IBM, Microsoft and others have realized before it – even as the conflation that is cloud infrastructure allows hyperscale providers to turn on hardware and software revenue spigots in ways that weren’t achievable even in the bundled mainframe days.

But if competitors have largely followed in AWS’ footsteps, where has the company yet to tread? Where is the opportunity to strike where it is weak, or at least comparatively so?

From a breadth of portfolio perspective, in terms of its ability to innovate at speed and at scale and on the basic question of who is leading in an exploding category, AWS is without peer. From an experiential perspective, however, AWS has seams.

1. Its developer experience has never been top of class; its success has come because of its leading services and their first-to-market nature.
2. The center of its gravity, meanwhile, is clearly post-deployment. While it’s had a presence in markets from pipelines to version control for years, AWS is known first as a deployment target. Its developer toolset is a distant second, with narrow exceptions as in its AI category.
3. The strength of AWS’ product portfolio is counterintuitively also a liability in certain scenarios. Service sprawl is so acute that even hand-selected AWS customers are often not aware of the availability of new or existing AWS services.
4. While AWS astutely anticipated the escalating appetite for fully managed services with the introduction of its RDS offerings, among others, a decade ago, it has thus far largely limited its managed approach to individual services or collections.
5. The organizational structure – from both the development and marketing perspectives – is heavily optimized for autonomous and fully independent services; it’s less well suited to broad, multi-area integrated solutions.

The AWS context, of course, is only one part of the equation. What are the market conditions that AWS is operating under and, to varying extents, driving that will influence the experience AWS is able to deliver?

The one that matters the most is fragmentation. Over a decade in the making, the accelerating arrival of new technology after new technology – and more problematically, new category after new category – is beginning to outstrip business’ ability to consume them. Even developers have begun to struggle under their growing embarrassment of riches.

In AWS terms, then, the question is whether accelerating fragmentation raises unique challenges moving forward. The crux of Amazon’s appeal is that everyone has been trained to expect and prefer primitives. But what if that were no longer true, or at least, no longer always true? A Do It Yourself (DIY) via primitives approach made perfect sense when there were fewer of them. As hundreds of new services are added to the already immense portfolio every November, will that DIY approach scale? Is it reasonable to expect buyers, developers or both to manage the growing complexity not just of AWS’ catalog, but the myriad pieces necessary to build, test and deliver secure software to Amazon’s platform?

In many cases, the answer is yes. Developers and the businesses they work with have spent too many years with access to base building blocks to give them up easily, meaning that the market for DIY-style offerings will remain robust.

What seems less likely is that this will remain, indefinitely, essentially the only approach used at scale. Much as it’s become obvious that there are few justifications today for self-managing an email server or, more recently, database infrastructure, parties focused on velocity – which is to say, most parties – will begin to focus on what the returns are on maintaining ever more complicated systems composed of dozens of individual services. Which will in turn create opportunities for “Integrated Innovation,” a long deprecated term that might be mere quarters away from coming back into fashion.

Interestingly, the company that coined that term may be in the best position to take advantage of this experiential window. Consider that:

1. Whatever its product limitations, Microsoft – like Amazon – is a company that has always focused on the needs of developers. Unlike Amazon, Microsoft’s history with developer tools is excellent.
2. For the developer experience to be improved and fragmentation mitigated, it has to extend from project inception all the way through to deployment and operation. AWS has unparalleled reach post-deployment; its pre-deployment footprint is much more limited. Microsoft, by contrast, owns GitHub, which has in recent years itself dramatically expanded its reach via products such as Actions and acquisitions such as Semmle.
3. Amazon’s effectively limitless ambition creates challenges with respect to partnerships, and makes alliances such as the “Anyone But Amazon” proposed by my colleague more likely.

Crucially, to deliver a fully integrated experience you need to own the origin for software as well as its destination, and have a bridge between the two. AWS has most if not all of the requisite services required, but is overweighted towards the destination. In GitHub, GitHub Actions and Azure, Microsoft owns the three necessary fundamental building blocks, the success and visibility of which are more proportional than in the case of AWS.

Is it possible, therefore, to envision a world in which Microsoft competes with Amazon not by bringing to market a wider, faster or cheaper bucket of infrastructure parts, but with a more complete developer experience that is seamlessly integrated from inception to promotion to production? There are seven and a half billion reasons to believe that the answer to this question is yes.

Whether it’s Microsoft or another player that seeks to compete not where AWS is strong but where it’s weak, however, they should heed another piece of advice from the Chinese general.

“Let your plans be dark and impenetrable as night, and when you move, fall like a thunderbolt.”

If AWS has proven one thing since its inception, it’s that they can move very, very quickly. If and when they begin to see their lack of higher levels of abstraction as a liability, then, do not expect them to remain so for long, whatever their organizational structure limitations.

Disclosure: Amazon, GitHub, IBM and Microsoft are RedMonk customers. Google is not currently a customer.