Patrones de arquitectura híbridos y de múltiples nubes

Este artículo es el segundo de una serie de varias partes que analiza implementaciones híbridas y de múltiples nubes, patrones de arquitectura y topologías de red. En esta parte, se exploran patrones de arquitectura híbridos y de múltiples nubes comunes. En este artículo, se describen las situaciones a las que se adaptan mejor estos patrones y se proporcionan recomendaciones para implementarlos con Google Cloud Platform (GCP).

La serie consta de las siguientes partes:

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.

Los patrones se dividen en dos categorías:

  • Patrones que se basan en una implementación distribuida de aplicaciones. El objetivo de estos patrones es ejecutar una aplicación en el entorno de procesamiento al que mejor se adapte y aprovechar las diferentes propiedades y características de los entornos de computación.

  • Patrones que se basan en implementaciones redundantes de aplicaciones. En estos patrones, se implementan las mismas aplicaciones en múltiples entornos informáticos con el objetivo de aumentar la capacidad o la resiliencia.

Patrones de implementación distribuidos

Cuando migras de un entorno de computación clásico a una configuración de nube híbrida o de múltiples nubes, ten en cuenta las restricciones que imponen las aplicaciones existentes. También debes aprovechar las capacidades únicas que ofrece cada entorno de computación. La finalidad de estos patrones distribuidos es lograr un equilibrio entre ambos objetivos.

Híbrido en niveles

La mayoría de las aplicaciones se puede clasificar como de frontend o de backend.

  • Las aplicaciones de frontend están expuestas de forma directa a los dispositivos o a los usuarios finales. Por lo tanto, estas aplicaciones suelen ser sensibles al rendimiento y pueden estar sujetas a lanzamientos frecuentes a medida que se desarrollan nuevas características y mejoras. Debido a que suelen depender de las aplicaciones de backend para almacenar y administrar datos, las aplicaciones de frontend suelen no tener estado o administran solo pequeñas cantidades de datos.

  • Las aplicaciones de backend se suelen enfocar en la administración de datos. Los desafíos clave para esas aplicaciones incluyen el manejo de grandes cantidades de datos la protección adecuada de estos. En general, las nuevas versiones de aplicaciones de backend son menos frecuentes que las de aplicaciones de frontend.

La idea del patrón híbrido en niveles es enfocarse primero en implementar las aplicaciones de frontend existentes en la nube pública. En este patrón, se vuelven a usar las aplicaciones de backend existentes que permanecen en su entorno de computación privado. Debes migrar aplicaciones de frontend caso por caso.

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

patrón híbrido por niveles

Con el tiempo, la fracción de aplicaciones que implementas en la nube aumenta hasta el punto en el que podrías considerar migrar las aplicaciones de backend a la nube pública.

Ventajas

Enfocarse primero en las aplicaciones de frontend tiene varias ventajas:

  • Las aplicaciones de frontend dependen de los backends y, en ocasiones, de otros frontends, pero los backends no dependen de los frontends. Por lo tanto, aislar y migrar aplicaciones de frontend suele ser menos complejo que migrar aplicaciones de backend, que pueden tener dependencias complejas.

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

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

  • 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 IC/EC que puedes usar para implementar actualizaciones de manera eficiente y automatizada.

  • Los frontends sensibles al rendimiento y los que están sujetos a cambios frecuentes pueden obtener un beneficio importante del balanceo de cargas, las implementaciones multirregionales y las características de ajuste de escala automático que permite una implementación en la nube.

  • Ya sea que se implementen interfaces de usuario o API, o se maneje la transferencia de datos de IoT (Internet de las cosas), las aplicaciones de frontend pueden beneficiarse de las capacidades que ofrecen los servicios en la nube como Firebase, Cloud CDN o Cloud IoT.

Si tus backends administran datos sujetos a restricciones reglamentarias o jurisdiccionales, puede que quieras mantenerlos en el entorno de computación privado, ya sea de forma permanente o al menos hasta que encuentres una manera de trabajar de acuerdo con las restricciones.

