Este documento es el segundo de un conjunto de tres. Se analizan patrones comunes de arquitectura híbrida y de múltiples nubes. También se describen las situaciones para las que estos patrones son más adecuados. Por último, proporciona las prácticas recomendadas que puedes usar cuando implementes esas arquitecturas en Google Cloud.

El conjunto de documentos sobre patrones de arquitectura híbrida y de múltiples nubes consta de las siguientes partes:

• Compila arquitecturas híbridas y de múltiples nubes: Se analiza la planificación de una estrategia para diseñar una configuración de nube híbrida y múltiples nubes con Google Cloud.
• Patrones de arquitectura híbrida y de múltiples nubes: Se analizan patrones de arquitectura comunes para adoptar como parte de una estrategia de nube híbrida y multinube (este documento).
• Patrones de arquitectura de herramientas de redes seguras de nubes híbridas y múltiples: se analizan los patrones de arquitectura de redes híbridas y de múltiples nubes desde la perspectiva de las herramientas de redes.

Cada empresa tiene una cartera única de cargas de trabajo de aplicaciones que definen requisitos y restricciones a la arquitectura de una configuración de nube híbrida o de múltiples nubes. Aunque debes diseñar y adaptar tu arquitectura para que cumpla con estas restricciones y requisitos, puedes basarte en algunos patrones comunes para definir la arquitectura básica.

Un patrón de arquitectura es una forma repetible de estructurar varios componentes funcionales de una solución, aplicación o servicio tecnológico para crear una solución reutilizable que aborde ciertos requisitos o casos de uso. Una solución tecnológica basada en la nube suele estar compuesta por varios servicios en la nube distintos y distribuidos. Estos servicios colaboran para ofrecer la funcionalidad requerida. 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, módulos o servicios funcionales, y cada uno puede representar un componente funcional de la arquitectura de la aplicación. Esta arquitectura se puede estandarizar para abordar casos de uso empresariales específicos y servir como un patrón fundamental y reutilizable.

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

• Son los componentes de la solución o la aplicación.
• Las funciones esperadas para cada componente, por ejemplo, las funciones de frontend para proporcionar una interfaz gráfica de usuario o las funciones de backend para proporcionar acceso a los datos
• Cómo se comunican los componentes entre sí y con los sistemas o usuarios externos En las aplicaciones modernas, estos componentes interactúan a través de interfaces o APIs bien definidas. Existen una amplia 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 indican las dos categorías principales de patrones de arquitectura híbridos y de múltiples nubes:

• Patrones de arquitectura distribuidos: Estos patrones se basan en una implementación distribuida de cargas de trabajo o componentes de aplicaciones. Esto significa que ejecutan una aplicación (o componentes específicos de esa aplicación) en el entorno de procesamiento que mejor se adapte al patrón. De esta manera, el patrón puede aprovechar las diferentes propiedades y características de los entornos de procesamiento distribuidos e interconectados.
• Patrones de arquitectura redundante: estos patrones se basan en implementaciones redundantes de cargas de trabajo. En estos patrones, implementas las mismas aplicaciones y sus componentes en múltiples entornos de computación. El objetivo es aumentar la capacidad de rendimiento o la capacidad de recuperación de una aplicación, o bien replicar un entorno existente para el desarrollo y las pruebas.

Cuando implementes el patrón de arquitectura que selecciones, debes usar un arquetipo de implementación adecuado. Los arquetipos de Deployment son zonales, regionales, multirregionales o globales. Esta selección constituye la base para construir arquitecturas de implementación específicas de la aplicación. Cada arquetipo de implementación define una combinación de dominios de falla dentro de los cuales puede operar una aplicación. Estos dominios con fallas pueden abarcar una o más Google Cloud zonas o regiones y se pueden expandir para incluir tus centros de datos locales o dominios con fallas en otros proveedores de servicios en la nube.

Esta serie contiene las siguientes páginas:

• Patrones de arquitectura distribuidos

  • Patrón híbrido en niveles.

  • Patrón particionado de múltiples nubes.

  • Patrón de estadísticas de nubes híbridas y múltiples.

  • Patrón híbrido perimetral.

• Patrones de arquitectura redundantes

  • Patrón híbrido de entorno.
  • Patrones de nube híbrida y de múltiples nubes de continuidad empresarial
  • Patrón de aumentos de actividad de nube.

Colaboradores

Autor: Marwan Al Shawi | Ingeniero de Atención al Cliente para Socios

Otros colaboradores:

• Saud Albazei | Ingeniero de Atención al Cliente, Modernización de aplicaciones
• Anna Berenberg | Socio de Ingeniería
• Marco Ferrari | Arquitecto de soluciones de nube
• Victor Moreno | Gerente de producto, Herramientas de redes de Cloud
• Johannes Passing | Arquitecto de soluciones de Cloud
• Mark Schlagenhauf | Escritor técnico, Herramientas de redes
• Daniel Strebel | Líder de soluciones para EMEA, Modernización de aplicaciones
• Ammett Williams | Ingeniero de relaciones con desarrolladores

Patrones de arquitectura distribuidos

Cuando migres de un entorno de computación que no sea híbrido ni de múltiples nubes a una arquitectura híbrida o de múltiples nubes, primero considera las restricciones de tus aplicaciones existentes y cómo esas restricciones podrían provocar fallas en las aplicaciones. Esta consideración se vuelve más importante cuando tus aplicaciones o componentes de aplicaciones operan de manera distribuida en diferentes entornos. Después de considerar tus limitaciones, desarrolla un plan para evitarlas o superarlas. Asegúrate de tener en cuenta las capacidades únicas de cada entorno de computación en una arquitectura distribuida.

Consideraciones del diseño

Las siguientes consideraciones de diseño se aplican a los patrones de implementación distribuida. Según la solución objetivo y los objetivos comerciales, la prioridad y el efecto de cada consideración pueden variar.

Latencia

En cualquier patrón de arquitectura que distribuya componentes de aplicaciones (backends, frontends o microservicios) en diferentes entornos de computación, puede producirse latencia de comunicación. Esta latencia se ve influenciada por la conectividad de red híbrida (Cloud VPN y Cloud Interconnect) y la distancia geográfica entre el sitio local y las regiones de la nube, o entre las regiones de la nube en una configuración de múltiples nubes. Por lo tanto, es fundamental evaluar los requisitos de latencia de tus aplicaciones y su sensibilidad a las demoras de la red. Las aplicaciones que pueden tolerar la latencia son candidatas más adecuadas para la implementación distribuida inicial en un entorno híbrido o de múltiples nubes.

Comparación entre la arquitectura de estado temporal y la final

Para especificar las expectativas y las posibles implicaciones en cuanto a costo, escala y rendimiento, es importante analizar qué tipo de arquitectura necesitas y la duración prevista como parte de la etapa de planificación. Por ejemplo, si planeas usar una arquitectura híbrida o multinube durante mucho tiempo o de forma permanente, tal vez te convenga usar Cloud Interconnect. Para reducir los costos de transferencia de datos salientes y optimizar el rendimiento de la red de conectividad híbrida, Cloud Interconnect ofrece descuentos en los cargos por transferencia de datos salientes que cumplen con las condiciones de la tarifa de transferencia de datos con descuento.

Confiabilidad

La confiabilidad es un factor importante a tener en cuenta cuando se diseñan sistemas de TI. La disponibilidad del tiempo de actividad es un aspecto esencial de la confiabilidad del sistema. En Google Cloud, puedes aumentar la resiliencia de una aplicación implementando componentes redundantes de esa aplicación en varias zonas de una sola región¹ o en varias regiones, con capacidades de conmutación por error. La redundancia es uno de los elementos clave para mejorar la disponibilidad general de una aplicación. Para las aplicaciones con una configuración distribuida en entornos híbridos y de múltiples nubes, 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, considera qué redundancia de hardware o software (con mecanismos de conmutación por error) necesitas para tus aplicaciones y sus componentes. Lo ideal es que consideres la disponibilidad de un servicio o una aplicación en los distintos componentes y la infraestructura de asistencia (incluida la disponibilidad de conectividad híbrida) en todos los entornos. Este concepto también se conoce como disponibilidad compuesta de una aplicación o un servicio.

Según 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 confiabilidad del sistema que deseas, define métricas de confiabilidad claras y diseña aplicaciones que se recuperen automáticamente y soporten las interrupciones de manera eficaz en los diferentes entornos. Para ayudarte a definir formas adecuadas de medir la experiencia del cliente de tus servicios, consulta Define la confiabilidad en función de los objetivos de la experiencia del usuario.

Conectividad híbrida y de múltiples nubes

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

Administración

Las herramientas de supervisión y administración coherentes y unificadas son fundamentales para lograr configuraciones híbridas y de múltiples nubes exitosas (con o sin portabilidad de cargas de trabajo). A corto plazo, estas herramientas pueden agregar costos de desarrollo, pruebas y operaciones. Técnicamente, cuantos más proveedores de servicios en la nube uses, más compleja será la administración de tus entornos. La mayoría de los proveedores de servicios en la nube pública no solo tienen características diferentes, sino que también diferentes herramientas, ANS y APIs para administrar los servicios en la nube. Por lo tanto, compara las ventajas estratégicas de la arquitectura seleccionada con la posible complejidad a corto plazo y los beneficios a largo plazo.

Costo

Cada proveedor de servicios en la nube en un entorno de varias nubes tiene sus propias métricas y herramientas de facturación. Para proporcionar una mejor visibilidad y paneles unificados, considera usar herramientas de administración y optimización de costos en múltiples nubes. Por ejemplo, cuando se crean soluciones que priorizan la nube en varios entornos de nube, los productos, los precios, los descuentos y las herramientas de administración de cada proveedor pueden generar inconsistencias en los costos entre esos entornos.

Te recomendamos que tengas un método único y bien definido para calcular los costos totales de los recursos en la nube y proporcionar visibilidad de los costos. La visibilidad de costos es fundamental para la optimización de costos. 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 administración de costos de Cloud de Looker, puedes crear una vista centralizada de tus costos en varias nubes. Esta vista puede ayudarte a obtener una vista consolidada de los informes de tu inversión en múltiples nubes. Para obtener más información, consulta La estrategia para optimizar de manera eficaz la administración de costos de la facturación de Cloud.

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

Transferencia de datos

