En este documento se ofrecen directrices sobre enfoques y consideraciones comunes y probados para migrar tu carga de trabajo a la nube. Se trata de una ampliación de la guía Diseñar una estrategia de arquitectura híbrida y multinube, que aborda varios pasos posibles y recomendados para diseñar una estrategia de adopción de una arquitectura híbrida o multinube.
Prioridad de la nube
Una forma habitual de empezar a usar la nube pública es con la estrategia primero la nube. Con este enfoque, despliegas tus nuevas cargas de trabajo en la nube pública, mientras que las cargas de trabajo que ya tienes se quedan donde están. En ese caso, plantéate hacer un despliegue clásico en un entorno de computación privado solo si no es posible hacer un despliegue en una nube pública por motivos técnicos o de organización.
La estrategia de priorizar la nube tiene ventajas y desventajas. Por otro lado, es una herramienta prospectiva. Puedes desplegar nuevas cargas de trabajo de forma modernizada y, al mismo tiempo, evitar (o al menos minimizar) los problemas que conlleva migrar las cargas de trabajo que ya tienes.
Aunque una estrategia cloud-first puede ofrecer ciertas ventajas, podría provocar que se pierdan oportunidades de mejorar o usar cargas de trabajo. Las cargas de trabajo nuevas pueden representar una fracción del panorama de TI general y su efecto en los gastos y el rendimiento de TI puede ser limitado. Asignar tiempo y recursos a la migración de una carga de trabajo ya existente podría generar más ventajas o ahorros de costes que intentar adaptar una carga de trabajo nueva al entorno de la nube.
Si sigues un enfoque cloud-first estricto, también corres el riesgo de aumentar la complejidad general de tu entorno de TI. Este enfoque puede crear redundancias, reducir el rendimiento debido a una comunicación excesiva entre entornos o dar lugar a un entorno informático que no se adapte bien a la carga de trabajo individual. Además, el cumplimiento de las normativas del sector y las leyes de privacidad de los datos puede impedir que las empresas migren determinadas aplicaciones que contengan datos sensibles.
Teniendo en cuenta estos riesgos, puede que te convenga más usar un enfoque que dé prioridad a la nube solo para determinadas cargas de trabajo. Si adoptas una estrategia basada en la nube, puedes centrarte en las cargas de trabajo que más se beneficien de una implementación o migración a la nube. Este enfoque también tiene en cuenta la modernización de las cargas de trabajo actuales.
Un ejemplo habitual de arquitectura híbrida cloud-first es cuando las aplicaciones y los servicios antiguos que contienen datos críticos deben integrarse con datos o aplicaciones nuevos. Para completar la integración, puedes usar una arquitectura híbrida que modernice los servicios antiguos mediante interfaces de API, lo que permite que los nuevos servicios y aplicaciones en la nube los utilicen. Con una plataforma de gestión de APIs en la nube, como Apigee, puedes implementar estos casos prácticos con cambios mínimos en la aplicación y añadir seguridad, analíticas y escalabilidad a los servicios antiguos.
Migración y modernización
La multinube híbrida y la modernización de TI son conceptos distintos que están vinculados en un círculo virtuoso. Usar la nube pública puede facilitar y simplificar la modernización de las cargas de trabajo de TI. Modernizar tus cargas de trabajo de TI puede ayudarte a sacar más partido a la nube.
Los objetivos principales de la modernización de las cargas de trabajo son los siguientes:
- Consigue una mayor agilidad para adaptarte a los cambios en los requisitos.
- Reduzca los costes de su infraestructura y sus operaciones.
- Aumenta la fiabilidad y la resiliencia para minimizar los riesgos.
Sin embargo, puede que no sea viable modernizar todas las aplicaciones del proceso de migración al mismo tiempo. Como se describe en Migración a Google Cloud, puedes implementar uno de los siguientes tipos de migración o incluso combinar varios tipos según sea necesario:
- Cambio de alojamiento (migrar mediante lift-and-shift)
- Cambio de plataforma (trasladar y optimizar)
- Refactorizar (migrar y mejorar)
- Cambiar de arquitectura (seguir modernizando)
- Recompilación (eliminar y sustituir, a veces denominado sustitución por completo)
- Volver a comprar
Cuando tomes decisiones estratégicas sobre tus arquitecturas híbridas y multicloud, es importante que tengas en cuenta la viabilidad de tu estrategia desde el punto de vista de los costes y los plazos. Puede que te interese adoptar un enfoque de migración por fases, empezando por la migración tal cual o la migración a otra plataforma, y luego refactorizar o rediseñar la arquitectura como paso siguiente. Por lo general, la migración lift-and-shift ayuda a optimizar las aplicaciones desde el punto de vista de la infraestructura. Una vez que las aplicaciones se ejecutan en la nube, es más fácil usar e integrar servicios en la nube para optimizarlas aún más con arquitecturas y funciones cloud-first. Además, estas aplicaciones pueden seguir comunicándose con otros entornos a través de una conexión de red híbrida.
Por ejemplo, puedes refactorizar o rediseñar la arquitectura de una aplicación grande y monolítica basada en VMs y convertirla en varios microservicios independientes basados en una arquitectura de microservicios en la nube. En este ejemplo, la arquitectura de microservicios usa Google Cloud servicios de contenedores gestionados, como Google Kubernetes Engine (GKE) o Cloud Run. Sin embargo, si la arquitectura o la infraestructura de una aplicación no se admiten en el entorno de nube de destino tal como están, puedes empezar por replataformar, refactorizar o rediseñar tu estrategia de migración para superar esas limitaciones cuando sea posible.
Cuando utilices cualquiera de estos métodos de migración, considera la posibilidad de modernizar tus aplicaciones (si procede y es viable). La modernización puede requerir la adopción e implementación de los principios de ingeniería de fiabilidad de sitios (SRE) o DevOps, por lo que también puede que tengas que extender la modernización de las aplicaciones a tu entorno privado en una configuración híbrida. Aunque la implementación de los principios de SRE implica la ingeniería en su esencia, se trata más de un proceso de transformación que de un reto técnico. Por lo tanto, es probable que requiera cambios en los procedimientos y en la cultura. Para obtener más información sobre cómo conseguir el apoyo de la dirección es el primer paso para implementar la SRE en una organización, consulta el artículo Con la SRE, no planificar es planificar el fracaso.
Combinar enfoques de migración
Cada enfoque de migración que se describe aquí tiene sus ventajas y desventajas. Una de las principales ventajas de seguir una estrategia híbrida y multinube es que no es necesario decantarse por un solo enfoque. En su lugar, puedes decidir qué enfoque se adapta mejor a cada carga de trabajo o pila de aplicaciones, como se muestra en el siguiente diagrama.
Este diagrama conceptual ilustra las distintas rutas o enfoques de migración y modernización que se pueden aplicar simultáneamente a diferentes cargas de trabajo, en función de los requisitos y objetivos técnicos y empresariales únicos de cada carga de trabajo o aplicación.
Además, no es necesario que los componentes de la misma pila de aplicaciones sigan el mismo enfoque o estrategia de migración. Por ejemplo:
- La base de datos backend local de una aplicación se puede cambiar de plataforma de MySQL autogestionado a una base de datos gestionada mediante Cloud SQL en Google Cloud.
- Las máquinas virtuales de frontend de la aplicación se pueden refactorizar para que se ejecuten en contenedores mediante Autopilot de GKE, donde Google gestiona la configuración del clúster, incluidos los nodos, el escalado, la seguridad y otros ajustes preconfigurados.
- La solución de balanceo de carga de hardware local y las funciones del cortafuegos de aplicaciones web (WAF) se pueden sustituir por Cloud Load Balancing y Google Cloud Armor.
Elige la opción de cambiar el alojamiento (lift and shift) si se cumple alguna de las siguientes condiciones en las cargas de trabajo:
- Tienen un número relativamente pequeño de dependencias en su entorno.
- No se considera que merezca la pena refactorizarlo o no es viable hacerlo antes de la migración.
- Se basan en software de terceros.
Considera la refactorización (migración y mejora) para estos tipos de cargas de trabajo:
- Tienen dependencias que deben resolverse.
- Se basan en sistemas operativos, hardware o sistemas de bases de datos que no se pueden alojar en la nube.
- No están aprovechando los recursos de computación o almacenamiento de forma eficiente.
- No se pueden implementar de forma automática sin esfuerzo.
Determina si la recompilación (eliminar y sustituir) se adapta a tus necesidades en estos tipos de cargas de trabajo:
- Ya no cumplen los requisitos actuales.
- Se pueden incorporar a otras aplicaciones que ofrezcan funciones similares sin poner en riesgo los requisitos empresariales.
- Se basan en tecnología de terceros que ha llegado al final de su ciclo de vida.
- Requieren tarifas de licencia de terceros que ya no son económicas.
El Programa de Migración Rápida muestra cómo Google Cloud ayuda a los clientes a usar las prácticas recomendadas, reducir los riesgos, controlar los costes y simplificar el proceso para alcanzar el éxito en la nube.