También puedes aplicar el patrón híbrido en niveles a la inversa, aunque no es tan común. Para ello, implementa backends en la nube mientras mantienes los frontends en entornos de computación privados. 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.

Recomendaciones

Cuando apliques el patrón híbrido en niveles, ten en cuenta las siguientes recomendaciones:

  • Usa una salida protegida o una topología de malla. Debido a que la mayor parte de la interacción del usuario involucra sistemas que se conectan en múltiples entornos de computación, una conectividad rápida y de baja latencia entre esos sistemas es importante. Por lo tanto, es fundamental un diseño con una alta disponibilidad, baja latencia y niveles de capacidad de procesamiento adecuados.

  • Para minimizar la latencia de comunicación entre entornos, elige una región de GCP y una ubicación de interconexión que estén geográficamente cerca de tu entorno de computación privado.

  • En una configuración híbrida en niveles, suelen ser más los datos que ingresan a GCP (entrada) que los datos que se transfieren de GCP al entorno de computación privado (salida). Sin embargo, ten en cuenta que el tráfico que sale de GCP está sujeto a los precios de salida. El uso de una interconexión dedicada o un intercambio de tráfico directo puede ayudar a reducir estos cargos.

  • Asegúrate de que la comunicación entre entornos sea unidireccional. Las aplicaciones de frontend que se ejecutan en la nube pública pueden comunicarse con los backends que se ejecutan en entornos de computación privados, pero no al revés.

  • Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas y dependan de los túneles de la red privada virtual (VPN), de la seguridad de la capa de transporte (TLS) o de ambos.

  • Recomendamos implementar una puerta de enlace de API como una fachada para los servicios de backend existentes, en especial cuando los protocolos, las API y los mecanismos de autenticación son incoherentes entre los backends. Además de funcionar como una capa de unificación, una puerta de enlace de API puede funcionar como un cuello de botella. Con esta puerta de enlace, puedes implementar medidas adicionales de seguridad y auditoría que se aplican a todas las comunicaciones entre entornos.

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

Para las cargas de trabajo individuales, considera estas recomendaciones adicionales:

  • Aunque el enfoque se encuentra en las aplicaciones de frontend en este patrón, mantente al tanto de la necesidad de modernizar las aplicaciones de backend. Si el ritmo de desarrollo de los backends es, en gran medida, más lento que el de los frontends, la diferencia puede causar una complejidad adicional en los proyectos.

  • Para habilitar las migraciones de transformación y transferencia, usa Kubernetes como la capa de entorno de ejecución común entre GCP y los entornos de computación privados. Con Kubernetes, puedes modernizar una carga de trabajo y migrar a GCP en diferentes momentos, lo que puede ser fundamental cuando una carga de trabajo depende en gran medida de otra y no se puede migrar de manera individual.

  • Evita la necesidad de comunicación bidireccional entre entornos. Para lograrlo, considera también implementar sistemas de IC/EC en la nube pública.

  • En una situación con un patrón híbrido en niveles, usa herramientas coherentes y procesos de IC/EC a través de entornos para ayudar a aumentar la eficiencia operativa. Esta práctica no es obligatoria.

  • Cuando uses Kubernetes a fin de ejecutar cargas de trabajo de frontend, usa servicios sin selectores para hacer que los servicios o las puertas de enlace de API que se ejecutan en el entorno de computación privado sean detectables. Con los dominios de stub de Kubernetes, puedes integrar con sistemas de detección de servicios externos basados en DNS, como Consul.

Múltiples nubes con partición

El patrón de múltiples nubes con partición combina múltiples entornos de nube pública, operados por diferentes proveedores, de tal manera que te brinda la flexibilidad para implementar una aplicación en el entorno de computación óptimo. En el siguiente diagrama, se muestra un típico patrón de múltiples nubes con partición.

patrón particionado de múltiples nubes

Puedes mantener la capacidad de cambiar las cargas de trabajo de un entorno de nube pública a otro según sea necesario. En este caso, la portabilidad de la carga 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.

