Uptime is the operational goal of keeping an application available despite interruptions. Availability measures how often a service responds; latency measures how long a response takes. For applications that must run around the clock, even a short outage can have real-world consequences. section 5.1.6 section 7.1
Match the deployment to the outage it must withstand:
- Across availability zones, a GKE cluster can keep running when one zone fails; the Kubernetes scheduler starts additional replicas on surviving nodes to meet configured replica requirements. section 7.1
- Across regions or providers, clusters in multiple environments can address outages beyond a single zone. Anthos offers a common Kubernetes pattern for deployment, scaling, and security, but multiple providers still add operational complexity and skill requirements. section 7.1
- During releases, upgrades, and maintenance, assess effects on availability objectives. Circuit breakers and fault injection can expose application failures before new code is released. section 5.1.6 section 4.8
Set an availability service-level objective (SLO) for a defined measurement period, such as a day, week, or month. Base the target on user needs and credible failure scenarios: approaching 99.99999% availability is expensive, and upgrade, rollback, and security-update risks affect what is realistic. The objective helps teams decide when to roll back, hotfix, or prioritize reliability work. section 5.1.6
A provider-level outage
A banking application may need more than a single-cloud plan if two hours of downtime during a cloud outage is unacceptable. One multicloud design connects Anthos GKE, GKE on AWS, and GKE on-prem through a service mesh. It can preserve application operation during a provider outage, but does not by itself promise that the application remains reachable from the internet. section 7.1 section 7.1.1
The multicloud availability diagram shows the service-mesh connectivity used in the provider-level design. section 7.1.1
