It's not that hard. You only need a few rules to make it work.
* Manage your own VPN and don't depend on the vendor's solution.
* Only use base level services that are available on every cloud you want to leverage. Which probably means you're on a container based system and not using anything like Lambda.
Then a service being in another cloud just doesn't matter. You're always making requests via your VPN anyway, if it's in a local cloud or remote cloud it doesn't matter.
You'll feel the egress pricing if you integrate cross cloud services that are chatty. So it really depends on your immediate goals.
If you just want redundancy then you need to keep the resources standing in the backup cloud/AZ and just move your entry point via DNS, in which case you don't really need "cross cloud", just the ability to provision else where.
If you're operating at large scale you should have enough control over your own infrastructure to distribute load to multiple providers. Then if one of them is down, spin up more instances on another one.
If you're operating at small scale, store your backups on another provider, and periodically test that you can quickly restore them to that provider.
This isn't just about redundancy. Doing this is necessary to keep you from getting locked in.
> If you're operating at small scale, store your backups on another provider, and periodically test that you can quickly restore them to that provider.
Sure, but that's not what people mean when they say cross cloud. It usually implies running active workloads.
Orchestrate hundreds of workloads that each depend on one another across several clouds and they reorganize upon a failure introduces a lot of new failure modes.
> Sure, but that's not what people mean when they say cross cloud. It usually implies running active workloads.
For workloads large enough to justify load balancing, that isn't that hard. Things should only rarely care which "cloud" they're running on. The amount of the load assigned to each one is a knob you can turn.
For workloads smaller than that, the primary way to achieve redundancy is failover. Whether it's worth the cost and complexity of making that happen automatically instead of manually doesn't have a universal answer.
But "just use a more reliable provider" doesn't work if being down matters. AWS, Azure and Google Cloud have all had major outages. More than that, sometimes a piece of equipment fails in a way that takes adjacent equipment with it, or there is a fire or a burst pipe. They call it "cloud" but somewhere there is physical hardware under your bits and it can fail. Each failure may only affect a limited number of customers, but those customers can include you. If your systems can't be down, you need a plan in place to have them running again somewhere else in short order. And putting the system you use for this on a different provider can save you from a major provider outage.
* Manage your own VPN and don't depend on the vendor's solution. * Only use base level services that are available on every cloud you want to leverage. Which probably means you're on a container based system and not using anything like Lambda.
Then a service being in another cloud just doesn't matter. You're always making requests via your VPN anyway, if it's in a local cloud or remote cloud it doesn't matter.
You'll feel the egress pricing if you integrate cross cloud services that are chatty. So it really depends on your immediate goals.
If you just want redundancy then you need to keep the resources standing in the backup cloud/AZ and just move your entry point via DNS, in which case you don't really need "cross cloud", just the ability to provision else where.