GCP proporciona un amplio conjunto de servicios que puedes usar para implementar tus cargas de trabajo de diferentes maneras. Sin embargo, en algunas situaciones, tiene sentido combinar GCP con otro proveedor de servicios en la nube y hacer particiones de tus cargas de trabajo en diferentes entornos de nube. A continuación, se incluyen algunos ejemplos:

  • Para evitar comprometerte con un solo proveedor, se distribuyen las aplicaciones en varios proveedores de servicios en la nube.

  • Por motivos regulatorios, se entrega un determinado segmento de tu base de usuarios y datos de un país donde aún no se encuentra GCP.

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

Ventajas

A continuación, se incluyen algunas ventajas clave sobre el patrón de múltiples nubes con partición:

  • Puedes evitar depender del proveedor. Este patrón ayuda a reducir el riesgo estratégico y te brinda la flexibilidad de cambiar de plan o de asociación más adelante.

  • Si las cargas de trabajo se mantienen portátiles, puedes optimizar tus operaciones. Para ello, cambia las cargas de trabajo entre los entornos de computación.

Recomendaciones

  • Compara las ventajas estratégicas de una configuración de múltiples nubes de partición con la complejidad adicional que aporta esta configuración. Lograr la portabilidad de la carga de trabajo y la coherencia de las herramientas en múltiples entornos de nube aumenta el trabajo de desarrollo, pruebas y operaciones.

  • Usa un entorno de nube múltiple solo para las cargas de trabajo esenciales o, si por razones legales o reglamentarias, un solo entorno de nube pública no puede admitir las cargas de trabajo.

  • 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 y la disponibilidad general.

  • Para abstraer las diferencias entre entornos, considera usar contenedores y Kubernetes.

  • Asegúrate de que los procesos y herramientas de IC/EC para la implementación y la supervisión sean coherentes en los diferentes entornos de nube.

  • Usa la topología de malla o protegida.

  • Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas y dependan de los túneles VPN, TLS o de ambos.

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

  • Cuando uses Kubernetes, considera usar ExternalDNS para hacer que los servicios puedan detectarse por sus nombres DNS en todos los entornos de computación.

  • Si bien puedes usar los balanceadores de cargas de GCP basados en IP de Anycast para equilibrar las solicitudes en varias regiones de GCP, no puedes usarlas a fin de distribuir solicitudes de usuarios en varias nubes. Para esta distribución, debes usar Round Robin o Geo DNS, como lo ofrecen los proveedores de servicios como, NS1, Dyn o Akamai.

Estadísticas de nube híbrida y de múltiples nubes

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.

Si bien los sistemas de estadísticas obtienen sus datos de los sistemas transaccionales mediante la consulta a las API 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 vinculados de manera flexible. La idea del patrón de estadísticas de nube híbrida y múltiples nubes es aprovechar esta división ya existente y ejecutar los dos tipos de cargas de trabajo en dos entornos de computación diferentes. Los datos sin procesar se extraen de las cargas de trabajo que se ejecutan en el entorno de computación privado y, luego, se cargan en GCP, en donde se usan para el procesamiento estadístico. Puede que algunos de los resultados se vuelvan a ingresar a los sistemas transaccionales.

patrón de estadísticas de múltiples nubes

Ventajas

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

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

  • GCP proporciona un amplio conjunto de servicios para administrar datos durante todo su ciclo de vida, desde la adquisición inicial, el procesamiento y análisis hasta la visualización final.

  • Cloud Storage es ideal para compilar un data lake.

  • El tráfico de entrada (el traslado de datos del entorno de computación privado a GCP) es gratuito.

Recomendaciones

