Migra a Google Cloud: evalúa y descubre tus cargas de trabajo

Last reviewed 2023-06-07 UTC

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 apps 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 apps y 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:

En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

La fase de evaluación es la primera fase de tu migración a Google Cloud, en la que determinas los requisitos y las dependencias para migrar las apps a Google Cloud.

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.

La fase de evaluación es fundamental para el éxito de la migración. Debes obtener un conocimiento profundo sobre las apps 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.

En esta fase, debes realizar los siguientes pasos:

  1. Crea un inventario completo de tus apps.
  2. Cataloga tus aplicaciones según sus propiedades y dependencias.
  3. Capacita y educa a tus equipos en Google Cloud.
  4. Compila un experimento y prueba de concepto en Google Cloud.
  5. Calcula el costo total de propiedad (TCO) del entorno de destino.
  6. Elige las cargas de trabajo que deseas migrar primero.

Crea un inventario de tus apps

Para determinar el alcance de la migración, primero debes saber cuántos elementos, como apps 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 apps, sino que debe contener lo siguiente:

  • Dependencias de cada app, como bases de datos, agentes de mensajes, sistemas de almacenamiento de configuración y otros componentes
  • Servicios compatibles con la infraestructura de tu app, como repositorios de origen, herramientas de integración continua (CI) 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 deseas exponer 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 app 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 apps en un proceso de implementación automatizado o manual.

Cómo crear tu inventario

Existen diferentes maneras de crear un inventario de apps. 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 se basó en suposiciones incorrectas.

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 apps, consulta Centro de migraciones: Inicia un descubrimiento de activos .

Google también se asocia con varias empresas para ayudarte en tu proceso de migración. Para obtener más información, consulta Busca ayuda.

Ejemplo de un inventario de apps

Este ejemplo es un inventario de un entorno compatible con una app de comercio electrónico. El inventario incluye apps, dependencias, servicios que admiten varias apps y dispositivos de hardware.

Apps

Para cada app 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 Automatizado 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 Automatizado N/A Base de datos SQL 4 núcleos de CPU
4 GB de RAM
App de comercio electrónico App privada 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) App privada 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 Automatizado 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 apps enumeradas en el inventario. Estas dependencias son necesarias para que las apps 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 apps. 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

Después de compilar los inventarios de tus cargas de trabajo, te recomendamos que evalúes tus procesos operativos y de implementación. Los procesos operativos y de implementación son una parte fundamental de las prácticas que preparan y mantienen el entorno de producción y las cargas de trabajo que se ejecutan allí.

Estos procesos pueden aprovisionar la infraestructura necesaria y compilar los artefactos que necesitan tus cargas de trabajo, como los paquetes del sistema operativo, los paquetes de implementación de cargas de trabajo, las imágenes del sistema operativo y las imágenes de contenedor. Para cada carga de trabajo, recopila información sobre la cantidad de artefactos que necesita, el tipo de cada artefacto, cómo los compilas, cómo y dónde los almacenas y cómo insertas la configuración del entorno de ejecución para que estos artefactos se puedan volver a usar en todos los entornos.

Después de evaluar los procesos operativos y de implementación, también te recomendamos evaluar cómo estos procesos pueden facilitar la migración a Google Cloud y cómo te ayudan a reducir el alcance y el riesgo de la migración. Por ejemplo, puedes refactorizar tus procesos de compilación de artefactos para almacenar artefactos en tu entorno de origen y en Google Cloud mientras se realiza la migración. Tener artefactos en ambos entornos te permite enfocarte en migrar las cargas de trabajo y los datos del entorno de origen a Google Cloud sin tener que implementar procesos de compilación de artefactos en el entorno de Google Cloud de destino desde el comienzo del proceso de migración.

Evalúa la 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:

  • Los procesos que adoptaste para aprovisionar los recursos que necesita la carga de trabajo, como la infraestructura como código.
  • 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 y proyectos.
  • Cómo conectaste el entorno a otros entornos, como entornos locales y otros proveedores de servicios en la nube.

Categoriza tus apps

Después de completar el inventario, debes organizar las apps en diferentes categorías. Esta categorización puede ayudarte a priorizar las apps 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 app. Por ejemplo, es posible que te interese saber si una app 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 app, debes agregar un indicador de la complejidad de migración. Este indicador calcula la calificación de dificultad para migrar cada app. El nivel de detalle de este indicador depende de tu entorno. Para un ejemplo básico, puedes tener tres categorías de apps: 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 apps, consulta Centro de migraciones: Inicia un descubrimiento de activos .