El movimiento de datos es una consideración importante para la planificación de la estrategia y la arquitectura híbrida y de múltiples nubes, en especial para los sistemas distribuidos. Las empresas deben identificar sus diferentes casos de uso comerciales, los datos que los respaldan y cómo se clasifican los datos (para las industrias reguladas). También deben considerar cómo el almacenamiento, el uso compartido y el acceso a los datos de los sistemas distribuidos en diferentes entornos pueden afectar el rendimiento de las aplicaciones y la coherencia de los datos. Esos factores pueden influir en la aplicación y la arquitectura de la canalización de datos. El conjunto integral deGoogle Cloudde opciones de movimiento de datos permite que las empresas satisfagan sus necesidades específicas y adopten arquitecturas híbridas y de múltiples nubes sin comprometer la simplicidad, la eficiencia ni el rendimiento.

Seguridad

Cuando migras aplicaciones a la nube, es importante tener en cuenta las capacidades de seguridad centradas en la nube, como la coherencia, la observabilidad y la visibilidad de seguridad unificada. Cada proveedor de servicios en la nube pública tiene su propio enfoque, prácticas recomendadas y capacidades de seguridad. Es importante analizar y alinear estas capacidades para crear una arquitectura de seguridad estándar y funcional. Los controles de IAM sólidos, la encriptación de datos, el análisis de vulnerabilidades y el cumplimiento de las reglamentaciones de la industria también son aspectos importantes de la seguridad en la nube.

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

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

• Patrón híbrido en niveles.
• Patrón particionado de múltiples nubes.
• Patrón de estadísticas de nubes híbridas y múltiples
• Patrón híbrido perimetral

Patrón híbrido en niveles.

Los componentes de la arquitectura de una aplicación se pueden clasificar como de frontend o de backend. En algunas situaciones, estos componentes se pueden alojar para operar desde diferentes entornos de procesamiento. Como parte del patrón de arquitectura híbrida por niveles, los entornos de procesamiento se encuentran en un entorno de procesamiento privado local y en Google Cloud.

Los componentes de las aplicaciones de frontend están expuestos directamente a los usuarios finales o a los dispositivos. Por lo tanto, estas aplicaciones suelen ser sensibles al rendimiento. Para desarrollar nuevas funciones y mejoras, las actualizaciones de software pueden ser frecuentes. Debido a que las aplicaciones de frontend suelen depender de las aplicaciones de backend para almacenar y administrar datos (y, posiblemente, la lógica empresarial y el procesamiento de entrada del usuario), a menudo no tienen estado o administran solo cantidades limitadas de datos.

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

Los componentes de las aplicaciones de backend suelen enfocarse en almacenar y administrar datos. En algunas arquitecturas, la lógica empresarial se puede incorporar dentro del componente de backend. En general, las nuevas versiones de aplicaciones de backend son menos frecuentes que las de aplicaciones de frontend. Las aplicaciones de backend tienen los siguientes desafíos que deben administrar:

• Cómo manejar un gran volumen de solicitudes
• Manejo de un gran volumen de datos
• Proteger los datos
• Mantener los datos actualizados en todas las réplicas del sistema

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

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

Colocar estas capas en contenedores separa sus necesidades técnicas, como los requisitos de escalamiento, y ayuda a migrarlas con un enfoque por fases. Además, te permite implementarlos en servicios de nube independientes de la plataforma que pueden ser portátiles en diferentes entornos, usar administración automatizada y escalar con plataformas administradas por la nube, como Cloud Run o la edición Enterprise de Google Kubernetes Engine (GKE). Además, las bases de datos administradas porGoogle Cloud, como Cloud SQL, ayudan a proporcionar el backend como la capa de la base de datos.

El patrón de arquitectura híbrida en niveles se enfoca en implementar los componentes de aplicaciones de frontend existentes en la nube pública. En este patrón, mantienes los componentes de la aplicación de backend existentes en su entorno de computación privado. Según la escala y el diseño específico de la aplicación, puedes migrar los componentes de la aplicación de frontend caso por caso. Si quieres obtener más información, consulta Migra a Google Cloud.

Si tienes una aplicación existente con componentes de backend y frontend alojados en tu entorno local, considera los límites de tu arquitectura actual. Por ejemplo, a medida que tu aplicación se expande y aumentan las exigencias en cuanto a su rendimiento y confiabilidad, debes comenzar a evaluar si se deben refactorizar partes de tu aplicación o moverlas a una arquitectura diferente y más óptima. El patrón de arquitectura híbrida por niveles te permite trasladar algunas cargas de trabajo y componentes de la aplicación a la nube antes de realizar una transición completa. También es fundamental tener en cuenta el costo, el tiempo y el riesgo que implica una migración de este tipo.

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

En el diagrama anterior, las solicitudes de clientes se envían al frontend de la aplicación que se aloja en Google Cloud. A su vez, el frontend de la aplicación envía datos de vuelta al entorno local en el que se aloja el backend de la aplicación (idealmente a través de una puerta de enlace de API).

Con el patrón de arquitectura híbrida en niveles, puedes aprovechar la infraestructura y los servicios globales deGoogle Cloud , como se muestra en la arquitectura de ejemplo del siguiente diagrama. Se puede acceder al frontend de la aplicación a través de Google Cloud. También puede agregar elasticidad al frontend usando el ajuste de escala automático para responder de manera dinámica y eficiente a la demanda de escalamiento sin aprovisionar en exceso la infraestructura. Existen diferentes arquitecturas que puedes usar para compilar y ejecutar aplicaciones web escalables en Google Cloud. Cada arquitectura tiene ventajas y desventajas para diferentes requisitos.

Para obtener más información, mira Three ways to run scalable web apps on Google Cloud en YouTube. Para obtener más información sobre las diferentes formas de modernizar tu plataforma de comercio electrónico enGoogle Cloud, consulta Cómo crear una plataforma de comercio digital en Google Cloud.

En el diagrama anterior, el frontend de la aplicación se aloja enGoogle Cloud para proporcionar una experiencia del usuario multirregional y optimizada a nivel global que utiliza el balanceo de cargas global, el ajuste de escala automático y la protección contra DSD a través de Google Cloud Armor.

Con el tiempo, la cantidad de aplicaciones que implementas en la nube pública puede aumentar hasta el punto en el que podrías considerar migrar los componentes de las aplicaciones de backend a la nube pública. Si prevés que tu sitio tendrá mucho tráfico, optar por servicios administrados en la nube puede ayudarte a ahorrar esfuerzo de ingeniería cuando administres tu propia infraestructura. Considera esta opción, a menos que las restricciones o los requisitos exijan alojar los componentes de la aplicación de backend de forma local. Por ejemplo, si los datos de tu backend están sujetos a restricciones reglamentarias, es probable que debas mantenerlos en las instalaciones. Sin embargo, cuando corresponda y se cumplan los requisitos, usar las capacidades de Sensitive Data Protection, como las técnicas de desidentificación, puede ayudarte a migrar 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 que proporciona y mantiene Google, y que es independiente del Google Cloud centro de datos. Para asegurarte de que Distributed Cloud satisfaga tus requisitos actuales y futuros, debes conocer sus limitaciones en comparación con una zona de GKE convencional basada en la nube.

Ventajas

Enfocarse primero en las aplicaciones de 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 de backend no dependen de los componentes de frontend. Por lo tanto, aislar y migrar aplicaciones de frontend suele ser menos complejo que migrar aplicaciones de backend.
• Como las aplicaciones de frontend a menudo no tienen estado o no administran datos por sí mismas, no suelen ser tan difíciles de migrar como los backends.
  • Los componentes del frontend se pueden optimizar como parte de la migración para usar la arquitectura sin estado. Para obtener más información, mira Cómo portar apps web con estado a Cloud Run en YouTube.

La implementación de aplicaciones de frontend existentes o desarrolladas hace poco en la nube pública ofrece varias ventajas:

• Muchas aplicaciones de frontend están sujetas a cambios frecuentes. La ejecución de estas aplicaciones en la nube pública simplifica la configuración de un proceso de integración continua/implementación continua (CI/CD). Puedes usar CI/CD para enviar actualizaciones de manera eficiente y automatizada. Para obtener más información, consulta CI/CD en Google Cloud.
• Los frontends sensibles al rendimiento con una carga de tráfico variable pueden beneficiarse de manera significativa del balanceo de cargas, las implementaciones multirregionales, el almacenamiento en caché de Cloud CDN, las capacidades sin servidores y de ajuste de escala automático que permite una implementación basada en la nube (idealmente con una arquitectura sin estado).

• Adoptar microservicios con contenedores a través de una plataforma administrada por la nube, como GKE, te permite usar arquitecturas modernas, como microfrontend, que extienden los microservicios a los componentes de frontend.

  La extensión de microservicios se usa comúnmente con los frontends que involucran a varios equipos que colaboran en la misma aplicación. Ese 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 separación, ya que los equipos de desarrollo individuales pueden seleccionar sus tecnologías y código preferidos.
  • Puede fomentar ciclos rápidos de desarrollo e implementación sin afectar al resto de los componentes de frontend que podrían administrar otros equipos.

• Ya sea que implementen interfaces de usuario o APIs, o manejen la transferencia de datos de Internet de las cosas (IoT), las aplicaciones de frontend pueden beneficiarse de las capacidades de los servicios en la nube como Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine o Cloud Run.

• Los proxies de API administrados por Cloud ayudan a hacer lo siguiente:

  • Desacopla la API orientada a la app de tus servicios de backend, como los microservicios.
  • Protege las apps de los cambios en el código de backend.
  • Admite tus arquitecturas de frontend existentes basadas en APIs, como backend para frontend (BFF), microfrontend y otras.
  • Expón tus APIs en Google Cloud o en otros entornos implementando proxies de API en Apigee.

También puedes aplicar el patrón híbrido en niveles a la inversa. Para ello, implementa backends en la nube mientras mantienes los frontends en entornos de computación privados. Aunque es menos común, este enfoque se aplica mejor cuando se trata de un frontend pesado y monolítico. En esos casos, podría ser más fácil extraer las funcionalidades de backend de forma iterativa y, luego, implementar estos nuevos backends en la nube.

En la tercera parte de esta serie, se analizan los posibles patrones de redes para habilitar esa arquitectura. Apigee Hybrid ayuda como plataforma para compilar y administrar proxies de API en un modelo de implementación híbrida. Para obtener más información, consulta Arquitectura con acoplamiento flexible, incluidas las arquitecturas monolíticas y de microservicios en niveles.

