Why Your E-Commerce Site Needs an Active-Active Multi-Cloud Approach This Holiday Season

For e-commerce leaders, the holidays bring two certainties: a massive influx of shoppers and heightened risk of cloud provider outages. Major cloud disruptions seem to be becoming more common and more devastating. The AWS US-East-1 region, for instance, has a history of significant holiday season disruptions. Similarly, every year around January, Microsoft Azure tends to have network latency issues or network outages due to its release or testing plan in certain regions. And we need only look back to this past June, when a major Google Cloud outage impacted a wide array of applications, to be reminded that no single provider is immune.

If you’re in charge of an e-commerce operation, you don’t want to find out that even though you have everything set up correctly, something has stopped working during the most critical time of the year. These cloud provider outage and issue trends might not be on your radar, and frankly, they shouldn’t be. If you’re a site reliability engineer, you shouldn’t have to worry about whether a cloud platform outage will impact your application, nor should you be trying to adjust your infrastructure on the fly during an issue. Instead, you should reexamine what you know about multi-cloud.

Multi-cloud applications

If your organization is paying AWS, Azure, and GCP fees, you do indeed have all three clouds at your disposal. That said, while you may be using all three, it’s important to examine what happens when you go one layer deeper. Are some of your applications AWS-, Azure-, or GCP-specific? Will they keep working if one cloud provider is down and you need to quickly switch to another?

Your application must work perfectly on any of the clouds. That’s what a true multi-cloud setup is. If you want to be cloud-agnostic, you can’t just pay for multi-cloud; you have to make sure that your applications are also multi-cloud.

Furthermore, relying on a single provider introduces inherent constraints on compute capacity, API rate limiting, and regional availability. A true multi-cloud architecture increases your aggregate compute power and provides resilience against these constraints. It unlocks your ability to scale on demand beyond the limits of a single provider, rapidly expand capacity across geographies, and to ensure consistent performance during peak shopping days. But having a portable, cloud-agnostic application is only the first step; the next is deploying it in a truly resilient architecture.

Scaling to an active-active approach

This requires some serious preparation by DevOps. It’s incredibly difficult to have a 100% accurate Business Continuity Disaster Recovery (BCDR) strategy since when it comes to running your operations live, there are multiple points of failure. You don’t want to test your BCDR strategy in an outage, so you might feel that all you can really do is predict possible scenarios and then prepare accordingly.

My advice to site reliability engineers is to architect for failure by default. This means having a secondary or even a tertiary cloud running in an active state. A BCDR strategy confined to a single provider is a single point of failure; if the provider’s control plane or network backbone fails, your entire recovery plan is rendered useless.

During the holiday season, it’s common for the number of visitors to suddenly increase, forcing your platform or application to start working at a reduced capability. If you have already created a copy of your working application, a secondary, you can switch to performing load balancing so that you can divert some requests to the other instance of your application.

This active-active approach means you have your full-blown product duplicated, running somewhere else. If your primary cloud provider experiences a severe degradation or outage, you can seamlessly shift 100% of your traffic to the secondary provider via DNS or a global load balancer, making it the primary entry point with no disruption to your customers.

The real cost of not going multi-cloud

While the cost of running a secondary cloud is not trivial, it is insignificant compared to the business impact of a major outage: apologizing to customers after a reliability failure, trying to assure them it won’t happen again, and convincing them not to leave you for one of your competitors. Let’s also not forget all the missed revenue from the lost sales you can’t win back. At FluidCloud, I have seen this scenario play out time and again: companies invest heavily in a single provider, only to find themselves on the wrong side of an outage with no immediate recourse.

That said, it’s difficult enough to control your costs if you’re just using one cloud provider; your cloud costs most likely look like an exponential graph. If you adopt multiple clouds, that exponential graph is only going to look even steeper.

When you duplicate your infrastructure from your primary cloud, you naturally don’t want your costs to double. I thus recommend focusing on cheaper clouds that offer competitive performance at a lower price point. If you have a secondary running in a cheaper cloud, you will still have full active-active redundancy, but at a cheaper cost. It’s a win-win.

Final Thoughts

Running your applications active-active across multiple cloud providers does not simply mean creating a backup. It means building for real-time resilience, ensuring your business does not have a single point of failure, and being able to offer consistent speed even during traffic spikes.

This holiday season, don’t just hope for reliability. Build for it. Engineer your systems to run consistently, no matter which cloud provider or region falters. Deliver a flawless customer experience by embracing a true active-active, multi-cloud architecture.