Ejemplo de un catálogo de apps

En este ejemplo, se usan los siguientes criterios de evaluación, uno para cada eje de la matriz:

  1. Qué tan importante es una app para la empresa
  2. Si una app tiene dependencias o si es una dependencia para otras apps
  3. Tiempo de inactividad máximo permitido para la app.
  4. Qué tan difícil es migrar una app
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 Las 24 horas Difícil
App 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 Las 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 Las 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:

Gráfico que muestra la dificultad asociada al traslado de apps a Google Cloud.

En el gráfico anterior, la mayoría de las apps son fáciles de mover, mientras que solo tres 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:

  1. 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.
  2. 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.
  3. 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 apps o a los operadores de infraestructura para que aprendan cómo usar mejor los servicios de Google Cloud.

También puedes certificar el conocimiento sobre Google Cloud de tus ingenieros con diferentes certificaciones y en diferentes niveles:

  1. 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.
  2. 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.
  3. Certificaciones de Google Workspace: puedes demostrar tus habilidades de colaboración mediante las herramientas de Google Workspace con una certificación de Google Workspace.
  4. 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.
  5. 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 app 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 apps, incluidos los casos poco comunes y los casos excepcionales
  • Todos los requisitos para cada caso de uso, como los requisitos de rendimiento y escalabilidad, las garantías de coherencia esperadas, 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 apps 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 app 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 apps 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 las apps que se migrarán primero

Ahora que tienes una vista exhaustiva de tu entorno actual, debes completar el plan de migración mediante la elección del orden inicial en el que deseas migrar las apps. Puedes definir mejor este orden durante la migración cuando adquieras experiencia con Google Cloud y comprendas el entorno y las apps.

Las apps 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. Puedes elegir una app o colocar muchas apps de la matriz de aplicaciones en la lista de las apps que se migrarán primero.

La tarea de identificar qué apps se migrarán primero es compleja, por lo que, a continuación, incluimos algunos criterios que te guiarán:

  • El valor empresarial de la app
  • Si la app 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 app
  • La cantidad, el tipo y el alcance de las dependencias de la app
  • El esfuerzo de refactorización para que la app funcione en el nuevo entorno
  • Los requisitos de cumplimiento y licencias de la app
  • Los requisitos de disponibilidad y confiabilidad de la app

Valor empresarial

Elegir una app 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 app 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 apps o, mejor aún, la base de datos de etapa de pruebas.

Debes evitar las apps con poco uso. Por ejemplo, si eliges una app 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 apps que se migrarán. Un objetivo principal a la hora de seleccionar la primera app que se migrará es adquirir experiencia con patrones comunes en tu organización para que puedas crear una base de conocimiento. Puedes volver a aplicar lo que aprendiste con estas primeras apps migradas cuando migres otras apps más adelante.

Por ejemplo, si la mayoría de tus apps 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 app 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 apps de Python.

Equipos

Cuando elijas las apps que se migrarán primero, presta atención a los equipos responsables de cada app. El equipo responsable una app 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 apps 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 apps, pueden ser un excelente candidato.

Dependencias

Además, debes enfocarte en las apps que tienen la menor cantidad de dependencias, ya sea de otras apps o servicios. La migración de una app sin dependencias es más fácil cuando tienes experiencia limitada con Google Cloud.

Si tienes que elegir apps con dependencias de otros componentes, elige las que estén vinculadas de forma flexible a sus dependencias. Si una app ya está diseñada para la posible falta de disponibilidad de sus dependencias, esto puede reducir los inconvenientes durante la migración de la app al entorno de destino. Por ejemplo, los candidatos con acoplamiento bajo son apps 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 apps con estado, una app sin estado casi nunca requiere que se migren sus datos. Migrar una app 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.

Esfuerzo de refactorización

Una app 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 apps. La refactorización debe enfocarse en los cambios necesarios que permiten que las apps se ejecuten en el entorno de destino, en lugar de enfocarse en la modernización y la optimización de las apps, aspectos que se abordan en las fases de migración posteriores.

Por ejemplo, una app 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 apps que se migrarán primero, ya que algunas de las apps 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 apps 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 apps. Por estos motivos, debes elegir las apps 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 apps que resultan adecuadas para migrarse primero son aquellas que pueden permitir un período de migración de sistemas. Si eliges una app 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 app orientada al cliente de tu sitio de comercio electrónico en la que los usuarios finalizan sus transacciones.

¿Qué sigue?