Having a two cloud providers isn’t going to save you from an outage. The public cloud providers (Microsoft Azure, Amazon AWS, Google GCP, etc.) have specifically designed their networks so that an outage at one region doesn’t impact other regions.
The day before US Thanksgiving (November 25, 2020), AWS had a major outage where the east-us facility suffered an outage for several hours. But you’ll notice something very interesting about this outage. No other AWS region was impacted by this outage. This is a very important distinction, as it shows that having multiple regions within AWS would give a solid Disaster Recovery strategy a great fail-over experience.
This same applies to Microsoft Azure as they had an outage just a day or so after the AWS outage Microsoft Azure has its own issue. The North South Africa region had an outage due to torrential rain which cases flooding at some of the buildings which host the Azure data centers, according to the incident notices that sent out. Just like the AWS outage, the Microsoft Azure outage only affected the one region that was effected. None of the other regions were effected by this. This should that if hosted within Microsoft Azure in the North South Africa region and another region a successful Disaster Recovery fail-over could have been executed without issue.
But we really want to be in two clouds
Having cloud services in two different cloud platforms is going to be expensive, complex, and very limiting.
Building services in multiple cloud platforms makes for an expensive solution. Not only do you need to run all services in effectively an active/active configuration between the two cloud services, but the staff needs to be well versed in both cloud platforms. This means that either the company would need to have people on staff that know both platforms, which usually means two (sets) of people. This also means that any additional discounts that you may be able to get by paying for all the cloud hosting won’t be available due to the fact that the workload is spread across the two different clouds.
All the cloud providers also charge more to egress beyond the border of the cloud at a higher rate then between the different regions of the cloud. This means that the expense of moving data between the production and disaster recovery site will cost more then if both sites were hosted within the same cloud.
Having services in two different clouds makes the cloud solution incredibility complex. Failing over a website between clouds gets difficult. In order to redirect web traffic between web servers running in two different clouds you’d need some sort of global load balancer such as the Microsoft Azure Traffic Manager. This by its nature is going to give you a “single point of failure” (it won’t really because these things are designed to not give you a single point of failure) as you have to pick one of these services to use.
By using two different clouds you need to choose between only using Infrastructure as a Service (IaaS) only, or attempting to use the Platform as a Service (PaaS) offerings (for things like website hosting) but only using the features that exist within both of your cloud platforms. Limiting yourself to IaaS takes away a lot of the benefit of using the cloud.
By using the PaaS offerings that will require having two different deployment processes, as well as QA and testing platforms in both cloud platforms.
Websites are one thing, databases are a whole separate problem. In order to have databases in two different clouds your only real option is to use Infrastructure as a Service as syncing between the PaaS SQL Server database in any two cloud platforms is going to be basically impossible to setup scale out as well as support some sort of fail-over. All three of the major cloud platforms have multi-site options for their PaaS databases offerings, and they should as regional failures happen, and you need a way to fail-over the database to the other region which is configured for disaster recovery.
What this comes down to, is that you don’t need to build your solution to support multiple clouds. It’s going to be harder to configure, harder to implement, and give you less options when developing your solution. Using a consulting partner that is well versed in the various cloud platforms is a great way to not be lured into building a solution that scales multiple cloud platforms.