Patrones de arquitectura híbridos y multinube

Last reviewed 2024-11-27 UTC

En esta página se ofrece una vista de una sola página de todas las páginas de Crea arquitecturas híbridas y multinube con Google Cloud. Puedes imprimir esta página o guardarla en formato PDF mediante la función de impresión de tu navegador y seleccionando la opción Guardar como PDF. Esta página no proporciona un panel de índice en la parte derecha.

Este documento es el segundo de un conjunto de tres documentos. En él se analizan los patrones de arquitectura híbridos y multinube más habituales. También se describen los casos en los que estos patrones son más adecuados. Por último, se indican las prácticas recomendadas que puede usar al desplegar este tipo de arquitecturas en Google Cloud.

El conjunto de documentos sobre patrones de arquitectura híbridos y multinube consta de las siguientes partes:

• Crea arquitecturas híbridas y multinube: se explica cómo planificar una estrategia para diseñar una configuración híbrida y multinube con Google Cloud.
• Patrones de arquitectura híbridos y multinube: se analizan los patrones de arquitectura habituales que se pueden adoptar como parte de una estrategia híbrida y multinube (este documento).
• Patrones de arquitectura de redes seguras híbridas y multinube: se analizan los patrones de arquitectura de redes híbridas y multinube desde una perspectiva de redes.

Cada empresa tiene una cartera única de cargas de trabajo de aplicaciones que imponen requisitos y restricciones a la arquitectura de una configuración híbrida o multinube. Aunque debes diseñar y adaptar tu arquitectura para cumplir estas restricciones y requisitos, puedes usar 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, aplicación o servicio tecnológicos para crear una solución reutilizable que satisfaga determinados requisitos o casos de uso. Una solución tecnológica basada en la nube suele estar formada por varios servicios en la nube distintos y distribuidos. Estos servicios colaboran para ofrecer la funcionalidad necesaria. En este contexto, cada servicio se considera un componente funcional de la solución tecnológica. Del mismo modo, una aplicación puede constar de varios niveles funcionales, módulos o servicios, y cada uno de ellos puede representar un componente funcional de la arquitectura de la aplicación. Esta arquitectura se puede estandarizar para abordar casos prácticos empresariales específicos y servir como patrón fundamental y reutilizable.

Para definir un patrón de arquitectura general para una aplicación o solución, identifica y define lo siguiente:

• Los componentes de la solución o la aplicación.
• Las funciones esperadas de cada componente (por ejemplo, las funciones del frontend para proporcionar una interfaz gráfica de usuario o las funciones del backend para proporcionar acceso a los datos).
• Cómo se comunican los componentes entre sí y con sistemas o usuarios externos. En las aplicaciones modernas, estos componentes interactúan a través de interfaces o APIs bien definidas. Hay una gran variedad de modelos de comunicación, como los asíncronos y síncronos, los de solicitud-respuesta o los basados en colas.

A continuación, se muestran las dos categorías principales de patrones de arquitectura híbrida y multinube:

• Patrones de arquitectura distribuida: estos patrones se basan en un despliegue distribuido 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 adapte al patrón. De esta forma, el patrón puede aprovechar las diferentes propiedades y características de los entornos de computación distribuidos e interconectados.
• Patrones de arquitectura redundantes: estos patrones se basan en implementaciones redundantes de cargas de trabajo. En estos patrones, se implementan las mismas aplicaciones y sus componentes en varios entornos informáticos. El objetivo es aumentar el rendimiento o la capacidad de recuperación de una aplicación, o bien replicar un entorno 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 despliegue son zonales, regionales, multirregionales o globales. Esta selección constituye la base para crear arquitecturas de implementación específicas de la aplicación. Cada arquetipo de implementación define una combinación de dominios de errores en los que puede operar una aplicación. Estos dominios de error pueden abarcar una o varias Google Cloud zonas o regiones y se pueden ampliar para incluir tus centros de datos on-premise o dominios de error de otros proveedores de servicios en la nube.

Esta serie contiene las siguientes páginas:

• Patrones de arquitectura distribuida

  • Patrón híbrido por niveles

  • Patrón multinube con particiones

  • Patrón híbrido y multinube de analíticas

  • Patrón híbrido de perímetro

• Patrones de arquitectura redundantes

  • Patrón híbrido de entorno
  • Patrones híbridos y multinube para la continuidad empresarial
  • Patrón de bursting en la nube

Colaboradores

Autor: Marwan Al Shawi | Ingeniero de clientes de partners

Otros colaboradores:

• Saud Albazei | Ingeniero de clientes, Modernización de aplicaciones
• Anna Berenberg | Ingeniera
• Marco Ferrari | Arquitecto de soluciones en la nube
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Arquitecto de soluciones en la nube
• Mark Schlagenhauf | Redactor técnico de redes
• Daniel Strebel | Líder de soluciones de EMEA, Modernización de aplicaciones
• Ammett Williams | Ingeniero de Relaciones con Desarrolladores

Patrones de arquitectura distribuida

Cuando migres de un entorno informático que no sea híbrido ni multinube a una arquitectura híbrida o multinube, primero debes tener en cuenta las limitaciones de tus aplicaciones actuales y cómo podrían provocar fallos en las aplicaciones. Esta consideración es más importante cuando tus aplicaciones o componentes de aplicaciones funcionan de forma distribuida en diferentes entornos. Una vez que hayas analizado tus limitaciones, elabora un plan para evitarlas o superarlas. Asegúrate de tener en cuenta las funciones únicas de cada entorno informático en una arquitectura distribuida.

Nota: Puedes aplicar diferentes patrones de arquitectura a distintas aplicaciones en función de sus casos prácticos y requisitos. Esto significa que es posible que tengas varias aplicaciones con diferentes patrones de arquitectura híbrida y multinube que funcionen al mismo tiempo.

Factores del diseño

Las siguientes consideraciones de diseño se aplican a los patrones de implementación distribuida. En función de la solución de destino y los objetivos de negocio, la prioridad y el efecto de cada consideración pueden variar.

Latencia

En cualquier patrón de arquitectura que distribuya componentes de aplicaciones (front-ends, back-ends o microservicios) en diferentes entornos informáticos, puede producirse latencia en la comunicación. Esta latencia se ve afectada por la conectividad de la red híbrida (Cloud VPN y Cloud Interconnect) y la distancia geográfica entre el sitio on‐premise y las regiones de la nube, o entre las regiones de la nube en una configuración multinube. Por lo tanto, es fundamental evaluar los requisitos de latencia de tus aplicaciones y su sensibilidad a los retrasos de la red. Las aplicaciones que pueden tolerar la latencia son más adecuadas para el despliegue distribuido inicial en un entorno híbrido o multinube.

Arquitectura de estado temporal frente a arquitectura de estado final

Para especificar las expectativas y las posibles implicaciones en cuanto a costes, escala y rendimiento, es importante analizar qué tipo de arquitectura necesitas y la duración prevista en la fase de planificación. Por ejemplo, si tienes previsto usar una arquitectura híbrida o multicloud durante mucho tiempo o de forma permanente, te recomendamos que utilices Cloud Interconnect. Para reducir los costes de transferencia de datos salientes y optimizar el rendimiento de la red de conectividad híbrida, Cloud Interconnect ofrece descuentos en los gastos de transferencia de datos salientes que cumplan las condiciones de la tarifa de transferencia de datos con descuento.

Fiabilidad

La fiabilidad es un factor importante a la hora de diseñar sistemas informáticos. La disponibilidad del tiempo de actividad es un aspecto esencial de la fiabilidad del sistema. En Google Cloud, puedes aumentar la resiliencia de una aplicación desplegando componentes redundantes de esa aplicación en varias zonas de una sola región¹ o en varias regiones, con funciones de conmutación. La redundancia es uno de los elementos clave para mejorar la disponibilidad general de una aplicación. En el caso de las aplicaciones con una configuración distribuida en entornos híbridos y multinube, es importante mantener un nivel de disponibilidad coherente.

Para mejorar la disponibilidad de un sistema en un entorno local o en otros entornos de nube, plantéate qué redundancia de hardware o software (con mecanismos de conmutación por error) necesitas para tus aplicaciones y sus componentes. Lo ideal es que tengas en cuenta la disponibilidad de un servicio o una aplicación en los distintos componentes y la infraestructura de asistencia (incluida la disponibilidad de la conectividad híbrida) en todos los entornos. Este concepto también se conoce como disponibilidad compuesta de una aplicación o un servicio.

En función de las dependencias entre los componentes o servicios, la disponibilidad compuesta de una aplicación puede ser mayor o menor que la de un servicio o componente individual. Para obtener más información, consulta Disponibilidad compuesta: cómo calcular la disponibilidad general de la infraestructura de la nube.

Para alcanzar el nivel de fiabilidad del sistema que quieras, define métricas de fiabilidad claras y diseña aplicaciones que se recuperen automáticamente y resistan las interrupciones de forma eficaz en los distintos entornos. Para definir las formas adecuadas de medir la experiencia de cliente de tus servicios, consulta el artículo Define la fiabilidad en función de los objetivos de experiencia de usuario.

Conectividad híbrida y multinube

Los requisitos de la comunicación entre los componentes de las aplicaciones distribuidas deben influir en la selección de una opción de conectividad de red híbrida. Cada opción de conectividad tiene sus ventajas e inconvenientes, así como factores específicos que se deben tener en cuenta, como el coste, el volumen de tráfico, la seguridad, etc. Para obtener más información, consulta la sección Consideraciones sobre el diseño de la conectividad.

Facilidad de gestión

Las herramientas de gestión y monitorización coherentes y unificadas son esenciales para que las configuraciones híbridas y multinube tengan éxito (con o sin portabilidad de cargas de trabajo). A corto plazo, estas herramientas pueden aumentar los costes de desarrollo, pruebas y operaciones. Técnicamente, cuantos más proveedores de servicios en la nube uses, más compleja será la tarea de gestionar tus entornos. La mayoría de los proveedores de nube pública no solo ofrecen distintas funciones, sino también diferentes herramientas, acuerdos de nivel de servicio y APIs para gestionar los servicios en la nube. Por lo tanto, sopesa las ventajas estratégicas de la arquitectura seleccionada frente a la complejidad a corto plazo y las ventajas a largo plazo.

Coste

Cada proveedor de servicios en la nube de un entorno multinube tiene sus propias métricas y herramientas de facturación. Para mejorar la visibilidad y unificar los paneles de control, te recomendamos que uses herramientas de gestión y optimización de costes multicloud. Por ejemplo, al crear soluciones centradas en la nube en varios entornos de nube, los productos, los precios, los descuentos y las herramientas de gestión de cada proveedor pueden generar incoherencias en los costes entre esos entornos.

Te recomendamos que utilices un único método bien definido para calcular los costes totales de los recursos de la nube y que proporciones visibilidad de los costes. La visibilidad de los costes es esencial para optimizarlos. Por ejemplo, si combinas los datos de facturación de los proveedores de servicios en la nube que usas y utilizas el Google Cloud bloque de gestión de costes en la nube de Looker, puedes crear una vista centralizada de tus costes multicloud. Esta vista puede ayudarte a obtener una vista de informes consolidada de tu gasto en varias nubes. Para obtener más información, consulta el artículo Estrategia para optimizar de forma eficaz la gestión de los costes de facturación en la nube.

También te recomendamos que uses las prácticas de FinOps para que los costes sean visibles. Como parte de una práctica de FinOps sólida, un equipo central puede delegar la toma de decisiones sobre la optimización de recursos en cualquier otro equipo que participe en un proyecto para fomentar la responsabilidad individual. En este modelo, el equipo central debe estandarizar el proceso, los informes y las herramientas de optimización de costes. Para obtener más información sobre los diferentes aspectos de la optimización de costes y las recomendaciones que debe tener en cuenta, consulte Google Cloud Well-Architected Framework: Cost optimization (Marco de trabajo Well-Architected: optimización de costes).

Migración de datos

