Turns out AWS can partner after all

Amazon Web Services (AWS) has never been the open source ogre that some have claimed, but it also hasn’t been quite as good as some have wanted. As AWS has grown larger, my personal view is that it has sometimes struggled to apply its own Leadership Principles or LPs (“Customer Obsession,” “Deliver Results,” “Insist on the Highest Standards,” “Bias for Action,” etc.). It has had difficulty controlling the customer experience while not stepping all over its partners’ toes when partners were often better situated to deliver a superior customer experience. In Amazonian-speak, the company wasn’t “Earning Trust.” Arguably, it failed to care for customers that might prefer “full-fat” partner software but were instead served a native AWS “skim milk” alternative.

That, apparently, was then. This is now.

The AWS of now keeps surprising the market with improved partnerships. Today AWS and MongoDB (disclosure: I work for MongoDB) announced a deep, strategic partnership that covers everything from extensive product integrations to joint developer relations initiatives to comarketing and coselling programs. This is a “very big deal” because the two companies have spent years fighting over compatibility of competing services and more. Nor is this the only example of AWS partnering well with erstwhile competitors: AWS and Confluent announced a strategic collaboration agreement in January 2022. I assume we’ll see others. Maybe many others.

As such, though AWS still has areas in which it can improve, it’s fair to say that old labels for AWS (like “strip miner”) are in serious need of a refresh.

This is not the AWS you’re looking for

In my experience, many outside observers don’t understand how AWS operates and therefore struggle to understand how it works with partners or customers. After I left AWS for MongoDB, I tried to describe some of the internal mechanics of AWS that both enable and complicate its approach to partnerships. To summarize, though everyone who works for Amazon is animated by the LPs, teams are intentionally kept relatively small and run autonomously, which affects the consistency of how LPs are used. This is good and bad.

For example, each individual team can interpret an LP such as “Customer Obsession” differently. Some might believe it’s best to contribute code to the relevant upstream open source communities, thereby minimizing technical debt and keeping higher fidelity to open source versions. Others, leaning into “Deliver Results,” might feel the need to patch a project without slowing down to make the effort to upstream those changes. Both teams have good intentions to serve customers, but they generate very different results.

Even abstracting away from open source, some of the LPs are harder to square with strong partnerships—or might be interpreted as such. For example, a general manager might say, “How can I, as a GM for a service, ‘Insist on the Highest Standards’ if I’m one step removed from the customer by working through a partner?” I stress interpreted because companies like Microsoft have shown for decades that it’s very possible to deliver a strong customer experience through partners. Responding to that hypothetical service GM, it’s very possible to achieve those standards through contractual service-level agreements, close collaboration on product integration, or other means. As with open source, it just requires different muscles and a different approach to meeting customer needs.

For some time, AWS seemed to lack these muscles. But this is changing, and fast.

Exercising its partnership muscle

In some degree, its partner approach is probably down to people. AWS recently hired Ruba Borno from Cisco to head up the company’s global partner program. Though Borno has only been with AWS since late 2021, friends inside AWS have said she has had a significant impact in shifting AWS to a more partner-friendly approach to meeting customer needs. Beyond executive leadership, AWS has increasingly hired open source/partner-friendly people (I counted myself among those ranks while I worked for AWS) who have pushed for change.

There’s also the question of scale. AWS has grown to a $71 billion run-rate by building native services such as Amazon EC2 and Amazon S3. The company now offers more than 200 native services. Clearly this strategy has worked. Even so, it’s hard to see how the company scales to the next $71 billion without turning to a partner ecosystem, just as Amazon has done in its retail business. (Third-party sellers account for more than 60% of Amazon.com’s revenue.) As the company has done in retail, the long-term success of AWS is almost certainly tied to how well it partners to enable a robust partner ecosystem around its core, native services.

As I’ve argued, “Long term, the cloud that enables the biggest ecosystem will win. Or in other words, the winning cloud will be the one that partners best.” My sense is that AWS sees this, perhaps prompted by earlier efforts by Google in particular.

None of this means that AWS will give up on its native services anytime soon. There’s just too much money at stake (or too much “Customer Obsession” at stake). AWS has shown no signs of waning ambition to deliver streaming data services with Apache Kafka through its Amazon Managed Service for Kafka (Amazon MSK). And yet AWS is also investing big in enabling the success of Confluent, which offers a directly competitive Kafka managed service.

Is AWS the same as it ever was? No. Not at all. Yes, AWS has always chosen to both compete and partner, but in my experience, the balance increasingly favors partnerships. It’s true that there’s still conflict and that some AWS teams partner better than others, just as some contribute to the open source projects on which they depend better than others.

I don’t want to present some overly optimistic picture of AWS. But the AWS of today is more partner friendly than the AWS of 2019 or 2013. Old dogs apparently can learn new tricks.