Prácticas recomendadas

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

Prácticas recomendadas para reducir la complejidad

Cuando apliques el patrón de arquitectura híbrido en niveles, considera las siguientes prácticas recomendadas que pueden ayudarte a reducir su complejidad operativa y de implementación general:

• 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.

Debido a que la mayor parte de la interacción del usuario involucra sistemas que se conectan en múltiples entornos de computación, es importante que estos sistemas cuenten con una conectividad rápida y de baja latencia. Para cumplir con las expectativas de disponibilidad y rendimiento, debes diseñar tu sistema para que tenga alta disponibilidad, baja latencia y niveles de capacidad de procesamiento adecuados. Desde el punto de vista de la seguridad, la comunicación debe ser detallada y controlada. Lo ideal es que expongas los componentes de la aplicación con APIs seguras. Para obtener más información, consulta Salida controlada.

• Para minimizar la latencia de comunicación entre entornos, selecciona una región deGoogle Cloud que esté cerca de la ubicación geográfica del entorno de computación privado en el que se alojan los componentes de backend de tu aplicación. Si deseas obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.
• Minimiza las dependencias altas entre sistemas que se ejecutan en diferentes entornos, en especial, cuando la comunicación se maneja de forma síncrona. Estas dependencias pueden disminuir el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por la transferencia de datos salientes.
• 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 ingresan aGoogle Cloud en comparación con el tráfico saliente que sale de Google Cloud. Sin embargo, debes conocer el volumen previsto de transferencia de datos salientes que saldrá de Google Cloud. Si planeas usar esta arquitectura a largo plazo con grandes volúmenes de transferencia de datos salientes, considera usar Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y puede reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.
• Para proteger la información sensible, te recomendamos que encriptes todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, puedes usar túneles de VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.

• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación en diversos backends, recomendamos, cuando corresponda, implementar una puerta de enlace de API o un proxy como una fachada unificadora. Esta puerta de enlace o proxy actúa como un punto de control centralizado y realiza las siguientes medidas:

  • Implementa medidas de seguridad adicionales.
  • Protege las apps para clientes y otros servicios de los cambios en el código de backend.
  • Facilita los registros de auditoría para la comunicación entre todas las aplicaciones de varios entornos y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios heredados y los modernizados.
    • Apigee y Apigee Hybrid te permiten alojar y administrar puertas de enlace híbridas y de nivel empresarial en entornos locales, perimetrales, otras nubes y entornos deGoogle Cloud .

• Para facilitar el establecimiento de configuraciones híbridas, usa Cloud Load Balancing con conectividad híbrida. Esto significa que puedes extender los beneficios del balanceo de cargas de Cloud a los servicios alojados en tu entorno de procesamiento local. Este enfoque permite migraciones de cargas de trabajo por fases a Google Cloud con una interrupción mínima o nula del servicio, lo que garantiza una transición fluida para los servicios distribuidos. Para obtener más información, consulta la descripción general de los grupos de extremos de red de conectividad híbrida.

• A veces, el uso de una puerta de enlace de API, o un proxy y un balanceador de cargas de aplicaciones en conjunto, puede proporcionar una solución más sólida para administrar, proteger y distribuir el tráfico de API a gran escala. El uso de Cloud Load Balancing con puertas de enlace de API te permite lograr lo siguiente:

  • Proporciona APIs de alto rendimiento con Apigee y Cloud CDN para reducir la latencia, alojar APIs a nivel global y aumentar la disponibilidad en las temporadas de tráfico pico. Para obtener más información, mira Delivering high-performing APIs with Apigee and Cloud CDN en YouTube.
  • Implementa la administración avanzada del tráfico.
  • Usa Cloud Armor como servicio de protección contra DSD y seguridad de red para proteger tus APIs.
  • Administra el balanceo de cargas eficiente en las puertas de enlace de varias regiones. Para obtener más información, mira Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee (Protege las APIs e implementa la conmutación por error multirregional con Private Service Connect y Apigee) en YouTube.

• Utiliza la administración de APIs y la malla de servicios para proteger y controlar la comunicación y la exposición de servicios con la arquitectura de microservicios.

  • Usa Cloud Service Mesh para permitir la comunicación de servicio a servicio que mantiene la calidad del servicio en un sistema compuesto por servicios distribuidos en el que puedes administrar la autenticación, la autorización y la encriptación entre servicios.
  • Usa una plataforma de administración de APIs, como Apigee, que permita que tu organización y las entidades externas consuman esos servicios exponiéndolos como APIs.

• Establece una identidad común entre los entornos para que los sistemas puedan autenticarse con seguridad a través de los límites del entorno.

• Implementa sistemas de CI/CD y administración de la configuración en la nube pública. Para obtener más información, consulta Patrón de arquitectura de redes duplicadas.

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

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

• Aunque el enfoque se encuentra en las aplicaciones de frontend en este patrón, mantente al tanto de la necesidad de modernizar tus aplicaciones de backend. Si el ritmo de desarrollo de las aplicaciones de backend es, en gran medida, más lento que el de las aplicaciones de frontend, la diferencia puede causar una complejidad adicional.
• Tratar las APIs como interfaces de backend optimiza las integraciones, el desarrollo de frontend, las interacciones de servicios y oculta las complejidades del sistema de backend. Para abordar estos desafíos, Apigee facilita el desarrollo y la administración de proxies o puertas de enlace de API para implementaciones híbridas y de múltiples nubes.
• Elige el enfoque de renderización para tu aplicación web de frontend según el contenido (estático o dinámico), el rendimiento de la optimización para motores de búsqueda y las expectativas sobre las velocidades de carga de la página.
• Cuando se selecciona una arquitectura para aplicaciones web basadas en contenido, hay varias opciones disponibles, incluidas las arquitecturas monolíticas, sin servidores, 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 de arquitectura que se alinee con tus objetivos comerciales 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 alojadas en contenedores con Kubernetes como la capa de tiempo de ejecución común. Con el patrón de arquitectura híbrida en niveles, puedes ejecutarlo en cualquiera de las siguientes situaciones:

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

    • Cuando usas contenedores y Kubernetes en diferentes entornos, tienes la flexibilidad de modernizar las cargas de trabajo y, luego, migrar a Google Cloud en diferentes momentos. Esto ayuda cuando una carga de trabajo depende en gran medida de otra y no se puede migrar de forma individual, o bien 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 que habilita este enfoque. Para obtener más información, consulta Entorno híbrido de GKE Enterprise.

  • En un entorno Google Cloud para los componentes de la aplicación modernizada y migrada

    • Usa este enfoque cuando tengas back-ends heredados locales que no admitan la contenedorización o que requieran una gran cantidad de tiempo y recursos para modernizarse a corto plazo.

    Para obtener más información sobre el diseño y la refactorización de una app monolítica en una arquitectura de microservicios para modernizar la arquitectura de tu aplicación web, consulta Introducción a los microservicios.

• Puedes combinar tecnologías de almacenamiento de datos según las necesidades de tus aplicaciones web. Usar Cloud SQL para datos estructurados y Cloud Storage para archivos multimedia es un enfoque común para satisfacer diversas necesidades de almacenamiento de datos. Dicho esto, la elección depende mucho de tu caso de uso. Para obtener más información sobre las opciones de almacenamiento de datos para los backends de aplicaciones basadas en contenido y las modalidades eficaces, consulta Opciones de almacenamiento de datos para apps web basadas en contenido. Consulta también Explicación de las opciones de bases de datos. Google Cloud

Patrón particionado de múltiples nubes.

El patrón de arquitectura de múltiples nubes con partición combina múltiples entornos de nube pública que son operados por diferentes proveedores de servicios en la nube. Esta arquitectura proporciona la flexibilidad necesaria para implementar una aplicación en un entorno de procesamiento óptimo que tenga en cuenta los factores y las consideraciones de múltiples nubes que se analizaron en la primera parte de esta serie.

En el siguiente diagrama, se muestra un patrón de arquitectura de múltiples nubes con partición.

Este patrón de arquitectura se puede compilar de dos maneras diferentes. El primer enfoque se basa en implementar 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 patrón de arquitectura híbrida en niveles. Sin embargo, en lugar de usar un entorno local con una nube pública, usa 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 implementa diferentes aplicaciones en diferentes entornos de nube pública. En la siguiente lista no exhaustiva, se describen algunos de los impulsores empresariales del segundo enfoque:

• Integrar por completo las aplicaciones alojadas en entornos de nube dispares durante una situación de fusión y adquisición entre dos empresas
• Promover la flexibilidad y satisfacer las diversas preferencias de la nube dentro de tu organización Adopta este enfoque para alentar a las unidades organizativas a elegir el proveedor de servicios en la nube que mejor se adapte a sus necesidades y preferencias específicas.
• Para operar en una implementación de nube global o multirregional Si una empresa debe cumplir con las reglamentaciones 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 de servicios en la nube no tiene una región en la nube allí.

Con el patrón de arquitectura de múltiples nubes con partición, 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 clave. Cuando implementas cargas de trabajo en múltiples entornos de computación y deseas mantener la capacidad de mover las cargas de trabajo entre entornos, debes abstraer las diferencias entre los entornos. Con GKE Enterprise, puedes diseñar y compilar una solución para resolver la complejidad de varias nubes con posturas coherentes de administración, operaciones y seguridad. Para obtener más información, consulta GKE Multi-Cloud.

Como se mencionó anteriormente, hay algunas situaciones en las que puede haber motivos comerciales y técnicos para combinar Google Cloud con otro proveedor de servicios en la nube y particionar las cargas de trabajo en esos entornos de nube. Las soluciones de múltiples nubes te ofrecen la flexibilidad para migrar, compilar y optimizar la portabilidad de las aplicaciones en entornos de múltiples nubes, a la vez que minimizan la dependencia y te ayudan a cumplir con tus requisitos reglamentarios. Por ejemplo, puedes conectarte Google Cloud con Oracle Cloud Infrastructure (OCI) para crear una solución de múltiples nubes que aproveche las capacidades de cada plataforma con un Cloud Interconnect privado para combinar componentes que se ejecutan en OCI con recursos que se ejecutan en Google Cloud. Para obtener más información, consulta Google Cloud y Oracle Cloud Infrastructure: aprovecha al máximo la multinube. Además, Cross-Cloud Interconnect facilita la conectividad dedicada de ancho de banda alto entre Google Cloud y otros proveedores de servicios en la nube admitidos, lo que te permite diseñar y compilar soluciones de múltiples nubes para controlar un volumen alto de tráfico entre nubes.