La migración de datos es un factor importante que se debe tener en cuenta en la estrategia híbrida y multinube, así como en la planificación de la arquitectura, sobre todo en los sistemas distribuidos. Las empresas deben identificar sus diferentes casos prácticos, los datos que los respaldan y cómo se clasifican los datos (en el caso de los sectores regulados). También deben tener en cuenta cómo pueden afectar el almacenamiento, el uso compartido y el acceso a los datos de los sistemas distribuidos en los distintos entornos al rendimiento de las aplicaciones y a la coherencia de los datos. Estos factores pueden influir en la aplicación y en la arquitectura de la canalización de datos. El conjunto completo de opciones de movimiento de datos deGoogle Cloudpermite a las empresas satisfacer sus necesidades específicas y adoptar arquitecturas híbridas y multinube sin sacrificar la sencillez, la eficiencia ni el rendimiento.

Seguridad

Al migrar aplicaciones a la nube, es importante tener en cuenta las funciones de seguridad de la nube, como la coherencia, la observabilidad y la visibilidad de seguridad unificada. Cada proveedor de nube pública tiene su propio enfoque, sus prácticas recomendadas y sus funciones de seguridad. Es importante analizar y alinear estas funciones para crear una arquitectura de seguridad estándar y funcional. Los controles de gestión de identidades y accesos, el cifrado de datos, el análisis de vulnerabilidades y el cumplimiento de las normativas del sector también son aspectos importantes de la seguridad en la nube.

Cuando planifiques una estrategia de migración, te recomendamos que analices los aspectos que hemos mencionado anteriormente. Pueden ayudarte a minimizar las probabilidades de introducir complejidades en la arquitectura a medida que crecen tus aplicaciones o volúmenes de tráfico. Además, diseñar y crear una zona de aterrizaje es casi siempre un requisito previo para desplegar cargas de trabajo empresariales en un entorno de nube. Una zona de aterrizaje ayuda a tu empresa a desplegar, usar y escalar servicios en la nube de forma más segura en varias áreas, e incluye diferentes elementos, como identidades, gestión de recursos, seguridad y redes. Para obtener más información, consulta el artículo sobre el diseño de la zona de aterrizaje en Google Cloud.

En los siguientes documentos de esta serie se describen otros patrones de arquitectura distribuida:

• Patrón híbrido por niveles
• Patrón multinube con particiones
• Patrón híbrido y multinube de analíticas
• Patrón híbrido de perímetro

Patrón híbrido por niveles

Los componentes de la arquitectura de una aplicación se pueden clasificar como frontend o backend. En algunos casos, estos componentes se pueden alojar para que funcionen en diferentes entornos informáticos. Como parte del patrón de arquitectura híbrida por niveles, los entornos de computación se encuentran en un entorno de computación privado on‐premise y en Google Cloud.

Los componentes de la aplicación frontend se exponen directamente a los usuarios finales o a los dispositivos. Por este motivo, estas aplicaciones suelen ser sensibles al rendimiento. Para desarrollar nuevas funciones y mejoras, las actualizaciones de software pueden ser frecuentes. Como las aplicaciones de frontend suelen depender de las aplicaciones de backend para almacenar y gestionar datos (y, posiblemente, lógica empresarial y procesamiento de entradas de usuario), a menudo son sin estado o gestionan solo volúmenes de datos limitados.

Para que sean accesibles y utilizables, puedes crear tus aplicaciones frontend con varios frameworks y tecnologías. Algunos factores clave para que una aplicación frontend funcione correctamente son el rendimiento de la aplicación, la velocidad de respuesta y la compatibilidad con el navegador.

Los componentes de las aplicaciones backend suelen centrarse en almacenar y gestionar datos. En algunas arquitecturas, la lógica empresarial puede incorporarse en el componente backend. Las nuevas versiones de las aplicaciones de backend suelen ser menos frecuentes que las de las aplicaciones de frontend. Las aplicaciones backend tienen los siguientes problemas que gestionar:

• Gestionar un gran volumen de solicitudes
• Gestionar un gran volumen de datos
• Proteger los datos
• Mantener los datos actualizados en todas las réplicas del sistema

La solución de aplicación web de tres niveles es una de las implementaciones más populares para crear aplicaciones web empresariales, como sitios web de comercio electrónico que contienen diferentes componentes de aplicación. Esta arquitectura contiene los siguientes niveles. Cada nivel funciona de forma independiente, pero están estrechamente vinculados y funcionan en conjunto.

• Frontend web y nivel de presentación
• Nivel de aplicación
• Acceso a datos o nivel de backend

Al poner estas capas en contenedores, se separan sus necesidades técnicas, como los requisitos de escalado, y se facilita la migración de forma gradual. Además, te permite desplegarlas en servicios en la nube independientes de la plataforma que se pueden transferir entre entornos, usar la gestión automatizada y escalar con plataformas gestionadas en la nube, como Cloud Run o la edición Enterprise de Google Kubernetes Engine (GKE). Además, las Google Cloudbases de datos gestionadas como Cloud SQL ayudan a proporcionar el backend como capa de base de datos.

Nota: La implementación de esta arquitectura y la definición de sus componentes pueden variar en función de si separas los niveles en sistemas y capas individuales o si los combinas.

El patrón de arquitectura híbrida por niveles se centra en desplegar los componentes de la aplicación frontend en la nube pública. En este patrón, mantienes los componentes de la aplicación backend en su entorno de computación privado. En función de la escala y el diseño específico de la aplicación, puedes migrar los componentes de la aplicación frontend caso por caso. Para obtener más información, consulta el artículo Migrar a Google Cloud.

Si tienes una aplicación con componentes de backend y frontend alojados en tu entorno local, ten en cuenta los límites de tu arquitectura actual. Por ejemplo, a medida que tu aplicación se vaya ampliando y aumenten las exigencias de rendimiento y fiabilidad, deberías empezar a evaluar si es necesario refactorizar partes de la aplicación o moverlas a una arquitectura diferente y más óptima. El patrón de arquitectura híbrida por niveles te permite migrar algunas cargas de trabajo y componentes de aplicaciones a la nube antes de hacer una transición completa. También es fundamental tener en cuenta el coste, el tiempo y los riesgos que conlleva una migración de este tipo.

En el siguiente diagrama se muestra un patrón de arquitectura híbrida por niveles típico.

En el diagrama anterior, las solicitudes de los clientes se envían al frontend de la aplicación, que está alojado en Google Cloud. A su vez, el frontend de la aplicación envía datos al entorno local donde se aloja el backend de la aplicación (idealmente, a través de una pasarela de APIs).

Con el patrón de arquitectura híbrida por niveles, puedes aprovechar laGoogle Cloud infraestructura y los servicios globalesGoogle Cloud , como se muestra en el ejemplo de arquitectura del siguiente diagrama. Se puede acceder al frontend de la aplicación a través de Google Cloud. También puede añadir elasticidad al frontend mediante el escalado automático para responder de forma dinámica y eficiente a la demanda de escalado sin aprovisionar en exceso la infraestructura. Hay diferentes arquitecturas que puedes usar para crear y ejecutar aplicaciones web escalables en Google Cloud. Cada arquitectura tiene ventajas e inconvenientes en función de los requisitos.

Para obtener más información, consulta el vídeo Tres formas de ejecutar aplicaciones web escalables en Google Cloud en YouTube. Para obtener más información sobre las diferentes formas de modernizar su plataforma de comercio electrónico enGoogle Cloud, consulte Cómo crear una plataforma de comercio digital en Google Cloud.

En el diagrama anterior, el frontend de la aplicación se aloja en Google Cloud para ofrecer una experiencia de usuario multirregional y optimizada a nivel mundial que utiliza el balanceo de carga, el escalado automático y la protección frente a DDoS a través de Google Cloud Armor.

Con el tiempo, el número de aplicaciones que implementes en la nube pública puede aumentar hasta el punto de que te plantees trasladar los componentes de la aplicación backend a la nube pública. Si prevés que vas a tener mucho tráfico, optar por servicios gestionados en la nube puede ayudarte a ahorrar tiempo y esfuerzo de ingeniería al gestionar tu propia infraestructura. Considera esta opción a menos que las restricciones o los requisitos exijan que los componentes de la aplicación backend se alojen en las instalaciones. Por ejemplo, si los datos de backend están sujetos a restricciones normativas, probablemente tengas que conservarlos en las instalaciones. Sin embargo, si es posible y cumple los requisitos, puedes usar las funciones de Protección de Datos Sensibles, como las técnicas de desidentificación, para transferir esos datos cuando sea necesario.

En el patrón de arquitectura híbrida por niveles, también puedes usar Google Distributed Cloud en algunos casos. Distributed Cloud te permite ejecutar clústeres de Google Kubernetes Engine en hardware dedicado proporcionado y mantenido por Google, que está separado del centro de datos. Google Cloud Para asegurarte de que Distributed Cloud cumple tus requisitos actuales y futuros, debes conocer las limitaciones de Distributed Cloud en comparación con una zona de GKE basada en la nube convencional.

Ventajas

Centrarse primero en las aplicaciones frontend tiene varias ventajas, entre las que se incluyen las siguientes:

• Los componentes de frontend dependen de los recursos de backend y, en ocasiones, de otros componentes de frontend.
• Los componentes del backend no dependen de los componentes del frontend. Por lo tanto, aislar y migrar aplicaciones frontend suele ser menos complejo que migrar aplicaciones backend.
• Como las aplicaciones de frontend suelen ser sin estado o no gestionan datos por sí mismas, suelen ser más fáciles de migrar que los backends.
  • Los componentes del frontend se pueden optimizar como parte de la migración para usar una arquitectura sin estado. Para obtener más información, consulta el vídeo Cómo migrar aplicaciones web con estado a Cloud Run en YouTube.

Implementar aplicaciones de frontend ya creadas o de nuevo desarrollo en la nube pública ofrece varias ventajas:

• Muchas aplicaciones frontend están sujetas a cambios frecuentes. Ejecutar estas aplicaciones en la nube pública simplifica la configuración de un proceso de integración continua y despliegue continuo (CI/CD). Puedes usar CI/CD para enviar actualizaciones de forma eficiente y automática. Para obtener más información, consulta CI/CD en Google Cloud.
• Los front-ends sensibles al rendimiento con cargas de tráfico variables pueden beneficiarse considerablemente del balanceo de carga, los despliegues multirregionales, el almacenamiento en caché de Cloud CDN, las funciones sin servidor y las funciones de escalado automático que permite un despliegue basado en la nube (idealmente con una arquitectura sin estado).

• Si adoptas microservicios con contenedores mediante una plataforma gestionada en la nube, como GKE, podrás usar arquitecturas modernas, como microfrontend, que amplían los microservicios a los componentes del frontend.

  La extensión de microservicios se suele usar con las interfaces que implican que varios equipos colaboren en la misma aplicación. Este tipo de estructura de equipo requiere un enfoque iterativo y un mantenimiento continuo. Estas son algunas de las ventajas de usar microfrontends:

  • Se puede convertir en módulos de microservicios independientes para el desarrollo, las pruebas y la implementación.
  • Proporciona una separación en la que los equipos de desarrollo pueden seleccionar las tecnologías y el código que prefieran.
  • Puede fomentar ciclos rápidos de desarrollo e implementación sin afectar al resto de los componentes del frontend que puedan gestionar otros equipos.

• Tanto si implementan interfaces de usuario o APIs como si gestionan la ingesta de datos del Internet de las cosas (IoT), las aplicaciones frontend pueden beneficiarse de las funciones de servicios en la nube como Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine o Cloud Run.

• Los proxies de API gestionados en la nube te permiten:

  • Desvincula la API orientada a aplicaciones de los servicios de backend, como los microservicios.
  • Protege las aplicaciones frente a cambios en el código del backend.
  • Admite tus arquitecturas de frontend basadas en APIs, como backend para frontend (BFF) y microfrontend, entre otras.
  • Expón tus APIs en Google Cloud u otros entornos implementando proxies de API en Apigee.

También puedes aplicar el patrón híbrido por niveles al revés, desplegando back-ends en la nube y manteniendo los front-ends en entornos informáticos privados. Aunque es menos habitual, este enfoque es el más adecuado cuando se trata de un frontend pesado y monolítico. En estos casos, puede ser más fácil extraer la funcionalidad del backend de forma iterativa y desplegar estos nuevos backends en la nube.

