Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2024-11-20 UTC
Como arquiteto de nuvem ou tomador de decisões, ao implantar um aplicativo
no Google Cloud, é preciso escolher um arquétipo de implantação1 adequado para seu aplicativo. Neste guia, descrevemos seis arquétipos de implantação: zonal, regional, multirregional, global, híbrida e de várias nuvens. Além disso, ele apresenta casos de uso e considerações de design para cada arquétipo de implantação. O guia também fornece uma análise comparativa para ajudar você a escolher os arquétipos de implantação que atendam aos seus requisitos de disponibilidade, custo, desempenho e eficiência operacional.
O que é um arquétipo de implantação?
Um arquétipo de implantação é um modelo abstrato e independente do provedor que você usa
como base para criar arquiteturas de implantação específicas do aplicativo que
atendam aos seus requisitos técnicos e comerciais. Cada arquétipo de implantação especifica uma combinação de domínios de falha em que um aplicativo pode ser executado. Esses
domínios de falha podem ser uma ou mais
zonas ou regiões doGoogle Cloud
e podem se estender para incluir seus data centers locais ou domínios de falha
em outros provedores de nuvem.
O diagrama a seguir mostra seis aplicativos implantados no Google Cloud.
Cada aplicativo usa um arquétipo de implantação que atende aos requisitos específicos.
Como mostra o diagrama anterior, em uma arquitetura que usa o arquétipo de implantação híbrida ou
de várias nuvens, a topologia da nuvem é baseada em um dos arquétipos
básicos: zonal, regional, multirregional ou global. Nesse sentido, os arquétipos de implantação híbrida e de várias nuvens podem ser considerados como arquétipos de implantação compostos que incluem um dos arquétipos básicos.
A escolha de um arquétipo de implantação ajuda a simplificar as decisões subsequentes sobre os Google Cloud produtos e recursos que você precisa usar. Por exemplo, para um aplicativo conteinerizado altamente disponível, se você escolher o arquétipo de implantação regional, os clusters regionais do Google Kubernetes Engine (GKE) serão mais apropriados do que os clusters zonais do GKE.
Ao escolher um arquétipo de implantação para um aplicativo, é preciso considerar as compensações entre fatores como disponibilidade, custo e complexidade operacional.
Por exemplo, se um aplicativo atende a usuários em vários países e precisa de alta
disponibilidade, você pode escolher o arquétipo de implantação multirregional. No entanto, para um aplicativo interno usado por funcionários em uma única região geográfica, é possível priorizar o custo em vez da disponibilidade e, portanto, escolher o arquétipo de implantação regional.
Visão geral dos arquétipos de implantação
As guias a seguir fornecem definições para os arquétipos de implantação e um resumo dos casos de uso e considerações de design para cada um.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-11-20 UTC."],[[["\u003cp\u003eThis guide defines six deployment archetypes—zonal, regional, multi-regional, global, hybrid, and multicloud—for applications in Google Cloud.\u003c/p\u003e\n"],["\u003cp\u003eA deployment archetype is a provider-independent model serving as the foundation for application-specific deployment architectures, dictating where an application can run across various failure domains.\u003c/p\u003e\n"],["\u003cp\u003eChoosing an appropriate deployment archetype involves evaluating trade-offs among factors like availability, cost, performance, and operational complexity based on specific application requirements.\u003c/p\u003e\n"],["\u003cp\u003eHybrid and multicloud archetypes are composite models that build upon basic archetypes like zonal, regional, multi-regional, or global.\u003c/p\u003e\n"],["\u003cp\u003eEach archetype has specific use cases and design considerations, including factors such as high availability, disaster recovery, latency, data residency, and cost optimization.\u003c/p\u003e\n"]]],[],null,["# Google Cloud deployment archetypes\n\nAs a cloud architect or decision maker, when you plan to deploy an application\nin Google Cloud, you need to choose a *deployment archetype* ^[1](#fn1)^ that's suitable\nfor your application. This guide describes six deployment\narchetypes---zonal, regional, multi-regional, global, hybrid, and\nmulticloud, and presents use cases and design considerations for each deployment\narchetype. The guide also provides a comparative analysis to help you choose the\ndeployment archetypes that meet your requirements for availability, cost,\nperformance, and operational efficiency.\n\nWhat is a deployment archetype?\n-------------------------------\n\nA deployment archetype is an abstract, provider-independent model that you use\nas the foundation to build application-specific *deployment architectures* that\nmeet your business and technical requirements. Each deployment archetype\nspecifies a combination of failure domains where an application can run. These\nfailure domains can be one or more\n[Google Cloud zones or regions](/architecture/infra-reliability-guide/building-blocks#regions_and_zones),\nand they can extend to include your on-premises data centers or failure domains\nin other cloud providers.\n\nThe following diagram shows six applications deployed in Google Cloud.\nEach application uses a deployment archetype that meets its specific\nrequirements.\n\nAs the preceding diagram shows, in an architecture that uses the hybrid or\nmulticloud deployment archetype, the cloud topology is based on one of the\n*basic* archetypes: zonal, regional, multi-regional, or global. In this sense,\nthe hybrid and multicloud deployment archetypes can be considered as *composite*\ndeployment archetypes that include one of the basic archetypes.\n| **Note:** Deployment archetypes are different from [location scopes](/architecture/infra-reliability-guide/building-blocks#location_scopes). The location scope of a Google Cloud resource defines its availability boundary. For example, the location scope of a Compute Engine VM is *zonal* . This means that if the Google Cloud zone in which a VM is provisioned has an outage, the availability of the VM is affected. However, by distributing VMs across multiple zones, you can build a highly available architecture that's based on the *regional* deployment archetype.\n\nChoosing a deployment archetype helps to simplify subsequent decisions regarding\nthe Google Cloud products and features that you should use. For example,\nfor a highly available containerized application, if you choose the regional\ndeployment archetype, then regional Google Kubernetes Engine (GKE) clusters are\nmore appropriate than zonal GKE clusters.\n\nWhen you choose a deployment archetype for an application, you need to consider\ntradeoffs between factors like availability, cost, and operational complexity.\nFor example, if an application serves users in multiple countries and needs high\navailability, you might choose the multi-regional deployment archetype. But for\nan internal application that's used by employees in a single geographical\nregion, you might prioritize cost over availability and, therefore, choose the\nregional deployment archetype.\n\nOverview of the deployment archetypes\n-------------------------------------\n\nThe following tabs provide definitions for the deployment archetypes and a\nsummary of the use cases and design considerations for each. \n\n### Zonal\n\nYour application runs within a single Google Cloud zone, as shown in\nthe following diagram:\n\n### Regional\n\nYour application runs independently in two or more zones within a single\nGoogle Cloud region, as shown in the following diagram:\n\n### Multi-regional\n\nYour application runs independently in multiple zones across two or more\nGoogle Cloud regions. You can use [DNS routing policies](/dns/docs/policies-overview#routing_policies) to route\nincoming traffic to the regional load balancers. The regional load balancers\nthen distribute the traffic to the zonal replicas of the application, as shown\nin the following diagram:\n\n### Global\n\nYour application runs across Google Cloud\nregions worldwide, either as a globally distributed (location-unaware) stack or\nas regionally isolated stacks. A global [anycast](https://wikipedia.org/wiki/Anycast) load\nbalancer distributes traffic to the region that's nearest to the user. Other\ncomponents of the application stack can also be global, such as the database,\ncache, and object store.\n\nThe following diagram shows the globally distributed variant of the global\ndeployment archetype. A global anycast load balancer forwards requests to an\napplication stack that's distributed across multiple regions and that uses a\nglobally replicated database.\n\nThe following diagram shows a variant of the global deployment archetype with\nregionally isolated application stacks. A global anycast load balancer forwards\nrequests to an application stack in one of the regions. All the application\nstacks use a single, globally replicated database.\n\n### Hybrid\n\nCertain parts of your application are deployed in Google Cloud,\nwhile other parts run on-premises, as shown in the following diagram. The\ntopology in Google Cloud can use the zonal, regional, multi-regional, or\nglobal deployment archetype.\n\n### Multicloud\n\nSome parts of your application are deployed in Google Cloud, and\nother parts are deployed in other cloud platforms, as shown in the following\ndiagram. The topology in each cloud platform can use the zonal, regional,\nmulti-regional, or global deployment archetype.\n\nContributors\n------------\n\nAuthor: [Kumar Dhanagopal](https://www.linkedin.com/in/kumardhanagopal) \\| Cross-Product Solution Developer\n\nOther contributors:\n\n- [Anna Berenberg](https://www.linkedin.com/in/annaberenberg) \\| Engineering Fellow\n- [Anshu Kak](https://www.linkedin.com/in/anshu-kak-26654a) \\| Distinguished Engineer\n- [Jeff Welsch](https://www.linkedin.com/in/jeffwelsch) \\| Director, Product Management\n- [Marwan Al Shawi](https://www.linkedin.com/in/marwanalshawi) \\| Partner Customer Engineer\n- [Sekou Page](https://www.linkedin.com/in/sekoupage) \\| Outbound Product Manager\n- [Steve McGhee](https://www.linkedin.com/in/stevemcghee) \\| Reliability Advocate\n- [Victor Moreno](https://www.linkedin.com/in/vimoreno) \\| Product Manager, Cloud Networking\n\n\u003cbr /\u003e\n\n*** ** * ** ***\n\n1. Anna Berenberg and Brad Calder, [Deployment Archetypes for Cloud Applications](https://dl.acm.org/doi/10.1145/3498336), ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 [↩](#fnref1)"]]
