En este documento, se muestra una arquitectura que usa una malla de servicios de Istio para migrar desde un entorno heredado, como un centro de datos local que ejecuta aplicaciones en máquinas virtuales a Google Kubernetes Engine (GKE). Usar una malla de servicios puede reducir la complejidad de la migración y la refactorización, ya que separa las funciones de red de las funciones de servicio.
En este documento, se explica la lógica de la migración y se describen sus fases de alto nivel. Puedes usar esta arquitectura para realizar una migración en una operación (a veces llamada migración Big Bang) o para realizar una migración gradual por funciones. El documento de implementación adjunto te guiará a través de una migración de ejemplo.
Esta arquitectura y su guía de implementación están destinadas a los profesionales de TI que administran una infraestructura compleja que desean migrar y modernizar de forma gradual y, al mismo tiempo, minimizar lo siguiente:
- Tiempo de inactividad
- Refactoriza el esfuerzo
- Complejidad operativa de la red
Los conceptos que se explican se aplican a cualquier nube, por lo que en el documento, suponemos que estás familiarizado con las tecnologías de la nube, los contenedores y los microservicios.
Como se describe en la sección Migra a Google Cloud: comienza ahora, existen varios patrones para migrar a la nube. La arquitectura de este documento usa un patrón de refactorización (a veces llamado mover y mejorar), en el que el patrón se aplica a cada función de la aplicación, en lugar de a la aplicación en general.
Durante la migración, la aplicación tiene una arquitectura híbrida en la que algunas funciones están en Google Cloud y otras todavía están en el entorno heredado. Cuando se finaliza la migración, la aplicación completa se aloja en Google Cloud.
Arquitectura
En el siguiente diagrama, se muestra cómo puedes usar una malla de servicios para enrutar el tráfico a los microservicios que se ejecutan en el entorno de origen o a Google Cloud:
La arquitectura incluye los siguientes componentes:
Un entorno de origen, en este caso, una instancia de Compute Engine que aloja la carga de trabajo de ejemplo que se migrará. El entorno de origen también puede ser local o estar alojado en otras plataformas en la nube.
Una malla de servicios, en este caso la puerta de enlace de Istio, que vincula diferentes servicios. La malla de servicios proporciona funciones de red de alto valor, como el descubrimiento de servicios, comunicaciones seguras, el balanceo de cargas, la administración del tráfico y la observabilidad.
Una implementación típica de una malla de servicios vincula cada servicio con un proxy que proporciona esas características. Se conoce al proxy de servicio como archivo adicional. La función del archivo adicional es aumentar y mejorar la aplicación a la que se conecta, a menudo sin el conocimiento de la aplicación. En la guía de implementación complementaria, debes usar Envoy como un proxy de sidecar.
Una carga de trabajo que contiene una aplicación compuesta por microservicios. Un microservicio es un componente independiente que se compila para adaptarse a una función de la aplicación. En esta arquitectura, la aplicación se compone de diferentes microservicios que los usuarios no pueden distinguir. Por ejemplo, un componente que controla las reseñas de libros es un microservicio.
En el patrón de microservicios, la aplicación es el agregado de varios microservicios, cada uno con un objetivo específico. Por ejemplo, puedes tener un microservicio que controle las calificaciones de los libros y otro que controle las reseñas de los libros. Esos microservicios deben estar vinculados de forma flexible y deben interactuar entre sí a través de las API bien definidas. Se pueden escribir en diferentes lenguajes y frameworks (como en las aplicaciones políglotas), y pueden tener ciclos de vida distintos.
Un contenedor que sirve para definir aún más los límites de cada microservicio. Debido a que el entorno de destino en esta arquitectura está organizado con Kubernetes, te recomendamos que alojes tus microservicios en contenedores mediante las siguientes herramientas:
- Docker es una herramienta para aislar programas a nivel del espacio del usuario en el nivel del sistema operativo. Ejecuta los paquetes llamados contenedores.
- Kubernetes es la solución de organización líder para cargas de trabajo en contenedores. Proporciona funciones como el descubrimiento de servicios, el balanceo de cargas, Pods de reparación automática, nodos, secretos y la administración de la configuración.
- GKE es un entorno de Kubernetes administrado y listo para la producción, que forma parte de Google Cloud.
Para obtener asesoramiento sobre cómo alojar estos microservicios en contenedores, consulta Prácticas recomendadas para compilar contenedores y Prácticas recomendadas para trabajar con contenedores.
Para realizar una migración mediante una malla de servicios, completa las siguientes fases:
- Evalúa el entorno heredado: Recopila información y establece un conjunto de requisitos del entorno de destino y un modelo de referencia de las pruebas y la validación.
- Crea una base en el entorno de destino: Aprovisiona tu entorno de destino y aplica una metodología de infraestructura como código para que tu infraestructura se pueda auditar, repetir y aprovisionar de forma automática.
- Implementa servicios y comienza a enrutar el tráfico al entorno de destino: Completa una sola operación para implementar todas las instancias de microservicios al mismo tiempo o completa una implementación gradual para implementar un microservicio a la vez.
- Detén el enrutamiento de tráfico al entorno heredado: Configura reglas de enrutamiento para enrutar el tráfico a servicios que se ejecutan solo en el entorno de destino.
- Retira el entorno heredado: Actualiza tus registros DNS para que apunten al balanceador de cargas que configuraste durante la fase de aprovisionamiento del entorno de destino.
En este documento, se describen algunas consideraciones de diseño para este tipo de migración y la guía de implementación complementaria proporciona pasos detallados a fin de completar la migración.
Consideraciones del diseño
En esta sección, se proporciona orientación para ayudarte a desarrollar una arquitectura que cumpla con tus requisitos específicos sobre la confiabilidad, la eficiencia operativa, el costo y la optimización del rendimiento.
Confiabilidad
En las siguientes secciones, se describen las consideraciones para la confiabilidad de la migración.
Usa una estrategia de migración gradual
Aunque esta arquitectura se puede usar para una migración de una sola operación, te recomendamos que uses una estrategia de migración gradual. Completar una migración en una operación es difícil debido a los desafíos y riesgos que implica la migración de una o más aplicaciones a la vez. Cuando tienes limitaciones en el tiempo y el presupuesto, enfocarte en una migración de una sola operación no deja mucha capacidad para trabajar en las funciones nuevas de la aplicación.
Por el contrario, una migración gradual y por funciones tiene una complejidad general más baja debido al menor tamaño de la carga de trabajo que se migrará: una función única tiene una huella más pequeña en comparación con una aplicación completa. Una migración gradual te permite repartir el riesgo entre eventos de migración más pequeños, en lugar de en un solo ejercicio de alta prioridad. Una migración gradual también permite que el equipo de migración planifique, diseñe y desarrolle varias estrategias de migración a fin de adaptarse a diferentes tipos de funciones.
Para obtener orientación sobre cómo elegir qué funciones migrar primero y cómo migrar funciones con estado, consulta Elige las apps que se migrarán primero en “Migra a Google Cloud: evalúa y descubre tus cargas de trabajo".
Usa un paquete de pruebas de cumplimiento
Para facilitar la migración, te recomendamos que uses un paquete de pruebas de cumplimiento. Un conjunto de pruebas de cumplimiento es un grupo de pruebas que se pueden ejecutar en un entorno para comprobar si este cumple con un conjunto de requisitos determinado. Si el entorno es válido, cumple con los requisitos. Por ejemplo, puedes validar la respuesta a una solicitud de prueba o comprobar si las dependencias de la aplicación se instalaron.
Puedes comenzar con la supervisión, el seguimiento y las herramientas de visualización de la malla de servicios para obtener una validación manual. Luego, puedes implementar el conjunto de pruebas y desarrollarlo con el tiempo de las siguientes maneras:
- Prueba de carga: Puedes hacer que el conjunto de pruebas evolucione si envías el tráfico de prueba al entorno de forma automática y evalúas los resultados.
- Herramienta de pruebas de cumplimiento: Puedes diseñar y desarrollar un conjunto de pruebas con una herramienta dedicada.
Ejecuta el conjunto de pruebas de cumplimiento en el entorno heredado como modelo de referencia y, también, en el entorno de destino durante y después de la migración y después de ella.
Tus conjuntos de pruebas estar enfocados para validar los siguientes aspectos durante la migración:
- Aprovisionamiento: Aprovisiona los recursos que necesitas en tu entorno antes de configurarlos.
- Configuración: Después de aprovisionar los recursos en el entorno, configúralos según las necesidades de tu aplicación. Tener un conjunto de pruebas de configuración garantiza que el entorno esté listo para alojar la aplicación.
- Lógica empresarial: Después de validar el aprovisionamiento y la configuración del entorno, valida la lógica empresarial de la aplicación. Por ejemplo, puedes validar las respuestas a las solicitudes.
Chef InSpec, RSpec y Serverspec son herramientas para desarrollar paquetes de prueba de cumplimiento automáticas. Funcionan en cualquier plataforma y son extensibles, por lo que puedes implementar tus propios controles a partir de los controles integrados.
Cuando aprovisionas el entorno de destino, puedes usar el conjunto de pruebas de cumplimiento para validarlo. Es posible que tengas que actualizar el conjunto de pruebas para tener en cuenta las diferencias eventuales entre el entorno heredado y el de destino, como el hardware y la topología de red. Ten en cuenta que migras de un entorno local, en el que tienes control total, a un entorno de nube pública, en el que, por lo general, no tienes acceso completo a toda la pila.
Antes de enrutar el tráfico desde la capa de balanceo de cargas del entorno heredado hasta el entorno de destino, te recomendamos que ejecutes el conjunto de pruebas de cumplimiento de la lógica empresarial en los microservicios expuestos por el entorno de destino. El conjunto de pruebas puede ayudar a garantizar que los microservicios funcionen como se espera. Por ejemplo, puedes validar las respuestas que muestran los servicios que expone la malla de servicios. Puedes mantener la ruta original como una opción de copia de seguridad en caso de que necesites revertir los cambios y volver al entorno heredado. Si enrutas una pequeña parte del tráfico de producción a instancias de los microservicios que se ejecutan en el entorno de destino, puedes generar confianza en el entorno de destino y aumentar el tráfico total con el tiempo.
Inhabilita las solicitudes entre entornos
Durante la fase de prueba de cumplimiento, recomendamos que definas mejor las reglas de enrutamiento para inhabilitar las solicitudes entre entornos, de modo que cuando una solicitud del cliente llegue a un entorno, ya sea heredado o de destino, permanezca en ese entorno. Inhabilitar las solicitudes entre entornos ayuda a garantizar que las pruebas validen de forma correcta el entorno de destino. Si no inhabilitas estas solicitudes, una prueba podría informar que se realizó de forma correcta en el entorno de origen en lugar del entorno de destino sin tu conocimiento.
Retira el entorno heredado
Antes de retirar el entorno heredado, verifica que se cumplan todas las siguientes condiciones:
- El tráfico no se enruta a instancias de microservicios que se ejecutan en el entorno heredado.
- No hay tráfico que provenga de las interfaces del entorno heredado.
- El entorno de destino se validó por completo.
Cuando se cumplan estas condiciones, podrás actualizar tus registros DNS para apuntar al balanceador de cargas que configuraste durante la fase de aprovisionamiento del entorno de destino. No retires el entorno heredado, a menos que estés seguro de que se validó el entorno de destino. No limites la validación solo a la lógica empresarial; considera otros requisitos no funcionales, como el rendimiento y la escalabilidad.
Eficiencia operativa
En las siguientes secciones, se describen las consideraciones para la eficiencia operativa de la migración.
Evalúa el entorno heredado
Antes de diseñar o implementar un plan de migración, debes evaluar el entorno heredado a fin de recopilar información y establecer un conjunto de requisitos del entorno de destino y un modelo de referencia de las pruebas y la validación. Puedes empezar por compilar un catálogo de todas las funciones de la aplicación que se migrarán. Para cada función, deberías poder responder a este conjunto de preguntas no exhaustivo:
- ¿Cuáles son los requisitos del entorno de ejecución y del rendimiento?
- ¿Existen dependencias en otras funciones?
- ¿Esta función es fundamental para la empresa?
- ¿Esta función es sin estado o con estado?
- ¿Cuánto se espera refactorizar para migrarla?
- ¿Esta función puede permitir un período de migración?
Para obtener más información, consulta Migra a Google Cloud: evalúa y descubre tus cargas de trabajo.
Recursos sin estado frente a recursos con estado
La arquitectura usa una malla de servicios porque separa las funciones de servicio (cómo se implementa la lógica empresarial) de funciones de red (cómo y cuándo enrutar el tráfico a las funciones de servicio). En la implementación adjunta, usarás Istio como la malla de servicios.
En el entorno heredado, la mayoría de las llamadas de servicio no incluyen la red, ya que se generan en una plataforma monolítica. En las arquitecturas de microservicios, las comunicaciones entre servicios se realizan a través de una red y los servicios deben ocuparse de este modelo diferente. Una malla de servicios abstrae las funciones para manejar las comunicaciones de red, por lo que no tienes que implementarlas en cada aplicación. Una malla de servicios también reduce la complejidad operativa de la red, y que proporciona canales de comunicación seguros, balanceo de cargas, administración del tráfico, supervisión y funciones de observabilidad que no necesitan configuración.
Si implementas y configuras una malla de servicios, puedes enrutar el tráfico de forma dinámica al entorno heredado o al entorno de destino. No necesitas modificar la configuración de la aplicación a fin de admitir tu migración, ya que la administración del tráfico es transparente para los servicios en la malla.
Aunque este enfoque funciona bien para las funciones sin estado, debes planificar y refactorizar de manera adicional las funciones con estado, sensibles a la latencia o muy vinculadas con otras:
- Con estado: Cuando migras funciones con estado, también debes migrar datos para minimizar el tiempo de inactividad y mitigar los problemas de sincronización e integridad durante la migración. Puedes obtener más información sobre las estrategias de migración de datos en la sección Evalúa enfoques de migración de datos de “Migración a Google Cloud: transfiere conjuntos de datos grandes”.
- Sensible a la latencia: Si una función es sensible a la latencia cuando se comunica con otras funciones, es posible que debas implementar componentes adicionales durante el proceso de migración. Los proxies que pueden cargar de forma previa datos o capas de almacenamiento en caché, por lo general, se usan para mitigar esta sensibilidad.
- Muy vinculadas a otras funciones: Si dos o más funciones están muy vinculadas, es posible que tengas que migrarlas al mismo tiempo. Aunque este enfoque es más fácil que migrar una aplicación completa, puede ser más difícil que migrar una sola función.
Registra servicios con la malla de servicios
Debido a que tu entorno heredado no está integrado directamente a la malla de servicios, cuando configuras tu migración, debes registrar de forma manual todos los servicios que se ejecutan en el entorno heredado con la malla de servicios. Si tu entorno ya se ejecuta en Kubernetes, puedes automatizar el registro mediante la integración incorporada con las APIs de malla de servicios.
Después de registrar el entorno heredado, usa la malla de servicios para exponer los microservicios que se ejecutan en el entorno heredado. Luego, puedes enrutar el tráfico de forma gradual a los microservicios desde las interfaces del entorno heredado hasta las interfaces del entorno de destino.
Los clientes no ven ninguna interrupción del servicio, ya que acceden a las interfaces de los dos entornos a través de una capa de balanceo de cargas. El enrutamiento del tráfico dentro de la malla de servicios es transparente para los clientes, por lo que los clientes no sabrán que se cambió la configuración de enrutamiento.
Optimización de costos
En esta arquitectura, se utilizan los siguientes componentes facturables de Google Cloud:
Cuando implementas la arquitectura, puedes usar la calculadora de precios para generar una estimación de costos según el uso previsto.
Optimización del rendimiento
En esta arquitectura, el tráfico se divide casi por igual entre los servicios que se ejecutan en Compute Engine y los servicios que se ejecutan en GKE. La malla de servicios balancea el tráfico entre las instancias de un servicio que selecciona, ya sea que se ejecuten en el clúster de GKE o en las instancias de Compute Engine. Si deseas que todo el tráfico pase por la malla de servicios, debes volver a configurar las cargas de trabajo que se ejecutan en Compute Engine para que apunten a los servicios en la malla de servicios, en lugar de conectarse directamente a ellas. Puedes configurar la política de balanceo de cargas para las revisiones de cada servicio con el recurso DestinationRule.
Implementación
Para implementar esta arquitectura, consulta Implementa la migración con la expansión de malla de Istio.
¿Qué sigue?
- Obtén más información sobre GKE.
- Lee acerca de Istio.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.