Para implementar el patrón de estadísticas de nube híbrida y múltiples nubes, ten en cuenta las siguientes recomendaciones:

  • Usa la topología de traspaso para habilitar la transferencia de datos. Si es necesario volver a ingresar los resultados de estadísticas a los sistemas transaccionales, combina las topologías de traspaso y de salida protegida.

  • Usa las colas de Cloud Pub/Sub o los depósitos de Cloud Storage para entregar datos a GCP desde sistemas transaccionales que se ejecutan en tu entorno de computación privado. Estas colas o depósitos pueden servir como fuentes para las cargas de trabajo y las canalizaciones de procesamiento de datos.

  • Cuando tengas cargas de trabajo existentes de Hadoop o Spark, considera migrar trabajos a Cloud Dataproc y migrar datos existentes de HDFS a Cloud Storage.

  • Cuando realices una transferencia de datos inicial de tu entorno de computación privado a GCP, elige el método de transferencia más adecuado según el tamaño de tu conjunto de datos y el ancho de banda disponible.

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

Híbrido perimetral

La ejecución de cargas de trabajo en la nube requiere que los clientes 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:

  • Las plataformas petrolíferas, los barcos y otros vehículos solo pueden estar conectados de manera intermitente o solo tienen acceso a vínculos satelitales de alta latencia.

  • Las fábricas o centrales eléctricas pueden estar conectadas a Internet. Estas instalaciones pueden tener requisitos de confiabilidad que exceden las garantías de disponibilidad del vínculo.

  • Las tiendas o los supermercados pueden conectarse solo de manera ocasional o usar vínculos que no proporcionan la confiabilidad o la capacidad de procesamiento necesarias a fin de manejar las transacciones fundamentales para la empresa.

El 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 configuración híbrida perimetral, el vínculo de Internet es un componente no fundamental que se usa con fines administrativos y para sincronizar o subir datos, a menudo de forma asíncrona. Sin embargo, no interviene en transacciones fundamentales para el tiempo o la empresa.

patrón híbrido perimetral

Ventajas

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

  • 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, ya sea mediante la reelaboración de ciertas aplicaciones o el equipamiento de algunas ubicaciones perimetrales con vínculos de Internet más confiables.

  • El tráfico de entrada (el traslado de datos del perímetro a GCP) es gratuito.

Recomendaciones

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

  • Si la comunicación es unidireccional, usa la topología de entrada protegida. Si la comunicación es bidireccional, considera la topología de entrada y salida protegidas.

  • 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, ten un plano de control centralizado en la nube.

  • Asegúrate de que los procesos de IC/EC 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 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 y mover cargas de trabajo entre el perímetro y la nube.

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

Patrones de implementación redundante

En las siguientes secciones, se exploran patrones comunes que se basan en una implementación redundante de aplicaciones en múltiples entornos de computación. En estos patrones, implementas las mismas aplicaciones en múltiples entornos de computación con el objetivo de aumentar la capacidad o la resiliencia.

Híbrido de entorno

La idea del patrón híbrido de entorno es mantener el entorno de producción de una carga de trabajo en el centro de datos existente, al tiempo que se usa la nube pública para otros entornos que no sean de producción.

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

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

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. Las restricciones que pueden hacer que una migración a la nube sea un desafío suelen aplicarse al entorno de producción y a sus datos, pero no a otros entornos.

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

patrón híbrido de entorno

Puede que ejecutar sistemas de desarrollo y prueba en entornos diferentes a los sistemas de producción parezca arriesgado y contrario a las recomendaciones existentes o a los intentos de reducir las diferencias entre esos 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.
    • Pruebas de implementación o etapas de pruebas: verificar que el procedimiento de implementación funcione.
    • Producción.

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.

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

Desde un punto de vista fundamental, está bien si los entornos que se usan para pruebas funcionales y de desarrollo difieren en términos no funcionales con los otros entornos. Esta situación se adapta 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, asegura la portabilidad de la carga de trabajo y abstrae las diferencias entre los entornos de computación.

  • Ejecuta entornos para la producción, la etapa de pruebas y las pruebas de rendimiento y confiabilidad en el entorno de computación privado, lo que garantiza la equivalencia funcional y no funcional.

  • Ejecuta entornos de pruebas funcionales y de desarrollo en la nube pública. Estos entornos son equivalentes en términos de funciones a los entornos restantes, pero puede que difieran en cuanto a aspectos no funcionales, como el rendimiento.

