Con el patrón de arquitectura de entorno híbrido, conservas el entorno de producción de una carga de trabajo en el centro de datos existente. Luego, usa la nube pública para tus entornos de desarrollo y pruebas, o cualquier otro entorno. 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.
- Puede que una aplicación requiera acceso a dispositivos de hardware que solo están disponibles de forma local.
En esos casos, considera el entorno de producción y también todos los entornos involucrados en el ciclo de vida de una aplicación, incluidos los sistemas de desarrollo, de prueba y de etapa de pruebas. A menudo, estas restricciones se aplican al entorno de producción y a sus datos. Es posible que no se apliquen a otros entornos que no usen los datos reales. Consulta 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.
Puede que ejecutar sistemas de desarrollo y prueba en entornos diferentes a los sistemas de producción parezca arriesgado y desviarse de tus prácticas recomendadas existentes o de tus intentos de minimizar las diferencias entre tus 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 la aplicación funcionan según lo previsto. En el momento en que una versión llega a un entorno de etapa de pruebas, tus pruebas funcionales deberían estar completas. La etapa de pruebas es el último paso antes de implementar el software en la 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 fallan 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 de base de datos y la misma versión en el entorno local, uno que sea equivalente en términos de funciones o una versión nueva que se lance en el entorno de producción después de la etapa de prueba. Sin embargo, debido a que la infraestructura subyacente de los dos entornos no es idéntica, este enfoque para la prueba de carga de rendimiento no es válido.
Las siguientes situaciones pueden ajustarse 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.
- Garantizar la portabilidad de la carga de trabajo y abstraer 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 puede que difieran en cuanto a aspectos no funcionales, como el rendimiento. Este concepto se ilustra en el diagrama anterior.
- Ejecuta entornos para la producción, la etapa de pruebas y las pruebas de rendimiento (pruebas de carga) y confiabilidad en el entorno de computación privado, lo que garantiza la equivalencia funcional y no funcional.
Consideraciones de diseño
- Necesidades empresariales: Cada estrategia de implementación y lanzamiento de aplicaciones tiene sus propias ventajas y desventajas. Para asegurarte de que el enfoque que selecciones se alinee con tus requisitos específicos, basa tus selecciones en una evaluación exhaustiva de las necesidades y limitaciones de tu empresa.
- Diferencias del entorno: como parte de este patrón, el objetivo principal de usar este entorno de nube es para 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 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 inspección 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 usa ninguna función de la nube en tus 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 control de calidad del software para 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. Es posible que los requisitos de situación de falla generen un diseño para incluir redundancia como parte del 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 entornos de forma automática 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 si inicias entornos efímeros para cada solicitud de extracción. Esto también reduce la sobrecarga de mantenimiento y reduce 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 comunicación entre entornos, esta debe ser de una manera controlada.
La estrategia de implementación y de prueba de la aplicación que elijas debe alinearse con los 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 una parte integral del proceso de DevOps (DevSecOps). Para obtener más información, consulta Entrega y protege tu aplicación orientada a Internet en menos de una hora con el kit de herramientas de Dev(Sec)Ops.
Usa las mismas herramientas para registrar y supervisar en Google 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 de nubes híbridas y múltiples.
Si existen diferentes equipos que administran las cargas de trabajo de prueba y producción, se pueden usar herramientas independientes. Sin embargo, usar las mismas herramientas con diferentes permisos de vista 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, recomendamos encriptar 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 |
| Redis Cluster, Redis, Memcached | Memorystore |
| Sistema de archivos de red (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |