Forty years and four months ago, Microsoft hired Tim Paterson, the author of 86-DOS – a Digital CP/M clone. Two months after that, Microsoft paid $75K – the equivalent of about $220K today – for the rights to that product, which they promptly renamed MS-DOS and licensed to IBM for use on its hastily constructed PC platform. In a decision that would be fantastically lucrative to Microsoft, however, and would unexpectedly help set the direction for the technology industry for the next three decades, IBM did not demand an exclusive license from the Seattle based software company.
Which is how Microsoft ended up licensing MS-DOS to better than seventy companies over the next year putting itself on the path to go from obscure startup to industry behemoth.
While this seems as inexplicable in hindsight as George Lucas retaining Star Wars merchandising rights, this was understandable in context. As the company behind the mainframe, the dominant enterprise computing platform at the time, IBM understood hardware to be the valuable asset. Software – the operating system, in this case – had historically been a complementary piece, not an important standalone asset.
If IBM regarded the purpose of software as selling hardware, however, for Microsoft the purpose of software was to make money. The company realized that software was an asset, and a highly scalable and thus profitable one. It also came to understand that software platforms could be used to advantage software in other, emerging areas.
Windows made it easier to sell Office, for example, or to spread Internet Explorer. It’s all too easy to forget in a world in which the power centers at Microsoft have long since shifted away from the erstwhile flagship operating system teams and towards Azure, its cloud platform, but once upon a time Microsoft made a bid for the entire business applications stack in a strategy it referred to as “Integrated Innovation.” The short version of this is that Microsoft wanted to offer an operating system, an Office suite, an application stack, packaged apps such as CRM and ERP, all pre-integrated and designed to work together.
If the goal was to monopolize the enterprise applications stack as it did operation systems and office software, Microsoft’s strategy failed. Customers already beholden to the Microsoft for big strategic pieces of their infrastructure were not particularly enthusiastic about having the company own yet another one. This would have been problematic regardless, but was made an even more difficult sell when Microsoft competitors banded together around the de facto standard of Java. While Microsoft offered a single vendor stack that didn’t play particularly well with others, the market countered with a wide ecosystem of Java-based products that customers could and did pit against each other to drive their costs down.
While the original vision of integrated innovation may have failed, however, it’s worth exploring whether that was a model problem or an execution problem. Specifically, whether the idea of integrated innovation is fundamentally unworkable, or whether Microsoft’s strategic and tactical decisions doomed their efforts.
It’s an important consideration, because the market appears headed back in that direction.
As has been discussed before, of course. Massive fragmentation seemed to provide a fertile enough ground for higher level collections of services. At the time, the question was whether would be competitors of Amazon would pursue an integrated innovation-like strategy in order to differentiate from and compete with the cloud giant, and whether that competitive pressures of these integrated platforms – or more likely the real customer demand behind them – would provoke Amazon to pursue such a strategy. With Amazon now actively pursuing a course of domain-specific abstractions, that question has been answered.
The important question now, then, is no longer whether higher level abstractions will become more common, but what they mean.
In a world dominated by primitives, there are only minor disadvantages to being a standalone, independent service provider. For database companies that offer a managed service, as but one example, it is certainly possible to position your database primitive positively even against first party native database primitives. More specifically, there’s a reason that MongoDB’s Atlas as-a-service product is growing so quickly, and the reason is that customers are adopting it in volume even with the existence of two hyperscale native offerings in Cosmos DB and DocumentDB that purport to offer MongoDB compatibility. When customers are responsible for hand selecting the various primitives and assembling the infrastructure, the difference between either Cosmos DB or DocumentDB and MongoDB is purely in the implementation – a scenario which will often favor the independent specialist rather than the generalist platform.
In a world that sees increasing adoption of pre-integrated, higher level services, however, the nature of competition will in some cases tilt away from the particular merits of a given primitive toward the collective value of a given combination of services. While a given customer might prefer MongoDB in a vacuum then – it might be willing to settle for CosmosDB, DocumentDB or another alternative if they’re integrated in a packaged service.
The obvious implication, then, is that any material shift towards higher level abstractions could be as problematic for independent service providers as it could be a boon to customers besieged by rampant and accelerating fragmentation. All of this depends on the calculus within the large hyperscale software providers, however. There are two reasons to believe that at least one if not all of AWS, Google and Microsoft will choose not to go down the native-services-only path with their respective emerging portfolios of higher level abstractions.
- Perhaps the most obvious of which is that this strategy, as mentioned, did not work for Microsoft. The market is very different today than it was two decades ago, of course, but historically customers have tended to resist being locked into a single vendor for a majority of their portfolio. The decision by AWS to spin up managed service versions of open source projects to compete with its own proprietary alternatives – Managed Services for Kafka versus Kinesis, for example – is suggestive of just this. While enterprises may only rarely take advantage of the optionality that projects such as Kubernetes afford them, they certainly value it highly.
-
But for the large cloud platforms, there are also Damoclean concerns of an anti-trust nature involved. If it could be determined that the large cloud providers improperly leveraged their platforms to starve and destroy independent, competitive alternatives via integrated abstractions, it would seem inevitable that the European Union and, pending domestic political considerations, perhaps the United States Department of Justice would get involved. This would be a circumstance which all three of the large providers would presumably seek to avoid at almost all costs, given the past history and current market tensions about their allegedly monopolistic behaviors in this and other markets.
Ultimately, the direction here, and by extension the level of threat independents should anticipate, is likely a function of the demand. If the slope of the interest in these packages of abstractions is relatively mild, the financial incentives for hyperscale cloud providers to advantage their own first party services at the expense of independent competition would be unlikely to outweigh the potential downsides of customer dissatisfaction and regulatory intervention.
If, on the other hand, the next million cloud customers are not only coming via abstractions like this but arriving in the near term, the calculus gets considerably more complicated. Long, drawn out battles with regulatory agencies like the DOJ may have been bad business in hindsight for the likes Microsoft and IBM before it, but as the companies printed currency in the meantime that kind of easy money can be difficult to resist.
Either way, even if their impact on the market landscape remains uncertain, we should all prepare for more abstractions. The days of DIY-only are coming to an end.
Disclosure: AWS, GCP, IBM, Microsoft and MongoDB are all RedMonk customers.
