Este documento puede ayudarte a planificar, diseñar e implementar la fase de evaluación de tu migración a Google Cloud. Descubrir tu inventario de cargas de trabajo y servicios y asignar sus dependencias puede ayudarte a identificar lo que necesitas migrar y en qué orden. Cuando planificas y diseñas una migración a Google Cloud, primero necesitas un conocimiento profundo de tu entorno actual y de las cargas de trabajo que se migrarán.
Este documento es parte de la siguiente serie de varias partes sobre la migración a Google Cloud:
- Migra a Google Cloud: comienza ahora
- Migra a Google Cloud: evalúa y descubre tus cargas de trabajo (este documento)
- Migra a Google Cloud: planifica y construye tu base
- Migra a Google Cloud: transfiere los conjuntos de datos grandes
- Migra a Google Cloud: implementa las cargas de trabajo
- Migra a Google Cloud: Migra de implementaciones manuales a implementaciones automatizadas y alojadas en contenedores
- Migra a Google Cloud: optimiza tu entorno
- Migra a Google Cloud: prácticas recomendadas para validar un plan de migración
- Migra a Google Cloud: Minimiza los costos
En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.
Este documento es útil si estás planificando una migración desde un entorno local, un entorno de hosting privado o cualquier otro proveedor de servicios en la nube, o bien si estás evaluando la oportunidad de migrar y explorar la fase de evaluación.
En la fase de evaluación, determinarás los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.
La fase de evaluación es fundamental para el éxito de la migración. Debes obtener un conocimiento profundo sobre las cargas de trabajo que deseas migrar, sus requisitos, sus dependencias y tu entorno actual. Debes saber cuál es tu punto de partida para planificar y ejecutar de forma correcta una migración de Google Cloud.
La fase de evaluación consta de las siguientes tareas:
- Crea un inventario completo de tus aplicaciones.
- Cataloga tus cargas de trabajo según sus propiedades y dependencias.
- Capacita y educa a tus equipos en Google Cloud.
- Crea experimentos y pruebas de concepto en Google Cloud.
- Calcula el costo total de propiedad (TCO) del entorno de destino.
- Elige la estrategia de migración para tus cargas de trabajo.
- Elige tus herramientas de migración.
- Define el plan y el cronograma de migración.
- Valida tu plan de migración.
Crea un inventario de tus cargas de trabajo
Para determinar el alcance de la migración, primero debes saber cuántos elementos, como las cargas de trabajo y dispositivos de hardware, existen en tu entorno actual, junto con sus dependencias. Crear el inventario es una tarea no trivial que requiere un gran esfuerzo, en especial cuando no se cuenta con un sistema de catalogación automático. Para tener un inventario integral, necesitas usar la experiencia de los equipos responsables del diseño, la implementación y el funcionamiento de cada carga de trabajo en tu entorno actual, así como del entorno mismo.
El inventario no debe limitarse solo a las cargas de trabajo, sino que debe contener lo siguiente:
- Dependencias de cada carga de trabajo, como bases de datos, agentes de mensajes, sistemas de almacenamiento de configuración y otros componentes
- Servicios compatibles con la infraestructura de tu carga de trabajo, como repositorios de origen, herramientas de integración y de implementación continua (CI/CD), y repositorios de artefactos
- Servidores, ya sean virtuales o físicos, y entornos de ejecución
- Dispositivos físicos, como dispositivos de red, firewalls y otro hardware dedicado
Cuando compiles esta lista, también debes recopilar información sobre cada elemento, incluidos los siguientes datos:
- La ubicación del código fuente y si puedes modificarlo
- El método de implementación para la carga de trabajo en un entorno de ejecución, por ejemplo, si usas una canalización de implementación automatizada o manual
- Las restricciones de red o los requisitos de seguridad
- Requisitos de dirección IP.
- Cómo expones la carga de trabajo a los clientes
- Los requisitos de licencia para cualquier software o hardware
- Cómo se autentica la carga de trabajo en tu sistema de administración de identidades y accesos
Por ejemplo, para cada dispositivo de hardware, debe conocer sus especificaciones detalladas, como el nombre, el proveedor, las tecnologías y las dependencias con otros elementos de tu inventario. Por ejemplo:
- Nombre: dispositivo de NAS
- Proveedor y modelo: proveedor Y, modelo Z
- Tecnologías: NFS, iSCSI
- Dependencias: conectividad de red con marcos Jumbo al hardware de procesamiento de VM.
Esta lista también debe incluir información no técnica, por ejemplo, bajo qué términos de licencias puedes usar cada elemento y cualquier otro requisito de cumplimiento. Si bien algunas licencias te permiten implementar una carga de trabajo en un entorno en la nube, otras prohíben de forma explícita la implementación en la nube. Algunas licencias se asignan según la cantidad de CPU o sockets en uso, y, es posible, que estos conceptos no se apliquen cuando se ejecutan en la tecnología de la nube. Puede que algunos de tus datos tengan restricciones relacionadas con la región geográfica en la que se almacenan. Por último, algunas cargas de trabajo sensibles pueden requerir un usuario único.
Junto con el inventario, es útil proporcionar recursos para una interpretación visual de los datos recopilados. Por ejemplo, puedes proporcionar un gráfico de dependencia y esquemas para destacar aspectos de interés, como la distribución de tus cargas de trabajo en un proceso de implementación automatizado o manual.
Cómo crear tu inventario
Existen diferentes maneras de crear un inventario de cargas de trabajo. Si bien la forma más rápida de comenzar es continuar de forma manual, este método puede resultar difícil para un entorno de producción grande. La información en los inventarios compilados de forma manual puede quedar desactualizada con rapidez, y la migración resultante podría fallar porque no confirmaste el contenido de tus inventarios.
La creación del inventario no es una tarea que se realiza una sola vez. Si tu entorno actual es muy dinámico, también debes invertir esfuerzo en automatizar la creación y el mantenimiento del inventario, de modo que, con el tiempo, tengas una vista coherente de todos los elementos del entorno en cualquier momento. Para obtener información sobre cómo compilar un inventario de tus cargas de trabajo, consulta Migration Center: Inicia un descubrimiento de activos .
Ejemplo de un inventario de cargas de trabajo
Este ejemplo es un inventario de un entorno compatible con una app de comercio electrónico. El inventario incluye cargas de trabajo, dependencias, servicios que admiten varias cargas de trabajo y dispositivos de hardware.
Cargas de trabajo
Para cada carga de trabajo en el entorno, la siguiente tabla destaca las tecnologías más importantes, su procedimiento de implementación y otros requisitos.
Nombre | Ubicación del código fuente | Tecnologías | Procedimiento de implementación | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
---|---|---|---|---|---|---|
Sitio web de marketing | Repositorio corporativo | Frontend de Angular | Automático | El departamento legal debe validar el contenido | Servicio de almacenamiento en caché | 5 núcleos de CPU 8 GB de RAM |
Oficina administrativa | Repositorio corporativo | Backend de Java, frontend de Angular | Automático | N/A | Base de datos SQL | 4 núcleos de CPU 4 GB de RAM |
Carga de trabajo de comercio electrónico | Carga de trabajo propietaria | Proveedor X Modelo Y Versión 1.2.0 |
Manual | Los datos del cliente deben estar dentro de la Unión Europea. | Base de datos SQL | 10 núcleos de CPU 32 GB de RAM |
Planificación de recursos empresariales (ERP) | Carga de trabajo propietaria | Proveedor Z, modelo C, versión 7.0 | Manual | N/A | Base de datos SQL | 10 núcleos de CPU 32 GB de RAM |
Microservicios sin estado | Repositorio corporativo | Java | Automático | N/A | Servicio de almacenamiento en caché | 4 núcleos de CPU 8 GB de RAM |
Dependencias
La siguiente tabla es un ejemplo de las dependencias de las cargas de trabajo enumeradas en el inventario. Estas dependencias son necesarias para que las cargas de trabajo funcionen de forma correcta.
Nombre | Tecnologías | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
---|---|---|---|---|
Base de datos SQL | PostgreSQL | Los datos del cliente deben estar dentro de la Unión Europea. | Sistema de archivo y copia de seguridad | 30 núcleos de CPU 512 GB de RAM |
Servicios con compatibilidad
En tu entorno, es posible que tengas servicios que admiten varias cargas de trabajo. En este ejemplo de comercio electrónico, existen los siguientes servicios:
Nombre | Tecnologías | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
---|---|---|---|---|
Repositorios de código fuente | Git | N/A | Sistema de archivo y copia de seguridad | 2 núcleos de CPU 4 GB de RAM |
Sistema de archivo y copia de seguridad | Proveedor G, modelo H, versión 2.3.0 | Por ley, se requiere almacenamiento a largo plazo para algunos elementos | N/A | 10 núcleos de CPU 8 GB de RAM |
Herramienta de CI | Jenkins | N/A | Repositorios de código fuente repositorio de artefactos sistema de archivo y copia de seguridad |
32 núcleos de CPU 128 GB de RAM |
Repositorio de artefactos | Proveedor A Modelo N Versión 5.0.0 |
N/A | Sistema de archivo y copia de seguridad | 4 núcleos de CPU 8 GB de RAM |
Servicio de procesamiento por lotes | Trabajos cron que se ejecutan dentro de la herramienta de CI | N/A | Herramienta de CI | 4 núcleos de CPU 8 GB de RAM |
Servicio de almacenamiento en caché | Memcached Redis |
N/A | N/A | 12 núcleos de CPU 50 GB de RAM |
Hardware
El entorno de ejemplo tiene las siguientes aplicaciones de hardware:
Nombre | Tecnologías | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
---|---|---|---|---|
Firewall | Proveedor H Modelo V |
N/A | N/A | N/A |
Instancias del servidor j | Proveedor K Modelo B |
Se debe dar de baja porque ya no es compatible | N/A | N/A |
Dispositivo NAS | Proveedor Y Modelo Z NFS iSCSI |
N/A | N/A | N/A |
Evalúa los procesos operativos y de implementación
Es fundamental comprender claramente cómo funcionan los procesos operativos y de implementación. Estas son una parte fundamental de las prácticas que preparan y mantienen tu entorno de producción y las cargas de trabajo que se ejecutan allí.
Tus procesos operativos y de implementación podrían compilar los artefactos que tus cargas de trabajo necesitan para funcionar. Por lo tanto, debes recopilar información sobre cada tipo de artefacto. Por ejemplo, un artefacto puede ser un paquete de sistema operativo, un paquete de implementación de aplicación, una imagen de sistema operativo, una imagen de contenedor o cualquier otro elemento.
Además del tipo de artefacto, considera cómo completas las siguientes tareas:
- Desarrolla tus cargas de trabajo. Evalúa los procesos que los equipos de desarrollo tienen establecidos para compilar tus cargas de trabajo. Por ejemplo, ¿cómo diseñan, codifican y prueban tus cargas de trabajo tus equipos de desarrollo?
- Genera los artefactos que implementes en tu entorno de origen. Para implementar tus cargas de trabajo en tu entorno de origen, es posible que generes artefactos implementables, como imágenes de contenedores o de sistemas operativos, o que personalices artefactos existentes, como imágenes de sistemas operativos de terceros, instalando y configurando software. La recopilación de información sobre cómo generas estos artefactos te ayuda a garantizar que los artefactos generados sean adecuados para la implementación en Google Cloud.
Almacena los artefactos. Si produces artefactos que almacenas en un registro de artefactos en tu entorno de origen, debes hacer que los artefactos estén disponibles en tu entorno de Google Cloud. Para ello, puedes emplear estrategias como las siguientes:
- Establece un canal de comunicación entre los entornos: Haz que los artefactos de tu entorno de origen sean accesibles desde el entorno de Google Cloud de destino.
- Refactoriza el proceso de compilación de artefactos: Completa una refactorización menor de tu entorno de origen para que puedas almacenar artefactos en el entorno de origen y en el de destino. Este enfoque admite tu migración compilando infraestructura como un repositorio de artefactos antes de que tengas que implementar procesos de compilación de artefactos en el entorno de Google Cloud de destino. Puedes implementar este enfoque directamente o basarte en el enfoque anterior de establecer un canal de comunicación primero.
Tener artefactos disponibles en los entornos de origen y de destino te permite enfocarte en la migración sin tener que implementar procesos de compilación de artefactos en el entorno de Google Cloud de destino como parte de la migración.
Escanea y firma el código. Como parte de los procesos de compilación de artefactos, es posible que uses el análisis de código para protegerte contra vulnerabilidades comunes y la exposición de red no deseada, y la firma de código para garantizar que solo se ejecute código de confianza en tus entornos.
Implementa artefactos en tu entorno de origen. Después de generar artefactos implementables, es posible que los implementes en tu entorno de origen. Te recomendamos que evalúes cada proceso de implementación. La evaluación ayuda a garantizar que tus procesos de implementación sean compatibles con Google Cloud. También te ayuda a comprender el esfuerzo que se necesitará para refactorizar los procesos con el tiempo. Por ejemplo, si tus procesos de implementación solo funcionan con tu entorno de origen, es posible que debas refactorizarlos para que se orienten a tu entorno de Google Cloud.
Incorpora la configuración del entorno de ejecución. Es posible que estés insertando una configuración del entorno de ejecución para clústeres, entornos de ejecución o implementaciones de cargas de trabajo específicos. La configuración puede inicializar variables de entorno y otros valores de configuración, como secretos, credenciales y claves. Para garantizar que los procesos de inserción de configuración del entorno de ejecución funcionen en Google Cloud, te recomendamos que evalúes cómo estás configurando las cargas de trabajo que se ejecutan en tu entorno de origen.
Registro, supervisión y generación de perfiles. Evalúa los procesos de registro, supervisión y generación de perfiles que tienes implementados para supervisar el estado de tu entorno de origen, las métricas de interés y cómo consumes los datos que proporcionan estos procesos.
Autenticación del clúster: Evalúa cómo te autenticas en tu entorno de origen.
Aprovisiona y configura tus recursos. Para preparar tu entorno de origen, es posible que hayas diseñado e implementado procesos que aprovisionen y configuren recursos. Por ejemplo, puedes usar Terraform junto con las herramientas de administración de configuración para aprovisionar y configurar recursos en tu entorno de origen.
Evalúa tu infraestructura
Después de evaluar los procesos operativos y de implementación, te recomendamos que evalúes la infraestructura que admite tus cargas de trabajo en el entorno de origen.
Para evaluar esa infraestructura, considera lo siguiente:
- Cómo organizaste los recursos en tu entorno de origen Por ejemplo, algunos entornos admiten una separación lógica entre los recursos mediante construcciones que aíslan grupos de recursos entre sí, como organizaciones, proyectos y espacios de nombres.
- Cómo conectaste tu entorno a otros entornos, como los entornos locales y otros proveedores de servicios en la nube
Categoriza tus cargas de trabajo
Después de completar el inventario, debes organizar las cargas de trabajo en diferentes categorías. Esta categorización puede ayudarte a priorizar las cargas de trabajo para que se migren según la complejidad y el riesgo de trasladarlas a la nube.
Una matriz de catálogo debe tener una dimensión para cada criterio de evaluación que consideres en el entorno. Elige un conjunto de criterios que cubra todos los requisitos de tu entorno, incluidos los recursos del sistema que necesita cada carga de trabajo. Por ejemplo, es posible que te interese saber si una carga de trabajo tiene dependencias, o si es sin estado o con estado. Cuando diseñes la matriz de catálogo, considera que para cada criterio que agregues, se agrega otra dimensión que representar. La matriz resultante puede ser difícil de visualizar. Una posible solución a este problema podría ser usar varias matrices más pequeñas, en lugar de una sola y compleja.
Además, junto a cada carga de trabajo, debes agregar un indicador de la complejidad de migración. Este indicador calcula la calificación de dificultad para migrar cada carga de trabajo. El nivel de detalle de este indicador depende de tu entorno. Para un ejemplo básico, puedes tener tres categorías: fáciles de migrar, difíciles de migrar o que no se pueden migrar. Para completar esta actividad, necesitas contar con expertos que calculen la complejidad de migración de cada elemento del inventario. Los factores de esta complejidad de migración son únicos en cada empresa.
Cuando el catálogo esté completo, también podrás crear imágenes y gráficos que te ayuden a ti y a tu equipo a evaluar las métricas de interés con rapidez. Por ejemplo, dibuja un gráfico que destaque cuántos componentes tienen dependencias o la dificultad de migración de cada componente.
Para obtener información sobre cómo compilar un inventario de tus cargas de trabajo, consulta Migration Center: Inicia un descubrimiento de activos .
Ejemplo de un catálogo de cargas de trabajo
En este ejemplo, se usan los siguientes criterios de evaluación, uno para cada eje de la matriz:
- Qué tan importante es una carga de trabajo para la empresa
- Si una carga de trabajo tiene dependencias o si es una dependencia para otras cargas de trabajo
- Es el tiempo de inactividad máximo permitido para la carga de trabajo.
- Qué tan difícil es migrar una carga de trabajo
Importancia para la empresa | No tiene dependencias ni dependientes | Tiene dependencias o dependientes | Tiempo de inactividad máximo permitido | Dificultad |
---|---|---|---|---|
Elementos esenciales | Microservicios sin estado | 2 minutos | Fácil | |
ERP | 24 horas | Difícil | ||
Carga de trabajo de comercio electrónico | No hay tiempo de inactividad | Difícil | ||
Firewall de hardware | No hay tiempo de inactividad | No se puede mover | ||
Base de datos SQL | 10 minutos | Fácil | ||
Repositorios de código fuente | 12 horas | Fácil | ||
Elementos no esenciales | Sitio web de marketing | 2 horas | Fácil | |
Copias de seguridad y archivo | 24 horas | Fácil | ||
Servicio de procesamiento por lotes | 48 horas | Fácil | ||
Servicio de almacenamiento en caché | 30 minutos | Fácil | ||
Oficina administrativa | 48 horas | Difícil | ||
Herramienta de CI | 24 horas | Fácil | ||
Repositorio de artefactos | 30 minutos | Fácil |
Para ayudarte a visualizar los resultados en el catálogo, puedes crear imágenes y gráficos. En el siguiente gráfico, se destaca la dificultad de la migración:
En el gráfico anterior, la mayoría de las cargas de trabajo son fáciles de mover, tres de ellas son difíciles de mover y una de ellas no se puede mover.
Capacita al personal de tu organización sobre Google Cloud
Para aprovechar al máximo Google Cloud, los miembros de tu organización deben comenzar a aprender sobre los servicios, los productos y las tecnologías que la empresa puede usar en Google Cloud. El personal puede comenzar con el uso de cuentas de prueba gratuita de Google Cloud que contengan créditos para ayudarlos a experimentar y aprender con experiencias prácticas. La creación de un entorno gratuito destinado a las pruebas y el aprendizaje es fundamental para la experiencia de aprendizaje del personal.
Tienes varias opciones de entrenamiento:
- Recursos públicos y abiertos: Comienza a aprender sobre Google Cloud con labs prácticos, series de videos, seminarios en línea de Cloud OnAir y eventos de capacitación de Cloud OnBoard.
- Cursos detallados: si deseas comprender mejor cómo funciona Google Cloud, puedes asistir a los cursos a pedido de Google Cloud Skills Boost o a las especializaciones de capacitación de Google Cloud dictadas por Coursera, opciones a las que puedes asistir en línea a tu propio ritmo, o bien puedes optar por una capacitación presencial a cargo de nuestros socios de capacitación autorizados en todo el mundo. Estos cursos suelen durar entre uno y varios días.
- Rutas de aprendizaje basadas en la función: Puedes capacitar a tus ingenieros según su función en la organización. Por ejemplo, puedes capacitar a los desarrolladores de cargas de trabajo o a los operadores de infraestructura para que aprendan cómo usar mejor los servicios de Google Cloud.
También puedes certify el conocimiento sobre Google Cloud de tus ingenieros con diferentes certificaciones y en diferentes niveles:
- Certificaciones de asociado: se trata de un punto de partida para aquellos nuevos en Google Cloud que puede abrir las puertas a certificaciones profesionales, como la certificación Associate Cloud Engineer.
- Certificaciones profesionales: si deseas evaluar las habilidades avanzadas de diseño e implementación de Google Cloud obtenidas durante años de experiencia, puedes obtener la certificación Professional Cloud Architect o Professional Data Engineer.
- Certificaciones de Google Workspace: puedes demostrar tus habilidades de colaboración mediante las herramientas de Google Workspace con una certificación de Google Workspace.
- Certificaciones de Apigee: con la certificación de ingeniero certificado de API de Apigee, puedes demostrar la capacidad de diseñar y desarrollar API sólidas, seguras y escalables.
- Certificaciones de desarrolladores de Google: puedes demostrar tus habilidades de desarrollo con las certificaciones Associate Android Developer (se está actualizando esta certificación) y Mobile Web Specialist.
Además de la capacitación y la certificación, una de las mejores formas de adquirir experiencia con Google Cloud es comenzar a usar el producto para crear pruebas de concepto empresariales.
Experimenta y diseña pruebas de concepto
Para mostrar el valor y la eficacia de Google Cloud, considera diseñar y desarrollar una o más pruebas de concepto (PoC) para cada categoría de carga de trabajo en tu catálogo. La experimentación y las pruebas te permiten validar las suposiciones y demostrar el valor de la nube a los líderes empresariales.
Como mínimo, tu PoC debe incluir lo siguiente:
- Una lista completa de los casos de uso que admiten tus cargas de trabajo, incluidos los casos poco comunes y los casos excepcionales
- Todos los requisitos para cada caso de uso, como los requisitos de rendimiento, escalabilidad y coherencia, los mecanismos de conmutación por error y los requisitos de red
- Una posible lista de tecnologías y productos que deseas investigar y probar
Debes diseñar las PoC y los experimentos con el fin de validar todos los casos de uso de la lista. Cada experimento debe tener un contexto de validez preciso, un alcance, resultados esperados y un impacto comercial medible.
Por ejemplo, si una de tus cargas de trabajo vinculadas a la CPU necesita escalar con rapidez para satisfacer los aumentos de demanda, puedes ejecutar un experimento a fin de verificar que una zona pueda crear muchos núcleos de CPU virtuales y el tiempo lleva hacerlo. Si experimentas un valor agregado significativo, como la reducción del tiempo de escalamiento de la carga de trabajo nueva en un 95% en comparación con tu entorno actual, esto puede demostrar el valor empresarial instantáneo.
Si te interesa evaluar cómo se compara el rendimiento de tus bases de datos locales con Cloud SQL, Spanner, Firestore o Bigtable, puedes implementar una PoC en la que la misma lógica empresarial use bases de datos diferentes. Esta PoC te brinda una oportunidad de bajo riesgo para identificar la solución de base de datos administrada que resulta adecuada para tu carga de trabajo con varias comparativas y costos operativos.
Si deseas evaluar el rendimiento del proceso de aprovisionamiento de VM en Google Cloud, puedes usar una herramienta de terceros, como PerfKit Benchmarker, y comparar a Google Cloud con otros proveedores de servicios en la nube. Puedes medir el tiempo de extremo a extremo para aprovisionar recursos en la nube, además de generar informes sobre métricas estándar de rendimiento máximo, incluida la latencia, la capacidad de procesamiento y el tiempo para completarse. Por ejemplo, puede interesarte cuánto tiempo y esfuerzo lleva aprovisionar muchos clústeres de Kubernetes. PerfKit Benchmarker es un esfuerzo de la comunidad de código abierto que involucra a más de 500 participantes, como investigadores, instituciones académicas y empresas, incluida Google.
Calcula el costo total de propiedad
Cuando tienes una vista clara de los recursos que necesitas en el entorno nuevo, puedes crear un modelo de costo total de propiedad que te permita comparar los costos en Google Cloud con los de tu entorno actual.
Cuando compiles este modelo de costos, deberías considerar no solo los costos de hardware y software, sino también todos los costos operativos que conlleva ejecutar tu propio centro de datos, como la energía, el enfriamiento, el mantenimiento y otros servicios de asistencia. Ten en cuenta que, por lo general, también es más fácil reducir costos gracias a la escalabilidad elástica de los recursos de Google Cloud, en comparación con un centro de datos local más rígido.
Un costo que se suele omitir cuando se considera la migración a la nube es el uso de una red en la nube. En un centro de datos, la adquisición de infraestructura de red, como interruptores y routers, y la ejecución del cableado de red apropiado son costos de una sola vez que te permiten usar toda la capacidad de la red. En un entorno de nube, existen muchas formas en las que se te puede facturar por el uso de red. En el caso de las cargas de trabajo que requieren una gran cantidad de datos o aquellas que generan mucho tráfico de red, es posible que debas considerar arquitecturas y flujos de red nuevos para reducir los costos de red en la nube.
Google Cloud también ofrece una amplia gama de opciones para el escalamiento inteligente de recursos y costos. Por ejemplo, en Compute Engine puedes ajustar el tamaño con Migrate for Compute Engine durante la migración o una vez que las VM ya se estén ejecutando, o bien puedes crear grupos de instancias con ajuste de escala automático. Estas opciones pueden tener un gran impacto en los costos de ejecución de los servicios y deben explorarse para calcular el costo total de propiedad (TCO).
Para calcular el costo total de los recursos de Google Cloud, puedes usar la calculadora de precios.
Elige la estrategia de migración para tus cargas de trabajo
Para cada carga de trabajo que se migrará, evalúa y selecciona una estrategia de migración que mejor se adapte a su caso de uso. Por ejemplo, tus cargas de trabajo podrían tener las siguientes condiciones:
- No toleran ningún tiempo de inactividad ni pérdida de datos, como las cargas de trabajo críticas. Para estas cargas de trabajo, puedes elegir estrategias de migración con un tiempo de inactividad cero o casi cero.
- Toleran los tiempos de inactividad, como las cargas de trabajo secundarias o de backend. Para estas cargas de trabajo, puedes elegir estrategias de migración que requieran un tiempo de inactividad.
Cuando elijas estrategias de migración, ten en cuenta que las estrategias de migración con cero tiempo de inactividad y con tiempo de inactividad cercano a cero suelen ser más costosas y complejas de diseñar e implementar que las estrategias de migración que requieren un tiempo de inactividad.
Elige tus herramientas de migración
Después de elegir una estrategia de migración para tus cargas de trabajo, revisa y decide las herramientas de migración.
Hay muchas herramientas de migración disponibles, cada una optimizada para ciertos casos de uso de migración. Los casos de uso pueden incluir lo siguiente:
- Estrategia de migración
- Entornos de origen y de destino
- Tamaño de los datos y la carga de trabajo
- Frecuencia de los cambios en los datos y las cargas de trabajo
- Disponibilidad para usar servicios administrados para la migración
Para garantizar una migración y una transición sin problemas, puedes usar patrones de implementación de aplicaciones, organización de la infraestructura y aplicaciones de migración personalizadas. Sin embargo, las herramientas especializadas llamadas servicios de migración administrada pueden facilitar el proceso de mover datos, cargas de trabajo o incluso infraestructuras completas de un entorno a otro. Con estas funciones, encapsulan la lógica compleja de la migración y ofrecen capacidades de supervisión de la migración.
Define el plan y el cronograma de migración
Ahora que tienes una vista exhaustiva de tu entorno actual, debes completar el plan de migración de la siguiente manera:
- Agrupa las cargas de trabajo y los datos que se migrarán en lotes (también llamados sprints en algunos contextos).
- Elige el orden en el que deseas migrar los lotes.
- Elegir el orden en el que deseas migrar las cargas de trabajo dentro de cada lote
Como parte de tu plan de migración, te recomendamos que también generes los siguientes documentos:
- Documento de diseño técnico
- Matriz RACI
- Cronograma (como un plan de T menos)
A medida que adquieras experiencia con Google Cloud, avances con la migración y comprendas tu entorno, puedes hacer lo siguiente:
- Define mejor la agrupación de cargas de trabajo y datos que se migrarán.
- Aumenta el tamaño de los lotes de migración.
- Actualiza el orden en que migras los lotes y las cargas de trabajo dentro de los lotes.
- Actualiza la composición de los lotes.
Para agrupar las cargas de trabajo y los datos que se migrarán por lotes y definir el orden de migración, debes evaluar tus cargas de trabajo en función de varios criterios, como los siguientes:
- Valor empresarial de la carga de trabajo
- Si la carga de trabajo se implementa o ejecuta de manera única en comparación con el resto de la infraestructura
- Los equipos responsables del desarrollo, la implementación y las operaciones de la carga de trabajo.
- La cantidad, el tipo y el alcance de las dependencias de la carga de trabajo.
- El esfuerzo de refactorización para que la carga de trabajo funcione en el nuevo entorno.
- Los requisitos de cumplimiento y licencias de la carga de trabajo.
- Los requisitos de disponibilidad y confiabilidad de la carga de trabajo.
Las cargas de trabajo que debes migrar primero son las que permiten que tus equipos desarrollen sus conocimientos y experiencia en Google Cloud. Una mayor exposición en la nube y una experiencia más profunda del equipo pueden reducir el riesgo de complicaciones durante la fase de migración y agilizar las migraciones posteriores. Por este motivo, es fundamental elegir cuáles serán las apps que se migrarán primero de forma adecuada para realizar una migración exitosa.
Valor empresarial
Elegir una carga de trabajo que no sea fundamental para la empresa protege tu línea de negocio principal y disminuye el impacto en la empresa de los riesgos y errores no descubiertos mientras el equipo aprende sobre tecnologías en la nube. Por ejemplo, si eliges el componente en el que la lógica de transacciones financieras principales de la carga de trabajo de comercio electrónico se implementa como una app que se migrará primero, cualquier error durante la migración podría causar un impacto en la línea de negocio principal. Una mejor opción es la base de datos SQL que respalda las cargas de trabajo o, mejor aún, la base de datos de etapa de pruebas.
Debes evitar las cargas de trabajo que se usan con poca frecuencia. Por ejemplo, si eliges una carga de trabajo que una cantidad reducida de usuarios usa unas pocas veces al año, si bien será una migración de bajo riesgo, no aumentará la velocidad de la migración, y puede ser difícil detectar los problemas y responder a ellos.
Casos extremos
También debes evitar los casos extremos, de modo que puedas descubrir patrones que puedas aplicar a otras cargas de trabajo que se migrarán. Un objetivo principal a la hora de seleccionar la primera carga de trabajo que se migrará es adquirir experiencia con patrones comunes en tu organización para que puedas crear una base de conocimiento. Puedes aplicar lo que aprendiste con estas primeras cargas de trabajo migradas cuando migres otras cargas de trabajo más adelante.
Por ejemplo, si la mayoría de tus cargas de trabajo están diseñadas según una metodología de desarrollo basado en pruebas y se desarrollan mediante el lenguaje de programación Python, elegir una carga de trabajo con poca cobertura de prueba y desarrollada con el lenguaje de programación Java no te permite descubrir ningún patrón que puedas aplicar cuando migres las cargas de trabajo de Python.
Equipos
Cuando elijas las cargas de trabajo que se migrarán primero, presta atención a los equipos responsables de cada carga de trabajo. El equipo responsable de una carga de trabajo que se migrará primero debe estar muy motivado y ansioso por probar Google Cloud y sus servicios. Además, el liderazgo empresarial debe tener objetivos claros para los equipos de cargas de trabajo que se migrarán primero y trabajar de manera activa a fin de apoyarlos y ayudarlos durante el proceso.
Por ejemplo, un equipo de alto rendimiento que se sienta en la oficina principal con un historial comprobado de implementación de prácticas modernas de desarrollo como DevOps y disciplinas como la ingeniería de confiabilidad de sitios puede ser un buen candidato. Si además tienen patrocinadores de liderazgo vertical y objetivos claros para cada migración de cargas de trabajo, pueden ser un excelente candidato.
Dependencias
Además, debes enfocarte en las cargas de trabajo que tienen la menor cantidad de dependencias, ya sea de otras cargas de trabajo o servicios. La migración de una carga de trabajo sin dependencias es más fácil cuando tienes experiencia limitada con Google Cloud.
Si tienes que elegir cargas de trabajo con dependencias de otros componentes, elige las que estén vinculadas con acoplamiento bajo a sus dependencias. Si una carga de trabajo ya está diseñada para la posible falta de disponibilidad de sus dependencias, esto puede reducir los inconvenientes durante la migración de la carga de trabajo al entorno de destino. Por ejemplo, los candidatos con acoplamiento bajo son cargas de trabajo que se comunican mediante un agente de mensajes, que funcionan sin conexión o que están diseñadas para tolerar la falta de disponibilidad del resto de la infraestructura.
Aunque existen estrategias para migrar datos de cargas de trabajo con estado, una carga de trabajo sin estado rara vez requiere que se migren datos. Migrar una carga de trabajo sin estado puede ser más fácil porque no necesitas preocuparte por una fase transitoria en la que los datos se encuentran de forma parcial en el entorno actual y en el entorno de destino. Por ejemplo, los microservicios sin estado son buenos candidatos para migrarse primero, ya que no dependen de datos locales con estado.
Refactoriza el esfuerzo
Una carga de trabajo que se migra primero debe requerir una cantidad mínima de refactorización, de modo que puedas enfocarte en la migración y en Google Cloud, en lugar de destinar un gran esfuerzo a los cambios en el código y la configuración de tus cargas de trabajo. La refactorización debe enfocarse en los cambios necesarios que permiten que las cargas de trabajo se ejecuten en el entorno de destino, en lugar de enfocarse en la modernización y la optimización de las cargas de trabajo, aspectos que se abordan en las fases de migración posteriores.
Por ejemplo, una carga de trabajo que solo requiere cambios de configuración es una buena candidata para migrarse primero, ya que no tienes que implementar ningún cambio en la base de código y puedes usar los artefactos existentes.
Licencias y cumplimiento
Las licencias también cumplen una función en la elección de las cargas de trabajo que se migrarán primero, ya que algunas de ellas pueden tener licencias con términos que afectan la migración. Por ejemplo, algunas licencias prohíben de forma explícita la ejecución de cargas de trabajo en un entorno de nube.
Cuando examines los términos de las licencias, no olvides los requisitos de cumplimiento, ya que puede que tengas requisitos de usuario único para algunas de tus cargas de trabajo. Por estos motivos, debes elegir las cargas de trabajo que tengan la menor cantidad de restricciones de licencias y cumplimiento para migrarlas primero.
Por ejemplo, es posible que tus clientes tengan el derecho legal de elegir en qué región almacenas sus datos, o puede que los datos de los clientes estén limitados a una región en particular.
Disponibilidad y confiabilidad
Las cargas de trabajo que resultan adecuadas para migrarse primero son aquellas que pueden permitir un período de migración de sistemas. Si eliges una carga de trabajo que tiene requisitos de disponibilidad estrictos, debes implementar una estrategia de migración de datos sin tiempo de inactividad, como Y (escritura y lectura), o bien debes desarrollar un microservicio de acceso a datos. Si bien este enfoque es posible, distrae a los equipos del propósito de obtener la experiencia necesaria con Google Cloud, ya que deben dedicar tiempo a implementar esas estrategias.
Por ejemplo, los requisitos de disponibilidad de un motor de procesamiento por lotes pueden tolerar un tiempo de inactividad más prolongado que la carga de trabajo orientada al cliente de tu sitio de comercio electrónico en la que los usuarios finalizan sus transacciones.
Valida tu plan de migración
Antes de tomar medidas para iniciar tu plan de migración, te recomendamos que validates su viabilidad. Para obtener más información, consulta Prácticas recomendadas para validar un plan de migración.
¿Qué sigue?
- Obtén información sobre cómo planificar la migración y construir tu base en Google Cloud.
- Obtén información sobre cuándo encontrar ayuda para tus migraciones.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.
Colaboradores
Autor: Marco Ferrari | Arquitecto de soluciones de nube