Back

Multicloud for Startups

TAM and Business Optionality
Mal EdgarMal Edgar

Mal Edgar

4 min read

If you like Tenet, you will like this story. It starts with two different companies, on different trajectories, on different timelines, with the same characters, grappling with the same conundrum.

In the first story, our character's successful tech company has been acquired and integrated into a much larger global Independent Software Vendor (ISV). They are now working with global teams to modernize the entire ISVs architecture. They are making it 'cloud native', supporting leading cloud platforms while still supporting on-premise deployments.

Why make this change? Well, the global customers are demanding it. They want the benefits of the cloud, but they want to use different clouds, and some of these customers want to be able to use multiple cloud vendors to mitigate risk.

So how are our characters doing? It's hard, really hard. Progress is being made but it's slow. Teams are working across different time zones, the hours are long and thousands of engineers are engaged. It's all-consuming. What had started as a 12-month initiative, has run into its third year.

Why is it so hard? Well, each cloud has been built by different companies (Amazon, Microsoft, Google), and with literally tens of thousands of engineers. There are no standards, and the ones that have been proposed have been ignored.

The big cloud vendors have no incentive to develop multi-cloud technologies, they want you to use their platform and stay there forever. Where there is interoperability, this was more by accident as they settled on the same open-source technology, or they needed it for developer adoption.

Now cutting forward in time, our characters have struck out on their own to create a startup. They are evaluating a business concept around automobiles and are mapping out a Minimum Viable Product (MVP). Using a Lean Enterprise approach they want to test the market as quickly as possible to determine if there is a product-market fit.

Google Cloud Platform (GCP) has some excellent capabilities with Firebase for rapid application development. GCP Firebase would be great for building an MVP. However, this approach is complete vendor lock-in.

The dilemma for our characters is they know the trade-off they are facing. If there is no market fit then GCP Firebase was a good choice, as they learn this quickly and cheaply. If there is a market fit, however, do they keep going with GCP moving quickly, but limiting their businesses optionality or Exit Potential.

Alternatively, do they stop and rebuild using technologies that are portal across clouds but are slower to develop on. What would this time delay cost them?

This is a really awful decision to have to make even before you get started.

So that's our story so far, which is all true.

The conundrum here for the Global ISV and the Startup is the same, how do they support multi-clouds.

For the Global ISV, this is a critical issue to stay competitive and maximize the Total Addressable Market (TAM). For the Startup, they want to maximize the optionality and potential value of their business.

For the successful businesses that have been built on a single cloud, the hosting costs often become a significant issue as they scale. Without the ability for competitive tendering, these businesses have very little leverage in negotiation hosting costs.

For our characters, this multi-cloud problem was more interesting than the automotive concept.

How to give startups the productivity benefits of a super focused 'cloud native' architecture, but still keeping multi-cloud their options open. For the big enterprise, how can we support multi-cloud at scale and provide a roadmap to the Cloud.

The next chapter in our character's story is Nitric a multi-cloud framework for Startups and Enterprises.

Previous Post
Choosing gRPC for Cloud and Microservice APIs
Next Post
The Paralysis of Choice in Cloud