En la tercera parte de esta serie se analizan los posibles patrones de redes para habilitar este tipo de arquitectura. Apigee hybrid es una plataforma que te ayuda a crear y gestionar proxies de API en un modelo de despliegue híbrido. Para obtener más información, consulta Arquitectura con bajo nivel de acoplamiento, incluidas las arquitecturas monolíticas y de microservicios por niveles.

Prácticas recomendadas

Usa la información de esta sección para planificar tu arquitectura híbrida por niveles.

Prácticas recomendadas para reducir la complejidad

Cuando apliques el patrón de arquitectura híbrida por niveles, ten en cuenta las siguientes prácticas recomendadas, que pueden ayudarte a reducir la complejidad general de la implementación y las operaciones:

• Según la evaluación de los modelos de comunicación de las aplicaciones identificadas, selecciona la solución de comunicación más eficiente y eficaz para esas aplicaciones.

Como la mayoría de las interacciones de los usuarios implican sistemas que se conectan en varios entornos informáticos, es importante que la conectividad entre esos sistemas sea rápida y tenga una latencia baja. Para cumplir las expectativas de disponibilidad y rendimiento, debes diseñar un sistema de alta disponibilidad, baja latencia y niveles de rendimiento adecuados. Desde el punto de vista de la seguridad, la comunicación debe ser detallada y controlada. Lo ideal es exponer los componentes de la aplicación mediante APIs seguras. Para obtener más información, consulta Salida controlada.

• Para minimizar la latencia de comunicación entre entornos, selecciona una Google Cloud región que esté geográficamente cerca del entorno de computación privado en el que se alojan los componentes backend de tu aplicación. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.
• Minimiza las dependencias elevadas entre sistemas que se ejecutan en entornos diferentes, sobre todo cuando la comunicación se gestiona de forma síncrona. Estas dependencias pueden ralentizar el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por transferencia de datos saliente.
• Con el patrón de arquitectura híbrida por niveles, es posible que tengas volúmenes más grandes de tráfico entrante desde entornos locales que de tráfico saliente.Google Cloud Google Cloud Sin embargo, debes conocer el volumen previsto de transferencia de datos salientes de Google Cloud. Si tienes previsto usar esta arquitectura a largo plazo con volúmenes de transferencia de datos salientes elevados, te recomendamos que utilices Cloud Interconnect. Cloud Interconnect puede ayudarte a optimizar el rendimiento de la conectividad y reducir los cargos por transferencia de datos salientes del tráfico que cumpla determinadas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.
• Para proteger la información sensible, te recomendamos que cifres todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, puedes usar túneles VPN, VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.

• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación de los diferentes back-ends, te recomendamos que, cuando sea posible, despliegues una pasarela o un proxy de APIs como fachada unificadora. Esta pasarela o proxy actúa como punto de control centralizado y lleva a cabo las siguientes medidas:

  • Implementa medidas de seguridad adicionales.
  • Protege las aplicaciones cliente y otros servicios frente a cambios en el código del backend.
  • Facilita las pistas de auditoría de la comunicación entre todas las aplicaciones de distintos entornos y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios antiguos y los modernizados.
    • Apigee y Apigee hybrid te permiten alojar y gestionar pasarelas híbridas y de nivel empresarial en entornos locales, perimetrales y de otras nubes, así como enGoogle Cloud entornos.

• Para facilitar la configuración híbrida, usa Cloud Load Balancing con conectividad híbrida. Esto significa que puedes ampliar las ventajas del balanceo de carga en la nube a los servicios alojados en tu entorno de computación local. Este enfoque permite realizar migraciones de cargas de trabajo por fases a Google Cloud con una interrupción mínima o inexistente del servicio, lo que garantiza una transición fluida para los servicios distribuidos. Para obtener más información, consulta la información general sobre los grupos de puntos finales de red de conectividad híbrida.

• A veces, usar una pasarela de API o un proxy y un balanceador de carga de aplicaciones juntos puede proporcionar una solución más sólida para gestionar, proteger y distribuir el tráfico de APIs a gran escala. Usar Cloud Load Balancing con pasarelas de API te permite hacer lo siguiente:

  • Ofrece APIs de alto rendimiento con Apigee y Cloud CDN para reducir la latencia, alojar APIs en todo el mundo y aumentar la disponibilidad durante las temporadas de tráfico máximo. Para obtener más información, consulta el vídeo Delivering high-performing APIs with Apigee and Cloud CDN en YouTube.
  • Implementa la gestión avanzada del tráfico.
  • Usa Cloud Armor como servicio de protección contra ataques DDoS y de seguridad de red para proteger tus APIs.
  • Gestiona el balanceo de carga eficiente en las pasarelas de varias regiones. Para obtener más información, consulta el vídeo Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee en YouTube.

• Usa la gestión de APIs y la malla de servicios para proteger y controlar la comunicación y la exposición de los servicios con la arquitectura de microservicios.

  • Usa Cloud Service Mesh para permitir que los servicios se comuniquen entre sí y mantengan su calidad en un sistema compuesto por servicios distribuidos en el que puedes gestionar la autenticación, la autorización y el cifrado entre servicios.
  • Usa una plataforma de gestión de APIs como Apigee, que permite que tu organización y entidades externas consuman esos servicios exponiéndolos como APIs.

• Establecer una identidad común entre los entornos para que los sistemas puedan autenticarse de forma segura a través de los límites de los entornos.

• Implementar sistemas de CI/CD y de gestión de la configuración en la nube pública. Para obtener más información, consulta el patrón de arquitectura de red reflejada.

• Para aumentar la eficiencia operativa, usa herramientas y canalizaciones de CI/CD coherentes en todos los entornos.

Prácticas recomendadas para arquitecturas de cargas de trabajo y aplicaciones individuales

• Aunque este patrón se centra en las aplicaciones frontend, no olvides que también debes modernizar las backend. Si el ritmo de desarrollo de las aplicaciones backend es considerablemente más lento que el de las aplicaciones frontend, la diferencia puede generar una complejidad adicional.
• Tratar las APIs como interfaces de backend simplifica las integraciones, el desarrollo del frontend y las interacciones de los servicios, además de ocultar las complejidades del sistema de backend. Para hacer frente a estos retos, Apigee facilita el desarrollo y la gestión de gateways o proxies de APIs para despliegues híbridos y multinube.
• Elige el método de renderización de tu aplicación web frontend en función del contenido (estático o dinámico), el rendimiento de la optimización para buscadores y las expectativas sobre la velocidad de carga de las páginas.
• Cuando se selecciona una arquitectura para aplicaciones web basadas en contenido, hay varias opciones disponibles, como las arquitecturas monolíticas, sin servidor, basadas en eventos y de microservicios. Para seleccionar la arquitectura más adecuada, evalúa a fondo estas opciones en función de los requisitos actuales y futuros de tu aplicación. Para ayudarte a tomar una decisión sobre la arquitectura que se ajuste a tus objetivos empresariales y técnicos, consulta Comparación de diferentes arquitecturas para back-ends de aplicaciones web basadas en contenido y Consideraciones clave para los back-ends web.

• Con una arquitectura de microservicios, puedes usar aplicaciones en contenedores con Kubernetes como capa de tiempo de ejecución común. Con el patrón de arquitectura híbrida por niveles, puedes ejecutarlo en cualquiera de los siguientes casos:

  • En ambos entornos (Google Cloud y en tus entornos locales).

    • Si usas contenedores y Kubernetes en distintos entornos, puedes modernizar las cargas de trabajo y, después, migrar a Google Cloud en momentos diferentes. Esto resulta útil cuando una carga de trabajo depende en gran medida de otra y no se puede migrar de forma individual, o para usar la portabilidad de cargas de trabajo híbridas y aprovechar los mejores recursos disponibles en cada entorno. En todos los casos, GKE Enterprise puede ser una tecnología clave. Para obtener más información, consulta el artículo sobre el entorno híbrido de GKE Enterprise.

  • En un Google Cloud entorno para los componentes de la aplicación migrados y modernizados.

    • Utiliza este enfoque cuando tengas back-ends antiguos en las instalaciones que no admitan la contenerización o que requieran mucho tiempo y recursos para modernizarse a corto plazo.

    Para obtener más información sobre cómo diseñar y refactorizar una aplicación monolítica para convertirla en una arquitectura de microservicios y modernizar la arquitectura de tu aplicación web, consulta el artículo Introducción a los microservicios.

• Puedes combinar tecnologías de almacenamiento de datos en función de las necesidades de tus aplicaciones web. Usar Cloud SQL para datos estructurados y Cloud Storage para archivos multimedia es una práctica habitual para satisfacer diversas necesidades de almacenamiento de datos. Dicho esto, la elección depende en gran medida de tu caso práctico. Para obtener más información sobre las opciones de almacenamiento de datos para back-ends de aplicaciones basadas en contenido y las modalidades eficaces, consulta Opciones de almacenamiento de datos para aplicaciones web basadas en contenido. Consulta también Explicación de las opciones de bases de datos Google Cloud .

Patrón multinube particionado

El patrón de arquitectura multinube particionada combina varios entornos de nube pública operados por diferentes proveedores de servicios en la nube. Esta arquitectura ofrece la flexibilidad necesaria para desplegar una aplicación en un entorno de computación óptimo que tenga en cuenta los factores y las consideraciones multicloud que se han tratado en la primera parte de esta serie.

En el siguiente diagrama se muestra un patrón de arquitectura multicloud particionada.

Este patrón de arquitectura se puede crear de dos formas diferentes. El primer enfoque se basa en desplegar los componentes de la aplicación en diferentes entornos de nube pública. Este enfoque también se conoce como arquitectura compuesta y es el mismo que el del patrón de arquitectura híbrida por niveles. Sin embargo, en lugar de usar un entorno local con una nube pública, utiliza al menos dos entornos de nube. En una arquitectura compuesta, una sola carga de trabajo o aplicación usa componentes de más de una nube. El segundo enfoque consiste en implementar diferentes aplicaciones en distintos entornos de nube pública. En la siguiente lista no exhaustiva se describen algunos de los factores empresariales que impulsan el segundo enfoque:

• Para integrar completamente las aplicaciones alojadas en entornos de nube dispares durante una fusión o adquisición entre dos empresas.
• Para fomentar la flexibilidad y adaptarse a las diversas preferencias de la nube de tu organización. Adopta este enfoque para animar a las unidades organizativas a elegir el proveedor de la nube que mejor se adapte a sus necesidades y preferencias específicas.
• Para operar en un despliegue multinube o global. Si una empresa tiene que cumplir las normativas de residencia de datos en regiones o países específicos, debe elegir entre los proveedores de servicios en la nube disponibles en esa ubicación si su proveedor principal no tiene una región de nube allí.

Con el patrón de arquitectura multinube particionada, puedes mantener la capacidad de cambiar las cargas de trabajo de un entorno de nube pública a otro según sea necesario. En ese caso, la portabilidad de tus cargas de trabajo se convierte en un requisito fundamental. Cuando despliegues cargas de trabajo en varios entornos de computación y quieras mantener la capacidad de mover cargas de trabajo entre entornos, debes abstraer las diferencias entre los entornos. Con GKE Enterprise, puedes diseñar y crear una solución para resolver la complejidad multicloud con una gestión, operaciones y posturas de seguridad coherentes. Para obtener más información, consulta GKE Multi-Cloud.

Como hemos mencionado anteriormente, hay situaciones en las que puede haber motivos empresariales y técnicos para combinar Google Cloud con otro proveedor de servicios en la nube y para particionar las cargas de trabajo en esos entornos de nube. Las soluciones multinube te ofrecen la flexibilidad de migrar, crear y optimizar la portabilidad de las aplicaciones en entornos multinube, a la vez que minimizan la dependencia y te ayudan a cumplir los requisitos normativos. Por ejemplo, puedes conectarte Google Cloud con Oracle Cloud Infrastructure (OCI) para crear una solución multinube que aproveche las funciones de cada plataforma mediante una interconexión privada de Cloud para combinar componentes que se ejecuten en OCI con recursos que se ejecuten en Google Cloud. Para obtener más información, consulta el artículo Google Cloud y Oracle Cloud Infrastructure: aprovecha al máximo tu solución multinube. Además, Cross-Cloud Interconnect facilita la conectividad dedicada de gran ancho de banda entre Google Cloud y otros proveedores de servicios en la nube admitidos, lo que te permite diseñar y crear soluciones multinube para gestionar un gran volumen de tráfico entre nubes.

Ventajas

Aunque usar una arquitectura multinube ofrece varias ventajas empresariales y técnicas, como se explica en Factores, consideraciones, estrategia y enfoques, es fundamental llevar a cabo una evaluación detallada de la viabilidad de cada posible ventaja. En tu evaluación, debes tener en cuenta detenidamente los problemas directos o indirectos que puedan surgir, así como tu capacidad para afrontarlos de forma eficaz. Además, ten en cuenta que el crecimiento a largo plazo de tus aplicaciones o servicios puede introducir complejidades que superen las ventajas iniciales.

Estas son algunas de las principales ventajas del patrón de arquitectura multicloud particionada:

• En los casos en los que necesites minimizar el compromiso con un solo proveedor de servicios en la nube, puedes distribuir las aplicaciones entre varios proveedores. Por lo tanto, podrías reducir relativamente la dependencia de proveedores gracias a la posibilidad de cambiar de plan (hasta cierto punto) entre tus proveedores de servicios en la nube. Nuestra nube abierta te ayuda a llevar las Google Cloud funciones, como GKE Enterprise, a diferentes ubicaciones físicas. Al ampliar las funciones on-premise, en varias nubes públicas y en el perímetro, ofrece flexibilidad, agilidad y impulsa la transformación. Google Cloud

• Por motivos normativos, puedes ofrecer un segmento determinado de tu base de usuarios y datos desde un país en el que Google Cloud no tenga una región en la nube.

• El patrón de arquitectura multinube particionada puede ayudar a reducir la latencia y mejorar la calidad general de la experiencia de usuario en las ubicaciones en las que el proveedor de nube principal no tenga una región de nube o un punto de presencia. Este patrón es especialmente útil cuando se usa una conectividad multicloud de alta capacidad y baja latencia, como Cross-Cloud Interconnect y CDN Interconnect, con una CDN distribuida.

• Puedes desplegar aplicaciones en varios proveedores de servicios en la nube de forma que te permita elegir entre los mejores servicios que ofrecen otros proveedores.

• El patrón de arquitectura multinube particionada puede facilitar y acelerar las fusiones y adquisiciones, en las que las aplicaciones y los servicios de las dos empresas pueden alojarse en diferentes entornos de nube pública.

Prácticas recomendadas

• Empieza desplegando una carga de trabajo no esencial. Esta implementación inicial en la nube secundaria puede servir como patrón para futuras implementaciones o migraciones. Sin embargo, este enfoque probablemente no sea aplicable en situaciones en las que la carga de trabajo específica deba residir en una región de la nube concreta por motivos legales o normativos, y el proveedor de la nube principal no tenga una región en el territorio requerido.
• Minimiza las dependencias entre los sistemas que se ejecutan en diferentes entornos de nube pública, sobre todo cuando la comunicación se gestiona de forma síncrona. Estas dependencias pueden ralentizar el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por la transferencia de datos salientes.
• Para abstraer las diferencias entre entornos, considera la posibilidad de usar contenedores y Kubernetes cuando las aplicaciones lo admitan y sea factible.
• Asegúrate de que los flujos de procesamiento de CI/CD y las herramientas de despliegue y monitorización sean coherentes en todos los entornos de nube.
• Selecciona el patrón de arquitectura de red óptimo que proporcione la solución de comunicación más eficiente y eficaz para las aplicaciones que estés usando.
  • La comunicación debe ser precisa y controlada. Usa APIs seguras para exponer componentes de la aplicación.
  • En función de tus requisitos empresariales y técnicos específicos, puedes usar el patrón de arquitectura de malla o uno de los patrones de redes con acceso controlado.
• Para cumplir tus expectativas de disponibilidad y rendimiento, diseña una alta disponibilidad (HA) de extremo a extremo, una latencia baja y niveles de rendimiento adecuados.

• Para proteger la información sensible, te recomendamos que cifres todas las comunicaciones en tránsito.

  • Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cross-Cloud Interconnect.

• Si usas varias CDNs como parte de tu patrón de arquitectura particionada multicloud y estás rellenando tu otra CDN con archivos de datos de gran tamaño de Google Cloud, considera la posibilidad de usar enlaces de CDN Interconnect entre Google Cloud y proveedores admitidos para optimizar este tráfico y, posiblemente, su coste.

• Amplía tu solución de gestión de identidades entre entornos para que los sistemas puedan autenticarse de forma segura en diferentes entornos.

• Para equilibrar las solicitudes de forma eficaz entre Google Cloud y otra plataforma en la nube, puedes usar Cloud Load Balancing. Para obtener más información, consulta Dirigir el tráfico a una ubicación local u otra nube.

  • Si el volumen de transferencia de datos salientes de Google Cloudhacia otros entornos es alto, plantéate usar Cross-Cloud Interconnect.

• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación de los diferentes back-ends, te recomendamos que, cuando sea posible, despliegues una pasarela o un proxy de APIs como fachada unificadora. Esta pasarela o proxy actúa como punto de control centralizado y lleva a cabo las siguientes medidas:

  • Implementa medidas de seguridad adicionales.
  • Protege las aplicaciones cliente y otros servicios frente a cambios en el código del backend.
  • Facilita las pistas de auditoría de la comunicación entre todas las aplicaciones de distintos entornos y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios antiguos y los modernizados.
    • Apigee y Apigee hybrid te permiten alojar y gestionar pasarelas híbridas y de nivel empresarial en entornos locales, perimetrales y de otras nubes, así como enGoogle Cloud entornos.

• En algunos de los siguientes casos, usar Cloud Load Balancing con una API Gateway puede proporcionar una solución sólida y segura para gestionar, proteger y distribuir el tráfico de APIs a gran escala en varias regiones:

  • Despliega la conmutación por error multirregional para los tiempos de ejecución de la API de Apigee en diferentes regiones.

  • Mejorar el rendimiento con Cloud CDN.

  • Proporciona protección frente a ataques DDoS y cortafuegos de aplicaciones web (WAF) a través de Google Cloud Armor.

• Utiliza herramientas coherentes para el registro y la monitorización en los entornos de nube siempre que sea posible. Puedes usar sistemas de monitorización de código abierto. Para obtener más información, consulta Patrones de almacenamiento de registros y monitorización para despliegues híbridos y multinube.

• Si vas a implementar componentes de aplicaciones de forma distribuida, es decir, si los componentes de una misma aplicación se van a implementar en más de un entorno de nube, consulta las prácticas recomendadas del patrón de arquitectura híbrida por niveles.

Patrón híbrido y multinube de analíticas

En este documento se explica que el objetivo del patrón híbrido y multinube de analíticas es sacar partido de la división entre las cargas de trabajo transaccionales y las analíticas.

En los sistemas empresariales, la mayoría de las cargas de trabajo se incluyen en estas categorías:

• Las cargas de trabajo transaccionales incluyen aplicaciones interactivas como ventas, procesamiento financiero, planificación de recursos empresariales o comunicación.
• Las cargas de trabajo de Analytics incluyen aplicaciones que transforman, analizan, refinan o visualizan datos para ayudar en los procesos de toma de decisiones.

Los sistemas de analíticas obtienen sus datos de sistemas transaccionales consultando APIs o accediendo a bases de datos. En la mayoría de las empresas, los sistemas analíticos y transaccionales suelen estar separados y poco acoplados. El objetivo del patrón analíticas híbrida y multinube es aprovechar esta división preexistente ejecutando cargas de trabajo transaccionales y analíticas en dos entornos de computación diferentes. Primero, los datos sin procesar se extraen de las cargas de trabajo que se ejecutan en el entorno de computación privado y, a continuación, se cargan enGoogle Cloud, donde se usan para el procesamiento analítico. Algunos de los resultados se pueden volver a incorporar a los sistemas transaccionales.

En el siguiente diagrama se ilustran las arquitecturas posibles conceptualmente mostrando las posibles canalizaciones de datos. Cada ruta o flecha representa una posible opción de flujo de procesamiento de transformación y movimiento de datos que se puede basar en ETL o ELT, en función de la calidad de los datos disponible y del caso práctico objetivo.

Para transferir tus datos a Google Cloud y extraer valor de ellos, usa los servicios de transferencia de datos, un paquete completo de servicios de ingestión, integración y replicación de datos.

Como se muestra en el diagrama anterior, la conexión Google Cloud con entornos on‐premise y otros entornos de nube puede habilitar varios casos prácticos de analíticas de datos, como la transmisión de datos y las copias de seguridad de bases de datos. Para impulsar el transporte fundamental de un patrón de analíticas híbrido y multinube que requiera un gran volumen de transferencia de datos, Cloud Interconnect y Cross-Cloud Interconnect proporcionan conectividad dedicada a las instalaciones locales y a otros proveedores de servicios en la nube.

Ventajas

Ejecutar cargas de trabajo de analíticas en la nube tiene varias ventajas clave:

• El tráfico entrante (es decir, el movimiento de datos desde tu entorno de computación privado u otras nubes aGoogle Cloud) puede ser gratuito.
• Las cargas de trabajo de analíticas suelen necesitar procesar grandes cantidades de datos y pueden ser irregulares, por lo que son especialmente adecuadas para desplegarse en un entorno de nube pública. Al escalar dinámicamente los recursos de computación, puedes procesar rápidamente grandes conjuntos de datos sin tener que hacer inversiones iniciales ni aprovisionar en exceso el equipo de computación.
• Google Cloud proporciona un amplio conjunto de servicios para gestionar los datos durante todo su ciclo de vida, desde la adquisición inicial hasta la visualización final, pasando por el procesamiento y el análisis.
  • Los servicios de movimiento de datos de Google Cloud proporcionan un conjunto completo de productos para mover, integrar y transformar datos de forma fluida de diferentes maneras.
  • Cloud Storage es una solución ideal para crear un lago de datos.

• Google Cloud te ayuda a modernizar y optimizar tu plataforma de datos para eliminar los silos de datos. Usar un data lakehouse ayuda a estandarizar los diferentes formatos de almacenamiento. También puede proporcionar la flexibilidad, la escalabilidad y la agilidad necesarias para que tus datos generen valor para tu negocio, y no ineficiencias. Para obtener más información, consulta BigLake.

• BigQuery Omni proporciona potencia de computación que se ejecuta de forma local en el almacenamiento de AWS o Azure. También te ayuda a consultar tus propios datos almacenados en Amazon Simple Storage Service (Amazon S3) o Azure Blob Storage. Esta función de analíticas multinube permite a los equipos de datos acabar con los silos de datos. Para obtener más información sobre cómo consultar datos almacenados fuera de BigQuery, consulta la introducción a fuentes de datos externas.

Prácticas recomendadas

Para implementar el patrón de arquitectura analíticas híbrida y multinube, ten en cuenta las siguientes prácticas recomendadas generales:

• Usa el patrón de red de transferencia para habilitar la ingesta de datos. Si los resultados analíticos deben enviarse a los sistemas transaccionales, puedes combinar los patrones de transferencia y de salida controlada.
• Usa colas de Pub/Sub o segmentos de Cloud Storage para transferir datos a Google Cloud desde sistemas transaccionales que se ejecutan en tu entorno de computación privado. Estas colas o contenedores pueden servir como fuentes para flujos de procesamiento de datos y cargas de trabajo.
• Para desplegar flujos de procesamiento de datos ETL y ELT, puedes usar Cloud Data Fusion o Dataflow, en función de los requisitos de tu caso práctico específico. Ambos son servicios de procesamiento de datos totalmente gestionados y nativos de la nube para crear y gestionar flujos de procesamiento de datos.
• Para descubrir, clasificar y proteger tus recursos de datos valiosos, puedes usar las funciones de Google Cloud Protección de Datos Sensibles como las técnicas de desidentificación. Estas técnicas te permiten enmascarar, cifrar y sustituir datos sensibles, como la información personal identificable (IPI), mediante una clave generada aleatoriamente o predeterminada, cuando sea aplicable y cumpla los requisitos.