Ventajas

Si bien el uso de una arquitectura de múltiples nubes ofrece varios beneficios comerciales y técnicos, como se analizó en Factores de impulso, consideraciones, estrategia y enfoques, es fundamental realizar una evaluación detallada de la factibilidad de cada beneficio potencial. En tu evaluación, debes tener en cuenta cuidadosamente los desafíos asociados directos o indirectos, o los posibles obstáculos, y tu capacidad para superarlos de manera eficaz. Además, ten en cuenta que el crecimiento a largo plazo de tus aplicaciones o servicios puede generar complejidades que superen los beneficios iniciales.

Estas son algunas ventajas clave del patrón de arquitectura de múltiples nubes con partición:

• En situaciones en las que necesites minimizar el compromiso con un solo proveedor de servicios en la nube, puedes distribuir las aplicaciones en varios proveedores. Como resultado, podrías reducir relativamente la dependencia del proveedor con la capacidad de cambiar de plan (hasta cierto punto) entre tus proveedores de servicios en la nube. La Nube abierta ayuda a llevar las capacidades de Google Cloud , como GKE Enterprise, a diferentes ubicaciones físicas. Al extender las capacidades en las instalaciones, en varias nubes públicas y en el borde, proporciona flexibilidad, agilidad y impulsa la transformación. Google Cloud

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

• El arquetipo de arquitectura de múltiples nubes particionadas puede ayudar a reducir la latencia y mejorar la calidad general de la experiencia del usuario en ubicaciones donde el proveedor de nube principal no tiene una región de nube o un punto de presencia. Este patrón es especialmente útil cuando se usa conectividad de múltiples nubes de alta capacidad y baja latencia, como Cross-Cloud Interconnect y CDN Interconnect con una CDN distribuida.

• Puedes implementar aplicaciones en múltiples proveedores de servicios en la nube de tal manera que puedes elegir entre los mejores servicios que estos ofrecen.

• El patrón de arquitectura multicloud particionada puede ayudar a facilitar y acelerar las situaciones de 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

• Comienza por implementar una carga de trabajo que no sea fundamental. Esta implementación inicial en la nube secundaria puede servir como patrón para futuras implementaciones o migraciones. Sin embargo, es probable que este enfoque no sea aplicable en situaciones en las que la carga de trabajo específica debe residir legal o reglamentariamente en una región de la nube específica, y el proveedor de nube principal no tiene una región en el territorio requerido.
• Minimiza las dependencias entre sistemas que se ejecutan en diferentes entornos de nube pública, en especial, cuando la comunicación se maneja de forma síncrona. Estas dependencias pueden disminuir el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por la transferencia de datos salientes.
• Para abstraer las diferencias entre entornos, considera usar contenedores y Kubernetes cuando las aplicaciones lo admitan y sea factible.
• Asegúrate de que las canalizaciones de CI/CD y las herramientas para la implementación y la supervisión sean coherentes en los diferentes entornos 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 usas.
  • La comunicación debe ser detallada y controlada. Usa APIs seguras para exponer los componentes de la aplicación.
  • Considera usar el patrón de arquitectura en malla o uno de los patrones de redes con puerta, según tus requisitos técnicos y comerciales específicos.
• Para satisfacer tus expectativas de disponibilidad y rendimiento, diseña una alta disponibilidad (HA) de extremo a extremo, una latencia baja y niveles de capacidad de procesamiento adecuados.

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

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

• Si usas varias CDN como parte de tu patrón de arquitectura particionada de varias nubes y propagas tu otra CDN con archivos grandes de datos de Google Cloud, considera usar vínculos de CDN Interconnect entre Google Cloud y los proveedores admitidos para optimizar este tráfico y, posiblemente, su costo.

• Extiende tu solución de administración de identidades entre los entornos para que los sistemas puedan autenticarse con seguridad a través de los límites del entorno.

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

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

• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación en diversos backends, recomendamos, cuando corresponda, implementar una puerta de enlace de API o un proxy como una fachada unificadora. Esta puerta de enlace o proxy actúa como un punto de control centralizado y realiza las siguientes medidas:

  • Implementa medidas de seguridad adicionales.
  • Protege las apps para clientes y otros servicios de los cambios en el código de backend.
  • Facilita los registros de auditoría para la comunicación entre todas las aplicaciones de varios entornos y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios heredados y los modernizados.
    • Apigee y Apigee Hybrid te permiten alojar y administrar puertas de enlace híbridas y de nivel empresarial en entornos locales, perimetrales, otras nubes y entornos deGoogle Cloud .

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

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

  • Aumenta el rendimiento con Cloud CDN.

  • Proporciona protección contra WAF y DSD a través de Google Cloud Armor.

• Usa herramientas coherentes para el registro y la supervisión en todos los entornos de nube siempre que sea posible. Puedes considerar usar sistemas de supervisión de código abierto. Para obtener más información, consulta Patrones de registro y supervisión para nubes híbridas y múltiples.

• Si implementas componentes de la aplicación de forma distribuida, en la que los componentes de una sola aplicación se implementan en más de un entorno de nube, consulta las prácticas recomendadas para el patrón de arquitectura híbrida por niveles.

Patrón de estadísticas de nubes híbridas y múltiples

En este documento, se explica que el objetivo del patrón de estadísticas de nubes híbridas y múltiples es aprovechar la división entre las cargas de trabajo transaccionales y las de estadísticas.

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

• Las cargas de trabajo transaccionales incluyen aplicaciones interactivas, como las de ventas, procesamiento financiero, planificación de recursos empresariales o comunicación.
• Las cargas de trabajo de estadísticas incluyen aplicaciones que transforman, analizan, definen mejor o permiten visualizar datos para facilitar los procesos de toma de decisiones.

Los sistemas de estadísticas obtienen sus datos de los sistemas transaccionales a través de consultas a las APIs o el acceso a las bases de datos. En la mayoría de las empresas, los sistemas de estadísticas y los transaccionales tienden a estar separados y con acoplamiento bajo. El objetivo del patrón de estadísticas de nubes híbridas y múltiples es aprovechar esta división ya existente y ejecutar las cargas de trabajo transaccionales y de estadísticas en dos entornos de computación diferentes. Los datos sin procesar se extraen primero de las cargas de trabajo que se ejecutan en el entorno de computación privado y, luego, se cargan enGoogle Cloud, donde se usan para el procesamiento analítico. Puede que algunos de los resultados se vuelvan a ingresar a los sistemas transaccionales.

En el siguiente diagrama, se ilustran las arquitecturas posibles de forma conceptual mostrando las canalizaciones de datos potenciales. Cada ruta o flecha representa una opción posible de canalización de transformación y movimiento de datos que puede basarse en ETL o ELT, según la calidad de los datos disponibles y el caso de uso objetivo.

Para trasladar tus datos a Google Cloud y aprovechar su valor, usa los servicios de transferencia de datos, un conjunto completo de servicios de transferencia, integración y replicación de datos.

Como se muestra en el diagrama anterior, la conexión Google Cloud con entornos locales y otros entornos de nube puede habilitar varios casos de uso de análisis de datos, como la transmisión de datos y las copias de seguridad de bases de datos. Para potenciar el transporte fundamental de un patrón de análisis híbrido y de múltiples nubes que requiere un gran volumen de transferencia de datos, Cloud Interconnect y Cross-Cloud Interconnect proporcionan conectividad dedicada a proveedores locales y otros proveedores de servicios en la nube.

Ventajas

La ejecución de cargas de trabajo de estadísticas en la nube tiene varias ventajas clave:

• El tráfico de entrada (trasladar datos de tu entorno de computación privado o de otras nubes aGoogle Cloud) puede ser gratuito.
• Las cargas de trabajo de estadísticas a menudo necesitan procesar cantidades sustanciales de datos y pueden ser impredecibles, por lo que son adecuadas en particular para implementarse en un entorno de nube pública. Si escalas los recursos de procesamiento de forma dinámica, puedes procesar grandes conjuntos de datos con rapidez al tiempo que evitas las inversiones iniciales o la necesidad de aprovisionar en exceso los equipos de procesamiento.
• Google Cloud proporciona un amplio conjunto de servicios para administrar datos durante todo su ciclo de vida, desde la adquisición inicial, luego el procesamiento y el análisis hasta la visualización final.
  • Los servicios de movimiento de datos en Google Cloud proporcionan un paquete completo de productos para mover, integrar y transformar datos sin problemas de diferentes maneras.
  • Cloud Storage es ideal para compilar un data lake.

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

• BigQuery Omni proporciona potencia de procesamiento 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 capacidad de análisis en múltiples nubes permite que los equipos de datos desglosen los silos de datos. Para obtener más información sobre cómo consultar datos almacenados fuera de BigQuery, consulta Introducción a las fuentes de datos externas.

Prácticas recomendadas

Para implementar el patrón de arquitectura de estadísticas híbridas y de múltiples nubes, ten en cuenta las siguientes prácticas recomendadas generales:

• Usa el patrón de redes de traspaso para habilitar la transferencia de datos. Si es necesario volver a ingresar los resultados de estadísticas a los sistemas transaccionales, puedes combinar los patrones de traspaso y de salida protegida.
• Usa colas de Pub/Sub o buckets de Cloud Storage para entregar datos a Google Cloud desde sistemas transaccionales que se ejecutan en tu entorno de computación privado. Estas colas o buckets pueden servir como fuentes para las cargas de trabajo y las canalizaciones de procesamiento de datos.
• Para implementar canalizaciones de datos de ETL y ELT, considera usar Cloud Data Fusion o Dataflow según los requisitos específicos de tu caso de uso. Ambos son servicios de procesamiento de datos completamente administrados y centrados en la nube para compilar y administrar canalizaciones de datos.
• Para descubrir, clasificar y proteger tus valiosos recursos de datos, considera usar las capacidades de la Protección de datos sensibles, como las técnicas de desidentificación. Google Cloud Estas técnicas te permiten enmascarar, encriptar y reemplazar datos sensibles, como la información de identificación personal (PII), con una clave predeterminada o generada de manera aleatoria, cuando corresponda y sea compatible.

