A Faster Horse

(Credit: Charles LeBlanc, used under CC BY-SA 2.0)

“If I had asked people what they wanted, they would have said faster horses.”

So said Henry Ford once upon a time, according to many, including one of his own decendents. Unfortunately, as is so often the case with attributions, the claim does not bear scrutiny. There is no evidence Ford ever uttered those words.

Their questionable provenance notwithstanding, however, the idea those words succinctly capture is sound. Innovation is a challenge as those in most need of it are the least able to perceive that need.

When AWS conceived of and launched the cloud market sixteen years ago, as has been well documented here and elsewhere, initial reactions to it were dismissive. It was not a faster horse, after all. Incumbent vendors and analysts viewed the technology as either charitably as a curious science project or scornfully as a toy for the interchangeable developer masses.

AWS, however, had two advantages. First, having built the technology equivalent of cars for itself, it understood from experience that others might in fact want cars rather than faster horses. Second, it knew which audience would be most open to this innovation. As Andy Jassy said at reInvent back in 2018:

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.

This might seem implausible or mere hyperbole in the year 2022, but during the five month period in 2006 when the first two foundational AWS services dropped it was nothing more or less than the market reality. Developers were an afterthought, a fungible resource to be dictated to by top down command and control organizational structures.

Open source had begun to loosen their shackles, to be sure, but for software to be truly useful, it needed hardware to run on. Thus the opportunity and demand for the cloud was born. AWS seized this opportunity and remade the industry in its image, all by deciding not to build a faster horse.

While the infrastructure model AWS pioneered remains the main attraction, both in terms of its visibility and the revenue generated, conversations of late have taken on a restless, impatient tone. Across an array of market participants, buyers and sellers, from all verticals and product categories, the more common questions being asked not publicly, but privately, can be distilled down to this:

Infrastructure was the cloud’s first act. What’s its second?

Those buying and most certainly those selling want to know where the next phase of growth is going to come from. Not that growth, of course, has been a particular problem for the cloud to date. While it’s slowed somewhat in recent quarters, even as the largest player in the space AWS still managed to grow its business by upwards of 25% on a $20.5B quarter. If growing in the double digits on a double digit billion per quarter run rate is a problem, most companies would be delighted to have it.

But while net new work is virtually all cloud and there are literal oceans of on premises workloads not migrated to the cloud that might yet be, there is a growing sense of saturation. An idea that the overflowing spigot of new and refined primitives is leading to diminishing returns as organizations approach and then pass their ability to absorb new features. Which suggests that logical, deliberate evolutions of existing primitives or introductions of new adjacent services might not lead back to the steep up and to the right trajectories that this industry, like every other one, prefers to see on charts depicting revenue growth.

The infrastructure market will be around, of course, until the end of time. But the bets around the industry for outsized growth are mostly being placed not on infrastructure but on alternative or complementary approaches to traditional clouds – and not just because infrastructure is stacked against new market entrants. There’s no consensus in exactly which abstract platform model is the one to bet on moving forward, and there may never be. Rather than one general purpose Heroku-like approach, it’s seemed likely for some time that the market will branch from general purpose into an array of options depending on workload and need. At one point it even seemed like AWS would be leading that charge, until it appeared to reverse course on that messaging a year ago this month. And with the exception of a few announcements like Code Catalyst, it did little to correct that impression at this year’s event.

Which is curious given the wider market context.

There was a time when it was possible to be a full stack developer, having good working familiarity with every layer of even moderately complicated systems. Those days are gone. Systems involve far too many moving pieces today. Even for those developers that might want to own every component of their stack are finding it impractical at best, impossible at worst. As Vicki Boykis said just four days ago:

Instead of working on the core of the code and focusing on the performance of a self-contained application, developers are now forced to act as some kind of monstrous manual management layer between hundreds of various APIs, puzzling together whether Flark 2.3.5 on a T5.enormous instance will work with a Kappa function that sends data from ElephantStore in the us-polar-north-1 region to the APIFunctionFactoryTerminal in us-polar-south-2.

Between the reality of that fractaly widening complexity and the fact that developers in general prefer to spend the majority of their time writing code and solving problems, not selecting, acquiring, integrating and operating dozens of separate primitives – or at least are more valuable when they do, the door is open for abstractions.

Hence the bets being made today on higher level platforms like Cosmonic, Fermyon, Fly, Glitch, Netlify, Render or Vercel. Bets which are being made for two simple reasons. First, because developers – drowning in primitives – are asking for help. The developer experience gap is real, and not by any means strictly a RedMonk view. As Sarah Drasner put it:

When we think about Developer Experience, we have think beyond a single product. In a Developer’s journey, we begin to prioritize the features that are touch points along the larger system. What I often find is there are gaps between these products where we have to do intentional work to make things feel seamless.

Second, and more prosaically, because the infrastructure market is crowded and dominated by large, highly capitalized competitors while the market for abstractions has comparatively less attention on it. It is, in other words, more of the proverbial green field.

And as always with green fields, nascent revenue streams and limited competition, the growth rates are likely to be excellent.

Which brings us back to AWS.

In many respects, the company today is, from a historical perspective, in a similar position to Microsoft circa 2005. Similarly dominant, the center of gravity for an entire technology universe and yet so successful in one market that it can be hard to perceive the need for the next.

There have been signs like the aforementioned Code Catalyst, and on top of that in descending chronological order App Runner, Proton, Amplify and Elastic Beanstalk. And then there are other signs like extensive keynote celebrations of the beauty of the Unix philosophy, which it seems fair to characterize as the academic version of “primitives not frameworks.”

There has been immense progress with the company, to be clear. Even at its size and scale, AWS has lost none of its ability to ship software at scale and with velocity. There are no signs that the company is resting on its laurels. And the argument can be made, as Matt Asay has, that the company has changed, and for the better.

But once upon a time AWS prided itself on building the future, something customers didn’t even know they needed. If you look at the list of announcements this year, however, it seems far more weighted to reaction and response than anticipation. There’s no question that AWS is building what customers want, and that this has been a lucrative endeavor. The interesting question, however, is whether it should be building what customers want, or returning to its roots and building what developers want.

Even if they don’t know it yet.

Disclosure: AWS, Glitch (Fastly), Heroku (Salesforce), Render and Vercel are RedMonk clients. Cosmonic, Fermyon, Fly, Netlify are not currently clients.