Este documento es el segundo de tres documentos de un conjunto. 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 para patrones de arquitectura híbrida y de múltiples nubes consta de estas 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 de tecnología para crear una solución reutilizable que aborde ciertos requisitos o casos de uso. A menudo, una solución de tecnología basada en la nube consta de varios servicios en la nube distintos y distribuidos. Estos servicios colaboran para proporcionar la funcionalidad requerida. En este contexto, cada servicio se considera un componente funcional de la solución tecnológica. De manera similar, una aplicación puede constar de varios niveles, módulos o servicios funcionales, y cada uno puede representar un componente funcional de la arquitectura de la aplicación. Esa 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:
- Los componentes de la solución o aplicación
- Las funciones esperadas para cada componente (por ejemplo, las funciones de frontend para proporcionar una interfaz de usuario gráfica o las funciones de backend para proporcionar acceso a los datos)
- Cómo se comunican los componentes entre sí y con sistemas o usuarios externos En las aplicaciones modernas, estos componentes interactúan a través de interfaces o APIs bien definidas. Hay una amplia variedad de modelos de comunicación, como asíncronos y síncronos, de solicitud y respuesta, o basados en colas.
Las siguientes son las dos categorías principales de patrones de arquitectura híbrida 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 la aplicación. 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 aprovecha las diferentes propiedades y características de los entornos de procesamiento distribuidos y conectados.
- Patrones de arquitectura redundante: estos patrones se basan en implementaciones redundantes de cargas de trabajo. En estos patrones, se implementan las mismas aplicaciones y sus componentes en varios entornos de computación. El objetivo es aumentar la capacidad de rendimiento o la resiliencia 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 forma la base para la construcción de arquitecturas de implementación específicas de la aplicación. Cada arquetipo de implementación define una combinación de dominios de fallas dentro de los cuales puede operar una aplicación. Estos dominios con fallas pueden abarcar una o más zonas o regiones de Google Cloud y se pueden expandir para incluir tus centros de datos locales o dominios con fallas en otros proveedores de servicios en la nube.
Esta serie contiene las siguientes páginas:
Patrones de arquitectura redundante
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 de EMEA, Modernización de Aplicaciones
- Ammett Williams | Ingeniero de relaciones con desarrolladores
Patrones de arquitectura distribuidos
Cuando migres de un entorno de computación no híbrido o no multinube 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 forma distribuida en diferentes entornos. Después de considerar tus limitaciones, desarrolla un plan para evitarlas o superarlas. Asegúrate de considerar 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 distribuidos. 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 la aplicación (frontends, backends o microservicios) en diferentes entornos de computación, puede ocurrir latencia de comunicación. Esta latencia está 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 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 los retrasos 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.
Arquitectura de estado temporal en comparación con la final
Para especificar las expectativas y las posibles implicaciones en el costo, la escala y el 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, te recomendamos que uses Cloud Interconnect. Para reducir los costos de transferencia de datos salientes y optimizar el rendimiento de la red de conectividad híbrida, Cloud Interconnect aplica descuentos a 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 una consideración importante 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 esta en varias zonas de una sola región1 o en varias regiones, con capacidades de conmutación. 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. Idealmente, debes considerar la disponibilidad de un servicio o una aplicación en los diversos componentes y la infraestructura de asistencia (incluida la disponibilidad de conectividad híbrida) en todos los entornos. Este concepto también se conoce como la 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: calcula la disponibilidad general de la infraestructura de nube.
Para lograr el nivel de confiabilidad del sistema que deseas, define métricas de confiabilidad claras y diseña aplicaciones que se autoreparen y resistan las interrupciones de manera eficaz en los diferentes entornos. Para ayudarte a definir las formas adecuadas de medir la experiencia del cliente de tus servicios, consulta Define tus objetivos de confiabilidad.
Conectividad híbrida y de múltiples nubes
Los requisitos de la comunicación entre los componentes de las aplicaciones distribuidas deben influir en la selección de una opción de conectividad de red híbrida. Cada opción de conectividad tiene sus ventajas y desventajas, así como factores específicos que se deben tener en cuenta, como el costo, el volumen de tráfico, la seguridad, etc. Para obtener más información, consulta la sección sobre consideraciones de diseño de conectividad.
Administración
Las herramientas de administración y supervisión coherentes y unificadas son esenciales 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 aumentar los costos de desarrollo, pruebas y operaciones. Técnicamente, cuanto 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 que seleccionaste con la posible complejidad a corto plazo en comparación con los beneficios a largo plazo.
Costo
Cada proveedor de servicios en la nube en un entorno multinube 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 multinube. Por ejemplo, cuando se compilan 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 crear inconsistencias de costos entre esos entornos.
Te recomendamos que tengas un método único y bien definido para calcular los costos completos de los recursos en la nube y proporcionar visibilidad de los costos. La visibilidad de costos es esencial 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 el bloque de administración de costos de la nube de Looker de Google Cloud, puedes crear una vista centralizada de tus costos multinube. Esta vista puede ayudarte a proporcionar una vista de informes consolidada de tu inversión en varias 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 la nube.
También te recomendamos que uses prácticas de FinOps para que los costos sean visibles. Como parte de una práctica sólida 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 y recomendaciones de optimización de costos que debes tener en cuenta, consulta Google Cloud Architecture Framework: Optimización de costos.
Traslado de datos
El movimiento de datos es una consideración importante para la estrategia y la planificación de la arquitectura de las nubes híbridas y múltiples, en especial para los sistemas distribuidos. Las empresas deben identificar sus diferentes casos de uso comerciales, los datos que los potencian 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 la aplicación 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 de opciones de movimiento de datos de Google Cloud permite que las empresas satisfagan sus necesidades específicas y adopten arquitecturas híbridas y multinube sin comprometer la simplicidad, la eficiencia ni el rendimiento.
Seguridad
Cuando se migran aplicaciones a la nube, es importante considerar las capacidades de seguridad que priorizan 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 funcional y estándar. 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 posibilidades de introducir complejidades en la arquitectura a medida que crecen tus aplicaciones o volúmenes de tráfico. Además, diseñar y compilar una zona de destino casi siempre es un requisito para implementar cargas de trabajo empresariales en un entorno de nube. Una zona de destino ayuda a tu empresa a implementar, usar y escalar servicios en la nube de forma más segura en varias áreas y, además, incluye elementos diferentes, 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 híbridas y de múltiples nubes
- Patrón híbrido perimetral
Patrón híbrido en niveles.
Los componentes de la arquitectura de una aplicación se pueden categorizar como frontend o backend. En algunos casos, 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 la aplicación de frontend están expuestos directamente a los dispositivos o a los usuarios finales. 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 entradas del usuario, a menudo son sin estado o administran solo volúmenes limitados de datos.
Para que sean accesibles y fáciles de usar, puedes compilar tus aplicaciones de frontend con varios frameworks y tecnologías. Algunos factores clave para que una aplicación de frontend sea exitosa incluyen el rendimiento de la aplicación, la velocidad de respuesta y la compatibilidad con el navegador.
Los componentes de la aplicación de backend suelen enfocarse en almacenar y administrar datos. En algunas arquitecturas, la lógica empresarial se puede incorporar en el 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 para administrar:
- Cómo controlar un gran volumen de solicitudes
- Cómo manejar un gran volumen de datos
- Protege los datos
- Mantener datos actuales y actualizados en todas las réplicas del sistema
La arquitectura de aplicaciones 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 funciona de forma independiente, pero están estrechamente vinculados y todos funcionan juntos.
- Nivel de presentación y frontend web
- Nivel de aplicación
- Acceso a los datos o nivel de backend
Colocar estas capas en contenedores separa sus necesidades técnicas, como los requisitos de escalamiento, y ayuda a migrarlas en un enfoque por fases. Además, te permite implementarlos en servicios en la nube independientes de la plataforma que se pueden portar a todos los entornos, usar la administración automatizada y escalar con plataformas administradas en la nube, como Cloud Run o la edición empresarial de Google Kubernetes Engine (GKE). Además, las bases de datos administradas por Google Cloud, como Cloud SQL, ayudan a proporcionar el backend como la capa de base de datos.
El patrón de arquitectura híbrida en niveles se enfoca en implementar los componentes existentes de la aplicación de frontend en la nube pública. En este patrón, mantienes los componentes existentes de la aplicación de backend 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. Para 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 escala y aumentan las demandas de su rendimiento y confiabilidad, debes comenzar a evaluar si las partes de tu aplicación deben refactorizarse o trasladarse a una arquitectura diferente y más óptima. El patrón de arquitectura híbrida por niveles te permite transferir algunas cargas de trabajo y componentes de la aplicación a la nube antes de realizar una transición completa. También es fundamental considerar 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 del cliente 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 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 por niveles, puedes aprovechar la infraestructura y los servicios globales de Google 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 mediante el uso del ajuste de escala automático para responder de forma dinámica y eficiente a la demanda de escalamiento sin sobreaprovisionar la infraestructura. Existen diferentes arquitecturas que puedes usar para compilar y ejecutar apps web escalables en Google Cloud. Cada arquitectura tiene ventajas y desventajas para diferentes requisitos.
Para obtener más información, mira el video Tres formas de ejecutar apps web escalables en Google Cloud en YouTube. Para obtener más información sobre las diferentes formas de modernizar tu plataforma de comercio electrónico en Google 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 en Google Cloud para proporcionar una experiencia del usuario optimizada a nivel global y multirregional que usa el balanceo de cargas, el escalamiento automático y la protección contra DSD a través de Google Cloud Armor.
Con el tiempo, la cantidad de aplicaciones que implementes en la nube pública podría aumentar hasta el punto en el que podrías considerar migrar los componentes de la aplicación de backend a la nube pública. Si esperas entregar mucho tráfico, optar por servicios administrados en la nube podría 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 el alojamiento de componentes de aplicaciones 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 cumpla con las políticas, usar las funciones de Protección de datos sensibles, como las técnicas de desidentificación, puede ayudarte a mover esos datos cuando sea necesario.
En el patrón de arquitectura híbrida en niveles, también puedes usar Google Distributed Cloud en algunas situaciones. Distributed Cloud te permite ejecutar clústeres de Google Kubernetes Engine en hardware dedicado que Google proporciona y mantiene, y es independiente del centro de datos de Google Cloud. Para asegurarte de que Distributed Cloud cumpla con tus requisitos actuales y futuros, conoce las limitaciones de Distributed Cloud 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 una arquitectura sin estado. Para obtener más información, mira el video 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 cargas de tráfico variables 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 escalamiento automático que permite una implementación basada en la nube (idealmente, con una arquitectura sin estado).
Adoptar microservicios con contenedores mediante una plataforma administrada en la nube, como GKE, te permite usar arquitecturas modernas, como microfrontend, que extienden los microservicios a los componentes del frontend.
La extensión de microservicios se usa comúnmente con 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 en la que los equipos de desarrollo individuales pueden seleccionar sus tecnologías y códigos preferidos.
- Puede fomentar ciclos rápidos de desarrollo e implementación sin afectar al resto de los componentes del frontend que otros equipos podrían administrar.
Ya sea que se implementen interfaces de usuario o APIs, o se maneje 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 en la nube ayudan a hacer lo siguiente:
- Separa 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 impulsadas por APIs, como backend para frontend (BFF), microfrontend y otras.
- Implementa proxies de API en Apigee para exponer tus APIs en Google Cloud o en otros entornos.
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 red para habilitar una arquitectura de este tipo. Apigee Hybrid es una plataforma que ayuda a compilar y administrar proxies de API en un modelo de implementación híbrida. Para obtener más información, consulta Arquitectura de 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 en niveles.
Prácticas recomendadas para reducir la complejidad
Cuando apliques el patrón de arquitectura híbrido en niveles, ten en cuenta las siguientes prácticas recomendadas que pueden ayudar a reducir su complejidad operativa y de implementación general:
- En función de 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 para una 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 con control de acceso.
- Para minimizar la latencia de comunicación entre entornos, selecciona una región de Google Cloud que esté geográficamente cerca del entorno de computación privado en el que se alojan los componentes del backend de tu aplicación. Si quieres 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 en niveles, es posible que tengas volúmenes más grandes de tráfico entrante de entornos locales que ingresan a Google Cloud en comparación con el tráfico saliente que sale de Google Cloud. Sin embargo, debes conocer el volumen estimado de transferencia de datos salientes que sale 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. 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 a las apps cliente y a 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 multientorno 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, perimetral, otras nubes y entornos de Google 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 en la nube a los servicios alojados en tu entorno de procesamiento local. Este enfoque permite realizar migraciones de cargas de trabajo por fases a Google Cloud con interrupciones mínimas o sin ellas, lo que garantiza una transición fluida para los servicios distribuidos. Para obtener más información, consulta 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, 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 durante las temporadas de mayor tráfico. Para obtener más información, mira Delivering high-performance APIs with Apigee and Cloud CDN en YouTube.
- Implementa la administración avanzada del tráfico.
- Usa Google Cloud Armor como protección contra DSD y servicio de seguridad de red para proteger tus APIs.
- Administra un balanceo de cargas eficiente en varias puertas de enlace de varias regiones. Para obtener más información, mira Protege las APIs e implementa la conmutación por error multirregional con Private Service Connect y Apigee en YouTube.
Usa la administración de APIs y la malla de servicios para proteger y controlar la comunicación y la exposición de los servicios con la arquitectura de microservicios.
- Usa Cloud Service Mesh para permitir una comunicación de servicio a servicio que mantenga la calidad del servicio en un sistema compuesto por servicios distribuidos en los que puedes administrar la autenticación, la autorización y la encriptación entre servicios.
- Usa una plataforma de administración de API como Apigee que permita que tu organización y las entidades externas consuman esos servicios exponiendo las 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 configuraciones en la nube pública. Para obtener más información, consulta Patrón de arquitectura de redes reflejadas.
Para ayudar a aumentar la eficiencia operativa, usa herramientas coherentes y canalizaciones de CI/CD en todos los entornos.
Prácticas recomendadas para cargas de trabajo individuales y arquitecturas de aplicaciones
- 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 a las APIs como interfaces de backend optimiza las integraciones, el desarrollo del frontend, las interacciones de los servicios y oculta las complejidades del sistema de backend. Para abordar estos desafíos, Apigee facilita el desarrollo y la administración de la puerta de enlace o el proxy de API para las implementaciones híbridas y de múltiples nubes.
- Elige el enfoque de renderización para tu aplicación web de frontend en función del 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 impulsadas por 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 en detalle estas opciones en función de tus requisitos actuales y futuros de la aplicación. Para ayudarte a tomar una decisión arquitectónica que esté alineada con tus objetivos técnicos y comerciales, consulta Comparación de diferentes arquitecturas para backends de aplicaciones web impulsados por contenido y Consideraciones clave para backends 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 entornos, tienes la flexibilidad para 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 de Google Cloud para los componentes de la aplicación migrados y modernizados.
- Usa este enfoque cuando tengas backends heredados on-premises que no admitan la contenedorización o requieran tiempo y recursos significativos para modernizarse a corto plazo.
Para obtener más información sobre el diseño y la refactorización de una app monolítica a 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 en gran medida de tu caso de uso. Para obtener más información sobre las opciones de almacenamiento de datos para los backend de aplicaciones impulsadas por contenido y las modalidades eficaces, consulta Opciones de almacenamiento de datos para apps web impulsadas por contenido. Consulta también Explicación de las opciones de bases de datos de Google Cloud.
Patrón particionado de múltiples nubes.
El patrón de arquitectura de múltiples nubes con particiones combina varios entornos de nube pública que operan diferentes proveedores de servicios en la nube. Esta arquitectura proporciona la flexibilidad para implementar una aplicación en un entorno de procesamiento óptimo que tenga en cuenta los impulsores y las consideraciones de multinube 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 enfoque que el patrón de arquitectura híbrida por 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:
- Para integrar por completo las aplicaciones alojadas en entornos de nube dispares durante una fusión y adquisición entre dos empresas.
- Para promover la flexibilidad y satisfacer las diversas preferencias de 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 multirregional o global. Si una empresa debe cumplir con las reglamentaciones de residencia de datos en regiones o países específicos, entonces debe elegir entre los proveedores de servicios en la nube disponibles en esa ubicación si su proveedor de servicios en la nube principal no tiene una región de nube allí.
Con el patrón de arquitectura de múltiples nubes particionadas, 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 de administración, operaciones y seguridad coherentes. Para obtener más información, consulta GKE multinube.
Como se mencionó anteriormente, hay algunas situaciones en las que puede haber motivos técnicos y comerciales 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 minimizas la dependencia de un solo proveedor y te ayudan a cumplir con los requisitos reglamentarios. Por ejemplo, puedes conectar Google Cloud con Oracle Cloud Infrastructure (OCI) para crear una solución de múltiples nubes que aproveche las capacidades de cada plataforma con una Cloud Interconnect privada 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 las múltiples nubes. 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 compatibles, lo que te permite diseñar y crear soluciones multinube para controlar un alto volumen de tráfico entre nubes.
Ventajas
Si bien el uso de una arquitectura multinube ofrece varios beneficios técnicos y comerciales, como se explica en Factores de impulso, consideraciones, estrategia y enfoques, es fundamental realizar una evaluación de viabilidad detallada de cada beneficio potencial. Tu evaluación debe considerar cuidadosamente cualquier desafío directo o indirecto asociado, o posibles obstáculos, y tu capacidad para navegar por ellos de manera eficaz. Además, ten en cuenta que el crecimiento a largo plazo de tus aplicaciones o servicios puede generar complejidades que podrían superar los beneficios iniciales.
A continuación, se incluyen algunas ventajas clave del patrón de arquitectura de múltiples nubes con partición:
En situaciones en las que debas minimizar el compromiso con un solo proveedor de servicios en la nube, puedes distribuir las aplicaciones en varios proveedores de servicios en la nube. Como resultado, podrías reducir de forma relativa la dependencia del proveedor con la posibilidad de cambiar de plan (hasta cierto punto) entre tus proveedores de servicios en la nube. La nube abierta ayuda a llevar las funciones de Google Cloud, como GKE Enterprise, a diferentes ubicaciones físicas. Cuando se extienden las capacidades de Google Cloud de forma local, en varias nubes públicas y en el perímetro, se proporciona flexibilidad, agilidad y se impulsa la transformación.
Por motivos regulatorios, puedes publicar un segmento determinado de tu base de usuarios y datos de un país en el que Google Cloud no tiene una región de la nube.
El patrón de arquitectura de multinube particionada puede ayudar a reducir la latencia y mejorar la calidad general de la experiencia del usuario en ubicaciones donde el proveedor de servicios en la nube principal no tiene una región ni un punto de presencia. Este patrón es especialmente útil cuando se usa conectividad multinube de alta capacidad y baja latencia, como interconexión entre nubes y interconexión de CDN 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 de multinube particionada puede ayudar a facilitar y acelerar las situaciones de fusión y adquisición, 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 se aplique en situaciones en las que la carga de trabajo específica esté legalmente o regulatoriamente obligada a residir en una región de nube específica y el proveedor de nube principal no tenga 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 componentes de la aplicación.
- Considera usar el patrón de arquitectura en malla o uno de los patrones de redes con puertas de enlace, según tus requisitos técnicos y comerciales específicos.
- Para cumplir con tus expectativas de disponibilidad y rendimiento, diseña para una alta disponibilidad (HA) de extremo a extremo, baja latencia 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 la interconexión entre nubes.
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 los vínculos de CDN Interconnect entre Google Cloud y los proveedores admitidos para optimizar este tráfico y, potencialmente, su costo.
Extiende tu solución de administración de identidades entre los entornos para que los sistemas puedan autenticarse de forma segura a través de los límites del entorno.
Para equilibrar de manera eficaz las solicitudes entre Google Cloud y otra plataforma en la nube, puedes usar Cloud Load Balancing. Para obtener más información, consulta Cómo enrutar el tráfico a una ubicación local o a otra nube.
- Si el volumen de transferencia de datos salientes de Google Cloud hacia otros entornos es alto, considera usar Interconexión entre nubes.
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. 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 a las apps cliente y a 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 multientorno 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, perimetral, otras nubes y entornos de Google 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 API a gran escala en varias regiones:
- Implementa 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.
Proporcionar protección contra DSD y WAF a través de Google Cloud Armor
Usa herramientas coherentes para el registro y la supervisión en todos los entornos de nube cuando sea posible. Considera usar sistemas de supervisión de código abierto. Para obtener más información, consulta Patrones de registro y supervisión híbridos y de múltiples nubes.
Si implementas componentes de 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íbrido por niveles.
Patrón de estadísticas híbridas y de múltiples nubes
En este documento, se explica que el objetivo del patrón de estadísticas híbridas y de múltiples nubes es aprovechar la división entre las cargas de trabajo transaccionales y analíticas.
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 mediante la consulta 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 nube híbrida y múltiples es aprovechar esta división ya existente y ejecutar 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 en Google 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 muestran posibles canalizaciones de datos para ilustrar las arquitecturas conceptualmente posibles. Cada ruta o flecha representa una posible opción de canalización de transformación y movimiento de datos que puede basarse en ETL o ELT, según la calidad de los datos disponible y el caso de uso objetivo.
Para trasladar tus datos a Google Cloud y desbloquear su valor, usa los servicios de movimiento de datos, un paquete completo de servicios de transferencia, integración y replicación de datos.
Como se muestra en el diagrama anterior, conectar 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 multinube que requiere un gran volumen de transferencia de datos, Cloud Interconnect y Cross-Cloud Interconnect proporcionan conectividad dedicada a proveedores locales y de otros 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 entrante (trasladar datos de tu entorno de computación privado o de otras nubes a Google Cloud) podría 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 transferencia 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 desglosar los silos de datos. El uso de 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 función de estadísticas de 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 red 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 las topologías de traspaso y de salida protegida.
- Usa las colas de Pub/Sub o los 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 que priorizan la nube para compilar y administrar canalizaciones de datos.
- Para descubrir, clasificar y proteger tus recursos de datos valiosos, considera usar las funciones de Protección de datos sensibles de Google Cloud, como las técnicas de desidentificación. 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 forma aleatoria, cuando corresponda y sea conforme.
- Cuando tengas cargas de trabajo existentes de Hadoop o Spark, considera migrar trabajos a Dataproc y migrar datos HDFS existentes a Cloud Storage.
Cuando realices una transferencia de datos inicial desde tu entorno de computación privado a Google Cloud, elige el enfoque de transferencia más adecuado para el tamaño del 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 Cross-Cloud Interconnect de Google Cloud para establecer una conectividad dedicada de ancho de banda alto entre Google Cloud y otros proveedores de servicios en la nube (disponible en ciertas ubicaciones).
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 la interconexión entre nubes.
Usa herramientas y procesos coherentes en todos los entornos. En una situación con un patrón híbrido de estadísticas, puede que esta práctica ayude 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 declaraciones 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 entrante (el traslado de datos desde el perímetro a Google 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 moverlas a la nube, ya sea mediante la reelaboración de ciertas aplicaciones o el equipamiento de algunas ubicaciones perimetrales con vínculos de Internet más confiables.
- Los proyectos relacionados con la Internet de las cosas (IoT) pueden ser más rentables si realizan cálculos de datos de forma local. Esto permite a las empresas ejecutar y procesar 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 de perímetro que se conectan a Google Cloud a través de Internet público, puedes usar una solución de WAN definida por software (SD-WAN). También puedes usar Network Connectivity Center con un router SD-WAN de terceros compatible con un socio de Google Cloud para simplificar el aprovisionamiento y la administración de la conectividad segura a gran escala.
- Minimiza las dependencias entre los sistemas que se ejecutan en el perímetro y los sistemas que se ejecutan en el entorno de nube. Cada dependencia puede comprometer las ventajas de confiabilidad y latencia de una configuración híbrida perimetral.
- Para administrar y operar múltiples ubicaciones perimetrales de manera eficiente, debes tener un plano de administración 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 corresponda y sea posible para abstraer las diferencias entre varias ubicaciones perimetrales y también entre ubicaciones perimetrales y de 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 perímetro 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 posibles opciones de conectividad que tienes para conectar un clúster de GKE Enterprise que se ejecuta en tu entorno local o perimetral a Google Cloud.
- Como parte de este patrón, aunque algunos componentes de GKE Enterprise pueden mantenerse durante una interrupción temporal de la conectividad a Google Cloud, no uses GKE Enterprise cuando 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 a las apps cliente y a 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 multientorno 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, perimetral, otras nubes y entornos de Google Cloud.
- Establece una identidad común entre los entornos para que los sistemas puedan autenticarse con seguridad a través de los límites del entorno.
- Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas con el uso de los túneles VPN, TLS o de ambos.
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, puedes usar la nube pública para tus entornos de desarrollo y pruebas, o bien para otros entornos. Este patrón se basa en la implementación redundante de las mismas aplicaciones en varios entornos de computación. El objetivo de la implementación es 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.
- Es posible 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 ambientes que no usen los datos reales. Consulta con el departamento de cumplimiento de tu organización o con el 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 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 el 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 la misma versión de la base de datos en el entorno local, uno que sea funcionalmente equivalente o una versión nueva que se lance 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 de 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 entorno de ejecución común cuando corresponda y sea posible.
La edición Enterprise de Google Kubernetes Engine (GKE) puede ser una tecnología clave que habilita este enfoque.
- Garantiza la portabilidad de las cargas de trabajo y abstrae las diferencias entre los entornos de computación. Con una malla de servicios de confianza cero, puedes controlar y mantener la separación de 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 pueden diferir 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 entre los entornos: Como parte de este patrón, el objetivo principal de usar este entorno de nube es el desarrollo y las pruebas. El estado final es alojar la aplicación probada en el entorno privado (producción) on-premises. 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 dependencias en otras aplicaciones y en la infraestructura de hardware, por ejemplo, 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 los entornos de desarrollo y pruebas que no existan en tu entorno de producción local.
- Criterios de éxito: Debe haber criterios de éxito de 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 fallas pueden llevar a que el diseño incluya la 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. De esta manera, también se reduce la sobrecarga de mantenimiento y las inconsistencias 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 la comunicación entre entornos, debe ser de forma controlada.
La estrategia de pruebas y de implementación 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 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 Cómo entregar y proteger tu aplicación orientada a Internet en menos de una hora con Dev(Sec)Ops Toolkit.
Usa las mismas herramientas para registrar y supervisar en Google Cloud y 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 híbridos y de múltiples nubes.
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 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 que se basan en 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 factor principal para considerar la continuidad empresarial en los sistemas de misión crítica es ayudar a una organización a ser resiliente y continuar con sus operaciones comerciales durante y después de los eventos de fallas. 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, un ataque de seguridad cibernética o incluso un error de configuración del sistema.
Optimizar un sistema para que resista las fallas es esencial para establecer una continuidad empresarial eficaz. La confiabilidad del sistema puede verse influenciada por varios factores, incluidos, sin limitaciones, el rendimiento, la resiliencia, la disponibilidad del tiempo de actividad, la seguridad y la experiencia del usuario. Si deseas obtener más información para diseñar y operar servicios confiables en Google Cloud, consulta el pilar de confiabilidad del framework de arquitectura de Google Cloud y los elementos básicos de la confiabilidad en Google Cloud.
Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en varios entornos de computación. En este patrón, se implementan 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 del negocio 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 un punto de vista tecnológico, cuando comiences a crear estrategias de recuperación ante desastres, tu análisis del impacto empresarial 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 más bajos 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 mínima de datos. Sin embargo, esto implica un costo más alto, ya que implica la creación de 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, la sobrecarga administrativa y el costo.
La decisión de seleccionar una estrategia de DR o un patrón debe estar basada en un análisis del impacto en el negocio. Por ejemplo, las pérdidas financieras que se generan por unos pocos minutos de tiempo de inactividad para una organización de servicios financieros pueden superar con creces el costo de implementar un sistema de DR. Sin embargo, las empresas de otros sectores pueden soportar horas de tiempo de inactividad sin un efecto comercial significativo.
Cuando ejecutas sistemas esenciales en un centro de datos local, un enfoque para la 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 impulsor principal 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 de menor costo, 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 conmutación por error o de recuperación ante desastres para un entorno local.
Una variante menos común (y rara vez obligatoria) de este patrón es el de múltiples nubes 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. 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 una DR en varias nubes en lugar de usar un proveedor de servicios en la nube con diferentes regiones requiere un análisis exhaustivo de varias consideraciones, como las siguientes:
- Administración
- Seguridad
- Viabilidad general
- Costo
- Los posibles cargos de transferencia de datos salientes de más de un proveedor de servicios en la nube podrían ser costosos con una 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, una opción puede ser usar un segundo proveedor de servicios en la nube que también esté en tu país como DR. El uso de un segundo proveedor de servicios en la nube supone que no hay opción para usar un entorno local para crear una configuración híbrida. Para evitar tener que volver a crear la arquitectura de 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 lograr deben guiar tu arquitectura de DR y la planificación de la compilación.
- 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 viabilidad de volver a alojar, refactorizar o reestructurar tus aplicaciones para proporcionar las mismas funciones y el mismo rendimiento (o más optimizados) en el entorno de la nube.
- Diseño y compilación: Crear una zona de destino suele ser un requisito 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 el diseño y el proceso de DR tengan en cuenta las siguientes preguntas:
- ¿Qué activa una situación de DR? Por ejemplo, una DR puede activarse debido a 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 alineación con el RTO esperado?
- ¿Cómo se vuelve a enrutar el tráfico al entorno de DR después de detectar la falla?
Valida tus respuestas a estas preguntas mediante pruebas.
Pruebas: Prueba y evalúa en detalle la conmutación por error a la DR. Asegúrate de que cumpla con tus expectativas de RPO y RTO. De esta manera, 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, vuelve a realizar las pruebas.
Habilidades del equipo: Uno o más equipos técnicos deben tener las habilidades y la experiencia para compilar, operar y solucionar problemas de la carga de trabajo de producción en el entorno de 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 tiene muchas regiones en todo el mundo para elegir, puedes usarlas 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 birregional o multirregional. Los datos se almacenan de manera redundante en al menos dos regiones geográficas
distintas. Los datos almacenados en buckets de región doble y múltiple se replican en regiones geográficas mediante la replicación predeterminada.
- Los buckets birregionales proporcionan redundancia geográfica para respaldar la continuidad de la actividad 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.
- De manera similar, 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 crear una DR:
- Las instancias de VM detenidas solo generan costos de almacenamiento y son mucho más baratas que las instancias de VM en ejecución. Esto significa que puedes minimizar el costo de mantenimiento de los sistemas de espera en frío.
- El modelo de pago por uso de Google Cloud significa que solo pagas por la capacidad de almacenamiento y procesamiento que usas.
- Las capacidades de elasticidad, como el ajuste de escala automático, te permiten escalar 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) que usa componentes de recuperación en Google Cloud con Compute Engine, Cloud SQL y Cloud Load Balancing. En esta situación, la base de datos se aprovisiona previamente con una base de datos basada en VM o con una base de datos administrada de Google Cloud, como Cloud SQL, para lograr una recuperación más rápida con la replicación de datos continua. Puedes lanzar VMs de Compute Engine desde 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 esté en funcionamiento en la nube, debes aprovisionar las VMs web y de la aplicación. Según el nivel de RTO objetivo y las políticas de la empresa, el proceso completo para invocar una 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 administrar la infraestructura como código. Puedes usar Cloud Build, que es un servicio de integración continua, para aplicar automáticamente los 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 el análisis del impacto comercial y
los objetivos de RPO y RTO identificados:
- 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 pasivos, semiactivos o activos).
- Define los servicios y productos que puedes usar como componentes básicos para tu plan de DR.
- Define las situaciones de DR aplicables para tus aplicaciones y datos como parte de la estrategia de DR que seleccionaste.
- Considera usar el patrón de traspaso cuando solo crees copias de seguridad de los datos. De lo contrario, el patrón en malla puede 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 del cerebro dividido. Si replicas datos de forma bidireccional entre entornos, es posible que te expongas al problema de cerebro dividido. El problema del cerebro dividido ocurre cuando dos entornos que replican datos de forma bidireccional pierden la comunicación entre sí. Esta división puede hacer que los sistemas de ambos entornos determinen que el otro entorno no está disponible y que tienen acceso exclusivo a los datos. Esto puede generar modificaciones en conflicto de los datos. Existen dos formas comunes de evitar el problema del 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 de SQL, puedes evitar el problema del 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 la base 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 (siempre que las aplicaciones las admitan y sea factible) para que los sistemas permanezcan coherentes en todos los entornos. Para lograr este enfoque, considera 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 tu 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 resiliencia 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 algunas situaciones que se producen cuando se usa este patrón de arquitectura. Las solicitudes de clientes internas o externas 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.
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 datos, las réplicas y otras tareas que cumplan con tus requisitos, incluidos tus objetivos de RPO y RTO.
Prueba y evalúa las situaciones de invocación de DR para comprender con qué facilidad la aplicación puede recuperarse de un evento de 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 varios 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 de Google 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 paga los recursos que se usan cuando se manejan cargas adicionales. Eso significa que no necesitas aprovisionar en exceso tu infraestructura. En su lugar, puedes aprovechar los recursos de nube bajo demanda y escalarlos para que se ajusten a la demanda y a cualquier medición predefinida. Como resultado, tu empresa podría evitar interrupciones del servicio durante los períodos de demanda máxima.
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 la 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 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 durante 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. Puedes usar este balanceador de cargas para enrutar solicitudes de clientes internas o solicitudes de clientes externas a backends que se encuentran de forma local y en Google Cloud, y que se basan en diferentes métricas, como la división de tráfico basada en el peso. También puedes escalar 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.
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. Por lo general, las diferencias en la infraestructura de computación subyacente, las capacidades de seguridad de la infraestructura o la infraestructura de red, junto con la proximidad a los servicios dependientes, determinan el rendimiento. A través de las pruebas, puedes obtener 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 los clientes cuando se redirecciona el tráfico 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 deseas cerrar todos los recursos de Google Cloud durante períodos de baja demanda, es posible que no siempre sea óptimo usar políticas de enrutamiento de DNS principalmente para el balanceo de cargas de tráfico. Esto se debe principalmente a lo siguiente:
- Los recursos pueden tardar un tiempo en inicializarse antes de poder entregar contenido a los usuarios.
- Las actualizaciones de DNS suelen propagarse lentamente a través de Internet.
Estos fueron algunos de los resultados:
- Es posible que los usuarios se dirijan 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, puedes incorporarlo a la configuración general de DNS híbrido que se basa en este patrón.
En algunas situaciones, puedes usar Cloud DNS para distribuir solicitudes de clientes con verificaciones de estado en Google Cloud, como cuando usas balanceadores de cargas de aplicaciones internos o balanceadores de cargas de aplicaciones internos entre regiones. En esta situación, 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 para la ubicación o red específicas del creador 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. El enfoque también ayuda a distribuir la carga de tráfico entre los 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 que los trabajos por lotes se ejecuten 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 permitir el acceso solo desde la nube al entorno de procesamiento local, no al revés.
- Para minimizar la latencia para la comunicación entre entornos, elige una región de Google Cloud que esté geográficamente cerca 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 usas los aumentos de actividad en la nube solo para cargas de trabajo por lotes, mantén todos los recursos de Google Cloud en privado para reducir la superficie de ataque de seguridad. No permitas el acceso directo de Internet a estos recursos, incluso si usas el balanceo de cargas externo de Google Cloud 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 mayor demanda.
- 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 de 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 aplicaciones distribuidas a nivel global.
Para autenticar a las personas que usan tus sistemas, establece 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íbrida 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.
- Obtén más información para 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 mediante el uso de GKE y una aplicación web dinámica basada en API sin servidores.
-
Las regiones de México, Montreal y Osaka tienen tres zonas en uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a, al menos, tres centros de datos físicos. Para obtener más información, consulta Ubicaciones de Cloud y ANS de Google Cloud Platform. Para mejorar la confiabilidad de tus cargas de trabajo, considera una implementación multirregional. ↩