Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Last reviewed 2023-12-14 UTC
La ejecución de cargas de trabajo en la nube requiere que los clientes en algunas situaciones tengan una conectividad a Internet rápida y confiable. Para las redes de hoy en día, este requisito no suele ser un desafío en cuanto a la adopción de la nube. Sin embargo, hay situaciones en las que no se puede confiar en la conectividad continua, como las siguientes:
Los barcos y otros vehículos marítimos pueden estar conectados solo de forma intermitente o tener acceso solo a vínculos satelitales de alta latencia.
Las fábricas o centrales eléctricas pueden estar conectadas a Internet. Estas instalaciones pueden tener requisitos de confiabilidad que exceden las reclamaciones de disponibilidad de su proveedor de Internet.
Las tiendas minoristas y los supermercados pueden conectarse solo de manera ocasional o usar vínculos que no proporcionan la confiabilidad o la capacidad de procesamiento necesarias para manejar las transacciones fundamentales para la empresa.
La arquitectura de patrón híbrido perimetral aborda estos desafíos mediante la ejecución de cargas de trabajo fundamentales para el tiempo y la empresa de forma local, en los extremos de la red, a la vez que usa la nube con todos los otros tipos de cargas de trabajo. En una arquitectura híbrida perimetral, el vínculo de Internet es un componente no fundamental que se usa con fines de administración y para sincronizar o subir datos, a menudo de forma asíncrona. Sin embargo, no interviene en transacciones fundamentales para el tiempo ni la empresa.
Ventajas
Ejecutar ciertas cargas de trabajo en el perímetro y otras cargas de trabajo en la nube ofrece varias ventajas:
El tráfico entrante (el traslado de datos desde el perímetro a Google Cloud) puede ser gratuito.
Ejecutar las cargas de trabajo fundamentales para el tiempo y la empresa en el perímetro ayuda a garantizar una baja latencia y autosuficiencia. Aunque la conectividad a Internet falle o no esté disponible de forma temporal, puedes ejecutar todas las transacciones importantes.
Al mismo tiempo, puedes beneficiarte del uso de la nube para una gran parte de tu carga de trabajo general.
Puedes volver a usar las inversiones existentes en equipos de procesamiento y almacenamiento.
Con el tiempo, puedes reducir de forma gradual la fracción de las cargas de trabajo que se ejecutan en el perímetro y moverlas a la nube, ya sea mediante la reelaboración de ciertas aplicaciones o el equipamiento de algunas ubicaciones perimetrales con vínculos de Internet que sean más confiables.
Los proyectos relacionados con la Internet de las cosas (IoT) pueden volverse más rentables mediante el cálculo de datos de manera local. Esto permite que las empresas ejecuten y procesen algunos servicios de forma local en el perímetro, más cerca de las fuentes de datos. También permite que las empresas envíen datos a la nube de forma selectiva, lo que puede ayudar a reducir la capacidad, la transferencia de datos, el procesamiento y los costos generales de la solución de IoT.
El procesamiento perimetral puede actuar como una capa de comunicación intermedia entre los servicios heredados y los modernizados. Por ejemplo, servicios que podrían ejecutar una puerta de enlace de API en contenedores, como Apigee Hybrid. Esto permite que las aplicaciones y los sistemas heredados se integren en los servicios modernizados, como las soluciones de IoT.
prácticas recomendadas
Ten en cuenta las siguientes recomendaciones si implementas el patrón de arquitectura híbrida perimetral:
Si la comunicación es unidireccional, usa el patrón de entrada protegida.
Si la solución consiste en muchos sitios remotos perimetrales que se conectan a Google Cloud a través de la Internet pública, puedes usar una solución de WAN definida por software (SD-WAN). También puedes usar Network Connectivity Center con un router SD-WAN de terceros compatible con un socio de Google Cloud para simplificar el aprovisionamiento y la administración de la conectividad segura a gran escala.
Minimiza las dependencias entre los sistemas que se ejecutan en el perímetro y los sistemas que se ejecutan en el entorno de nube. Cada dependencia puede comprometer las ventajas de confiabilidad y latencia de una configuración híbrida perimetral.
Para administrar y operar múltiples ubicaciones perimetrales de manera eficiente, debes tener un plano de administración y una solución de supervisión centralizados en la nube.
Asegúrate de que las canalizaciones de CI/CD y las herramientas para la implementación y la supervisión sean coherentes en los diferentes entornos perimetrales y de nube.
Considera usar contenedores y Kubernetes cuando corresponda y sea posible, para abstraer las diferencias entre varias ubicaciones perimetrales y también entre ubicaciones perimetrales y la nube. Debido a que Kubernetes proporciona una capa de entorno de ejecución común, puedes desarrollar, ejecutar y operar cargas de trabajo de manera coherente en entornos de computación. También puedes mover las cargas de trabajo entre el perímetro y la nube.
Para simplificar la configuración y la operación híbridas, puedes usar GKE Enterprise para esta arquitectura (si se usan contenedores en todos los entornos).
Considera las posibles opciones de conectividad que tienes para conectar un clúster de GKE Enterprise que se ejecuta en tu entorno local o perimetral a Google Cloud.
Como parte de este patrón, aunque algunos componentes de GKE Enterprise pueden mantenerse durante una interrupción temporal de la conectividad a Google Cloud, no uses GKE Enterprise cuando se desconecte de Google Cloud como un modo de trabajo nominal. Para obtener más información, consulta Impacto de la desconexión temporal de Google Cloud.
Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación en diversos servicios de backend y perimetrales, recomendamos, cuando corresponda, implementar una puerta de enlace de API o un proxy como una fachada.
Esta puerta de enlace o proxy actúa como un punto de control centralizado y realiza las siguientes medidas:
Implementa medidas de seguridad adicionales.
Protege las apps cliente y otros servicios de los cambios en el código de backend.
Facilita registros de auditoría para la comunicación entre todas las aplicaciones entre entornos y sus componentes separados.
Apigee y Apigee Hybrid te permiten alojar y administrar puertas de enlace híbridas y de nivel empresarial en entornos locales, perimetral, otras nubes y entornos de Google Cloud.
Establece una identidad común entre los entornos para que los sistemas puedan autenticarse con seguridad a través de los límites del entorno.
Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas con el uso de los túneles VPN, TLS o de ambos.
[[["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\u003eEdge hybrid architecture allows for running time- and business-critical workloads locally at the edge while utilizing the cloud for other workloads, addressing challenges posed by intermittent or unreliable internet connectivity.\u003c/p\u003e\n"],["\u003cp\u003eThis architecture ensures low latency and self-sufficiency for essential transactions, even during internet outages, while still leveraging cloud benefits for a significant portion of overall workload.\u003c/p\u003e\n"],["\u003cp\u003eImplementing edge hybrid can improve cost efficiency, particularly for IoT projects, by enabling local data processing and selective cloud data transfer.\u003c/p\u003e\n"],["\u003cp\u003eIt's best to minimize dependencies between edge and cloud systems to maximize reliability and latency advantages, while also employing a centralized management and monitoring solution in the cloud for efficient operation.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing containers and Kubernetes, along with a unified API gateway, helps maintain consistency across diverse edge locations and between edge and cloud environments.\u003c/p\u003e\n"]]],[],null,["# Edge hybrid pattern\n\nRunning workloads in the cloud requires that clients in some scenarios have\nfast and reliable internet connectivity. Given today's networks, this\nrequirement rarely poses a challenge for cloud adoption. There are, however,\nscenarios when you can't rely on continuous connectivity, such as:\n\n- Sea-going vessels and other vehicles might be connected only intermittently or have access only to high-latency satellite links.\n- Factories or power plants might be connected to the internet. These facilities might have reliability requirements that exceed the availability claims of their internet provider.\n- Retail stores and supermarkets might be connected only occasionally or use links that don't provide the necessary reliability or throughput to handle business-critical transactions.\n\nThe *edge hybrid* architecture pattern addresses these challenges by running\ntime- and business-critical workloads locally, at the edge of the network, while\nusing the cloud for all other kinds of workloads. In an edge hybrid\narchitecture, the internet link is a noncritical component that is used for\nmanagement purposes and to synchronize or upload data, often asynchronously, but\nisn't involved in time or business-critical transactions.\n\nAdvantages\n----------\n\nRunning certain workloads at the edge and other workloads in the cloud offers\nseveral advantages:\n\n- Inbound traffic---moving data from the edge to Google Cloud---[might be free of charge](/vpc/network-pricing#general).\n- Running workloads that are business- and time-critical at the edge helps ensure low latency and self-sufficiency. If internet connectivity fails or is temporarily unavailable, you can still run all important transactions. At the same time, you can benefit from using the cloud for a significant portion of your overall workload.\n- You can reuse existing investments in computing and storage equipment.\n- Over time, you can incrementally reduce the fraction of workloads that are run at the edge and move them to the cloud, either by reworking certain applications or by equipping some edge locations with internet links that are more reliable.\n- Internet of Things (IoT)-related projects can become more cost-efficient by performing data computations locally. This allows enterprises to run and process some services locally at the edge, closer to the data sources. It also allows enterprises to selectively send data to the cloud, which can help to reduce the capacity, data transfer, processing, and overall costs of the IoT solution.\n- Edge computing can act as an [intermediate communication layer](/solutions/unlocking-legacy-applications#section-3) between legacy and modernized services. For example, services that might be running a containerized API gateway such as Apigee hybrid). This enables legacy applications and systems to integrate with modernized services, like IoT solutions.\n\nBest practices\n--------------\n\nConsider the following recommendations when implementing the edge hybrid\narchitecture pattern:\n\n- If communication is unidirectional, use the [gated ingress pattern](/architecture/hybrid-multicloud-secure-networking-patterns/gated-ingress).\n- If communication is bidirectional, consider the [gated egress and gated ingress pattern](/architecture/hybrid-multicloud-secure-networking-patterns/gated-egress-ingress).\n- If the solution consists of many edge remote sites connecting to Google Cloud over the public internet, you can use a software-defined WAN (SD-WAN) solution. You can also use [Network Connectivity Center](/network-connectivity/docs/network-connectivity-center/concepts/ra-overview) with a third-party SD-WAN router supported by a [Google Cloud partner](/network-connectivity/docs/network-connectivity-center/partners) to simplify the provisioning and management of secure connectivity at scale.\n- Minimize dependencies between systems that are running at the edge and systems that are running in the cloud environment. Each dependency can undermine the reliability and latency advantages of an edge hybrid setup.\n- To manage and operate multiple edge locations efficiently, you should have a centralized management plane and monitoring solution in the cloud.\n- Ensure that CI/CD pipelines along with tooling for deployment and monitoring are consistent across cloud and edge environments.\n- Consider using containers and Kubernetes when applicable and feasible, to abstract away differences among various edge locations and also among edge locations and the cloud. Because Kubernetes provides a common runtime layer, you can develop, run, and operate workloads consistently across computing environments. You can also move workloads between the edge and the cloud.\n - To simplify the hybrid setup and operation, you can use [GKE Enterprise](/anthos/docs/concepts/gke-editions) for this architecture (if containers are used across the environments). Consider [the possible connectivity options](/anthos/clusters/docs/bare-metal/latest/concepts/connect-on-prem-gcp) that you have to connect a GKE Enterprise cluster running in your on-premises or edge environment to Google Cloud.\n- As part of this pattern, although some GKE Enterprise components might sustain during a temporary connectivity interruption to Google Cloud, don't use GKE Enterprises when it's disconnected from Google Cloud as a nominal working mode. For more information, see [Impact of temporary disconnection from Google Cloud](/anthos/docs/concepts/anthos-connectivity).\n- To overcome inconsistencies in protocols, APIs, and authentication mechanisms across diverse backend and edge services, we recommend, where applicable, to deploy an API gateway or proxy as a unifying [facade](/apigee/resources/ebook/api-facade-pattern-register). This gateway or proxy acts as a centralized control point and performs the following measures:\n - Implements additional security measures.\n - Shields client apps and other services from backend code changes.\n - Facilitates audit trails for communication between all cross-environment applications and its decoupled components.\n - Acts as an [intermediate communication layer](/solutions/unlocking-legacy-applications#section-3) between legacy and modernized services.\n - Apigee and [Apigee Hybrid](/apigee/docs/hybrid/v1.10/what-is-hybrid) let you host and manage enterprise-grade and hybrid gateways across on-premises environments, edge, other clouds, and Google Cloud environments.\n- [Establish common identity](/architecture/authenticating-corporate-users-in-a-hybrid-environment) between environments so that systems can authenticate securely across environment boundaries.\n- Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted in transit by using VPN tunnels, [TLS](/architecture/landing-zones/decide-security#option-2-require-layer7), or both."]]