• Cuando realices una transferencia de datos inicial desde tu entorno de computación privado a Google Cloud, elige el método de transferencia que mejor se adapte al tamaño de tu conjunto de datos y al ancho de banda disponible. Para obtener más información, consulta el artículo Migrar a Google Cloud: transferir conjuntos de datos grandes.

• Si se requiere una transferencia o un intercambio de datos entre Google Cloud y otras nubes a largo plazo con un volumen de tráfico elevado, debes evaluar la posibilidad de usar Google Cloud Cross-Cloud Interconnect para establecer una conectividad dedicada de gran ancho de banda entreGoogle Cloud y otros proveedores de servicios en la nube (disponible en determinadas ubicaciones).

• Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles de VPN, VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cross-Cloud Interconnect.

• Usa herramientas y procesos coherentes en todos los entornos. En un escenario híbrido de analíticas, esta práctica puede ayudar a aumentar la eficiencia operativa, aunque no es un requisito.

Patrón híbrido de Edge

Para ejecutar cargas de trabajo en la nube, en algunos casos los clientes necesitan una conexión a Internet rápida y fiable. En las redes actuales, este requisito rara vez supone un problema para la adopción de la nube. Sin embargo, hay situaciones en las que no puedes depender de una conectividad continua, como las siguientes:

• Los barcos y otros vehículos pueden tener conexión solo de forma intermitente o acceder únicamente a enlaces de satélite con una latencia alta.
• Las fábricas o las centrales eléctricas pueden estar conectadas a Internet. Es posible que estas instalaciones tengan requisitos de fiabilidad que superen las afirmaciones de disponibilidad de su proveedor de Internet.
• Es posible que las tiendas y los supermercados solo tengan conexión de forma ocasional o que usen enlaces que no proporcionen la fiabilidad o el rendimiento necesarios para gestionar transacciones críticas para la empresa.

El patrón de arquitectura híbrida perimetral aborda estos problemas ejecutando cargas de trabajo críticas para el tiempo y la empresa de forma local, en el perímetro de la red, mientras que usa la nube para todos los demás tipos de cargas de trabajo. En una arquitectura híbrida perimetral, el enlace a Internet es un componente no crítico que se usa para fines de gestión y para sincronizar o subir datos, a menudo de forma asíncrona, pero no participa en transacciones críticas para el tiempo o la empresa.

Ventajas

Ejecutar determinadas cargas de trabajo en el perímetro y otras en la nube ofrece varias ventajas:

• El tráfico entrante (transferencia de datos desde el perímetro aGoogle Cloud) puede ser gratuito.
• Ejecutar cargas de trabajo que son cruciales para la empresa y el tiempo en el perímetro ayuda a garantizar una latencia baja y la autosuficiencia. Si la conexión a Internet falla o no está disponible temporalmente, podrás seguir realizando todas las transacciones importantes. Al mismo tiempo, puedes beneficiarte de la nube para una parte significativa de tu carga de trabajo general.
• Puedes reutilizar las inversiones que ya hayas hecho en equipos de computación y almacenamiento.
• Con el tiempo, puedes reducir gradualmente la fracción de cargas de trabajo que se ejecutan en el perímetro y trasladarlas a la nube. Para ello, puedes modificar algunas aplicaciones o equipar algunas ubicaciones perimetrales con enlaces a Internet más fiables.
• Los proyectos relacionados con el Internet de las cosas (IoT) pueden ser más rentables si se realizan cálculos de datos de forma local. De esta forma, las empresas pueden ejecutar y procesar algunos servicios de forma local en el extremo, más cerca de las fuentes de datos. También permite a las empresas enviar datos a la nube de forma selectiva, lo que puede ayudar a reducir la capacidad, la transferencia de datos, el procesamiento y los costes generales de la solución de IoT.
• La computación perimetral puede actuar como una capa de comunicación intermedia entre servicios antiguos y modernizados. Por ejemplo, los servicios que pueden ejecutar una pasarela de APIs en contenedores, como Apigee hybrid. Esto permite que las aplicaciones y los sistemas antiguos se integren con servicios modernizados, como las soluciones de IoT.

Prácticas recomendadas

Ten en cuenta las siguientes recomendaciones al implementar el patrón de arquitectura híbrida perimetral:

• Si la comunicación es unidireccional, usa el patrón de entrada controlada.
• Si la comunicación es bidireccional, considera el patrón de salida y entrada controladas.
• Si la solución consta de muchos sitios remotos perimetrales que se conectan aGoogle Cloud a través de Internet público, puedes usar una solución de red WAN definida por software (SD-WAN). También puedes usar Network Connectivity Center con un router SD-WAN de terceros compatible con un Google Cloud partner para simplificar el aprovisionamiento y la gestión de la conectividad segura a gran escala.
• Minimiza las dependencias entre los sistemas que se ejecutan en el perímetro y los que se ejecutan en el entorno de nube. Cada dependencia puede menoscabar las ventajas de fiabilidad y latencia de una configuración híbrida de edge.
• Para gestionar y operar varias ubicaciones perimetrales de forma eficiente, debes tener un plano de gestión centralizado y una solución de monitorización en la nube.
• Asegúrate de que los flujos de procesamiento de CI/CD, junto con las herramientas de despliegue y monitorización, sean coherentes en los entornos de nube y de edge.
• Considera la posibilidad de usar contenedores y Kubernetes cuando sea aplicable y factible para abstraer las diferencias entre las distintas ubicaciones perimetrales, así como entre las ubicaciones perimetrales y la nube. Como Kubernetes proporciona una capa de tiempo de ejecución común, puedes desarrollar, ejecutar y operar cargas de trabajo de forma coherente en diferentes entornos informáticos. También puedes mover cargas de trabajo entre el perímetro y la nube.
  • Para simplificar la configuración y el funcionamiento híbridos, puedes usar GKE Enterprise en esta arquitectura (si se usan contenedores en los entornos). Ten en cuenta las posibles opciones de conectividad que tienes para conectar un clúster de GKE Enterprise que se ejecute en tu entorno on-premise 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 conGoogle Cloud, no utilices GKE Enterprise cuando esté desconectado de Google Cloud como modo de funcionamiento nominal. Para obtener más información, consulta la sección Impacto de la desconexión temporal de Google Cloud.
• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación entre los distintos servicios de backend y perimetrales, te recomendamos que, cuando sea posible, implementes una pasarela o un proxy de API como fachada unificadora. Esta pasarela o proxy actúa como punto de control centralizado y lleva a cabo las siguientes medidas:
  • Implementa medidas de seguridad adicionales.
  • Protege las aplicaciones cliente y otros servicios frente a cambios en el código del backend.
  • Facilita las pistas de auditoría de la comunicación entre todas las aplicaciones de distintos entornos y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios antiguos y los modernizados.
    • Apigee y Apigee Hybrid te permiten alojar y gestionar pasarelas híbridas y de nivel empresarial en entornos locales, perimetrales y de otras nubes, así como enGoogle Cloud entornos.
• Establecer una identidad común entre los entornos para que los sistemas puedan autenticarse de forma segura a través de los límites de los entornos.
• Como los datos que se intercambian entre entornos pueden ser sensibles, asegúrate de que todas las comunicaciones se cifren en tránsito mediante túneles VPN, TLS o ambos.

Patrón híbrido de entorno

Con el patrón de arquitectura híbrido de entorno, mantienes el entorno de producción de una carga de trabajo en el centro de datos. Después, puedes usar la nube pública para tus entornos de desarrollo y de prueba, u otros entornos. Este patrón se basa en la implementación redundante de las mismas aplicaciones en varios entornos de computación. El objetivo de la implementación es aumentar la capacidad, la agilidad y la resiliencia.

Al evaluar qué cargas de trabajo migrar, puede que observes casos en los que ejecutar una aplicación específica en la nube pública suponga un reto:

• Las restricciones jurisdiccionales o normativas pueden requerir que conserves los datos en un país concreto.
• Los términos de licencia de terceros pueden impedir que utilices determinado software en un entorno de nube.
• Una aplicación puede requerir acceso a dispositivos de hardware que solo estén disponibles de forma local.

En estos casos, no solo debes tener en cuenta el entorno de producción, sino todos los entornos que intervienen en el ciclo de vida de una aplicación, incluidos los sistemas de desarrollo, pruebas y preproducción. Estas restricciones suelen aplicarse al entorno de producción y a sus datos. Es posible que no se apliquen a otros entornos que no usen los datos reales. Ponte en contacto con el departamento de cumplimiento de tu organización o con el equipo correspondiente.

En el siguiente diagrama se muestra un patrón de arquitectura híbrida de entorno típico:

Puede que te parezca arriesgado ejecutar sistemas de desarrollo y de prueba en entornos diferentes a los de producción, y que esto se desvíe de tus prácticas recomendadas o de tus intentos de minimizar las diferencias entre tus entornos. Aunque estas preocupaciones están justificadas, no se aplican si distingues entre las fases de los procesos de desarrollo y prueba:

Aunque los procesos de desarrollo, prueba y despliegue varían en función de la aplicación, suelen incluir variaciones de las siguientes fases:

• Desarrollo: crear una versión candidata.
• Pruebas funcionales o pruebas de aceptación de usuarios: se verifica que la versión candidata cumple los requisitos funcionales.
• Pruebas de rendimiento y fiabilidad: se verifica que la versión candidata cumple los requisitos no funcionales. También se conoce como prueba de carga.
• Pruebas de la fase de desarrollo o de la implementación: comprueba que el procedimiento de implementación funcione.
• Producción: lanzamiento de aplicaciones nuevas o actualizadas.

Rara vez es práctico realizar más de una de estas fases en un mismo entorno, por lo que cada fase suele requerir uno o varios entornos específicos.

Nota: El término entorno de preproducción se suele confundir con entorno de prueba.

El objetivo principal de un entorno de pruebas es ejecutar pruebas funcionales. El objetivo principal de un entorno de preproducción es probar si los procedimientos de implementación de tu aplicación funcionan correctamente. Cuando una versión llega a un entorno de preproducción, las pruebas funcionales ya deberían haberse completado. El entorno de preproducción es el último paso antes de implementar el software en el entorno de producción.

Para asegurarte de que los resultados de las pruebas sean significativos y se apliquen a la implementación de producción, el conjunto de entornos que utilices a lo largo del ciclo de vida de una aplicación debe cumplir las siguientes reglas en la medida de lo posible:

• Todos los entornos son funcionalmente equivalentes. Es decir, la arquitectura, las APIs y las versiones de los sistemas operativos y las bibliotecas son equivalentes, y los sistemas se comportan de la misma forma en todos los entornos. Esta equivalencia evita situaciones en las que las aplicaciones funcionan en un entorno, pero no en otro, o en las que los defectos no se pueden reproducir.
• Los entornos que se usan para las pruebas de rendimiento y fiabilidad, las fases de preproducción y la producción no son equivalentes desde el punto de vista funcional. Es decir, su rendimiento, escala y configuración, así como la forma en que se operan y mantienen, son iguales o solo difieren en aspectos poco importantes. De lo contrario, las pruebas de rendimiento y de puesta en escena no tendrán sentido.

Por lo general, no hay problema si los entornos que se usan para el desarrollo y las pruebas funcionales difieren de los demás entornos en aspectos no funcionales.

Como se muestra en el siguiente diagrama, los entornos de prueba y desarrollo se basan en Google Cloud. Una base de datos gestionada, como Cloud SQL, se puede usar como opción para el desarrollo y las pruebas en Google Cloud. En el desarrollo y las pruebas se puede usar el mismo motor de base de datos y la misma versión en el entorno local, un motor funcionalmente equivalente o una nueva versión que se implemente en el entorno de producción después de la fase de pruebas. Sin embargo, como la infraestructura subyacente de los dos entornos no es idéntica, este enfoque para las pruebas de carga de rendimiento no es válido.

Los siguientes casos se adaptan bien al patrón de entorno híbrido:

• Consigue una equivalencia funcional en todos los entornos utilizando Kubernetes como capa de tiempo de ejecución común cuando sea aplicable y factible. La edición Enterprise de Google Kubernetes Engine (GKE) puede ser una tecnología clave para este enfoque.
  • Asegura la portabilidad de las cargas de trabajo y abstrae las diferencias entre los entornos de computación. Con una malla de servicios de confianza cero, puedes controlar y mantener la separación de comunicaciones necesaria entre los diferentes entornos.
• Ejecuta entornos de desarrollo y pruebas funcionales en la nube pública. Estos entornos pueden ser funcionalmente equivalentes a los demás, pero pueden diferir en aspectos no funcionales, como el rendimiento. Este concepto se ilustra en el diagrama anterior.
• Ejecuta entornos de producción, de preproducción y de rendimiento (pruebas de carga) y pruebas de fiabilidad en el entorno de computación privada, lo que garantiza la equivalencia funcional y no funcional.

Consideraciones de diseño

• Necesidades empresariales: cada estrategia de implementación y lanzamiento de aplicaciones tiene sus propias ventajas e inconvenientes. Para asegurarte de que el enfoque que elijas se ajusta a tus requisitos específicos, basa tus decisiones en una evaluación exhaustiva de las necesidades y las limitaciones de tu empresa.
• Diferencias entre entornos: como parte de este patrón, el objetivo principal de usar este entorno de nube es el desarrollo y las pruebas. El estado final es alojar la aplicación probada en el entorno local privado (producción). Para evitar desarrollar y probar una función que pueda funcionar correctamente en el entorno de la nube y no en el entorno de producción (local), el equipo técnico debe conocer y comprender las arquitecturas y las funciones de ambos entornos. Esto incluye las dependencias de otras aplicaciones y de la infraestructura de hardware, como los sistemas de seguridad que realizan inspecciones de tráfico.
• Gobernanza: para controlar qué puede desarrollar tu empresa en la nube y qué datos puede usar para las pruebas, utiliza un proceso de aprobación y gobernanza. Este proceso también puede ayudar a tu empresa a asegurarse de que no utiliza ninguna función en la nube en sus entornos de desarrollo y pruebas que no exista en su entorno de producción local.
• Criterios de éxito: deben ser claros, predefinidos y medibles, y deben ajustarse a los estándares de garantía de calidad del software de tu organización. Aplica estos estándares a cualquier aplicación que desarrolles y pruebes.
• Redundancia: aunque los entornos de desarrollo y de pruebas no requieran tanta fiabilidad como el entorno de producción, sí necesitan funciones redundantes y la capacidad de probar diferentes situaciones de fallo. Los requisitos de los escenarios de fallo pueden llevar a que el diseño incluya redundancia como parte de tu entorno de desarrollo y pruebas.

Ventajas

Ejecutar cargas de trabajo de desarrollo y pruebas funcionales en la nube pública tiene varias ventajas:

• Puedes iniciar y detener entornos automáticamente según sea necesario. Por ejemplo, puedes aprovisionar un entorno completo para cada confirmación o solicitud de extracción, permitir que se ejecuten pruebas y, después, desactivarlo de nuevo. Este enfoque también ofrece las siguientes ventajas:
  • Puedes reducir los costes deteniendo las instancias de máquinas virtuales (VM) cuando estén inactivas o aprovisionando entornos solo bajo demanda.
  • Puedes acelerar el desarrollo y las pruebas creando entornos efímeros para cada solicitud de extracción. De esta forma, también se reduce la sobrecarga de mantenimiento y las incoherencias en el entorno de compilación.
• Ejecutar estos entornos en la nube pública ayuda a familiarizarse con la nube y las herramientas relacionadas, lo que puede facilitar la migración de otras cargas de trabajo. Este enfoque es especialmente útil si decides explorar la portabilidad de cargas de trabajo con contenedores y Kubernetes, por ejemplo, usando GKE Enterprise en diferentes entornos.

Prácticas recomendadas

Para implementar correctamente el patrón de arquitectura híbrida de entorno, ten en cuenta las siguientes recomendaciones:

• Define los requisitos de comunicación de tu aplicación, incluido el diseño óptimo de la red y la seguridad. A continuación, utiliza el patrón de red reflejada para diseñar tu arquitectura de red de forma que se eviten las comunicaciones directas entre sistemas de diferentes entornos. Si se requiere comunicación entre entornos, debe hacerse de forma controlada.

• La estrategia de implementación y pruebas de aplicaciones que elijas debe ajustarse a tus objetivos y requisitos empresariales. Esto puede implicar implementar cambios sin tiempo de inactividad o implementar funciones gradualmente en un entorno o grupo de usuarios específicos antes de lanzarlas de forma generalizada.

• Para que las cargas de trabajo sean portátiles y abstraer las diferencias entre entornos, puedes usar contenedores con Kubernetes. Para obtener más información, consulta la arquitectura de referencia del entorno híbrido de GKE Enterprise.

• Establece una cadena de herramientas común que funcione en diferentes entornos informáticos para desplegar, configurar y operar cargas de trabajo. Si usas Kubernetes, tendrás esta coherencia.

• Asegúrate de que las pipelines de CI/CD sean coherentes en todos los entornos informáticos y de que se implemente el mismo conjunto de archivos binarios, paquetes o contenedores en todos esos entornos.

• Cuando uses Kubernetes, utiliza un sistema de integración continua como Tekton para implementar una canalización de despliegue que se despliegue en clústeres y funcione en diferentes entornos. Para obtener más información, consulta Soluciones de DevOps en Google Cloud.

• Para ayudarte a lanzar continuamente aplicaciones seguras y fiables, incorpora la seguridad como parte integral del proceso de DevOps (DevSecOps). Para obtener más información, consulta el artículo Deliver and secure your internet-facing application in less than an hour using Dev(Sec)Ops Toolkit (Entrega y protege tu aplicación orientada a Internet en menos de una hora con Dev(Sec)Ops Toolkit).

• Usa las mismas herramientas para registrar y monitorizar los entornos de nube Google Cloudy los entornos de nube que ya tengas. Te recomendamos que uses sistemas de monitorización de código abierto. Para obtener más información, consulta Patrones de almacenamiento de registros y monitorización para despliegues híbridos y multinube.

• Si distintos equipos gestionan las cargas de trabajo de prueba y producción, puede ser aceptable usar herramientas independientes. Sin embargo, si usas las mismas herramientas con diferentes permisos de visualización, puedes reducir el esfuerzo y la complejidad de la formación.

• Cuando elijas servicios de bases de datos, almacenamiento y mensajería para las pruebas funcionales, utiliza productos que tengan un equivalente gestionado en Google Cloud. Si utilizas servicios gestionados, se reduce el esfuerzo administrativo necesario para mantener los entornos de desarrollo y pruebas.

• Para proteger la información sensible, recomendamos cifrar todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.

En la siguiente tabla se muestran los productos de Google Cloud que son compatibles con productos de software libre comunes.

Producto de OSS	Compatible con el producto Google Cloud
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL y PostgreSQL	Cloud SQL
Redis Cluster, Redis y Memcached	Memorystore
Sistema de archivos de red (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise

Patrones híbridos y multinube de continuidad empresarial

El principal motivo para tener en cuenta la continuidad empresarial de los sistemas críticos es ayudar a una organización a ser resiliente y a continuar con sus operaciones empresariales durante y después de los fallos. Al replicar sistemas y datos en varias regiones geográficas y evitar los puntos únicos de fallo, puedes minimizar los riesgos de que una catástrofe natural afecte a la infraestructura local. Otros casos de fallo son los fallos graves del sistema, los ataques de ciberseguridad o incluso los errores de configuración del sistema.

Optimizar un sistema para que resista los fallos es esencial para establecer una continuidad de la actividad empresarial eficaz. La fiabilidad del sistema puede verse afectada por varios factores, como el rendimiento, la resiliencia, la disponibilidad, la seguridad y la experiencia de usuario. Para obtener más información sobre cómo diseñar y operar servicios fiables enGoogle Cloud, consulta el pilar de fiabilidad del Google Cloud framework Well-Architected y los componentes de fiabilidad en Google Cloud.

Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en varios entornos informáticos. En este patrón, se implementan las mismas aplicaciones en varios entornos informáticos con el objetivo de aumentar la fiabilidad. La continuidad del negocio se puede definir como la capacidad de una organización para seguir ofreciendo sus funciones o servicios empresariales clave a niveles aceptables predefinidos tras un evento disruptivo.

La recuperación tras fallos (DR) se considera un subconjunto de la continuidad empresarial y se centra explícitamente en que los sistemas de TI en los que se basan funciones empresariales esenciales funcionen lo antes posible después de que se produzca una interrupción. En general, las estrategias y los planes de recuperación ante desastres a menudo contribuyen a crear una estrategia de continuidad de la actividad más amplia. Desde el punto de vista tecnológico, cuando empieces a crear estrategias de recuperación tras fallos, tu análisis de impacto en el negocio debe definir dos métricas clave: el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). Si necesitas más ayuda para usar Google Cloud con el proceso de recuperación tras fallos, consulta la guía de planificación para la recuperación tras fallos.

Cuanto menores sean los valores de RPO y RTO, más rápido podrán recuperarse los servicios tras una interrupción con una pérdida de datos mínima. Sin embargo, esto implica un coste mayor, ya que significa crear sistemas redundantes. Los sistemas redundantes que pueden replicar datos casi en tiempo real y que operan a la misma escala tras un fallo aumentan la complejidad, los costes y la carga administrativa.

La decisión de seleccionar una estrategia de recuperación ante desastres o un patrón debe basarse en un análisis del impacto empresarial. Por ejemplo, las pérdidas financieras derivadas de unos pocos minutos de inactividad de una organización de servicios financieros pueden superar con creces el coste de implementar un sistema de recuperación ante desastres. Sin embargo, las empresas de otros sectores pueden sufrir horas de inactividad sin que esto tenga un impacto significativo en su actividad.

Cuando ejecutas sistemas críticos en un centro de datos local, una de las estrategias de recuperación tras desastres es mantener sistemas de reserva en un segundo centro de datos de otra región. Sin embargo, una opción más rentable es usar un entorno de computación basado en una nube pública para la conmutación por error. Este enfoque es el principal impulsor del patrón híbrido para la continuidad empresarial. La nube puede ser especialmente atractiva desde el punto de vista de los costes, ya que te permite desactivar parte de tu infraestructura de recuperación ante desastres cuando no se esté usando. Para conseguir una solución de recuperación tras fallos de menor coste, una solución en la nube permite a las empresas aceptar el posible aumento de los valores de RPO y RTO.

El diagrama anterior muestra el uso de la nube como entorno de conmutación por error o recuperación ante desastres para un entorno local.

Una variante menos habitual (y que rara vez se requiere) de este patrón es el patrón multicloud de continuidad empresarial. En ese patrón, el entorno de producción usa un proveedor de nube y el entorno de recuperación ante desastres usa otro proveedor de nube. Si despliegas copias de cargas de trabajo en varios proveedores de servicios en la nube, puedes aumentar la disponibilidad más allá de lo que ofrece un despliegue multirregional.

Evaluar una recuperación ante desastres en varias nubes en lugar de usar un proveedor de nube con diferentes regiones requiere un análisis exhaustivo de varios aspectos, entre los que se incluyen los siguientes:

• Facilidad de gestión
• Seguridad
• Viabilidad general.
• Coste
  • Los posibles cargos por transferencia de datos salientes de más de un proveedor de servicios en la nube podrían ser costosos si la comunicación entre nubes es continua.
  • Puede haber un gran volumen de tráfico al replicar bases de datos.
  • El coste total de propiedad y el coste de gestionar la infraestructura de red entre nubes.