• Cuando realices una transferencia de datos inicial desde tu entorno de computación privado a Google Cloud, elige el método de transferencia más adecuado según el tamaño de tu conjunto de datos y el ancho de banda disponible. Para obtener más información, consulta Migración a Google Cloud: Transfiere tus conjuntos de datos grandes.

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

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

• Usa herramientas y procesos coherentes en todos los entornos. En una situación con un patrón híbrido de estadísticas, esta práctica puede ayudar a aumentar la eficiencia operativa, aunque no es un requisito previo.

Patrón híbrido perimetral.

La ejecución de cargas de trabajo en la nube requiere que los clientes en algunos casos tengan una conectividad a Internet rápida y confiable. Para las redes de hoy en día, este requisito no suele ser un desafío en cuanto a la adopción de la nube. Sin embargo, hay situaciones en las que no se puede confiar en la conectividad continua, como las siguientes:

• Los barcos y otros vehículos marítimos pueden estar conectados solo de forma intermitente o tener acceso solo a vínculos satelitales de alta latencia.
• Las fábricas o centrales eléctricas pueden estar conectadas a Internet. Estas instalaciones pueden tener requisitos de confiabilidad que exceden las garantías de disponibilidad de su proveedor de Internet.
• Las tiendas minoristas y los supermercados pueden conectarse solo de manera ocasional o usar vínculos que no proporcionan la confiabilidad o la capacidad de procesamiento necesarias para manejar las transacciones fundamentales para la empresa.

La arquitectura de patrón híbrido perimetral aborda estos desafíos mediante la ejecución de cargas de trabajo fundamentales para el tiempo y la empresa de forma local, en los extremos de la red, a la vez que usa la nube con todos los otros tipos de cargas de trabajo. En una arquitectura híbrida perimetral, el vínculo de Internet es un componente no fundamental que se usa con fines de administración y para sincronizar o subir datos, a menudo de forma asíncrona. Sin embargo, no interviene en transacciones fundamentales para el tiempo ni la empresa.

Ventajas

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

• El tráfico de entrada (el traslado de datos del perímetro aGoogle Cloud) podría ser gratuito.
• Ejecutar las cargas de trabajo fundamentales para el tiempo y la empresa en el perímetro ayuda a garantizar una baja latencia y autosuficiencia. Aunque la conectividad a Internet falle o no esté disponible de forma temporal, puedes ejecutar todas las transacciones importantes. Al mismo tiempo, puedes beneficiarte del uso de la nube para una gran parte de tu carga de trabajo general.
• Puedes volver a usar las inversiones existentes en equipos de procesamiento y almacenamiento.
• Con el tiempo, puedes reducir de forma gradual la fracción de las cargas de trabajo que se ejecutan en el perímetro y trasladarlas a la nube, ya sea mediante la reelaboración de ciertas aplicaciones o el equipamiento de algunas ubicaciones perimetrales con vínculos de Internet más confiables.
• Los proyectos relacionados con el Internet de las cosas (IoT) pueden volverse más rentables si se realizan cálculos de datos de forma local. Esto permite que las empresas ejecuten y procesen algunos servicios de forma local en el perímetro, más cerca de las fuentes de datos. También permite que las empresas envíen datos de forma selectiva a la nube, lo que puede ayudar a reducir la capacidad, la transferencia de datos, el procesamiento y los costos generales de la solución de IoT.
• La computación perimetral puede actuar como una capa de comunicación intermedia entre los servicios heredados y los modernizados. Por ejemplo, servicios que podrían ejecutar una puerta de enlace de API en contenedores, como Apigee Hybrid. Esto permite que las aplicaciones y los sistemas heredados se integren con servicios modernizados, como las soluciones de IoT.

prácticas recomendadas

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

• Si la comunicación es unidireccional, usa el patrón de entrada protegida.
• Si la comunicación es bidireccional, considera el patrón de entrada y salida protegidas.
• Si la solución consta de muchos sitios remotos perimetrales que se conectan aGoogle Cloud a través de Internet pública, puedes usar una solución de WAN definida por software (SD-WAN). También puedes usar Network Connectivity Center con un router SD-WAN de terceros compatible con un socio para simplificar el aprovisionamiento y la administración de la conectividad segura a gran escala.Google Cloud
• Minimiza las dependencias entre los sistemas que se ejecutan en el perímetro y los sistemas que se ejecutan en el entorno de nube. Cada dependencia puede comprometer las ventajas de confiabilidad y latencia de una configuración híbrida perimetral.
• Para administrar y operar múltiples ubicaciones perimetrales de manera eficiente, debes tener un plano de administración centralizado y una solución de supervisión en la nube.
• Asegúrate de que las canalizaciones de CI/CD y las herramientas para la implementación y la supervisión sean coherentes en los diferentes entornos perimetrales y de nube.
• Considera usar contenedores y Kubernetes cuando sea aplicable y factible para abstraer las diferencias entre varias ubicaciones perimetrales y también entre ubicaciones perimetrales y la nube. Debido a que Kubernetes proporciona una capa de entorno de ejecución común, puedes desarrollar, ejecutar y operar cargas de trabajo de manera coherente en todos los entornos de computación. También puedes mover cargas de trabajo entre el borde y la nube.
  • Para simplificar la configuración y el funcionamiento híbridos, puedes usar GKE Enterprise para esta arquitectura (si se usan contenedores en todos los entornos). Considera las opciones de conectividad posibles que tienes para conectar un clúster de GKE Enterprise que se ejecuta en tu entorno local o perimetral a Google Cloud.
• Como parte de este patrón, aunque algunos componentes de GKE Enterprise pueden mantenerse durante una interrupción temporal de la conectividad conGoogle Cloud, no uses GKE Enterprise cuando esté desconectado de Google Cloud como un modo de trabajo nominal. Para obtener más información, consulta Impacto de la desconexión temporal de Google Cloud.
• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación en diversos servicios de backend y perimetrales, recomendamos, cuando corresponda, implementar una puerta de enlace de API o un proxy como una fachada. Esta puerta de enlace o proxy actúa como un punto de control centralizado y realiza las siguientes medidas:
  • Implementa medidas de seguridad adicionales.
  • Protege las apps para clientes y otros servicios de los cambios en el código de backend.
  • Facilita los registros de auditoría para la comunicación entre todas las aplicaciones de varios entornos y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios heredados y los modernizados.
    • Apigee y Apigee Hybrid te permiten alojar y administrar puertas de enlace híbridas y de nivel empresarial en entornos locales, perimetrales, otras nubes y entornos deGoogle Cloud .
• Establece una identidad común entre los entornos para que los sistemas puedan autenticarse con seguridad a través de los límites del entorno.
• Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas con el uso de los túneles VPN, TLS o de ambos.

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 existente. Luego, usas la nube pública para tus entornos de desarrollo y pruebas, o para otros entornos. Este patrón se basa en la implementación redundante de las mismas aplicaciones en múltiples entornos de computación. El objetivo de la implementación es ayudar a aumentar la capacidad, la agilidad y la resiliencia.

Cuando evalúes qué cargas de trabajo migrar, puede que observes casos en los que ejecutar una aplicación específica en la nube pública presente ciertos desafíos:

• Puede que las restricciones jurisdiccionales o reglamentarias requieran que mantengas los datos en un país específico.
• Puede que los términos de licencia de terceros te impidan operar un software determinado en un entorno de nube.
• Puede que una aplicación requiera acceso a dispositivos de hardware que solo están disponibles de forma local.

En esos casos, considera el entorno de producción y también todos los entornos involucrados en el ciclo de vida de una aplicación, incluidos los sistemas de desarrollo, de prueba y de etapa de pruebas. 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. Consulta al departamento de cumplimiento de tu organización o al equipo equivalente.

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

Ejecutar sistemas de desarrollo y prueba en entornos diferentes a los sistemas de producción puede parecer arriesgado y podría desviarse de las prácticas recomendadas existentes o de los intentos de minimizar las diferencias entre los entornos. Si bien estas preocupaciones están justificadas, no se aplican si haces una distinción entre las etapas de los procesos de desarrollo y de prueba:

A pesar de que los procesos de implementación, prueba y desarrollo difieren para cada aplicación, en general involucran variaciones de las siguientes etapas:

• Desarrollo: crear una versión candidata para lanzamiento.
• Pruebas funcionales o pruebas de aceptación del usuario: verificar que la versión candidata para lanzamiento cumpla con los requisitos funcionales.
• Pruebas de rendimiento y confiabilidad: verificar que la versión candidata para lanzamiento cumpla con los requisitos no funcionales. También se conoce como prueba de carga.
• Pruebas de implementación o etapas de pruebas: verificar que el procedimiento de implementación funcione.
• Producción: lanzamiento de aplicaciones nuevas o actualizadas.

Llevar a cabo más de una etapa en un mismo entorno no suele ser práctico, por lo que cada etapa requiere, la mayoría de las veces, uno o más entornos dedicados.

El propósito principal de un entorno de pruebas es ejecutar pruebas funcionales. El propósito principal de un entorno de etapa de pruebas es verificar si los procedimientos de implementación de tu aplicación funcionan según lo previsto. En el momento en que una versión llega a un entorno de etapa de pruebas, las pruebas funcionales ya deberían estar completas. La etapa de pruebas es el último paso antes de implementar software en tu implementación de producción.

Para garantizar que los resultados de las pruebas sean significativos y se apliquen a la implementación de producción, el conjunto de entornos que uses durante el ciclo de vida de una aplicación debe satisfacer las siguientes reglas, en la medida de lo posible:

• Todos los entornos son equivalentes en cuanto a sus funciones. Es decir, la arquitectura, las APIs y las versiones de los sistemas operativos y las bibliotecas son equivalentes y los sistemas se comportan igual en todos los entornos. Esta equivalencia evita situaciones en las que las aplicaciones funcionan en un entorno, pero no en otro, o donde los defectos no son reproducibles.
• Los entornos que se usan para las pruebas de rendimiento y confiabilidad, la etapa de pruebas y la producción son equivalentes en términos no funcionales. Es decir, su rendimiento, escala y configuración, así como la forma en que se operan y mantienen, son iguales o difieren solo en cuestiones insignificantes. De lo contrario, las pruebas de rendimiento y etapas de pruebas no tienen sentido.

