Whether developers know it or not, their companies likely already have a multi-cloud environment. Multi-cloud is a strategy where a business selects different services from different cloud providers because some are better for certain tasks than others. So company X could use cloud A for infrastructure, cloud B for app dev and testing, and cloud C for data localization in a region. While traditionally considered multi-cloud, this setup really only scratches the surface of what’s possible today. That’s because clouds A, B, and C are isolated from each other from a workflow perspective and there’s little or no data sharing across them. That’s where the real payoff is for developers.
Data sharing has been tough
It’s just been too difficult for developers to build and deploy across clouds. Data sharing has been almost impossible, which is why most developers haven’t jumped at the opportunity. If they have chosen to do it, it hasn’t been easy. It’s meant:
More work To migrate or duplicate any data from one cloud provider to another, developers have had to create and maintain bespoke processes.
Living in hope If one cloud region goes down, jumping over to another is not seamless and results in slower experiences for all. Incompatible operations It’s difficult to secure, monitor, maintain, and govern across clouds.
The barriers between clouds have always been high. Devs have had to rewrite the majority of their application code for a second cloud, and even then they still had siloed data sets. It’s true that portability for the application tier is getting easier. Kubernetes, orchestration solutions such as Terraform, and monitoring solutions like Datadog have made multi-cloud more manageable. But even in a world where stateless applications can be consistently managed across clouds, having both the data and operations management keep up has been a beast.
So who’s doing multi-cloud?
Still, business units are plowing ahead. More than half (55%) of organizations use multiple public clouds, with 21% using three or more, according to a recent IDG report. Take Panoskin as an example. Panoskin’s software allows users to develop custom VR tours of the world and upload them to Google Street View in minutes. The Chicago-based startup currently has 60+ million scenes in its platform across 100 countries, with ~18,000 photographers uploading 12,000 new tours monthly. The team uses a multi-cloud strategy across Google Cloud and AWS to deliver better scale and tools to its users. Another example is Ticketek. The company is Australia’s leading ticket distributor and can handle up to 300,000 ticket sales in less than 30 minutes. It also has data in various regions across AWS and Google Cloud, as well as a secondary ticketing platform that runs in Google Cloud’s Sydney region.
Advantages of “true” data sharing
Imagine if you could take modern applications like these one step further and deploy a single data layer across AWS and Google Cloud, or Google Cloud and Azure, or across all of the “big three” at the same time. All without the deployment and interoperability hassles. That would give developers the flexibility to choose the best tools and cloud services for the apps they are building. In other words, use AWS Lambda, Google Cloud’s AI Platform, and Microsoft’s Azure DevOps Services within a unified console. That’s cool, right? It’s now possible. You can operate seamlessly across clouds — AWS, Azure, and Google Cloud — with the new multi-cloud clusters capability on MongoDB Atlas. Multi-cloud clusters let developers deploy data and apps across all of the different clouds at the same time, or seamlessly migrate from one cloud to the other without downtime. Here’s why you might want to do that:
Pick and mix the best tools across clouds Developers prefer to work this way, of course. And it gives your company flexibility if, say, a customer prefers a specific cloud provider.
Expand apps globally with high availability and low latency No cloud is spared outages. Distribute data across more regions and sleep better at night. Satisfy local data sovereignty requirements Certain geographies are covered by only one cloud provider (for example, AWS in Italy, Azure in Norway, Google Cloud in Indonesia), so use the one that works.
Benefit from portability Migrate apps from one cloud to another in any situation.
Many developer teams are already using single-cloud clusters; multi-cloud clusters are what’s new. A single-cloud cluster enables continuous backups, automated data tiering, and workload isolation. Multi-cloud clusters on MongoDB Atlas do all that, plus data sharing and resiliency across clouds.
The secret ‘data sharing’ weapon
With multi-cloud clusters, there’s a tight organization between the various cloud platforms, so you can use the app-building tools you want and shift workloads as you see fit. And you can do that without adding data management complexity. Maybe you don’t need to run workloads across multiple public clouds right now — not everyone does. But with multi-cloud clusters, you can rest easier knowing that cross-cloud migration is now a simple option if you need it. It’s only a matter of time before most devs do. If you’re interested in getting up and running with multi-cloud clusters on MongoDB Atlas, learn more here.
