Google Cloud deployment archetypes

Last reviewed 2024-11-20 UTC

As a cloud architect or decision maker, when you plan to deploy an applicationin Google Cloud, you need to choose adeployment archetype1 that's suitablefor your application. This guide describes six deploymentarchetypes—zonal, regional, multi-regional, global, hybrid, andmulticloud, and presents use cases and design considerations for each deploymentarchetype. The guide also provides a comparative analysis to help you choose thedeployment archetypes that meet your requirements for availability, cost,performance, and operational efficiency.

What is a deployment archetype?

A deployment archetype is an abstract, provider-independent model that you useas the foundation to build application-specificdeployment architectures thatmeet your business and technical requirements. Each deployment archetypespecifies a combination of failure domains where an application can run. Thesefailure domains can be one or moreGoogle Cloud zones or regions,and they can extend to include your on-premises data centers or failure domainsin other cloud providers.

The following diagram shows six applications deployed in Google Cloud.Each application uses a deployment archetype that meets its specificrequirements.

Applications in Google Cloud deployed using different deployment archetypes.

As the preceding diagram shows, in an architecture that uses the hybrid ormulticloud deployment archetype, the cloud topology is based on one of thebasic archetypes: zonal, regional, multi-regional, or global. In this sense,the hybrid and multicloud deployment archetypes can be considered ascompositedeployment archetypes that include one of the basic archetypes.

Note: Deployment archetypes are different fromlocation scopes.The location scope of a Google Cloud resource defines its availabilityboundary. For example, the location scope of a Compute Engine VM iszonal.This means that if the Google Cloud zone in which a VM is provisioned hasan outage, the availability of the VM is affected. However, by distributing VMsacross multiple zones, you can build a highly available architecture that'sbased on theregional deployment archetype.

Choosing a deployment archetype helps to simplify subsequent decisions regardingthe Google Cloud products and features that you should use. For example,for a highly available containerized application, if you choose the regionaldeployment archetype, then regional Google Kubernetes Engine (GKE) clusters aremore appropriate than zonal GKE clusters.

When you choose a deployment archetype for an application, you need to considertradeoffs between factors like availability, cost, and operational complexity.For example, if an application serves users in multiple countries and needs highavailability, you might choose the multi-regional deployment archetype. But foran internal application that's used by employees in a single geographicalregion, you might prioritize cost over availability and, therefore, choose theregional deployment archetype.

Overview of the deployment archetypes

The following tabs provide definitions for the deployment archetypes and asummary of the use cases and design considerations for each.

Zonal

Your application runs within a single Google Cloud zone, as shown inthe following diagram:

Zonal deployment archetype
Use cases
  • Development and test environments.
  • Applications that don't need high availability.
  • Low-latency networking between application components.
  • Migrating commodity workloads.
  • Applications that use license-restricted software.
Design considerations

  • Downtime during zone outages.

    For business continuity, you can provision a passive replica of theapplication in another zone in the same region. If a zone outage occurs, you canrestore the application to production by using the passive replica.

More information

See the following sections:

Regional

Your application runs independently in two or more zones within a singleGoogle Cloud region, as shown in the following diagram:

Regional deployment archetype
Use cases
  • Highly available applications that serves users within a geographic area.
  • Compliance with data residency and sovereignty requirements.
Design considerations

  • Downtime during region outages.

    For business continuity, you can back up the application and data to anotherregion. If a region outage occurs, you can use the backups in the other regionto restore the application to production.

  • Cost and effort to provision and manage redundant resources.
More information

See the following sections:

Multi-regional

Your application runs independently in multiple zones across two or moreGoogle Cloud regions. You can useDNS routing policies to routeincoming traffic to the regional load balancers. The regional load balancersthen distribute the traffic to the zonal replicas of the application, as shownin the following diagram:

Multi-regional deployment archetype
Use cases
  • Highly available application with geographically dispersed users.
  • Applications that require low end-user latency experience.
  • Compliance with data residency and sovereignty requirements by using ageofenced DNS routing policy.
Design considerations
  • Cost for cross-region data transfer and data replication.
  • Operational complexity.
More information

See the following sections:

Global

Your application runs across Google Cloudregions worldwide, either as a globally distributed (location-unaware) stack oras regionally isolated stacks. A globalanycast loadbalancer distributes traffic to the region that's nearest to the user. Othercomponents of the application stack can also be global, such as the database,cache, and object store.

The following diagram shows the globally distributed variant of the globaldeployment archetype. A global anycast load balancer forwards requests to anapplication stack that's distributed across multiple regions and that uses aglobally replicated database.

Global deployment archetype: Globally distributed stack

The following diagram shows a variant of the global deployment archetype withregionally isolated application stacks. A global anycast load balancer forwardsrequests to an application stack in one of the regions. All the applicationstacks use a single, globally replicated database.

Global deployment archetype: Regionally isolated stacks
Use cases
  • Highly available applications that serve globally dispersed users.
  • Opportunity to optimize cost and simplify operations by using globalresources instead of multiple instances of regional resources.
Design considerationsCosts for cross-region data transfer and data replication.
More information

See the following sections:

Hybrid

Certain parts of your application are deployed in Google Cloud,while other parts run on-premises, as shown in the following diagram. Thetopology in Google Cloud can use the zonal, regional, multi-regional, orglobal deployment archetype.

Hybrid deployment archetype
Use cases
  • Disaster recovery (DR) site for on-premises workloads.
  • On-premises development for cloud applications.
  • Progressive migration to the cloud for legacy applications.
  • Enhancing on-premises applications with cloud capabilities.
Design considerations
  • Setup effort and operational complexity.
  • Cost of redundant resources.
More information

See the following sections:

Multicloud

Some parts of your application are deployed in Google Cloud, andother parts are deployed in other cloud platforms, as shown in the followingdiagram. The topology in each cloud platform can use the zonal, regional,multi-regional, or global deployment archetype.

Multicloud deployment archetype
Use cases
  • Google Cloud as the primary site and another cloud as a DRsite.
  • Enhancing applications with advanced Google Cloud capabilities.
Design considerations
  • Setup effort and operational complexity.
  • Cost of redundant resources and cross-cloud network traffic.
More information

See the following sections:

Contributors

Author:Kumar Dhanagopal | Cross-Product Solution Developer

Other contributors:

  1. Anna Berenberg and Brad Calder,Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 ↩

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2024-11-20 UTC.