En general, está bien si los entornos que se usan para pruebas funcionales y de desarrollo difieren en términos no funcionales con los otros entornos.

Como se ilustra en el siguiente diagrama, los entornos de prueba y desarrollo se compilan en Google Cloud. Una base de datos administrada, como Cloud SQL, se puede usar como opción para el desarrollo y las pruebas en Google Cloud. El desarrollo y las pruebas pueden usar el mismo motor y versión de la base de datos en el entorno local, uno que sea funcionalmente equivalente o una nueva versión que se implemente en el entorno de producción después de la etapa 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.

Las siguientes situaciones pueden adaptarse bien al patrón híbrido de entorno:

• Para lograr una equivalencia funcional en todos los entornos, usa Kubernetes como una 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 que habilita este enfoque.
  • Garantizar la portabilidad de las cargas de trabajo y abstraer las diferencias entre los entornos de computación Con una malla de servicio de confianza cero, puedes controlar y mantener la separación de comunicación requerida entre los diferentes entornos.
• Ejecuta entornos de pruebas funcionales y de desarrollo en la nube pública. Estos entornos pueden ser equivalentes en términos de funciones a los entornos restantes, pero puede que difieran en cuanto a aspectos no funcionales, como el rendimiento. Este concepto se ilustra en el diagrama anterior.
• Ejecuta entornos para la producción, la etapa de pruebas y las pruebas de rendimiento (pruebas de carga) y confiabilidad en el entorno de computación privado, 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 y desventajas. Para asegurarte de que el enfoque que selecciones se alinee con tus requisitos específicos, basa tus selecciones en una evaluación exhaustiva de las necesidades y limitaciones de tu empresa.
• Diferencias del entorno: 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 privado local (producción). Para evitar desarrollar y probar una capacidad que podría funcionar como se espera en el entorno de nube y fallar en el entorno de producción (local), el equipo técnico debe conocer y comprender las arquitecturas y las capacidades de ambos entornos. Esto incluye las dependencias de otras aplicaciones y de la infraestructura de hardware (por ejemplo, los sistemas de seguridad que realizan inspecciones de tráfico).
• Administración: Para controlar lo que tu empresa puede desarrollar en la nube y qué datos puede usar para las pruebas, usa un proceso de aprobación y administración. Este proceso también puede ayudar a tu empresa a asegurarse de que no use ninguna función de la nube en sus entornos de desarrollo y pruebas que no existan en su entorno de producción local.
• Criterios de éxito: Debe haber criterios de éxito de las pruebas claros, predefinidos y medibles que se alineen con 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 pruebas pueden no requerir tanta confiabilidad como el entorno de producción, de cualquier manera necesitan capacidades redundantes y la capacidad de probar diferentes situaciones de fallas. Los requisitos de situaciones de falla pueden impulsar el diseño para incluir redundancia como parte de tu entorno de desarrollo y pruebas.

Ventajas

La ejecución de cargas de trabajo de pruebas funcionales y de desarrollo en la nube pública tiene varias ventajas:

• Puedes iniciar y detener los entornos automáticamente a medida que surja la necesidad. Por ejemplo, puedes aprovisionar un entorno completo para cada solicitud de extracción o confirmación, permitir que se ejecuten las pruebas y, luego, volver a apatar el entorno. Este enfoque también ofrece las siguientes ventajas:
  • Puedes reducir los costos si detienes las instancias de máquina virtual (VM) cuando están inactivas o si solo aprovisionas entornos a pedido.
  • Puedes acelerar el desarrollo y las pruebas iniciando entornos efímeros para cada solicitud de extracción. Esto también reduce la sobrecarga de mantenimiento y las incoherencias en el entorno de compilación.
• La ejecución de estos entornos en la nube pública ayuda a mejorar los conocimientos sobre la nube y las herramientas relacionadas, además de aumentar la confianza en ellos, lo que podría facilitar la migración de otras cargas de trabajo. Este enfoque es particularmente útil si decides explorar la portabilidad de la carga de trabajo usando contenedores y Kubernetes, por ejemplo, GKE Enterprise entre entornos.

Prácticas recomendadas

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

• Define los requisitos de comunicación de tu aplicación, incluido el diseño óptimo de red y seguridad. Luego, usa el patrón de red duplicada para ayudarte a diseñar la arquitectura de red a fin de evitar comunicaciones directas entre sistemas de diferentes entornos. Si se requiere comunicación entre entornos, debe ser de forma controlada.

• La estrategia de implementación y prueba de aplicaciones que elijas debe alinearse con tus objetivos y requisitos comerciales. Esto puede implicar lanzar cambios sin tiempo de inactividad o implementar funciones gradualmente en un entorno o grupo de usuarios específico antes del lanzamiento más amplio.

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

• Establece una cadena de herramientas común que funcione en todos los entornos de computación para implementar, configurar y operar cargas de trabajo. El uso de Kubernetes te brinda esta coherencia.

• Asegúrate de que las canalizaciones de CI/CD sean coherentes en todos los entornos de computación y que el mismo conjunto de archivos binarios, paquetes o contenedores se implemente en esos entornos.

• Cuando uses Kubernetes, usa un sistema de integración continua, como Tekton, para llevar a cabo una canalización de implementación que se implemente en clústeres y funcione en todos los entornos. Para obtener más información, consulta las soluciones de DevOps en Google Cloud.

• Para ayudarte con el lanzamiento continuo de aplicaciones seguras y confiables, incorpora la seguridad como parte integral del proceso de DevOps (DevSecOps). Para obtener más información, consulta Entrega y protege tu aplicación orientada a Internet en menos de una hora con el kit de herramientas de Dev(Sec)Ops.

• Usa las mismas herramientas para registrar y supervisar en Google Cloudy en los entornos de nube existentes. Considera usar sistemas de supervisión de código abierto. Para obtener más información, consulta Patrones de registro y supervisión para nubes híbridas y múltiples.

• Si existen diferentes equipos que administran las cargas de trabajo de prueba y producción, se pueden usar distintas herramientas por separado. Sin embargo, usar las mismas herramientas con diferentes permisos de visualización puede ayudar a reducir el esfuerzo y la complejidad del entrenamiento.

• Cuando elijas servicios de base de datos, almacenamiento y mensajería para las pruebas funcionales, usa productos que tengan un equivalente administrado en Google Cloud. Confiar en los servicios administrados ayuda a disminuir el esfuerzo administrativo de mantener entornos de desarrollo y pruebas.

• Para proteger la información sensible, te recomendamos que encriptes todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, hay varias opciones disponibles según la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.

En la siguiente tabla, se muestra qué productos de Google Cloud son compatibles con los productos de OSS comunes.

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

Patrones de nube híbrida y de múltiples nubes de continuidad empresarial

El principal motivo para considerar la continuidad empresarial para los sistemas de servicio crítico es ayudar a una organización a ser resiliente y continuar con sus operaciones comerciales durante y después de los eventos de falla. Si replicas los sistemas y los datos en múltiples regiones geográficas y evitas los puntos únicos de falla, puedes minimizar el riesgo de que un desastre natural afecte a la infraestructura local. Otras situaciones de falla incluyen fallas graves del sistema, ataques de ciberseguridad o incluso errores de configuración del sistema.

Optimizar un sistema para que resista las fallas es fundamental para establecer una continuidad empresarial eficaz. La confiabilidad del sistema puede verse afectada por varios factores, incluidos, sin limitaciones, el rendimiento, la resiliencia, la disponibilidad del tiempo de actividad, la seguridad y la experiencia del usuario. Para obtener más información sobre cómo diseñar y operar servicios confiables enGoogle Cloud, consulta el pilar de confiabilidad del Google Cloud Framework de Well-Architected y los componentes básicos de la confiabilidad en Google Cloud.

Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en múltiples entornos de computación. En este patrón, implementas las mismas aplicaciones en múltiples entornos de computación con el objetivo de aumentar la confiabilidad. La continuidad del negocio se puede definir como la capacidad de una organización para continuar con sus funciones o servicios comerciales clave en niveles aceptables predefinidos después de un evento disruptivo.

La recuperación ante desastres (DR) se considera un subconjunto de la continuidad empresarial y se enfoca de forma explícita en garantizar que los sistemas de TI que admiten funciones empresariales fundamentales estén en funcionamiento lo antes posible después de una interrupción. En general, los planes y las estrategias de DR a menudo ayudan a formar una estrategia de continuidad empresarial más amplia. Desde el punto de vista de la tecnología, cuando comiences a crear estrategias de recuperación ante desastres, tu análisis del 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 deseas obtener más orientación sobre cómo usar Google Cloud para abordar la recuperación ante desastres, consulta la Guía de planificación de recuperación ante desastres.

Cuanto menores sean los valores objetivo de RPO y RTO, más rápido se recuperarán los servicios de una interrupción con una pérdida de datos mínima. Sin embargo, esto implica un costo más alto, ya que significa crear sistemas redundantes. Los sistemas redundantes que pueden realizar la replicación de datos casi en tiempo real y que operan a la misma escala después de un evento de falla aumentan la complejidad, los gastos administrativos y el costo.

La decisión de seleccionar una estrategia o un patrón de DR debe basarse en un análisis del impacto en el negocio. Por ejemplo, las pérdidas financieras que se producen incluso por unos pocos minutos de inactividad en una organización de servicios financieros podrían superar con creces el costo de implementar un sistema de DR. Sin embargo, las empresas de otros sectores pueden soportar horas de inactividad sin que esto tenga un efecto significativo en el negocio.

Cuando ejecutas sistemas esenciales en un centro de datos local, un enfoque de DR es mantener los sistemas en modo de espera en un segundo centro de datos en una región diferente. Sin embargo, un enfoque más rentable es usar un entorno de computación basado en la nube pública para fines de conmutación por error. Este enfoque es el principal factor del patrón híbrido de continuidad empresarial. La nube puede ser especialmente atractiva desde el punto de vista de los costos, ya que te permite desactivar parte de tu infraestructura de DR cuando no está en uso. Para lograr una solución de DR más económica, una solución en la nube permite que una empresa acepte el posible aumento en los valores de RPO y RTO.

En el diagrama anterior, se ilustra el uso de la nube como un entorno de recuperación ante desastres o conmutación por error para un entorno local.

Una variante menos común (y rara vez obligatoria) de este patrón es el patrón de multicloud de continuidad empresarial. En ese patrón, el entorno de producción usa un proveedor de servicios en la nube y el entorno de DR usa otro proveedor de servicios en la nube. Si implementas copias de cargas de trabajo en múltiples proveedores de servicios en la nube, puedes aumentar la disponibilidad más allá de lo que puede ofrecer una implementación de varias regiones.

Evaluar un DR en varias nubes en comparación con el uso de un proveedor de servicios en la nube con diferentes regiones requiere un análisis exhaustivo de varias consideraciones, incluidas las siguientes:

• Administración
• Seguridad
• Viabilidad general
• Costo
  • Los posibles cargos por transferencia de datos salientes de más de un proveedor de servicios en la nube podrían ser costosos con la comunicación continua entre nubes.
  • Puede haber un gran volumen de tráfico cuando se replican bases de datos.
  • El TCO y el costo de administrar la infraestructura de red entre nubes

Si tus datos deben permanecer en tu país para cumplir con los requisitos reglamentarios, usar un segundo proveedor de servicios en la nube que también se encuentre en tu país como DR puede ser una opción. El uso de un segundo proveedor de servicios en la nube supone que no hay opción de usar un entorno local para crear una configuración híbrida. Para evitar reestructurar tu solución en la nube, lo ideal es que tu segundo proveedor de servicios en la nube ofrezca todas las capacidades y los servicios necesarios en la región.

Consideraciones del diseño

• Expectativa de DR: Los objetivos de RPO y RTO que tu empresa desea alcanzar deben impulsar la planificación de la arquitectura y la compilación de DR.
• Arquitectura de la solución: Con este patrón, debes replicar las funciones y capacidades existentes de tu entorno local para cumplir con tus expectativas de DR. Por lo tanto, debes evaluar la factibilidad y la viabilidad de volver a alojar, refactorizar o rediseñar tus aplicaciones para proporcionar las mismas funciones (o más optimizadas) y el mismo rendimiento en el entorno de la nube.
• Diseño y compilación: La compilación de una zona de destino casi siempre es 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 destino en Google Cloud.

• Invocación de DR: Es importante que tu diseño y proceso de DR tengan en cuenta las siguientes preguntas:

  • ¿Qué activa una situación de DR? Por ejemplo, un DR puede activarse por la falla de funciones o sistemas específicos en el sitio principal.
  • ¿Cómo se invoca la conmutación por error al entorno de DR? ¿Es un proceso de aprobación manual o se puede automatizar para lograr un objetivo de RTO bajo?
  • ¿Cómo se deben diseñar los mecanismos de detección y notificación de fallas del sistema para invocar la conmutación por error en consonancia con el RTO esperado?
  • ¿Cómo se redirecciona el tráfico al entorno de DR después de que se detecta la falla?

  Valida tus respuestas a estas preguntas con pruebas.

• Pruebas: Prueba y evalúa a fondo la conmutación por error en la DR. Asegúrate de que cumpla con tus expectativas de RPO y RTO. Si lo haces, podrías tener más confianza para invocar la DR cuando sea necesario. Cada vez que se realice un cambio o una actualización nuevos en el proceso o la solución tecnológica, vuelva a realizar las pruebas.

• Habilidades del equipo: Uno o más equipos técnicos deben tener las habilidades y la experiencia necesarias para compilar, operar y solucionar problemas de la carga de trabajo de producción en el entorno de la nube, a menos que un tercero administre tu entorno.

Ventajas

Usar Google Cloud para la continuidad empresarial ofrece varias ventajas:

• Debido a que Google Cloud tienemuchas regiones en todo el mundo para elegir, puedes usarlo para crear copias de seguridad o replicar datos en un sitio diferente dentro del mismo continente. También puedes crear copias de seguridad o replicar datos en un sitio de otro continente.
• Google Cloud ofrece la capacidad de almacenar datos en Cloud Storage en un bucket de región doble o multirregión. Los datos se almacenan de forma redundante en al menos dos regiones geográficas separadas. Los datos almacenados en buckets de región doble y múltiple se replican en regiones geográficas a través de la replicación predeterminada.
  • Los buckets birregionales proporcionan redundancia geográfica para admitir la continuidad empresarial y los planes de DR. Además, para replicar más rápido, con un RPO más bajo, los objetos almacenados en regiones dobles pueden usar de forma opcional la replicación turbo en esas regiones.
  • Del mismo modo, la replicación multirregional proporciona redundancia en varias regiones, ya que almacena tus datos dentro del límite geográfico de la multirregión.
• Proporciona una o más de las siguientes opciones para reducir los gastos de capital y los gastos operativos para compilar una DR:
  • Las instancias de VM detenidas solo generan costos de almacenamiento y son mucho más económicas que las instancias de VM en ejecución. Esto significa que puedes minimizar el costo de mantener los sistemas de reserva en frío.
  • El modelo de pago por uso de Google Cloud significa que solo pagas por la capacidad de almacenamiento y procesamiento que realmente usas.
  • Las capacidades de elasticidad, como el ajuste de escala automático, te permiten aumentar o reducir automáticamente tu entorno de DR según sea necesario.

Por ejemplo, en el siguiente diagrama, se muestra una aplicación que se ejecuta en un entorno local (producción) y 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 con una base de datos basada en VM o con una base de datos administrada por Google Cloud , como Cloud SQL, para una recuperación más rápida con replicación de datos continua. Puedes iniciar VMs de Compute Engine a partir de instantáneas creadas previamente para reducir los costos durante las operaciones normales. Con esta configuración, y después de un evento de falla, 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 VMs de la aplicación y la Web. Según el nivel de RTO objetivo y las políticas de la empresa, todo el proceso para invocar un DR, aprovisionar la carga de trabajo en la nube y redireccionar el tráfico se puede completar de forma manual o automática.

Para acelerar y automatizar el aprovisionamiento de la infraestructura, considera administrarla 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 Administra la infraestructura como código con Terraform, Cloud Build y GitOps.

Prácticas recomendadas

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

• Crea un plan de recuperación ante desastres que documente tu infraestructura y los procedimientos de recuperación y conmutación por error.
• Ten en cuenta las siguientes acciones según tu análisis de impacto comercial y los objetivos de RPO y RTO requeridos que se identificaron:
  • Decide si es suficiente crear una copia de seguridad de los datos en Google Cloud o si necesitas considerar otra estrategia de DR (sistemas en espera pasiva, semiactiva o activa).
  • Define los servicios y productos que puedes usar como componentes básicos para tu plan de DR.
  • Enmarca las situaciones de DR aplicables para tus aplicaciones y datos como parte de la estrategia de DR seleccionada.
• Considera usar el patrón de traspaso cuando solo realices copias de seguridad de datos. De lo contrario, el patrón de malla podría ser una buena opción para replicar la arquitectura de red del entorno existente.
• Minimiza las dependencias entre sistemas que se ejecutan en diferentes entornos, en especial, cuando la comunicación se maneja de forma síncrona. Estas dependencias pueden disminuir el rendimiento y la disponibilidad general.

• Evita el problema de cerebro dividido. Si replicas datos de forma bidireccional entre entornos, puede que te expongas al problema de cerebro dividido. El problema de cerebro dividido se produce cuando dos entornos que replican datos de forma bidireccional pierden la comunicación entre sí. Esta división puede hacer que los sistemas en ambos entornos concluyan que el otro entorno no está disponible y que tienen acceso exclusivo a los datos. Esto puede generar modificaciones conflictivas de los datos. Existen dos formas comunes de evitar el problema de cerebro dividido:

  • Usar un tercer entorno de procesamiento Este entorno permite que los sistemas verifiquen un quórum antes de modificar los datos.

  • Permite que se concilien las modificaciones de datos en conflicto después de que se restablezca 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 comiencen a usar la instancia principal nueva. Para obtener más información, consulta Recuperación ante desastres de bases de datos de Cloud SQL.

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

• Haz que todas las cargas de trabajo sean portátiles cuando uses sistemas en espera. Todas las cargas de trabajo deben ser portátiles (cuando las aplicaciones lo admitan y sea factible) para que los sistemas permanezcan coherentes en todos los entornos. Puedes lograr este enfoque considerando los contenedores y Kubernetes. Si usas la edición Enterprise de Google Kubernetes Engine (GKE), puedes simplificar la compilación y las operaciones.

• Integra la implementación de sistemas en modo de espera en tu canalización de CI/CD. Esta integración ayuda a garantizar que las versiones y configuraciones de las aplicaciones sean coherentes en todos los entornos.

• Para garantizar que los cambios de DNS se propaguen con rapidez, configura tu DNS con un valor de tiempo de actividad razonablemente corto para poder redirigir a los usuarios a sistemas en modo de espera cuando ocurra un desastre.

• Selecciona la política de DNS y de enrutamiento que se alinee con tu arquitectura y el comportamiento de la solución. Además, puedes combinar varios balanceadores de cargas regionales con políticas de enrutamiento de DNS para crear arquitecturas de balanceo de cargas globales para diferentes casos de uso, incluida la configuración híbrida.

• Usa varios proveedores de DNS. Cuando usas varios proveedores de DNS, puedes hacer lo siguiente:

  • Mejora la disponibilidad y la capacidad de recuperación de tus aplicaciones y servicios.

  • Simplifica la implementación o migración de aplicaciones híbridas que tienen dependencias en entornos locales 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 operar un entorno con varios proveedores de DNS. Para obtener más información, consulta DNS público de varios proveedores con Cloud DNS.

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

• Usa Cloud Load Balancing en lugar de balanceadores de cargas de hardware para potenciar algunos casos de uso que se producen cuando se usa este patrón de arquitectura. Las solicitudes de clientes internos o las solicitudes de clientes externos se pueden redireccionar al entorno principal o al entorno de DR según diferentes métricas, como la división del tráfico basada en el peso. Para obtener más información, consulta Descripción general de la administración del tráfico en el balanceador de cargas de aplicaciones externo global.

• Considera usar Cloud Interconnect o Cross‑Cloud Interconnect si el volumen de transferencia de datos salientes de Google Cloud hacia el otro entorno es alto. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y puede reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

• Considera usar tu solución de socio preferida en Google Cloud Marketplace para facilitar las copias de seguridad de los datos, las replicaciones y otras tareas que cumplan con tus requisitos, incluidos tus objetivos de RPO y RTO.

