Con el patrón de arquitectura híbrido de entorno, mantienes el entorno de producción de una carga de trabajo en el centro de datos. Después, puedes usar la nube pública para tus entornos de desarrollo y de prueba, u otros entornos. Este patrón se basa en la implementación redundante de las mismas aplicaciones en varios entornos de computación. El objetivo de la implementación es aumentar la capacidad, la agilidad y la resiliencia.
Al evaluar qué cargas de trabajo migrar, puede que observes casos en los que ejecutar una aplicación específica en la nube pública suponga un reto:
- Las restricciones jurisdiccionales o normativas pueden requerir que conserves los datos en un país concreto.
- Los términos de licencia de terceros pueden impedir que utilices determinado software en un entorno de nube.
- Una aplicación puede requerir acceso a dispositivos de hardware que solo estén disponibles de forma local.
En estos casos, no solo debes tener en cuenta el entorno de producción, sino todos los entornos que intervienen en el ciclo de vida de una aplicación, incluidos los sistemas de desarrollo, pruebas y preproducción. Estas restricciones suelen aplicarse al entorno de producción y a sus datos. Es posible que no se apliquen a otros entornos que no usen los datos reales. Ponte en contacto con el departamento de cumplimiento de tu organización o con el equipo correspondiente.
En el siguiente diagrama se muestra un patrón de arquitectura híbrida de entorno típico:
Puede que te parezca arriesgado ejecutar sistemas de desarrollo y de prueba en entornos diferentes a los de producción, y que esto se desvíe de tus prácticas recomendadas o de tus intentos de minimizar las diferencias entre tus entornos. Aunque estas preocupaciones están justificadas, no se aplican si distingues entre las fases de los procesos de desarrollo y prueba:
Aunque los procesos de desarrollo, prueba y despliegue varían en función de la aplicación, suelen incluir variaciones de las siguientes fases:
- Desarrollo: crear una versión candidata.
- Pruebas funcionales o pruebas de aceptación de usuarios: se verifica que la versión candidata cumple los requisitos funcionales.
- Pruebas de rendimiento y fiabilidad: se verifica que la versión candidata cumple los requisitos no funcionales. También se conoce como prueba de carga.
- Pruebas de la fase de desarrollo o de la implementación: comprueba que el procedimiento de implementación funcione.
- Producción: lanzamiento de aplicaciones nuevas o actualizadas.
Rara vez es práctico realizar más de una de estas fases en un mismo entorno, por lo que cada fase suele requerir uno o varios entornos específicos.
El objetivo principal de un entorno de pruebas es ejecutar pruebas funcionales. El objetivo principal de un entorno de preproducción es probar si los procedimientos de implementación de tu aplicación funcionan correctamente. Cuando una versión llega a un entorno de preproducción, las pruebas funcionales ya deberían haberse completado. El entorno de preproducción es el último paso antes de implementar el software en el entorno de producción.
Para asegurarte de que los resultados de las pruebas sean significativos y se apliquen a la implementación de producción, el conjunto de entornos que utilices a lo largo del ciclo de vida de una aplicación debe cumplir las siguientes reglas en la medida de lo posible:
- Todos los entornos son funcionalmente equivalentes. Es decir, la arquitectura, las APIs y las versiones de los sistemas operativos y las bibliotecas son equivalentes, y los sistemas se comportan de la misma forma en todos los entornos. Esta equivalencia evita situaciones en las que las aplicaciones funcionan en un entorno, pero no en otro, o en las que los defectos no se pueden reproducir.
- Los entornos que se usan para las pruebas de rendimiento y fiabilidad, las fases de preproducción y la producción no son equivalentes desde el punto de vista funcional. Es decir, su rendimiento, escala y configuración, así como la forma en que se operan y mantienen, son iguales o solo difieren en aspectos poco importantes. De lo contrario, las pruebas de rendimiento y de puesta en escena no tendrán sentido.
Por lo general, no hay problema si los entornos que se usan para el desarrollo y las pruebas funcionales difieren de los demás entornos en aspectos no funcionales.
Como se muestra en el siguiente diagrama, los entornos de prueba y desarrollo se basan en Google Cloud. Una base de datos gestionada, como Cloud SQL, se puede usar como opción para el desarrollo y las pruebas en Google Cloud. En el desarrollo y las pruebas se puede usar el mismo motor de base de datos y la misma versión en el entorno local, un motor funcionalmente equivalente o una nueva versión que se implemente en el entorno de producción después de la fase de pruebas. Sin embargo, como la infraestructura subyacente de los dos entornos no es idéntica, este enfoque para las pruebas de carga de rendimiento no es válido.
Los siguientes casos se adaptan bien al patrón de entorno híbrido:
- Consigue una equivalencia funcional en todos los entornos utilizando Kubernetes como capa de tiempo de ejecución común cuando sea aplicable y factible.
La edición Enterprise de Google Kubernetes Engine (GKE) puede ser una tecnología clave para este enfoque.
- Asegura la portabilidad de las cargas de trabajo y abstrae las diferencias entre los entornos de computación. Con una malla de servicios de confianza cero, puedes controlar y mantener la separación de comunicaciones necesaria entre los diferentes entornos.
- Ejecuta entornos de desarrollo y pruebas funcionales en la nube pública. Estos entornos pueden ser funcionalmente equivalentes a los demás, pero pueden diferir en aspectos no funcionales, como el rendimiento. Este concepto se ilustra en el diagrama anterior.
- Ejecuta entornos de producción, de preproducción y de rendimiento (pruebas de carga) y pruebas de fiabilidad en el entorno de computación privada, lo que garantiza la equivalencia funcional y no funcional.
Consideraciones de diseño
- Necesidades empresariales: cada estrategia de implementación y lanzamiento de aplicaciones tiene sus propias ventajas e inconvenientes. Para asegurarte de que el enfoque que elijas se ajusta a tus requisitos específicos, basa tus decisiones en una evaluación exhaustiva de las necesidades y las limitaciones de tu empresa.
- Diferencias entre entornos: como parte de este patrón, el objetivo principal de usar este entorno de nube es el desarrollo y las pruebas. El estado final es alojar la aplicación probada en el entorno local privado (producción). Para evitar desarrollar y probar una función que pueda funcionar correctamente en el entorno de la nube y no en el entorno de producción (local), el equipo técnico debe conocer y comprender las arquitecturas y las funciones de ambos entornos. Esto incluye las dependencias de otras aplicaciones y de la infraestructura de hardware, como los sistemas de seguridad que realizan inspecciones de tráfico.
- Gobernanza: para controlar qué puede desarrollar tu empresa en la nube y qué datos puede usar para las pruebas, utiliza un proceso de aprobación y gobernanza. Este proceso también puede ayudar a tu empresa a asegurarse de que no utiliza ninguna función en la nube en sus entornos de desarrollo y pruebas que no exista en su entorno de producción local.
- Criterios de éxito: deben ser claros, predefinidos y medibles, y deben ajustarse a los estándares de garantía de calidad del software de tu organización. Aplica estos estándares a cualquier aplicación que desarrolles y pruebes.
- Redundancia: aunque los entornos de desarrollo y de pruebas no requieran tanta fiabilidad como el entorno de producción, sí necesitan funciones redundantes y la capacidad de probar diferentes situaciones de fallo. Los requisitos de los escenarios de fallo pueden llevar a que el diseño incluya redundancia como parte de tu entorno de desarrollo y pruebas.
Ventajas
Ejecutar cargas de trabajo de desarrollo y pruebas funcionales en la nube pública tiene varias ventajas:
- Puedes iniciar y detener entornos automáticamente según sea necesario.
Por ejemplo, puedes aprovisionar un entorno completo para cada confirmación o solicitud de extracción, permitir que se ejecuten pruebas y, después, desactivarlo de nuevo. Este enfoque también ofrece las siguientes ventajas:
- Puedes reducir los costes deteniendo las instancias de máquinas virtuales (VM) cuando estén inactivas o aprovisionando entornos solo bajo demanda.
- Puedes acelerar el desarrollo y las pruebas creando entornos efímeros para cada solicitud de extracción. De esta forma, también se reduce la sobrecarga de mantenimiento y las incoherencias en el entorno de compilación.
- Ejecutar estos entornos en la nube pública ayuda a familiarizarse con la nube y las herramientas relacionadas, lo que puede facilitar la migración de otras cargas de trabajo. Este enfoque es especialmente útil si decides explorar la portabilidad de cargas de trabajo con contenedores y Kubernetes, por ejemplo, usando GKE Enterprise en diferentes entornos.
Prácticas recomendadas
Para implementar correctamente el patrón de arquitectura híbrida de entorno, ten en cuenta las siguientes recomendaciones:
- Define los requisitos de comunicación de tu aplicación, incluido el diseño óptimo de la red y la seguridad. A continuación, utiliza el patrón de red reflejada para diseñar tu arquitectura de red de forma que se eviten las comunicaciones directas entre sistemas de diferentes entornos. Si se requiere comunicación entre entornos, debe hacerse de forma controlada.
La estrategia de implementación y pruebas de aplicaciones que elijas debe ajustarse a tus objetivos y requisitos empresariales. Esto puede implicar implementar cambios sin tiempo de inactividad o implementar funciones gradualmente en un entorno o grupo de usuarios específicos antes de lanzarlas de forma generalizada.
Para que las cargas de trabajo sean portátiles y abstraer las diferencias entre entornos, puedes usar contenedores con Kubernetes. Para obtener más información, consulta la arquitectura de referencia del entorno híbrido de GKE Enterprise.
Establece una cadena de herramientas común que funcione en diferentes entornos informáticos para desplegar, configurar y operar cargas de trabajo. Si usas Kubernetes, tendrás esta coherencia.
Asegúrate de que las pipelines de CI/CD sean coherentes en todos los entornos informáticos y de que se implemente el mismo conjunto de archivos binarios, paquetes o contenedores en todos esos entornos.
Cuando uses Kubernetes, utiliza un sistema de integración continua como Tekton para implementar una canalización de despliegue que se despliegue en clústeres y funcione en diferentes entornos. Para obtener más información, consulta Soluciones de DevOps en Google Cloud.
Para ayudarte a lanzar continuamente aplicaciones seguras y fiables, incorpora la seguridad como parte integral del proceso de DevOps (DevSecOps). Para obtener más información, consulta el artículo Deliver and secure your internet-facing application in less than an hour using Dev(Sec)Ops Toolkit (Entrega y protege tu aplicación orientada a Internet en menos de una hora con Dev(Sec)Ops Toolkit).
Usa las mismas herramientas para registrar y monitorizar los entornos de nube Google Cloudy los entornos de nube que ya tengas. Te recomendamos que uses sistemas de monitorización de código abierto. Para obtener más información, consulta Patrones de almacenamiento de registros y monitorización para despliegues híbridos y multinube.
Si distintos equipos gestionan las cargas de trabajo de prueba y producción, puede ser aceptable usar herramientas independientes. Sin embargo, si usas las mismas herramientas con diferentes permisos de visualización, puedes reducir el esfuerzo y la complejidad de la formación.
Cuando elijas servicios de bases de datos, almacenamiento y mensajería para las pruebas funcionales, utiliza productos que tengan un equivalente gestionado en Google Cloud. Si utilizas servicios gestionados, se reduce el esfuerzo administrativo necesario para mantener los entornos de desarrollo y pruebas.
Para proteger la información sensible, recomendamos cifrar todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.
En la siguiente tabla se muestran los productos de Google Cloud que son compatibles con productos de software libre comunes.
| Producto de OSS | Compatible con el producto Google Cloud |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL y PostgreSQL | Cloud SQL |
| Redis Cluster, Redis y Memcached | Memorystore |
| Sistema de archivos de red (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |