By Fernando Rodriguez, Co-Founder @ GlueOps
In the last few weeks, two of the big three hyperscalers suffered outages: first AWS took down Reddit, Snapchat, and Coinbase, followed by Azure disrupting airlines and retailers like Starbucks, Costco, and Kroger – among thousands of others spread across both platforms.
At GlueOps, we followed the chaos in our news feeds and not in our incident management dashboards.
We built our platform around multi-cloud resilience. Our challenge is building a cloud-agnostic platform that is simple enough to enable broad adoption, not a strategy reserved for companies with armies of platform engineers.
We’ve been on the other side of this. At a previous company, even with nearly 100 platform engineers, we were forced to abandon our multi-cloud strategy. Instead, we treated AWS outages like natural disasters: bad for everyone, so not our unique problem to solve. The complexity wasn’t worth it.
We built GlueOps to prove that trade-off doesn’t have to exist.
Cloud-Agnostic by Design
Thanks to our architecture, the impact of these outages was limited: we couldn’t use resources in us-east-1 or create any new AWS accounts anywhere. Active workloads, pipelines, and environments ran without incident. We continued deploying and spinning up development environments to ship features.
Declarative, GitOps Workflows
Our platform is anchored on GitOps workflows that define environments declaratively and enable us to avoid provider-specific scripts and runbooks. Every workload can run on any cloud without customization: AWS, GCP, Azure, neo-clouds, even bare metal.
This means a regional (or even entire cloud) outage can be remediated with a single config change that redirects deployments to healthy regions or clouds. From there, GitOps automation handles rollout, syncing, and verification.
Migrations across clouds are part of our standard operations, so we didn’t search for DR runbooks or worry about manual deployments. The GlueOps Platform treats cloud providers as interchangeable components rather than one-way doors.
For example, our GlueKube project provides integration testing for our Kubernetes deployments on any cloud and gives us confidence in cross-cloud deployments. Our automated validation ensures that our migration destination has feature and interface parity with the originating cloud, giving us confidence that migrating a workload across clouds will succeed.
Dependency Caching
GlueOps also implements redundancy for upstream registries via a pull-through cache that stores the base images and dependencies required to build and deploy the platform.
Even if an external registry or service like ECR is down, our pipelines continue running from cached artifacts. During the us-east-1 event, this meant uninterrupted build and deploy cycles. Our All-In-One Harbor Registry cache enables us to configure core and replica deployments for dependencies across clouds, ensuring that even an entire provider outage won’t prevent our platform from being deployed.
Achieving Cloud-Independent Reliability
Multi-zone and cross-region deployments within a single provider offer limited protection. When centralized control plane services fail, like AWS’s account management systems or Azure’s Front Door, the impact cascades across all regions. Regions are nominally independent, but a single misconfiguration in the wrong place can compromise the entire platform.
Multi-cloud architectures eliminate single-vendor dependencies. They require tooling that works across providers rather than relying on the proprietary offerings of a single vendor.
They are also the most reliable way to truly own service availability.
The Multi-Cloud Advantage
In pursuit of reliability, many teams stop before multi-zonal architectures; even fewer implement cross-region. Still, regional outages happen and provider-wide issues are an enduring risk due to each provider’s use of centralized systems.
Multi-cloud is powerful insurance against critical, single-vendor dependency. Cloud lock-in means a single provider’s outage is your outage, which is especially painful for teams paying financial penalties for missed SLAs.
During the outages, over 100 services on AWS and approximately 20 on Azure were affected. For many teams, the outage meant stalled deployments, broken APIs, and delayed releases. Even the restaurant down the street lost revenue because Toast was down.
Two major outages in 10 days is uncommon, but failures in the cloud aren’t black swans. They’re inevitable. Hyperscalers are all racing to ship new products, build out infrastructure, and compete on price. Their speed and complexity guarantee mistakes. Betting on a single provider means betting that provider will never have a bad day.
What’s next?
As more of the internet becomes centralized around a few dominant providers, the fragility of complex systems sharing centralized components creates growing risk. Proprietary tooling from major providers accelerates this trend and creates one-way doors for organizations by encouraging commitment to a single cloud.
In the coming weeks, many engineering teams will be asked how they’re preparing for outages like those we’ve experienced in past weeks. Some teams will pursue cloud provider migrations or double down on their current provider’s redundancy tools.
However, the challenge isn’t choosing the best cloud.
It is designing the flexibility to use the best of all of them.
Everything we’ve built to power our multi-cloud deployments is available on GitHub: https://github.com/GlueOps/
Curious what it would take for your organization to go multi-cloud?
fWe’d be happy to share what we’ve built and offer advice: https://schedule.glueops.dev.