How to Compete With the Cloud

While it was once a controversial statement, more and more software projects are acknowledging that their primary competition is not another software project, but cloud platforms offering similar functionality as a service. The directness of the threat varies, depending on whether a major cloud vendor has targeted a given market yet, but it’s rare that there are businesses – or open source projects, for that matter – for whom the accelerating adoption of cloud services doesn’t have significant implications over a reasonable planning horizon.

The advantages of cloud providers are many. Most obviously, economics are clearly in their favor. Not only are the largest cloud providers in Amazon, Google and Microsoft better capitalized than stand alone providers, the breadth at which they operate generates enormous and daunting economies of scale. As de facto platforms, they also enjoy massive development mindshare, while stand alone software providers must strive to stand out amongst an increasingly crowded field of competitors. Most important of all, perhaps, is the fact cloud providers are selling something fundamentally distinct from – and more convenient than – software alone. Software-as-a-service is inherently more convenient than on premise alternatives; it’s easier to provision and simpler to manage.

When on premise vendors are faced with this type of threat, the obvious question is how to compete. Given that none are likely to achieve Amazon, Google or Microsoft’s size overnight if ever, what are the recommended tactics in competing with the cloud giants?

The first and most important step is as much philosophical as execution. It’s important to think beyond the confines of your project or product, to consider what the user might consider the Job to be Done. Independent players should maintain their independence, obviously, but they must think in broader terms about integrations with adjacent technologies. They must Join or Die, in other words.

But because integrations and partnerships are high friction to initiate and effort to maintain, that’s a longer term approach. What can on premise projects or vendors do in the short term to better position themselves against competition from the cloud? More crucially, what can they do to compete asymmetrically?

AWS, Azure and the Google Cloud are able to do things that smaller software providers cannot, clearly. What is less discussed is that the reverse is true.

Much as AWS itself once courted the types of workloads that incumbents were unable to or uninterested in targeting – “I don’t want to be in the hosting business,” as one senior executive at a systems firm put it years ago – to become the cloud behemoth it is today, smart ISVs will capitalize on the cloud provider’s most permanent and unyielding limitation: that they will be unable to interoperate on each other’s platforms.

For all of the development velocity of the cloud providers and their ability to roll out new services at an unprecedented pace – AWS in particular, software from Amazon is not likely to ever run on Google’s cloud, or Microsoft’s. And vice versa.

This creates an opportunity. There are many customers, of course, that will simply default to whatever is offered by a given cloud platform, proprietary or no. But if you believe, as seems most probable, that we’ll have at least two major competitive cloud platforms and likely three or more, consideration for multi-cloud services becomes vastly more important. Consider the options facing a PostgreSQL user today, for example. They have several choices:

1. Roll-your-own PostgreSQL stack
2. Vanilla cloud implementations (e.g. Azure Database for Postgres, Compose, Google Cloud SQL, Heroku Postgres, RDS)
3. PostgreSQL ISV (e.g. Citus Data, EnterpriseDB)
4. Proprietary relational replacement (e.g. Aurora, Spanner)

While the proprietary cloud implementations may offer superior performance characteristics and lower setup friction, they come with the obvious and unavoidable caveat that the software is tied to a single platform – users are unlikely to be able to run Aurora for PostgreSQL on Azure or Google, for example. Such proprietary services serve as a means of differentiation between cloud providers. This makes them, by design, non-options for multi-cloud strategies. And even the vanilla implementations of open source projects-as-a-service come with an overhead: the user interfaces and APIs will differ from platform to platform.

None of which matters, particularly, if the future for your organization is and will always be a single cloud platform. Comparatively few organizations can guarantee that indefinitely, however. Which is why the portability of services can be an advantage in some scenarios for some customers, particularly if they are emphasizing it – as too few do today – as a competitive differentiator.

Assuming that customers are likely to be leveraging multiple cloud platforms then, and that they would prefer not to be tied to a single platform and enjoy a consistent developer experience, ISVs that can traverse multiple clouds become more attractive. Citus, for example, might not be functionally equivalent to Spanner or as low friction out-of-the-box as Aurora, but it will serve as a consistent interface and platform wherever you need it to.

For all that this is an important and underemphasized feature, however, the key for vendors is to not rely on this alone. The power of convenience is strong, and while customers will choose not to be locked in to a vendor if all other things are equal, that means that all other things need to be equal – or least close enough. Software vendors, therefore, that are selling against cloud platforms strictly on the basis of their multi-cloud facility are likely to lose more than they win, because they brought a knife to a gunfight.

Software vendors, on the other hand, that can offer a product on premise or across multiple clouds comparable to what they might get from those cloud platforms natively can mitigate the service disadvantage they face while simultaneously introducing a competitive differentiator – one unlikely to be bridged by cloud platforms – into the mix.

If you want to compete with the cloud then, it’s best to do so by doing what they can’t, not what they can.

Disclosure: Amazon, Citus Data, Google, IBM (Compose), Microsoft and Salesforce (Heroku) are RedMonk clients. EnterpriseDB is not currently a RedMonk client.