Patrones de arquitectura híbridos y de múltiples nubes
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Last reviewed 2023-12-14 UTC
Este documento es el segundo de tres documentos de un conjunto. Se analizan patrones de arquitectura híbridos y de múltiples nubes comunes. También se describen las situaciones para las que estos patrones son más adecuados. Por último, se proporcionan las prácticas recomendadas que puedes usar cuando implementes esas arquitecturas en Google Cloud.
El conjunto de documentos para patrones de arquitectura híbridos y de múltiples nubes consta de estas partes:
Patrones de arquitectura híbridos y de múltiples nubes: se analizan los patrones de arquitectura comunes para adoptar como parte de una estrategia de nube híbrida y múltiples nubes (este documento).
Cada empresa tiene una cartera única de cargas de trabajo de aplicaciones que definen requisitos y restricciones a la arquitectura de una configuración de nube híbrida o de múltiples nubes. Aunque debes diseñar y adaptar tu arquitectura para que cumpla con estas restricciones y requisitos, puedes basarte en algunos patrones comunes para definir la arquitectura básica.
Un patrón de arquitectura es una forma repetible de estructurar varios componentes funcionales de una solución tecnológica, una aplicación o un servicio para crear una solución reutilizable que aborde ciertos requisitos o casos de uso. Una solución tecnológica basada en la nube a menudo está compuesta por varios servicios en la nube distintos y distribuidos. Estos servicios colaboran para entregar la funcionalidad requerida. En este contexto, cada servicio se considera un componente funcional de la solución tecnológica. De manera similar, una aplicación puede constar de varios niveles, módulos o servicios funcionales, y cada uno puede representar un componente funcional de la arquitectura de la aplicación. Esta arquitectura se puede estandarizar para que aborde casos de uso empresariales específicos y funcione como un patrón fundamental y reutilizable.
Para definir en general un patrón de arquitectura para una aplicación o solución, identifica y define lo siguiente:
Los componentes de la solución o aplicación.
Las funciones esperadas para cada componente, por ejemplo, funciones de frontend que proporcionan una interfaz gráfica de usuario o funciones de backend a fin de proporcionar acceso a los datos
Cómo los componentes se comunican entre sí y con usuarios o sistemas externos. En las aplicaciones modernas, estos componentes interactúan a través de interfaces o APIs bien definidas. Existe una amplia variedad de modelos de comunicación, como asíncronos y síncronos, de solicitud y respuesta, o basados en colas.
Las siguientes son las dos categorías principales de patrones de arquitectura híbridos y de múltiples nubes:
Patrones de arquitectura distribuidos: Estos patrones se basan en una implementación distribuida de cargas de trabajo o componentes de aplicaciones. Esto significa que ejecutan una aplicación (o componentes específicos de esa aplicación) en el entorno de computación que mejor se adapta al patrón.
Si lo haces, el patrón podrá aprovechar las diferentes propiedades y características de los entornos de computación interconectados y distribuidos.
Patrones de arquitectura redundante: estos patrones se basan en implementaciones redundantes de cargas de trabajo. En estos patrones, debes implementar las mismas aplicaciones y sus componentes en varios entornos de computación. El objetivo es aumentar la capacidad de rendimiento o la resiliencia de una aplicación o replicar un entorno existente para el desarrollo y las pruebas.
Cuando implementes el patrón de arquitectura que selecciones, debes usar un arquetipo de implementación adecuado.
Los arquetipos de implementación son zonales, regionales, multirregionales o globales. Esta selección forma la base para construir arquitecturas de implementación específicas de la aplicación. Cada arquetipo de implementación define una combinación de dominios con fallas dentro de los cuales puede operar una aplicación. Estos dominios con fallas pueden abarcar una o más zonas o regiones de Google Cloud y se pueden expandir para incluir tus centros de datos locales o dominios con fallas en otros proveedores de servicios en la nube.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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"]]