Ventajas

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

  • Puedes poner en marcha y eliminar los entornos de forma automática según sea necesario. 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 eliminar el entorno.

  • Los entornos de desarrollo y de prueba a menudo se usan de forma intermitente. Puedes reducir los costos si detienes las instancias de máquina virtual (VM) durante los momentos de inactividad o si solo aprovisionas entornos a pedido.

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

Recomendaciones

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

  • Usa la topología duplicada, lo que evita que los sistemas de diferentes entornos se comuniquen entre sí. Como los sistemas no necesitan comunicarse entre entornos, no es necesario establecer una identidad común.

  • Para hacer que las cargas de trabajo sean portátiles y abstraer las diferencias entre los entornos, usa contenedores y Kubernetes, pero ten en cuenta los límites de la portabilidad de cargas de trabajo.

  • Asegúrate de que los procesos de IC/EC sean coherentes en todos los entornos de computación y que el mismo conjunto de archivos binarios, paquetes o contenedores se implemente en los distintos entornos.

  • Para implementar, configurar y operar cargas de trabajo, establece una cadena de herramientas común que funcione en todos los entornos de computación. El uso de Kubernetes te brinda esta coherencia, con la excepción de algunas pequeñas diferencias en la forma en la que te conectas a los clústeres que se ejecutan en diferentes entornos de computación o te autenticas en ellos.

  • Cuando uses Kubernetes, usa un sistema de integración continua, como Jenkins, para llevar a cabo una canalización de implementación que se implemente en clústeres y funcione en todos los entornos. También puedes ejecutar Jenkins en Google Kubernetes Engine (GKE).

  • Usa las mismas herramientas para el registro y la supervisión en GCP y en los entornos de nube existentes. Considera usar sistemas de supervisión de código abierto, como Prometheus. 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 puede ayudar a reducir el esfuerzo y la complejidad del entrenamiento.

  • Cuando elijas servicios de base de datos, almacenamiento y mensajería, usa productos que tengan un equivalente administrado en GCP. Depender de los servicios administrados ayuda a disminuir el esfuerzo administrativo de mantener los entornos de desarrollo y de prueba. En la siguiente tabla, se muestra qué productos de GCP son compatibles con los productos de OSS comunes.

Producto de OSS Compatible con productos de GCP
Apache HBase Cloud Bigtable
Apache Beam Cloud Dataflow
Apache Hadoop Cloud Dataproc
MySQL, PostgreSQL Cloud SQL
Redis Cloud Memorystore
Sistema de archivos de red (NFS) Cloud Filestore
JMS, Kafka Cloud Pub/Sub

Continuidad empresarial híbrida y de múltiples nubes

Lo ideal es que los sistemas esenciales se configuren de tal manera que sean resilientes en caso de desastres. 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. Sin embargo, en este enfoque no se tiene en cuenta el riesgo de interrupciones causadas por errores humanos o defectos de software. Por lo tanto, es fundamental contar con un plan de recuperación ante desastres (DR) que garantice que puedas recuperar tus sistemas dentro de límites de tiempo aceptables y con una pérdida de datos mínima si ocurren otros tipos de desastres.

Una parte clave de la planificación de DR es hacer una copia de seguridad de los datos en una ubicación geográfica diferente con frecuencia para minimizar el objetivo de punto de recuperación (RPO). Además, mantener los sistemas en modo de espera fríos, templados o calientes en una segunda ubicación puede ayudar a minimizar el objetivo de tiempo de recuperación (RTO).

Cuando ejecutas sistemas esenciales en un centro de datos central, un enfoque para la DR es mantener los sistemas en modo de espera en un segundo centro de datos que se encuentre 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, que es la idea detrás del patrón híbrido de continuidad empresarial.

patrón híbrido de continuidad empresarial

Una variante más inusual (y rara vez obligatoria) de este patrón es el de múltiples nubes de continuidad empresarial, en el que el entorno de producción usa un proveedor de servicios en la nube y el entorno de DR usa uno diferente. 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.

Ventajas

Usar la nube pública para la continuidad empresarial ofrece una serie de ventajas:

  • Debido a que GCP tiene más de una decena de regiones para elegir, puedes usarlo a fin de realizar copias de seguridad o replicar datos en un sitio diferente dentro del mismo continente o incluso en un sitio en un continente diferente.

  • Las instancias de VM detenidas solo generan costos de almacenamiento y son mucho más baratas que las instancias de VM que se ejecutan, por lo que puedes minimizar el costo de mantener los sistemas en modo de espera fríos.

  • El modelo de pago por uso de GCP garantiza que solo pagues por la capacidad de almacenamiento y procesamiento que realmente usas. Puedes aumentar o reducir su entorno de DR según sea necesario.

Recomendaciones

Cuando uses el patrón de continuidad empresarial, ten en cuenta las siguientes recomendaciones:

  • Crea un plan de recuperación ante desastres que documente tu infraestructura y los procedimientos de recuperación y conmutación por error.

  • En función de tu RPO y RTO, decide si realizar una copia de seguridad de los datos en GCP es suficiente o si necesitas mantener los sistemas en modo de espera fríos, templados o calientes. Consulta la Guía de planificación de recuperación ante desastres para ver situaciones comunes y consejos sobre su implementación en GCP.

  • Cuando solo realices copias de seguridad de datos, usa la topología de traspaso. De lo contrario, considera usar la topología duplicada.

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

  • Si replicas datos de forma bidireccional entre entornos, puede que te expongas al problema de cerebro dividido. En este problema, si se interrumpe la comunicación entre los dos entornos, es posible que los sistemas en ambos lados determinen que el otro entorno no está disponible. Puede que los sistemas lleguen a la conclusión de que tienen acceso exclusivo a los datos, lo que podría generar modificaciones conflictivas. Una forma de evitar esta división es agregar un tercer entorno de computación. Este enfoque permite que un sistema que se basa en la replicación de datos verifique un quórum antes de determinar que la modificación de los datos es segura. De forma alternativa, puedes permitir la conciliación de las modificaciones de datos en conflicto después de que se restablezca la conectividad.

  • Asegúrate de que los sistemas de IC/EC 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.

  • Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas y dependan de los túneles VPN, TLS o de ambos.

  • Cuando usas sistemas en espera, asegúrate de que las cargas de trabajo sean portátiles para que los sistemas permanezcan coherentes en todos los entornos. Considera el uso de contenedores y Kubernetes.

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

  • Cuando uses sistemas en modo de espera calientes, usa balanceadores de cargas para crear una conmutación por error automática, pero ten en cuenta que los balanceadores de cargas también pueden fallar. Como medida de precaución, configura tu DNS para que puedas redirigir a los usuarios a sistemas en modo de espera en caso de un desastre. Usa un TTL corto para garantizar que los cambios de DNS se propaguen con rapidez y usa el ANS con el 100% de tiempo de actividad que Cloud DNS proporciona.

  • Para DR, considera soluciones de socios, como Actifio o Commvault.

Picos de actividad de nube

Las aplicaciones de Internet, en particular aquellas dirigidas a usuarios, 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 IC/EC.

Si bien puedes acomodar las cargas de trabajo inestables en un entorno de computación clásico basado en centros de datos mediante el aprovisionamiento excesivo de recursos, este enfoque no es 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 picos de actividad de nube es usar de forma temporal un entorno de computación privado para la carga y los picos de actividad del modelo de referencia en la nube cuando necesites capacidad adicional.

patrón de picos de actividad de nube

Un requisito clave para las situaciones de picos de actividad de 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.

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 y, luego, ejecute un ajuste ascendente o descendente automático de los recursos.

    image

    Por un lado, el uso este enfoque te permite retirar todos los recursos de nube en momentos de baja actividad. Por otro lado, la implementación de mecanismos para realizar un seguimiento de los recursos podría superar las capacidades de las soluciones del balanceador de cargas listas para usar y, por lo tanto, aumentar la complejidad general.

  • De forma alternativa, puedes enrutar las solicitudes a GCP y, luego, distribuirlas a través de los entornos. Debido a que los balanceadores de cargas de GCP solo admiten el balanceo y el ajuste de escala automático entre los recursos de GCP, debes combinar un balanceador de cargas de GCP con mecanismos adicionales y personalizados de balanceo de cargas a fin de facilitar la distribución de las solicitudes. Este enfoque aumenta la complejidad.

    El balanceo de cargas mediante el DNS de Round Robin no es práctico si pretendes desactivar todos los recursos en GCP en períodos de baja demanda. Debido a que las actualizaciones de DNS tienden a propagarse con lentitud, el uso de DNS para el balanceo de cargas implica el riesgo de que se enrute a los usuarios a GCP cuando no hay recursos disponibles para procesar sus solicitudes.

Dados estos desafíos, el patrón de picos de actividad de nube se suele prestar mejor para cargas de trabajo por lotes que cargas de trabajo interactivas.

Ventajas

Estas son algunas de las ventajas clave de este patrón de arquitectura:

  • El patrón de picos de actividad de 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 a la nube.

  • Es posible que puedas aumentar el uso y la rentabilidad de tus entornos de computación privados debido a que ya no tienes que mantener un exceso de capacidad para satisfacer las demandas máximas.

  • El patrón de picos 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.

Recomendaciones

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

  • Usa la topología de malla 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 otros entornos de computación. Si las cargas de trabajo lo permiten, solo otorga acceso desde la nube al otro entorno de computación, no al revés.

  • Para minimizar la latencia de comunicación entre entornos, elige una región de GCP y una ubicación de interconexión que esté cerca, en términos geográficos, de tu entorno de computación privado.

  • Cuando uses el patrón de picos de actividad de nube solo para cargas de trabajo por lotes, puedes reducir la superficie de ataque de seguridad si mantienes todos los recursos de GCP privados y no permites el acceso directo desde Internet a estos recursos.

  • Para los trabajos que no se ejecutan por más de 24 horas y no son urgentes, considera el uso de instancias de VM interrumpibles, que son mucho más baratas que las instancias de VM normales. Sin embargo, un requisito previo es que si la VM en la que se ejecuta un trabajo se interrumpe, el sistema debe poder reiniciar el trabajo de forma automática.

  • Usa contenedores para lograr la portabilidad de la carga de trabajo. Para cargas de trabajo por lotes de uso intensivo de recursos, puedes implementar estos contenedores en las VM de Compute Engine directamente y usar un grupo de instancias administrado a fin de escalar la cantidad de VM. En caso de cargas de trabajo interactivas o diversas, que requieran menos recursos, también puedes usar Google Kubernetes Engine (GKE) con ajuste de escala automático del clúster para implementar estos contenedores. Sin embargo, ten en cuenta que GKE requiere que al menos un nodo por zona se ejecute en todo momento.

  • Supervisa el tráfico enviado desde GCP a un entorno de computación diferente. Este tráfico está sujeto a cargos de salida.

  • Debido a que los datos que se intercambian entre los entornos pueden ser sensibles, asegúrate de que todas las comunicaciones estén encriptadas y dependan de los túneles VPN, TLS o de ambos.

  • Para cargas de trabajo que requieren una gran cantidad de almacenamiento, considera una integración con una solución de almacenamiento híbrido, como Cloudian, ClearSky, Avere vFXT, Egnyte o SwiftStack.

  • Usa el patrón de picos de actividad de nube para escalar de forma dinámica un sistema de integración continua. Si usas Jenkins, puedes usar el complemento de Google Compute Engine para administrar y hacer un ajuste de escala automático de las instancias de Jenkins en Compute Engine.

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

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...