To properly digest and summarize Amazon’s annual re:Invent show would take months and a novel’s wordcount, which is impractical not least because said summary would be rendered obsolete long before it was published. Instead of attempting to document every last facet of the sprawling event, then, it’s useful to take a critical eye to the sea of announcements and extract the big picture narratives: what did the show mean, both for Amazon and for the market it inhabits?

RedMonk has already taken a stab at this with our annual re:Invent Slack chat recap, but to explore a few of the issues raised there in more depth than that medium affords, here is a brief look at some of the most important trends from re:Invent 2018.

The AWS Customer Lifecycle

Since its de facto creation of the cloud computing market in 2006 with the releases of S3 and EC2, AWS has become such a massively disruptive force within the enterprise technology market that it can be easy to forget where it came from. AWS CEO Andy Jassy, however, clearly hasn’t. Speaking to analysts at the event in Las Vegas, Jassy was blunt and candid in his assessment of where the initial traction for the platform had come from: developers. In his words:

When we got started, we noticed that developers were being ignored – I’m not sure why, maybe it’s because they didn’t have money, and they were largely constrained in terms of what they could use.

In other words, according to Jassy, AWS’ success can be read as a validation of RedMonk’s foundational assertion that developers, long viewed as a fungible, non-strategic resource, were in fact the most important constituency in technology – Kingmakers, in fact.

This is not a particularly controversial idea in 2018; many seem to take it for granted, in fact. In an era which openly asked whether IT Mattered, however, it was certainly unorthodox, and borderline heretical. Having been one of the earliest organizations arguing on behalf of developers, we can say that AWS’ embrace of developers early as a core potential customer base was significantly differentiated from the market incumbents at that time.

But while developers played their part in making the new market king, Amazon’s continued growth depends on their ability to court not just the kingmakers but their employers as well. Amazon needs, in other words, to be able to sell into the quote unquote boring enterprise.

Part of that challenge is product, of course: enterprises tend to have a lower threshold for complexity than individual developers, but a greater willingness to pay a premium for abstractions they believe will save time. As Mårten Mickos used to say, enterprises are willing spend money to save time, while an individual developer is more likely to spend time to save money. Where developers might be content to start from basic building blocks such as TensorFlow or MXNet, an enterprise might prefer to consume ML as an existing service as with SageMaker.

But part of selling top down to enterprises, as companies that began their lives selling bottom up inevitably discover, has little to do with product. Instead, there is a sales and marketing infrastructure that needs to be in place for enterprises to have the confidence to invest at the highest level in a given platform, and Amazon has been on that journey for several years now, poaching people right and left from the enterprise-focused organizations it seeked to displace.

In part, then, what Amazon described at re:Invent was a post-Kingmakers world. What comes after the developers make you king?

AWS and the Open Source Question

For most of its history, and particularly in recent years, AWS has had a complicated – and from the perspective of commercial open source communities and competitors, at least, contentious – relationship with open source. While the company learned from prior platforms and was flexible about using open source projects such as Linux, MySQL or PostgreSQL as on-ramps to its platform, it has been a target of growing criticism both for its minimal historical contributions back to the open source projects it monetized and for its tendency to compete with smaller organizations developing and commercializing that software.

The company has internalized a portion of these concerns, clearly, both because it is investing in a growing open source team lead by Adrian Cockcroft and because one of the more interesting technologies it has produced was released as open source software as we’ll see below. Neither of which suggests an end to the controversy surrounding the company’s relationship with open source, of course. If anything AWS’ strategy may accelerate concerns for commercial open source organizations, for the simple reason that its prior approach of open source or an AWS proprietary offering may be giving way to an open source and AWS proprietary offering approach.

Individual open source and proprietary offerings for AWS are nothing new, of course – it has had both for years. But outside of its RDS database platform which has included both open source and proprietary solutions, AWS has typically compelled customers to choose between a proprietary offering managed by the company, and open source implementations supported by either the enterprise itself or a third party commercial supplier.

Consider the streaming use case, for example. Kafka has long been dominant in this space; but up until re:Invent, AWS’ only offering in that space was its own proprietary Kinesis service. At the show, AWS unveiled a new offering called Managed Streaming for Kafka (MSK) – an implementation of the open source streaming platform that actively competes with its own proprietary offering. This is the same approach that AWS is taking in other product areas such as containers (ECS/Fargate vs EKS) and ML (Forecast/Comprehend/Rekognition/SageMaker/etc vs TensorFlow/MXNet/etc).

This pragmatic approach would seem to be straightforward enough on paper, but in fact it breaks with precedent. Most dominant suppliers have had an ideologically driven approach to their market. Microsoft, for example, for decades was fiercely committed to a proprietary model, to such an extent that it was compelled by its ideology to oppose open source even when it negatively impacted the company’s ability to meet customer demand. AWS, at least so far, has not fallen victim to this mindset.