• Prueba y evalúa situaciones de invocación de DR para comprender con qué facilidad la aplicación se puede recuperar de un desastre en comparación con el valor de RTO objetivo.

• Encripta las comunicaciones en tránsito. Para proteger la información sensible, te recomendamos que encriptes todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, hay varias opciones disponibles según la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.

Patrón de aumentos de actividad de nube.

Las aplicaciones de Internet pueden experimentar fluctuaciones extremas en relación con el uso. Si bien la mayoría de las aplicaciones empresariales no enfrentan este desafío, muchas empresas deben lidiar con un tipo diferente de carga de trabajo inestable: los trabajos por lotes o de CI/CD.

Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en múltiples entornos de computación. El objetivo es aumentar la capacidad, la resiliencia o ambas.

Si bien puedes acomodar las cargas de trabajo inestables en un entorno de computación basado en centros de datos mediante el aprovisionamiento excesivo de recursos, este enfoque podría no ser rentable. En los trabajos por lotes, puedes optimizar el uso con una ejecución extendida durante períodos más largos. Sin embargo, retrasar los trabajos no es práctico si son urgentes.

La idea del patrón de aumentos de actividad de nube es usar de forma temporal un entorno de computación privado para la carga y el aumento de actividad del modelo de referencia en la nube cuando necesites capacidad adicional.

En el diagrama anterior, cuando la capacidad de datos está al límite en un entorno privado local, el sistema puede obtener capacidad adicional de un entorno deGoogle Cloud cuando sea necesario.

Los factores clave de este patrón son ahorrar dinero y reducir el tiempo y el esfuerzo necesarios para responder a los cambios de los requisitos de escalamiento. Con este enfoque, solo pagas los recursos que se usan cuando se controlan cargas adicionales. Esto significa que no necesitas aprovisionar en exceso tu infraestructura. En cambio, puedes aprovechar los recursos de la nube a pedido y escalarlos para que se ajusten a la demanda y a cualquier métrica predefinida. Como resultado, tu empresa podría evitar interrupciones del servicio durante los períodos de mayor demanda.

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

Consideraciones del diseño

El patrón de picos de actividad de nube se aplica a cargas de trabajo interactivas y por lotes. Sin embargo, cuando se trata de cargas de trabajo interactivas, debes determinar cómo distribuir las solicitudes entre los entornos:

• Puedes enrutar las solicitudes entrantes de los usuarios a un balanceador de cargas que se ejecuta en el centro de datos existente y, luego, hacer que este distribuya las solicitudes a través de los recursos locales y de nube.

  Este enfoque requiere que el balanceador de cargas o un sistema diferente que se ejecute en el centro de datos existente también realice un seguimiento de los recursos asignados en la nube. El balanceador de cargas o algún otro sistema también debe iniciar el ajuste ascendente o descendente automático de los recursos. Con este enfoque, puedes retirar todos los recursos de nube en momentos de baja actividad. Sin embargo, la implementación de mecanismos para realizar un seguimiento de los recursos podría superar las capacidades de tus soluciones de balanceador de cargas y, por lo tanto, aumentar la complejidad general.

• En lugar de implementar mecanismos para realizar seguimientos de los recursos, puedes usar Cloud Load Balancing con un backend de grupo de extremos de red (NEG) de conectividad híbrida. Usas este balanceador de cargas para enrutar solicitudes de clientes internos o solicitudes de clientes 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 reducir la escala de los backends según la capacidad de entrega del balanceo de cargas para las cargas de trabajo en Google Cloud. Para obtener más información, consulta Descripción general de la administración del tráfico en el balanceador de cargas de aplicaciones externo global.

  Este enfoque tiene varios beneficios adicionales, como el uso de las capacidades de protección contra DSD de Google Cloud Armor, WAF y el contenido del almacenamiento en caché en el perímetro de la nube mediante Cloud CDN. Sin embargo, debes dimensionar la conectividad de red híbrida para controlar el tráfico adicional.

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

• Puedes usar los servicios de infraestructura de nube para crear un entorno para alojar tus aplicaciones sin portabilidad. Usa los siguientes enfoques para controlar las solicitudes de clientes cuando el tráfico se redirecciona durante los períodos de mayor demanda:

  • Usa herramientas coherentes para supervisar y administrar estos dos entornos.
  • Garantiza que el control de versiones de las cargas de trabajo sea coherente y que tus fuentes de datos estén actualizadas.
  • Es posible que debas agregar automatización para aprovisionar el entorno de nube y redirigir el tráfico cuando la demanda aumente y se espera que la carga de trabajo en la nube acepte solicitudes de clientes para tu aplicación.

• Si pretendes cerrar todos los recursos Google Cloud en períodos de baja demanda, usar políticas de enrutamiento de DNS principalmente para el balanceo de cargas de tráfico podría no ser siempre óptimo. 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.

  Estos fueron algunos de los resultados:

  • Es posible que los usuarios se enruten al entorno de Cloud incluso cuando no haya recursos disponibles para procesar sus solicitudes.
  • Es posible que los usuarios se sigan enrutando al entorno local de forma temporal mientras se propagan las actualizaciones de DNS en Internet.

Con Cloud DNS, puedes elegir la política de DNS y de enrutamiento que se alinee con la arquitectura y el comportamiento de tu solución, como las políticas de enrutamiento de DNS de ubicación geográfica. Cloud DNS también admite verificaciones de estado para el balanceador de cargas de red de transferencia interno y el balanceador de cargas de aplicaciones interno. En ese caso, podrías incorporarlo a tu configuración general de DNS híbrido basada en este patrón.

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

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

Dadas estas configuraciones, el patrón de aumentos de actividad en la nube se suele prestar mejor para cargas de trabajo por lotes que cargas de trabajo interactivas.

Ventajas

Estas son algunas de las ventajas clave del patrón de arquitectura de aumentos de actividad en la nube:

• El patrón de aumentos de actividad en la nube te permite volver a usar las inversiones existentes en centros de datos y entornos de computación privados. Esta acción puede ser permanente o durar hasta que se deba reemplazar el equipo existente. En ese momento, podrías considerar una migración total.
• Debido a que ya no tienes que mantener un exceso de capacidad para satisfacer las demandas máximas, es posible que puedas aumentar el uso y la rentabilidad de tus entornos de computación privados.
• El patrón de aumentos de actividad de nube te permite ejecutar trabajos por lotes de manera oportuna sin la necesidad de aprovisionar recursos de procesamiento en exceso.

Prácticas recomendadas

Cuando implementes el patrón de picos de actividad de nube, ten en cuenta las siguientes recomendaciones:

• Para garantizar que las cargas de trabajo que se ejecutan en la nube puedan acceder a los recursos de la misma manera 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 menos privilegios. Si el diseño de la carga de trabajo lo permite, puedes otorgar acceso solo desde la nube al entorno de computación local, no al revés.
• Para minimizar la latencia de comunicación entre entornos, elige una región deGoogle Cloud que esté cerca de la ubicación geográfica de tu entorno de computación privado. Si deseas obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.
• Cuando uses el patrón de picos de actividad de nube solo para cargas de trabajo por lotes, mantén todos los recursos de Google Cloud privados para reducir la superficie de ataque de seguridad. No permitas el acceso directo desde Internet a estos recursos, incluso si usas Google Cloud balanceo de cargas externo para proporcionar el punto de entrada a la carga de trabajo.

• Selecciona la política de DNS y de enrutamiento que se alinee con tu patrón de arquitectura y el comportamiento de la solución objetivo.

  • 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 con otro entorno durante los períodos de demanda máxima.
  • Puedes usar políticas de enrutamiento de DNS de ubicación geográfica para tener un extremo de DNS global para tus balanceadores de cargas regionales. Esta táctica tiene muchos casos de uso para las políticas de enrutamiento de DNS de ubicación geográfica, incluidas las aplicaciones híbridas que usan Google Cloud junto con una implementación local en la que existe la región de Google Cloud .

  • Si necesitas proporcionar registros diferentes para las mismas consultas de DNS, puedes usar el 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 garantizar que los cambios de DNS se propaguen con rapidez, configura tu DNS con un valor de tiempo de actividad razonablemente corto para poder redirigir a los usuarios a sistemas en modo de espera cuando necesites capacidad adicional con entornos de nube.

• Para trabajos que no son fundamentales para el tiempo y no almacenan datos de forma local, considera usar instancias de VM Spot, que son mucho más económicas que las instancias de VM normales. Sin embargo, un requisito es que si el trabajo de VM se interrumpe, el sistema debe poder reiniciar el trabajo de forma automática.

• Usa contenedores para lograr la portabilidad de la carga de trabajo cuando corresponda. Además, GKE Enterprise puede ser una tecnología clave que habilita ese diseño. Para obtener más información, consulta Arquitectura de referencia del entorno híbrido de GKE Enterprise.

• Supervisa el tráfico enviado desde Google Cloud a un entorno de computación diferente. Este tráfico está sujeto a cargos por transferencia de datos salientes.

• Si planeas usar esta arquitectura a largo plazo con un alto volumen de transferencia de datos salientes, considera usar Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y puede reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

• Cuando se use Cloud Load Balancing, debes usar sus capacidades de optimización de la capacidad de la aplicación cuando corresponda. Esto puede ayudarte a abordar algunos de los desafíos de capacidad que pueden ocurrir en las aplicaciones distribuidas a nivel global.

• Autentica a las personas que usan tus sistemas estableciendo una identidad común entre los entornos para que los sistemas puedan autenticarse de manera segura a través de los límites del entorno.

• Para proteger la información sensible, se recomienda encriptar todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, hay varias opciones disponibles según la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.

Patrones de arquitectura híbridos y de múltiples nubes: ¿Qué sigue?

• Aprende a abordar la arquitectura híbrida y de múltiples nubes y a elegir cargas de trabajo adecuadas.
• Obtén más información sobre los patrones de arquitectura de redes adecuados para los patrones de arquitectura híbrida y de múltiples nubes seleccionados.
• Obtén más información sobre los arquetipos de implementación para aplicaciones en la nube.
• Aprende a diseñar e implementar una aplicación web de comercio electrónico con diferentes arquitecturas, incluida una aplicación web de comercio electrónico basada en microservicios con GKE y una aplicación web dinámica basada en una API sin servidores.