Nota: Para obtener más información sobre cómo puede ayudarte Cross-Cloud Interconnect a reducir el coste total de propiedad y la complejidad, consulta el artículo Presentamos Cross-Cloud Interconnect: conectividad fluida con todas tus nubes.

Si tus datos deben permanecer en tu país para cumplir los requisitos normativos, puedes usar un segundo proveedor de servicios en la nube que también esté en tu país como recuperación ante desastres. Para usar un segundo proveedor de servicios en la nube, se presupone que no hay ninguna opción para usar un entorno local con el fin de crear una configuración híbrida. Para evitar tener que rediseñar tu solución en la nube, lo ideal es que tu segundo proveedor de servicios en la nube ofrezca todas las funciones y los servicios que necesites en la región.

Factores del diseño

• Expectativas de recuperación ante desastres: los objetivos de RPO y RTO que quiera alcanzar tu empresa deben determinar la arquitectura de recuperación ante desastres y la planificación de la compilación.
• Arquitectura de la solución: con este patrón, debe replicar las funciones y las capacidades de su entorno local para cumplir sus expectativas de recuperación ante desastres. Por lo tanto, debe evaluar la viabilidad de volver a alojar, refactorizar o rediseñar sus aplicaciones para ofrecer las mismas funciones y el mismo rendimiento (o uno mejor) en el entorno de la nube.
• Diseño y creación: la creación de una zona de aterrizaje es casi siempre un requisito previo para implementar cargas de trabajo empresariales en un entorno de nube. Para obtener más información, consulta Diseño de la zona de aterrizaje en Google Cloud.

• Activación de la recuperación tras fallos: es importante que tu diseño y proceso de recuperación tras fallos tengan en cuenta las siguientes preguntas:

  • ¿Qué activa un escenario de recuperación tras desastres? Por ejemplo, un DR puede activarse si fallan funciones o sistemas específicos del sitio principal.
  • ¿Cómo se invoca la conmutación por error al entorno de recuperación ante desastres? ¿Es un proceso de aprobación manual o se puede automatizar para conseguir un objetivo de RTO bajo?
  • ¿Cómo deben diseñarse los mecanismos de detección y notificación de fallos del sistema para invocar la conmutación por error de acuerdo con el RTO esperado?
  • ¿Cómo se redirige el tráfico al entorno de recuperación tras fallos una vez que se detecta el fallo?

  Valida tus respuestas a estas preguntas mediante pruebas.

• Pruebas: prueba y evalúa a fondo la conmutación por error a la recuperación ante desastres. Asegúrate de que cumpla tus expectativas de RPO y RTO. De esta forma, tendrás más confianza para invocar la recuperación ante desastres cuando sea necesario. Cada vez que se haga un cambio o una actualización en el proceso o en la solución tecnológica, vuelve a realizar las pruebas.

• Habilidades del equipo: uno o varios equipos técnicos deben tener las habilidades y los conocimientos necesarios para crear, operar y solucionar problemas de la carga de trabajo de producción en el entorno de la nube, a menos que tu entorno esté gestionado por un tercero.

Ventajas

Usar Google Cloud para la continuidad empresarial ofrece varias ventajas:

• Como Google Cloud tiene muchas regiones en todo el mundo, puedes usarlo para crear copias de seguridad o replicar datos en otro sitio del mismo continente. También puedes crear copias de seguridad o replicar datos en un sitio de otro continente.
• Google Cloud ofrece la posibilidad de almacenar datos en Cloud Storage en un segmento birregional o multirregional. Los datos se almacenan de forma redundante en al menos dos regiones geográficas distintas. Los datos almacenados en los contenedores birregionales y multirregionales se replican en regiones geográficas mediante la replicación predeterminada.
  • Los segmentos de dos regiones proporcionan redundancia geográfica para admitir planes de continuidad del negocio y de recuperación tras fallos. Además, para replicar más rápido y con un RPO más bajo, los objetos almacenados en dos regiones pueden usar opcionalmente la replicación turbo entre esas regiones.
  • Del mismo modo, la replicación multirregional proporciona redundancia en varias regiones almacenando los datos dentro del límite geográfico de la multirregión.
• Ofrece una o varias de las siguientes opciones para reducir los gastos de capital y los gastos operativos a la hora de crear una recuperación tras fallos:
  • Las instancias de VM detenidas solo generan costes de almacenamiento y son mucho más económicas que las instancias de VM en ejecución. Esto significa que puedes minimizar el coste de mantener sistemas de reserva inactivos.
  • El modelo de pago por uso de Google Cloud significa que solo pagas por el almacenamiento y la capacidad de computación que utilizas.
  • Las funciones de elasticidad, como el escalado automático, te permiten escalar o reducir automáticamente tu entorno de recuperación ante desastres según sea necesario.

Por ejemplo, el siguiente diagrama muestra una aplicación que se ejecuta en un entorno local (producción) que usa componentes de recuperación enGoogle Cloud con Compute Engine, Cloud SQL y Cloud Load Balancing. En este caso, la base de datos se aprovisiona previamente mediante una base de datos basada en una VM o una base de datos gestionada de Google Cloud , como Cloud SQL, para que la recuperación sea más rápida con la replicación continua de datos. Puedes iniciar VMs de Compute Engine a partir de snapshots creados previamente para reducir los costes durante las operaciones normales. Con esta configuración, y tras un evento de fallo, el DNS debe apuntar a la dirección IP externa de Cloud Load Balancing.

Para que la aplicación funcione en la nube, debes aprovisionar las máquinas virtuales web y de aplicación. En función del nivel de RTO objetivo y de las políticas de la empresa, todo el proceso para invocar una recuperación tras fallos, aprovisionar la carga de trabajo en la nube y redirigir el tráfico se puede completar de forma manual o automática.

Para acelerar y automatizar el aprovisionamiento de la infraestructura, considera la posibilidad de gestionarla como código. Puedes usar Cloud Build, que es un servicio de integración continua, para aplicar automáticamente manifiestos de Terraform a tu entorno. Para obtener más información, consulta el artículo Gestionar la infraestructura como código con Terraform, Cloud Build y GitOps.

Prácticas recomendadas

Cuando uses el patrón de continuidad de negocio, ten en cuenta las siguientes prácticas recomendadas:

• Crea un plan de recuperación tras fallos que documente tu infraestructura junto con los procedimientos de conmutación por error y recuperación.
• Tenga en cuenta las siguientes acciones en función de su análisis del impacto empresarial y de los objetivos de RPO y RTO identificados:
  • Decide si es suficiente con hacer una copia de seguridad de los datos en Google Cloud o si necesitas plantearte otra estrategia de recuperación ante desastres (sistemas de reserva inactivos, activos o en espera).
  • Define los servicios y productos que puedes usar como bloques de creación para tu plan de recuperación tras desastres.
  • Define los escenarios de recuperación ante desastres aplicables a tus aplicaciones y datos como parte de la estrategia de recuperación ante desastres que hayas seleccionado.
• Si solo vas a crear copias de seguridad de los datos, te recomendamos que uses el patrón de transferencia. De lo contrario, el patrón en malla puede ser una buena opción para replicar la arquitectura de red del entorno.
• Minimiza las dependencias entre los sistemas que se ejecutan en entornos diferentes, sobre todo cuando la comunicación se gestiona de forma síncrona. Estas dependencias pueden ralentizar el rendimiento y reducir la disponibilidad general.

• Evita el problema del cerebro dividido. Si replicas datos de forma bidireccional entre entornos, es posible que te enfrentes al problema de cerebro dividido. El problema de cerebro dividido se produce cuando dos entornos que replican datos bidireccionalmente pierden la comunicación entre sí. Esta división puede provocar que los sistemas de ambos entornos concluyan que el otro entorno no está disponible y que tienen acceso exclusivo a los datos. Esto puede provocar que los datos se modifiquen de forma contradictoria. Hay dos formas habituales de evitar el problema de split-brain:

  • Usar un entorno informático de terceros. Este entorno permite que los sistemas comprueben si hay un quórum antes de modificar los datos.

  • Permite que se concilien las modificaciones de datos conflictivas después de que se restaure la conectividad.

    Con las bases de datos SQL, puedes evitar el problema de cerebro dividido haciendo que la instancia principal original sea inaccesible antes de que los clientes empiecen a usar la nueva instancia principal. Para obtener más información, consulta Recuperación tras fallos de la base de datos de Cloud SQL.

• Asegúrate de que los sistemas CI/CD y los repositorios de artefactos no se conviertan en un único punto de fallo. Cuando un entorno no esté disponible, debes poder implementar nuevas versiones o aplicar cambios en la configuración.

• Haz que todas las cargas de trabajo sean portátiles cuando utilices sistemas de reserva. Todas las cargas de trabajo deben ser portátiles (si las aplicaciones lo permiten y es viable) para que los sistemas sigan siendo coherentes en todos los entornos. Para ello, puedes usar contenedores y Kubernetes. Si usas la edición Enterprise de Google Kubernetes Engine (GKE), puedes simplificar la compilación y las operaciones.

• Integra el despliegue de sistemas de reserva en tu flujo de procesamiento de CI/CD. Esta integración ayuda a garantizar que las versiones y las configuraciones de las aplicaciones sean coherentes en todos los entornos.

• Para asegurarte de que los cambios en el DNS se propaguen rápidamente, configura tu DNS con un valor de tiempo de vida razonablemente corto, de forma que puedas redirigir a los usuarios a los sistemas de reserva cuando se produzca un desastre.

• Seleccione la política de DNS y la política de enrutamiento que se ajusten a su arquitectura y al comportamiento de la solución. Además, puedes combinar varios balanceadores de carga regionales con políticas de enrutamiento de DNS para crear arquitecturas de balanceo de carga globales para diferentes casos prácticos, incluida la configuración híbrida.

• Utiliza varios proveedores de DNS. Si usas varios proveedores de DNS, puedes hacer lo siguiente:

  • Mejora la disponibilidad y la resiliencia de tus aplicaciones y servicios.

  • Simplifica el despliegue o la migración de aplicaciones híbridas que tienen dependencias en entornos on-premise y de nube con una configuración de DNS de varios proveedores.

    Google Cloud ofrece una solución de código abierto basada en octoDNS para ayudarte a configurar y gestionar un entorno con varios proveedores de DNS. Para obtener más información, consulta DNS público de varios proveedores con Cloud DNS.

• Utiliza balanceadores de carga cuando uses sistemas de reserva para crear una conmutación por error automática. Ten en cuenta que el hardware del balanceador de carga puede fallar.

• Usa Cloud Load Balancing en lugar de balanceadores de carga de hardware para llevar a cabo algunos de los casos que se dan al usar este patrón de arquitectura. Las solicitudes de clientes internos o las solicitudes de clientes externos se pueden redirigir al entorno principal o al entorno de recuperación tras desastres en función de diferentes métricas, como la división del tráfico basada en el peso. Para obtener más información, consulta la descripción general de la gestión del tráfico del balanceador de carga de aplicación externo global.

• Si el volumen de transferencia de datos salientes de Google Cloud hacia el otro entorno es alto, plantéate usar Cloud Interconnect o Cross-Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y reducir los cargos por transferencia de datos salientes del tráfico que cumpla determinadas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

• Te recomendamos que uses la solución de tu partner preferido en Google Cloud Marketplace para facilitar las copias de seguridad de los datos, las replicaciones y otras tareas que cumplan tus requisitos, incluidos tus objetivos de RPO y RTO.

• Prueba y evalúa escenarios de invocación de recuperación ante desastres para saber con qué facilidad puede recuperarse la aplicación de un desastre en comparación con el valor de RTO objetivo.

• Cifra las comunicaciones en tránsito. Para proteger la información sensible, te recomendamos que cifres todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.

Patrón de ráfaga en la nube

Las aplicaciones de Internet pueden experimentar fluctuaciones extremas en el uso. Aunque la mayoría de las aplicaciones empresariales no se enfrentan a este problema, muchas empresas deben gestionar otro tipo de cargas de trabajo irregulares: los trabajos por lotes o de CI/CD.

Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en varios entornos informáticos. El objetivo es aumentar la capacidad, la resiliencia o ambas.

Aunque puede dar cabida a cargas de trabajo irregulares en un entorno informático basado en un centro de datos aprovisionando recursos en exceso, este enfoque puede no ser rentable. Con los trabajos por lotes, puedes optimizar el uso prolongando su ejecución durante periodos más largos, aunque no es práctico retrasar los trabajos si son sensibles al tiempo.

La idea del patrón de bursting en la nube es usar un entorno de computación privado para la carga de referencia y pasar a la nube temporalmente cuando necesites capacidad adicional.

En el diagrama anterior, cuando la capacidad de datos alcanza su límite en un entorno privado local, el sistema puede obtener capacidad adicional de un entorno de nube pública cuando sea necesario.Google Cloud

Los principales factores de este patrón son ahorrar dinero y reducir el tiempo y el esfuerzo necesarios para responder a los cambios en los requisitos de escalado. Con este enfoque, solo pagas por los recursos utilizados al gestionar cargas adicionales. Esto significa que no tienes que aprovisionar en exceso tu infraestructura. En su lugar, puedes aprovechar los recursos en la nube bajo demanda y escalarlos para que se adapten a la demanda y a las métricas predefinidas. De esta forma, tu empresa puede evitar interrupciones del servicio durante los periodos de máxima demanda.

Un requisito potencial para los escenarios de bursting en la nube es la portabilidad de las cargas de trabajo. Cuando permites que las cargas de trabajo se implementen en varios entornos, debes abstraer las diferencias entre ellos. Por ejemplo, Kubernetes te permite lograr la coherencia a nivel de carga de trabajo en diversos entornos que usan diferentes infraestructuras. Para obtener más información, consulta la arquitectura de referencia del entorno híbrido de GKE Enterprise.

Factores del diseño

El patrón de bursting en la nube se aplica a cargas de trabajo interactivas y por lotes. Sin embargo, cuando trabajas con cargas de trabajo interactivas, debes determinar cómo distribuir las solicitudes entre los entornos:

• Puede enrutar las solicitudes de los usuarios entrantes a un balanceador de carga que se ejecute en el centro de datos, y, a continuación, hacer que el balanceador de carga distribuya las solicitudes entre los recursos locales y en la nube.

  Este enfoque requiere que el balanceador de carga u otro sistema que se ejecute en el centro de datos actual también monitorice los recursos que se asignan en la nube. El balanceador de carga u otro sistema también deben iniciar el escalado vertical automático de los recursos. Con este enfoque, puedes retirar todos los recursos de la nube durante los periodos de poca actividad. Sin embargo, implementar mecanismos para monitorizar los recursos puede superar las capacidades de tus soluciones de balanceo de carga y, por lo tanto, aumentar la complejidad general.

• En lugar de implementar mecanismos para monitorizar los recursos, puedes usar Cloud Load Balancing con un backend de grupo de puntos finales de red (NEG) de conectividad híbrida. Este balanceador de carga se usa para enrutar solicitudes de clientes internos u externos a backends que se encuentran tanto en las instalaciones como enGoogle Cloud y que se basan en diferentes métricas, como la división del tráfico basada en el peso. También puedes escalar los backends en función de la capacidad de servicio del balanceo de carga de las cargas de trabajo de Google Cloud. Para obtener más información, consulta la descripción general de la gestión del tráfico del balanceador de carga de aplicación externo global.

  Este enfoque tiene varias ventajas adicionales, como aprovechar las funciones de protección frente a ataques DDoS de Google Cloud Armor, el cortafuegos de aplicaciones web y el almacenamiento en caché de contenido en el perímetro de la nube mediante Cloud CDN. Sin embargo, debes dimensionar la conectividad de red híbrida para gestionar el tráfico adicional.

• Como se destaca en la sección Portabilidad de cargas de trabajo, una aplicación puede ser portátil a otro entorno con cambios mínimos para lograr la coherencia de la carga de trabajo, pero eso no significa que la aplicación funcione igual en ambos entornos. Las diferencias en la computación subyacente, las funciones de seguridad de la infraestructura o la infraestructura de red, junto con la proximidad a los servicios dependientes, suelen determinar el rendimiento. Gracias a las pruebas, puedes tener una visibilidad más precisa y comprender las expectativas de rendimiento.

• Puedes usar servicios de infraestructura en la nube para crear un entorno en el que alojar tus aplicaciones sin portabilidad. Usa los siguientes métodos para gestionar las solicitudes de los clientes cuando se redirija el tráfico durante los periodos de máxima demanda:

  • Usa herramientas coherentes para monitorizar y gestionar estos dos entornos.
  • Asegúrate de que las versiones de las cargas de trabajo sean coherentes y de que tus fuentes de datos estén actualizadas.
  • Es posible que tengas que añadir automatización para aprovisionar el entorno de nube y redirigir el tráfico cuando aumente la demanda y se espere que la carga de trabajo en la nube acepte las solicitudes de los clientes de tu aplicación.

• Si tienes previsto cerrar todos los recursos durante los periodos de baja demanda, usar políticas de enrutamiento de DNS principalmente para el balanceo de carga del tráfico no siempre será la mejor opción. Google Cloud Esto se debe principalmente a lo siguiente:

  • Los recursos pueden tardar un tiempo en inicializarse antes de poder atender a los usuarios.
  • Las actualizaciones de DNS suelen propagarse lentamente por Internet.

  En este caso, ocurre lo siguiente:

  • Es posible que se dirija a los usuarios al entorno de Cloud aunque no haya recursos disponibles para procesar sus solicitudes.
  • Es posible que los usuarios sigan dirigiéndose al entorno local temporalmente mientras las actualizaciones de DNS se propagan por Internet.

Con Cloud DNS, puedes elegir la política de DNS y la política de enrutamiento que se adapten a la arquitectura y el comportamiento de tu solución, como las políticas de enrutamiento de DNS por geolocalización. Cloud DNS también admite comprobaciones de estado para el balanceador de carga de red con paso a través interno y el balanceador de carga de aplicaciones interno. En ese caso, podrías incorporarlo a tu configuración de DNS híbrido general basada en este patrón.

En algunos casos, puedes usar Cloud DNS para distribuir solicitudes de clientes con comprobaciones de estado activadas Google Cloud, como cuando usas balanceadores de carga de aplicaciones internos o balanceadores de carga de aplicaciones internos entre regiones. En este caso, Cloud DNS comprueba el estado general del balanceador de carga de aplicaciones interno, que a su vez comprueba el estado de las instancias de backend. Para obtener más información, consulta Gestionar políticas de enrutamiento de DNS y comprobaciones de estado.

También puedes usar horizonte dividido de Cloud DNS. El horizonte dividido de Cloud DNS es un método para configurar respuestas o registros DNS en la ubicación o la red específicas del originador de la consulta DNS para el mismo nombre de dominio. Este enfoque se suele usar para cumplir los requisitos en los que una aplicación está diseñada para ofrecer una experiencia privada y otra pública, cada una con características únicas. Este enfoque también ayuda a distribuir la carga de tráfico entre los entornos.

Teniendo en cuenta estas consideraciones, el cloud bursting suele ser más adecuado para cargas de trabajo por lotes que para cargas de trabajo interactivas.

Ventajas

Estas son algunas de las ventajas clave del patrón de arquitectura de cloud bursting:

• El cloud bursting te permite reutilizar las inversiones que ya has hecho en centros de datos y entornos de computación privados. Esta reutilización puede ser permanente o estar en vigor hasta que sea necesario sustituir el equipo, momento en el que puedes plantearte una migración completa.
• Como ya no tienes que mantener una capacidad excesiva para satisfacer las demandas máximas, puedes aumentar el uso y la rentabilidad de tus entornos de computación privados.
• El reventón en la nube te permite ejecutar tareas por lotes de forma oportuna sin necesidad de aprovisionar en exceso recursos de computación.

Prácticas recomendadas

Cuando implementes el cloud bursting, ten en cuenta las siguientes prácticas recomendadas:

• Para asegurarte de que las cargas de trabajo que se ejecutan en la nube puedan acceder a los recursos de la misma forma que las cargas de trabajo que se ejecutan en un entorno local, usa el patrón de malla con el principio de acceso de seguridad con los mínimos privilegios. Si el diseño de la carga de trabajo lo permite, puedes permitir el acceso solo desde la nube al entorno informático local, pero no al revés.
• Para minimizar la latencia de la comunicación entre entornos, elige una Google Cloud región que esté geográficamente cerca de tu entorno de computación privado. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.
• Si solo usas el cloud bursting para cargas de trabajo por lotes, reduce la superficie de ataque de seguridad manteniendo todos los recursos privados. Google Cloud No permitas el acceso directo desde Internet a estos recursos, aunque uses el Google Cloud balanceo de carga externo para proporcionar el punto de entrada a la carga de trabajo.

• Selecciona la política de DNS y la política de enrutamiento que se ajusten a tu patrón de arquitectura y al comportamiento de la solución de destino.

  • Como parte de este patrón, puedes aplicar el diseño de tus políticas de DNS de forma permanente o cuando necesites capacidad adicional usando otro entorno durante las horas de máxima demanda.
  • Puedes usar políticas de enrutamiento de DNS por geolocalización para tener un endpoint de DNS global para tus balanceadores de carga regionales. Esta táctica tiene muchos casos prácticos para las políticas de enrutamiento de DNS de geolocalización, incluidas las aplicaciones híbridas que usan Google Cloud junto con una implementación local en la que existe la región Google Cloud .

  • Si necesitas proporcionar registros diferentes para las mismas consultas de DNS, puedes usar DNS de horizonte dividido. Por ejemplo, consultas de clientes internos y externos.

    Para obtener más información, consulta las arquitecturas de referencia para DNS híbrido.

• Para asegurarte de que los cambios de DNS se propaguen rápidamente, configura tu DNS con un valor de tiempo de vida razonablemente corto para que puedas redirigir a los usuarios a sistemas de reserva cuando necesites capacidad adicional en entornos de nube.

• En el caso de las tareas que no son muy urgentes y no almacenan datos de forma local, te recomendamos que uses instancias de VM de acceso puntual, que son considerablemente más baratas que las instancias de VM normales. Sin embargo, es necesario que, si se interrumpe el trabajo de la VM, el sistema pueda reiniciarlo automáticamente.

• Usa contenedores para conseguir la portabilidad de las cargas de trabajo cuando sea posible. Además, GKE Enterprise puede ser una tecnología clave para ese diseño. Para obtener más información, consulta la arquitectura de referencia del entorno híbrido de GKE Enterprise.

• Monitoriza el tráfico enviado desde Google Cloud a un entorno informático diferente. Este tráfico está sujeto a cargos por transferencia de datos salientes.

• Si tienes previsto usar esta arquitectura a largo plazo con un volumen de transferencia de datos salientes elevado, plantéate usar Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y reducir los cargos por transferencia de datos salientes del tráfico que cumpla determinadas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

• Cuando se usa Cloud Load Balancing, debes usar sus funciones de optimización de la capacidad de las aplicaciones cuando sea necesario. De esta forma, podrás solucionar algunos de los problemas de capacidad que pueden producirse en aplicaciones distribuidas a nivel mundial.

• Autentica a los usuarios de tus sistemas estableciendo una identidad común entre los entornos para que los sistemas puedan autenticarse de forma segura entre los límites de los entornos.

• Para proteger la información sensible, es muy recomendable cifrar todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.

Patrones de arquitectura híbridos y multinube: qué es lo siguiente

• Descubre cómo abordar la arquitectura híbrida y multinube y cómo elegir las cargas de trabajo adecuadas.
• Consulta más información sobre los patrones de arquitectura de red adecuados para los patrones de arquitectura híbrida y multinube seleccionados.
• Consulta más información sobre los arquetipos de despliegue de aplicaciones en la nube.
• Aprende a diseñar y desplegar una aplicación web de comercio electrónico con diferentes arquitecturas, como una aplicación web de comercio electrónico basada en microservicios con GKE y una aplicación web dinámica que se basa en APIs sin servidor.

---

1. Para obtener más información sobre las consideraciones específicas de cada región, consulta el artículo sobre geografía y regiones.  ↩