What Amazon Learned From Microsoft

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

As the company most clearly associated with the rise of the commercial software industry, it is no surprise that Microsoft’s business model historically reflected a profound, even emotional, attachment to software as an asset. Microsoft didn’t make money with software, it made money from software. At rates that were unprecedented in the technology industry at the time.

In practical terms, Microsoft was a platform business – and arguably even still is as it moves aggressively into services. Microsoft owned two of the most important platforms in the business and productivity software and operating system markets, and it studiously built on top of and alongside these platforms to deliver not just base platforms to their customers, but complete end-to-end stacks. Need a database? Microsoft had one. Ditto for web servers, app servers and integrated development environments. The value of these individual pieces was intended to be more than the sum of the parts, thanks to a practice known as integrated innovation. This describes an approach in which individual components are improved when used in conjunction with one another.

The byproduct of both the integrated innovation approach and Microsoft’s fixation on software as an asset was that company felt compelled to own the stack. If software was an asset, and higher switching costs meant higher profits, then logically Microsoft needed to sell more and more software that would raise the switching costs which would result in higher profits. While the company pointed to integrated innovation as an opportunity for partners as well as Microsoft, the Redmond software giant left little available oxygen amidst the core infrastructure – and later, segments of the packaged applications market – for partners. The end to end stack that Microsoft took to market was, by and large, built and sold by Microsoft.

Which in turn meant tradeoffs for customers. On the one hand, the stack offered the promise of lower integration costs, the proverbial one throat to choke and Microsoft’s characteristically strong developer experience. On the other hand, the stack was in many respects an all or nothing proposition. At the time, developing in Microsoft languages or leveraging Microsoft infrastructure meant that you used Windows. And while there was certainly a wealth of non-Microsoft server software that ran very capably and could be mixed and matched on Windows, it was difficult to do this with Microsoft server software – SQL Server being a notable exception.

Microsoft’s vision for customers, in other words, was complete, end-to-end and full service. Which, again, was not a surprise given that the company had internalized – was probably the best example of, in fact – Shapiro and Varian’s maxim that “the profits you can earn from a customer – on a going forward, present-value basis – exactly equal the total switching costs.” Customers that used less Microsoft software could switch platforms more easily. If customers that used one Microsoft product could be incented to use another Microsoft product, however, they would be less likely to make a jump from the platform. Each additional Microsoft product consumed further raised the switching costs, which according to Shapiro and Varian meant that Microsoft’s profits would rise in direct proportion.

This strategy worked very well, and for a very long time. While it’s impossible to know for sure, it’s not impossible that it could have survived the transition to mobile had the company executed more effectively in that market.

In the cloud, however, the player that appears to have learned the most from Microsoft’s platform success ironically has not been Microsoft, but Amazon. What the companies have in common – besides their geographical location, respective market dominance and some shared history amongst its executives – is that they are both platform businesses. Amazon’s Web Services business, it can be argued, is the new Microsoft, in the cloud. Which would imply that the AWS Management Console, as mentioned above, is the new Visual Studio.

(click to embiggen)

Like Microsoft, AWS is intent on delivering a complete, end-to-end experience for its customers. Whether the market need is a database, a CDN, directory service, streaming data support, logging, storage, messaging, data warehousing capabilities or something else, AWS has an offering. Or if they don’t today, they are likely to eventually. Like Microsoft with Office or SQL Server, AWS is comfortable augmenting its internal development with inorganic acquisition or OEMing where need be. AWS’ relentless drive to deliver the most complete platform in the cloud, at a rate that is impressive bordering on intimidating, has garnered the company a great deal of attention over the past few years. But it is not unprecedented. Those who followed Microsoft before it was temporarily stalled by the emergence of cloud and mobile will recognize a great deal of Amazon’s behavior and ambition.

Amazon has broken from the Microsoft playbook in one very important way, however: they have provided more and more accessible on ramps.

Microsoft woke to this strategy late, as evidenced by decisions such as the one to explicitly court the PHP community. As popular and ubiquitous as Microsoft technologies were, the theory went, there were open source alternatives that were far more popular that might be growth opportunities for IIS, and by default, the only operating system it ran on.

Amazon, by contrast, has had this essentially baked in from day one. The Elastic Compute Cloud, for example, may be accessible via proprietary APIs, but what runs on an EC2 LAMP stack will run equally well on premises or in a competitor’s cloud. Likewise, when Amazon’s Relational Database Service launched three years after EC2 and S3 debuted, it was an implementation of an open source project – MySQL. Unlike SQL Server, which could only be obtained from Microsoft, Amazon could plausibly tell its users that they if they were unsatisfied, they could get MySQL support from any number of alternative providers. Buying into Amazon, in other words, doesn’t mean a commitment to only buying from Amazon.

Which is not to say, of course, that Amazon has pursued a purely open strategy where Microsoft’s was proprietary. Quite the contrary; the majority of Amazon’s services are proprietary to Amazon, and in cases such as Aurora even open source-based offerings have a proprietary flavor to them. Amazon, and its sizable body of employees from Microsoft, have not forgotten the lessons of the software giant. But by including open or open-ish entrypoints such as Elasticsearch, MariaDB, MySQL, PostgreSQL – not to mention the core support for distributions such as RHEL or Ubuntu, or the Docker support within ECS – Amazon is not requiring customers to make the same tradeoffs that Microsoft did once upon a time. If customers choose to leverage standard services such as compute or open source databases, Amazon can monetize them. If they expand from there into proprietary services such as Kinesis or Redshift, AWS profit potential goes up, but the company will happily pursue volume and margin markets simultaneously. Amazon is like Microsoft, in other words, if Microsoft had been able to offer more, better and wider support for open source platforms years earlier.

Whether this is because Amazon understands that its cloud services’ instant availability and the inertia that comes from its usage is a powerful staying factor, the fact that they can monetize even non-AWS software services by selling the hardware to run it on, or some combination of the two is ultimately irrelevant. The net result is a provider that appears to have understood the most important lessons learned by one of the most dominant technology companies on the planet, and has even managed to improve upon them. It also is suggestive of the best way to compete with Amazon, but that’s a post for another day.

Disclosure: Amazon and Microsoft are both RedMonk customers.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *