What’s Scary About Amazon Web Services

As has become routine at re:Invent, Amazon Web Services used the opportunity of its annual conference to shine a light on the fruits of a year’s worth of its labor. The product of which would represent years plural if not decades of almost any other company’s work, it must be said. Hundreds of new features, services and products were unleashed on a large crowd crammed into a not large enough venue. This left attendees with ample time to try and digest the dizzying array of new information as they stood in epically long, snaking lines for sessions and events.

Much of the press coverage of the event took the announcements at face value, looking at the individual or contextual importance of a new feature or set of features. These stories were then neatly fit within one of two standard industry narratives, narratives that either cement AWS as the once and future cloud market leader or highlight the size of the target painted on its back.

All of which is understandable and, arguably, appropriate.

What was interesting to me about re:Invent, however, was looking at it through a competitive lens. If I were an industry competitor, what would scare me about Amazon Web Services?

As it turns out, that wasn’t the new services, nor the unparalleled velocity at which they continue to be introduced. Both are impressive, to be sure, and under other circumstances would be grim news for other market participants. But if re:Invent demonstrated anything, it’s that AWS competitors should be far more concerned instead about what’s happening around the introduction of all of the new features.

It’s one thing to have features, it’s another thing to be able to sell them. Amazon and other cloud providers have always had an advantage in that regard, of course, because of their inherently accessible, frictionless delivery model. But AWS increasingly appears to have an intuitive grasp, if not completely consistently, of the jobs its customers are hiring it for.

Consider the case of the app registry for Lambda, or as AWS calls it, the “Serverless Application Repository.” One of AWS’ most interesting and innovative services since its launch, serverless has held enormous technical promise but seen a slower adoption curve than comparative technologies because of a higher barrier to entry due in part to its distinct nature. How best to speed adoption of the service, then, if not by way of more speed, performance or scale?

In this case, by taking a page from past lessons in package and application management: specifically, creating a central repository where users can come together and help each other by sharing and collaborating. The best and most important innovation for the service, in other words, may have less to do with the service itself than enabling its users to connect with each other.

Similarly, with RDS and other services, AWS continues to expand the role it can play. It used to be that doing things like spreading 6 replicas of a database across 3 availability zones was a full time job. Today, it’s a feature. Database providers historically have focused on aspects of the product: higher performance, better transactional support and the like. With Aurora, AWS wants to match some of those features, but also tackle the wider job to be done. The difference between selling a database and selling a database that doesn’t have to be setup or managed is critical in a world in which developers have much higher complexity and consequently higher appetites for services.

If it wasn’t impressive enough, however, that AWS had begun to at least implicitly embrace a Jobs to Be Done methodology at scale, the company also showed signs that it intended to close its largest remaining vulnerability.

As the company that got to market first in the cloud, and to quote Ray Ozzie’s words, the only one who took that market seriously for years, AWS has given itself an enormous headstart. For this reason, and for the unholy speed at which it executes, the company is universally and correctly regarded as the dominant player in the space. But it historically has left a door open for competition in its distant relationship with open source.

Unlike Microsoft, the company from which many of its executives hail, open source has never been a religious issue for AWS. AWS indeed appeared to learn from Microsoft’s missteps in this regard, leveraging open source projects like Linux or MySQL as funnels for customer acquisition. But that aside, the company’s attitude towards open source could be characterized at best as indifference.

At Microsoft, its caustic attitudes were the product of leadership. At Amazon, the reasons were less cut and dry. One of the simplest explanations for AWS’ lack of appreciation for open source, however, comes from the old adage that things that aren’t someone’s job are no one’s job. Unique to large, modern technology organizations, AWS historically had very little in the way of central authority or organizational structure around open source. To some extent this is an artifact of the company’s historically heavily autonomous internal structure, but it also signalled a lack of priority for open source.

Given the company’s performance both from an adoption standpoint and from a financial perspective, it’s difficult to make the case that this lack of attention to open source materially impacted the company in any way. But as Microsoft’s example shows, these things tend not to matter until they do, at which point they’re very difficult to correct.

Which is why the original hiring of Adrian Cockcroft, Zaheda Bhorat and others with their explicit open source charter was interesting. Was it a signal that AWS had yet again learned from Microsoft, and was avoiding following too closely in that company’s footsteps?

This re:Invent, signals that this was in fact the case were common. Most obviously, there’s an organization (with headcount) within AWS now – @AWSOpen – whose mission is explicitly open source. Then there are collaborations like Gluon. And decisions to join organizations like the CNCF. Whose leadership has, it would seem, noticed a change.

fair enough, I think they are moving in the right direction by establishing @AWSOpen and having them tell their story

— Chris Aniszczyk (@cra) November 28, 2017

It’s still early in AWS’ open source efforts, of course, and as evidenced by some reactions at re:Invent there is much work yet to be done. The story may be mostly public, but the public has to do a lot of connecting the dots at present. It’s also possible that AWS will decline to go as far in embracing open source as many in the community would prefer, instead keeping it largely at arm’s length.

But re:Invent was an opportunity to contemplate, at least, a company that both understand the jobs it’s hired for and the importance of open source in helping it satisfy them. And that is a company that most of its competitors, frankly, would prefer not to contemplate. If you’re a developer, however, you were living your best life.

Until you had to get in line, anyway.