Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2023-12-14 UTC
Este documento é o segundo de três documentos de um conjunto. Ele discute padrões comuns de
arquitetura híbrida e multicloud. Ele também descreve os cenários para os quais
esses padrões são mais adequados. Por fim, ele fornece as práticas recomendadas
que você pode seguir ao implantar essas arquiteturas no Google Cloud.
O conjunto de documentos para padrões de arquitetura híbrida e multicloud consiste
nestas partes:
Padrões de arquitetura híbrida e multicloud: discute padrões comuns de arquitetura a serem
adotados como parte de uma estratégia híbrida e multicloud (este documento).
Cada empresa tem um portfólio exclusivo de cargas de trabalho de aplicativos, que estabelecem
requisitos e restrições na arquitetura de uma configuração híbrida
ou multicloud. Embora você precise projetar e adaptar sua arquitetura para atender a essas
restrições e requisitos, é possível contar com alguns padrões comuns para definir a arquitetura fundamental.
Um padrão de arquitetura é uma maneira replicável de estruturar vários componentes funcionais
de uma solução de tecnologia, aplicativo ou serviço para criar uma
solução reutilizável que atenda a determinados requisitos ou casos de uso. Em geral,
uma solução de tecnologia baseada em nuvem é composta de vários serviços de nuvem distintos
e distribuídos. Esses serviços colaboram para fornecer a
funcionalidade necessária. Nesse contexto, cada serviço é considerado um componente funcional
da solução de tecnologia. Da mesma forma, um aplicativo pode consistir em
várias camadas funcionais, módulos ou serviços, e cada um pode representar um
componente funcional da arquitetura do aplicativo. Essa arquitetura pode ser
padronizada para abordar casos de uso de negócios específicos e atuar como um
padrão fundamental e reutilizável.
Para definir de modo geral um padrão de arquitetura para um aplicativo ou solução,
identifique e defina o seguinte:
Os componentes da solução ou aplicativo.
As funções esperadas para cada componente, como funções de
front-end para fornecer uma interface gráfica do usuário ou funções de back-end para
fornecer acesso a dados.
Como os componentes se comunicam entre si e com sistemas ou usuários externos. Em aplicativos modernos, esses componentes interagem por meio de interfaces ou APIs bem definidas. Há uma ampla variedade de modelos de
comunicação, como os assíncronos e síncronos, os de solicitação-resposta ou os
baseados em fila.
Estas são as duas principais categorias de padrões de arquitetura híbrida e
multicloud:
Padrões de arquitetura distribuída:
esses padrões dependem de uma implantação distribuída de cargas de trabalho ou componentes
de aplicativos. Isso significa que eles executam um aplicativo (ou componentes específicos desse aplicativo)
no ambiente de computação que melhor se adapta ao padrão.
Isso permite que o padrão capitalize as diferentes propriedades e
características de ambientes de computação distribuídos e interconectados.
Padrões de arquitetura redundantes:
esses padrões são baseados em implantações redundantes de cargas de trabalho. Neles,
você implanta os mesmos aplicativos e componentes associados em vários
ambientes de computação. O objetivo é aumentar a capacidade de desempenho
ou a resiliência de um aplicativo ou replicar um ambiente atual
para desenvolvimento e teste.
Ao implementar o padrão de arquitetura selecionado, você deve usar um
arquétipo de implantação
adequado.
Os arquétipos de implantação são zonais, regionais, multirregionais ou globais. Essa
seleção forma a base para a criação de arquiteturas de implantação específicas
do aplicativo. Cada arquétipo de implantação define uma combinação de domínios de
falha em que um aplicativo pode operar. Esses domínios de falha podem
abranger uma ou mais
zonas ou regiões do Google Cloud,
e podem ser expandidos para incluir os data centers locais ou domínios de falha
em outros provedores de nuvem.
[[["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 2023-12-14 UTC."],[[["\u003cp\u003eThis document outlines common hybrid and multicloud architecture patterns, offering insights into their ideal use cases.\u003c/p\u003e\n"],["\u003cp\u003eThe content is the second part of a three-part series, focusing specifically on the patterns themselves, with the other parts covering planning and secure networking.\u003c/p\u003e\n"],["\u003cp\u003eThe document distinguishes between two primary categories of architecture patterns: distributed patterns, which utilize varied computing environments, and redundant patterns, which employ multiple deployments for enhanced performance or resilience.\u003c/p\u003e\n"],["\u003cp\u003eArchitecture patterns are described as repeatable structures that define functional components, their expected roles, and their communication methods within a solution or application, often standardized for specific business use cases.\u003c/p\u003e\n"],["\u003cp\u003eImplementing selected architecture patterns requires choosing a deployment archetype, such as zonal, regional, multi-regional, or global, which defines the failure domains for application operation across various computing environments.\u003c/p\u003e\n"]]],[],null,["# Hybrid and multicloud architecture patterns\n\nThis document is the second of three documents in a set. It discusses common hybrid and\nmulticloud architecture patterns. It also describes the scenarios that these\npatterns are best suited for. Finally, it provides the best practices you can\nuse when deploying such architectures in Google Cloud.\n\nThe document set for hybrid and multicloud architecture patterns consists of\nthese parts:\n\n- [Build hybrid and multicloud architectures](/architecture/hybrid-multicloud-patterns): discusses planning a strategy for architecting a hybrid and multicloud setup with Google Cloud.\n- Hybrid and multicloud architecture patterns: discusses common architecture patterns to adopt as part of a hybrid and multicloud strategy (this document).\n- [Hybrid and multicloud secure networking architecture patterns](/architecture/hybrid-multicloud-secure-networking-patterns): discusses hybrid and multicloud networking architecture patterns from a networking perspective.\n\nEvery enterprise has a unique portfolio of application workloads that place\nrequirements and constraints on the architecture of a hybrid or multicloud\nsetup. Although you must design and tailor your architecture to meet these\nconstraints and requirements, you can rely on some common patterns to define the foundational architecture.\n\nAn architecture pattern is a repeatable way to structure multiple functional\ncomponents of a technology solution, application, or service to create a\nreusable solution that addresses certain requirements or use cases. A\ncloud-based technology solution is often made of several distinct and\ndistributed cloud services. These services collaborate to deliver required\nfunctionality. In this context, each service is considered a functional\ncomponent of the technology solution. Similarly, an application can consist of\nmultiple functional tiers, modules, or services, and each can represent a\nfunctional component of the application architecture. Such an architecture can\nbe standardized to address specific business use cases and serve as a\nfoundational, reusable pattern.\n\nTo generally define an architecture pattern for an application or solution,\nidentify and define the following:\n\n- The components of the solution or application.\n- The expected functions for each component---for example, frontend functions to provide a graphical user interface or backend functions to provide data access.\n- How the components communicate with each other and with external systems or users. In modern applications, these components interact through well-defined interfaces or APIs. There are a wide range of communication models such as asynchronous and synchronous, request-response, or queue-based.\n\nThe following are the two main categories of hybrid and multicloud architecture\npatterns:\n\n- [Distributed architecture patterns](/architecture/hybrid-multicloud-patterns-and-practices/distributed-patterns): These patterns rely on a distributed deployment of workloads or application components. That means they run an application (or specific components of that application) in the computing environment that suits the pattern best. Doing so lets the pattern capitalize on the different properties and characteristics of distributed and interconnected computing environments.\n- Redundant architecture patterns: These patterns are based on redundant deployments of workloads. In these patterns, you deploy the same applications and their components in multiple computing environments. The goal is to either increase the performance capacity or resiliency of an application, or to replicate an existing environment for development and testing.\n\nWhen you implement the architecture pattern that you select, you must use a\nsuitable\n[deployment archetype](/architecture/deployment-archetypes).\nDeployment archetypes are zonal, regional, multi-regional, or global. This\nselection forms the basis for constructing application-specific deployment\narchitectures. Each deployment archetype defines a combination of failure\ndomains within which an application can operate. These failure domains can\nencompass one or more\n[Google Cloud zones or regions](/architecture/infra-reliability-guide/building-blocks#regions_and_zones),\nand can be expanded to include your on-premises data centers or failure domains\nin other cloud providers.\n\nThis series contains the following pages:\n\n- [Distributed architecture patterns](/architecture/hybrid-multicloud-patterns-and-practices/distributed-patterns)\n\n - [Tiered hybrid pattern](/architecture/hybrid-multicloud-patterns-and-practices/tiered-hybrid-pattern)\n - [Partitioned multicloud pattern](/architecture/hybrid-multicloud-patterns-and-practices/partitioned-multicloud-pattern)\n\n - [Analytics hybrid and multicloud pattern](/architecture/hybrid-multicloud-patterns-and-practices/analytics-hybrid-multicloud-pattern)\n\n - [Edge hybrid pattern](/architecture/hybrid-multicloud-patterns-and-practices/edge-hybrid-pattern)\n\n- Redundant architecture patterns\n\n - [Environment hybrid pattern](/architecture/hybrid-multicloud-patterns-and-practices/environment-hybrid-pattern)\n - [Business continuity hybrid and multicloud patterns](/architecture/hybrid-multicloud-patterns-and-practices/business-continuity-patterns)\n - [Cloud bursting pattern](/architecture/hybrid-multicloud-patterns-and-practices/cloud-bursting-pattern)\n\nContributors\n------------\n\nAuthor: [Marwan Al Shawi](https://www.linkedin.com/in/marwanalshawi) \\| Partner Customer Engineer\n\nOther contributors:\n\n- [Saud Albazei](https://www.linkedin.com/in/albazei) \\| Customer Engineer, Application Modernization\n- [Anna Berenberg](https://www.linkedin.com/in/annaberenberg) \\| Engineering Fellow\n- [Marco Ferrari](https://www.linkedin.com/in/ferrarimark) \\| Cloud Solutions Architect\n- [Victor Moreno](https://www.linkedin.com/in/vimoreno) \\| Product Manager, Cloud Networking\n- [Johannes Passing](https://www.linkedin.com/in/johannespassing) \\| Cloud Solutions Architect\n- [Mark Schlagenhauf](https://www.linkedin.com/in/mark-schlagenhauf-63b98) \\| Technical Writer, Networking\n- [Daniel Strebel](https://www.linkedin.com/in/danistrebel) \\| EMEA Solution Lead, Application Modernization\n- [Ammett Williams](https://www.linkedin.com/in/ammett) \\| Developer Relations Engineer\n\n\u003cbr /\u003e"]]
