In the technology world, the definition of multi-cloud is usually - choosing more than one cloud provider from among the usual suspects (AWS, Azure, GCP, etc.) to build your IT infrastructure. And the reasons given for choosing a multi-cloud setup are various - risk management, avoiding lock-in and reliance on one provider, compliance with regulatory requirements, etc. This recommendation usually comes from cloud providers who want to make inroads into each other's customer base and service providers and IT consulting firms who have lots to gain from complexity. The complexity that comes from companies creating infrastructure setups involving multiple clouds and their unique concepts. Does it add value? It is debatable whether a business really benefits from such multi-cloud setups. Both from the perspective of standardization as well as affordability, one can argue that large enterprises are better off staying with one cloud: Central standardization is important to large enterprises. However, it is harder to standardize internally when multiple cloud providers are in play. Large enterprises are not very cost-sensitive. So the minuscule differences in costs for individual products from large cloud providers don't justify the additional complexity. Regardless, multi-cloud is a popular topic among large enterprise IT decision-makers. The hype has worked. How do startups and smaller tech companies approach multi-cloud? In my experience, smaller companies tend to be more pragmatic practitioners of multi-cloud. However, the specific multi-cloud aspect of their apps and infrastructure is not usually discussed in popular tech literature. Most smaller companies adopt multi-cloud architectures almost by necessity. They have two needs: They want to focus on building their apps and not reinvent the wheel They want tools and services that are best of breed in their respective areas in terms of productivity and ROI In fact, tech startups and small development teams are increasingly picking some combination of the below services: compute from an infra-provider like AWS/GCP/Azure/DigitalOcean, payment services from Stripe, communication services from Twilio, auth services from Auth0, Atlas from MongoDB, CDN / security services from Cloudflare, etc When they do this, "Adopting a Multi-Cloud strategy" is not the thing they have in mind. They are merely looking to compose their apps together using the best tools in the market. They are trying to get to their desired results faster and in an economically viable manner. However, what they do is essentially what a good Multi-Cloud setup looks like. In many cases, they don’t really care where these different “component service” providers build their services. Any concern around the manageability of these multiple providers is also much smaller than the alternatives - building this functionality yourself or using an inferior alternative from someone who is focused on much more horizontal problems. Will this trend continue? An argument can be made that if you go with a large cloud provider (AWS, Azure, GCP, etc.), all your needs can be met within one provider. They have both infrastructure (IaaS) and managed (PaaS) services for every building block needed by application developers. However, the reality is that modern app builders are not only choosing lighter-weight specialized tools for the job but actively experimenting with non-mega-providers. This is spurring on smaller providers to continue to identify and service specialized use case scenarios and underserved audiences through hyper-focused solutions. Composing apps using best-of-breed services from experts in their respective areas is a trend that will continue to grow, and we all will benefit from it.