This suggests a few things. First, that AWS – which prides itself on being aggressively customer driven – is actively seeing demand for open source alternatives to some of its AWS-only offerings. Which means that on top of its existing proprietary services, there exists a substantial reservoir of demand for an open source alternative – which is interesting. Second, that in response it is happy to meet customers’ demand, even if it means both competing with their own offering and contributing to product sprawl at the same time. And lastly, that commercial organizations that might have considered themselves shielded from direct competition with an AWS-managed open source implementation because AWS already had an existing proprietary service in market should rethink that assumption.

Which is likely to exacerbate rather than calm fears about the impact of AWS on commercial open source providers.

AWS Contributing Open Source Software

As discussed above, AWS has been criticized by many in the industry about a lack of contributions to open source, both in terms of allowing code to flow back to upstream projects (though there are signs that this is improving) as well as net new contributions. It will be interesting to see if the announcement of Firecracker at re:Invent has any impact on the latter perception, and whether it is a one off event or the signal of a strategic change in AWS’ relationship with the wider open source world.

Firecracker is a virtualization technology derived from Chromium’s crosvm project that allows for the management of microVMs. As an aside, it will be interesting to see how long it is before Chromium and derivative projects take over the world. Between Microsoft’s decision to retire its own browser engine in favor of Chromium and the remarkably diverse array of entirely unrelated projects based on Chromium or its component technologies such as Node.js, Cloudflare’s Isolates and now Firecracker, the number and significance of important infrastructure projects that have sprouted from an open source browser project is as surprising as it is impressive.

But back to Firecracker, out of everything announced at re:Invent, it was the most interesting for three reasons.

1. The Technology
   In many ways, Firecracker can be thought of as embodying the best of both the classic virtual machine and container worlds. Pre-Firecracker, VMs and containers had clearly defined strengths and weaknesses – which implied that users had to consciously make tradeoffs with each – primarily speed/size and security, respectively. AWS, however, didn’t want to make those sacrifices, and for services like Lambda, couldn’t. As AWS’ Arun Gupta and Linda Lian put it:

   We needed something that could give us the hardware virtualization-based security boundaries of virtual machines while maintaining the smaller package size and agility of containers and functions.

   Virtual machines have been one of the most transformative infrastructure technologies of the last two decades, and for their part containers have grown faster than any technology we’e seen in our time at RedMonk. A project that borrows the best of both, therefore, is likely to be popular.

2. The Reception
   Unsurprisingly, therefore, the reception for Firecracker from an industry standpoint has been universely positive. Aside from some grumbling that AWS neglected to mention the project’s Chromium (read: Google) origins, virtually everyone that has looked at Firecracker has come away impressed.

   • Bryan Cantrill: “Honestly, Firecracker looks amazing”
   • Jessie Frazelle: “What I love about this thing is it has taste”
   • Kelsey Hightower: “Extra dope!”

   Even more important than the over the top nature of the reactions has been the context. Many of the project’s admirers work for AWS competitors, on projects that might be impacted by a new Firecracker-style model, or both. When even your competitors are singing your praises, it’s safe to say you’ve done well.

3. The Implications
   Important as the project is likely to be based on the above, what’s not clear as yet is what the project’s wider implications are – both for AWS and for the market as a whole.

   The latter will be interesting to watch, because conservative enterprises running seas of classic virtual machines that were just beginning to get their minds around the concept and role of a container and how they related to VMs. Now they will need to consider if and where microVMs might play a role in their future infrastructure – and that’s without even mentioning the concept of isolates. Underlying container and VM products and projects, meanwhile, will need to decide where and how Firecracker competes with, complements or even replaces (e.g. QEMU) their offering.

   For AWS, meanwhile, this will be a fascinating release. On the one hand, it’s a home run for the open source team at AWS. For one of if not their first AWS originated open source projects to achieve such massive visibility from the moment it launched is a just reward for the presumably significant investment in political capital it took to get this released as open source software. On the other hand, the project’s extreme initial popularity will mean that AWS’ project governance efforts will be heavily scrutinized.

   The documentation says that Firecracker welcomes contributions (and kudos for the Code of Conduct), but the current maintainer list is composed entirely of Amazon employees and there is no CLA or DCO at present. The combination of those imply both that this will be a strictly AWS maintained project at least in the near term and that AWS doesn’t anticipate contributions from third party commercial organizations. Even if that is the expectation longer term, AWS should take a page from the early days of the Cloud Foundry project, and attempt to set expectations for potential contributors in terms of the volume of requests accepted, the expected velocity of that process and so on, because excitement can give way to frustration quickly if expectations are not managed properly.

   Given the level of technical challenge involved here, this may seem counterintuitive, but releasing an open source project in many respects is the easy part. Managing it over the long term poses an entirely different set of community, governance, legal, messaging, political and, yes, technical challenges. For an organization with extensive history of navigating these waters as a consumer but little as a steward, there may be some rough weather ahead.

   Either way, the bet here is that when we look back a year from now, Firecracker will be the most interesting and significant announcement made at re:Invent 2018 – which is saying something.

Disclosure: Amazon, Google, and Microsoft are all RedMonk customers. Cloudflare is not a RedMonk customer. Additionally, AWS paid for travel and expenses to re:Invent 2018.