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, así como asignar sus dependencias, puede ayudarte a identificar qué necesitas migrar y en qué orden. Cuando planifiques y diseñes una migración a Google Cloud, primero debes conocer a fondo tu entorno actual y las cargas de trabajo que vas a migrar.
Este documento forma parte de la siguiente serie de artículos sobre la migración aGoogle Cloud:
- Migrar a Google Cloud: primeros pasos
- Migración a Google Cloud: evaluar e identificar cargas de trabajo (este documento)
- Migrar a Google Cloud: planificar y sentar las bases
- Migrar a: Google Cloudtransferir conjuntos de datos grandes
- Migrar a: desplegar tus cargas de trabajo Google Cloud
- Migrar a: Google Cloudmigrar de los despliegues manuales a los automatizados y en contenedores
- Migrar a: Google Cloudoptimizar el entorno
- Migrar a: prácticas recomendadas para validar un plan de migración Google Cloud
- Migrar a Google Cloud: minimizar los costes
En el siguiente diagrama se muestra el recorrido de tu migración.
Este documento es útil si tienes previsto migrar desde un entorno local, un entorno de alojamiento privado u otro proveedor de la nube, o si estás evaluando la oportunidad de migrar y quieres saber cómo sería la fase de evaluación.
En la fase de evaluación, determinas los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.
La fase de evaluación es fundamental para que la migración se lleve a cabo correctamente. Debes conocer en profundidad las cargas de trabajo que quieres migrar, sus requisitos, sus dependencias y tu entorno actual. Para planificar y llevar a cabo una migración correctamente, debes conocer tu punto de partida. Google Cloud
La fase de evaluación consta de las siguientes tareas:
- Crea un inventario completo de tus cargas de trabajo.
- Cataloga tus cargas de trabajo según sus propiedades y dependencias.
- Forma y educa a tus equipos sobre Google Cloud.
- Crea experimentos y pruebas de concepto en Google Cloud.
- Calcula el coste total de propiedad (CTP) del entorno de destino.
- Elige la estrategia de migración de tus cargas de trabajo.
- Elige las herramientas de migración.
- Define el plan y la cronología de la migración.
- Valida tu plan de migración.
Crea un inventario de tus cargas de trabajo
Para definir el alcance de la migración, primero debes saber cuántos elementos, como cargas de trabajo y dispositivos de hardware, hay en tu entorno actual, así como sus dependencias. Crear el inventario es una tarea compleja que requiere un esfuerzo considerable, sobre todo si no tienes ningún sistema de catalogación automática. Para tener un inventario completo, debes usar la experiencia de los equipos responsables del diseño, la implementación y el funcionamiento de cada carga de trabajo de tu entorno actual, así como del propio entorno.
El inventario no debe limitarse solo a las cargas de trabajo, sino que debe contener al menos lo siguiente:
- Las dependencias de cada carga de trabajo, como bases de datos, intermediarios de mensajes, sistemas de almacenamiento de configuración y otros componentes.
- Servicios que admiten la infraestructura de tu carga de trabajo, como repositorios de origen, herramientas de integración y despliegue continuos (CI/CD) y repositorios de artefactos.
- Servidores, ya sean virtuales o físicos, y entornos de tiempo de ejecución.
- Dispositivos físicos, como dispositivos de red, cortafuegos y otro hardware especializado.
Al compilar esta lista, también debe recoger información sobre cada elemento, como la siguiente:
- La ubicación del código fuente y si puedes modificarlo.
- Método de implementación de la carga de trabajo en un entorno de ejecución. Por ejemplo, si usas una canalización de implementación automatizada o manual.
- Restricciones de red o requisitos de seguridad.
- Requisitos de las direcciones IP.
- Cómo expones la carga de trabajo a los clientes.
- Requisitos de licencia de cualquier software o hardware.
- Cómo se autentica la carga de trabajo en tu sistema de gestión de identidades y accesos.
Por ejemplo, en el caso de cada dispositivo de hardware, debe conocer sus especificaciones detalladas, como el nombre, el proveedor, las tecnologías y las dependencias de otros elementos de su inventario. Por ejemplo:
- Nombre: dispositivo NAS
- Proveedor y modelo: proveedor Y, modelo Z
- Tecnologías: NFS, iSCSI
- Dependencias: conectividad de red con tramas Jumbo al hardware de computación de la VM.
Esta lista también debe incluir información no técnica, como los términos de licencia con los que puedes usar cada elemento y otros requisitos de cumplimiento. Aunque algunas licencias te permiten desplegar una carga de trabajo en un entorno de nube, otras prohíben explícitamente el despliegue en la nube. Algunas licencias se asignan en función del número de CPUs o sockets en uso, y estos conceptos pueden no ser aplicables cuando se ejecutan en tecnología en la nube. Es posible que algunos de tus datos tengan restricciones en cuanto a la región geográfica en la que se almacenan. Por último, algunas cargas de trabajo sensibles pueden requerir un único inquilino.
Además del inventario, es útil proporcionar ayudas para interpretar visualmente los datos que has recogido. Por ejemplo, puedes proporcionar un gráfico de dependencias y gráficos para destacar aspectos de interés, como la forma en que se distribuyen tus cargas de trabajo en un proceso de implementación automatizado o manual.
Cómo crear tu inventario
Hay varias formas de crear un inventario de cargas de trabajo. Aunque la forma más rápida de empezar es hacerlo manualmente, este método puede ser difícil en un entorno de producción grande. La información de los inventarios creados manualmente puede quedar obsoleta rápidamente y la migración resultante puede fallar porque no has confirmado el contenido de tus inventarios.
Crear el inventario no es una tarea puntual. Si tu entorno actual es muy dinámico, también deberías dedicar tiempo a automatizar la creación y el mantenimiento del inventario para que, con el tiempo, tengas una visión coherente de todos los elementos de tu entorno en cualquier momento. Para obtener información sobre cómo crear un inventario de tus cargas de trabajo, consulta Migration Center: Start an asset discovery (Migration Center: iniciar un descubrimiento de activos).
Ejemplo de inventario de cargas de trabajo
En este ejemplo se muestra un inventario de un entorno que admite una aplicación 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
En la siguiente tabla se destacan las tecnologías más importantes de cada carga de trabajo del entorno, 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 | Automatizada | El departamento jurídico debe validar el contenido | Servicio de almacenamiento en caché | 5 núcleos de CPU 8 GB de RAM |
| Actividades administrativas | Repositorio corporativo | Backend de Java y frontend de Angular | Automatizada | N/A | Base de datos SQL | CPU de 4 núcleos 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 de los clientes deben residir en 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 | Automatizada | 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 que se indican en el inventario. Estas dependencias son necesarias para que las cargas de trabajo funcionen correctamente.
| Nombre | Tecnologías | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
|---|---|---|---|---|
| Base de datos SQL | PostgreSQL | Los datos de los clientes deben residir en la Unión Europea | Sistema de copias de seguridad y archivado | 30 núcleos de CPU 512 GB de RAM |
Servicios compatibles
En tu entorno, puede que tengas servicios que admitan varias cargas de trabajo. En este ejemplo de comercio electrónico, se ofrecen los siguientes servicios:
| Nombre | Tecnologías | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
|---|---|---|---|---|
| Repositorios de código fuente | Git | N/A | Sistema de copias de seguridad y archivado | CPU de 2 núcleos 4 GB de RAM |
| Sistema de copias de seguridad y archivado | Proveedor G, modelo H, versión 2.3.0 | Por ley, algunos elementos deben almacenarse durante un periodo prolongado | 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 copias de seguridad y archivado |
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 copias de seguridad y archivado | 4 núcleos de CPU 8 GB de RAM |
| Servicio de procesamiento por lotes | Tareas cron que se ejecutan en 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 los siguientes dispositivos de hardware:
| Nombre | Tecnologías | Otros requisitos | Dependencias | Requisitos de recursos del sistema |
|---|---|---|---|---|
| Cortafuegos | Proveedor H Modelo V |
N/A | N/A | N/A |
| Instancias de Server j | Proveedor K Modelo B |
Se debe retirar 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 tus procesos de implementación y operativos
Es importante que tengas claro cómo funcionan tus procesos de implementación y operativos. Estos procesos 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 en él.
Tus procesos de implementación y operativos pueden crear los artefactos que necesitan tus cargas de trabajo para funcionar. Por lo tanto, debes recoger información sobre cada tipo de artefacto. Por ejemplo, un artefacto puede ser un paquete de sistema operativo, un paquete de despliegue de aplicaciones, una imagen de sistema operativo, una imagen de contenedor u otro elemento.
Además del tipo de artefacto, ten en cuenta cómo completas las siguientes tareas:
- Desarrolla tus cargas de trabajo. Evalúa los procesos que tienen los equipos de desarrollo para crear tus cargas de trabajo. Por ejemplo, ¿cómo diseñan, codifican y prueban tus equipos de desarrollo las cargas de trabajo?
- Genera los artefactos que vas a implementar en tu entorno de origen. Para implementar tus cargas de trabajo en el entorno de origen, puedes generar artefactos implementables, como imágenes de contenedor o imágenes de sistema operativo, o personalizar artefactos, como imágenes de sistema operativo de terceros, instalando y configurando software. Recopilar información sobre cómo generas estos artefactos te ayuda a asegurarte de que sean adecuados para implementarlos enGoogle Cloud.
Almacena los artefactos. Si produces artefactos que almacenas en un registro de artefactos de tu entorno de origen, debes hacer que estén disponibles en tu entorno de destino. 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 destino.Google Cloud
- Refactorizar el proceso de compilación de artefactos: completa una refactorización menor de tu entorno de origen para que puedas almacenar artefactos tanto en el entorno de origen como en el de destino. Este enfoque facilita la migración, ya que crea una infraestructura, como un repositorio de artefactos, antes de que tengas que implementar procesos de compilación de artefactos en el entorno de destino Google Cloud. Puedes implementar este enfoque directamente o basarte en el enfoque anterior de establecer primero un canal de comunicación.
Si los artefactos están disponibles tanto en el entorno de origen como en el de destino, puedes centrarte en la migración sin tener que implementar procesos de compilación de artefactos en el entorno de destino Google Cloud como parte de la migración.
Escanear y firmar código. Como parte de los procesos de compilación de artefactos, puedes usar el análisis de código para protegerte frente a vulnerabilidades comunes y exposiciones de red no deseadas, así como la firma de código para asegurarte de que solo se ejecute código de confianza en tus entornos.
Despliega 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 asegurar que tus procesos de implementación sean compatibles con Google Cloud. También te ayuda a entender el esfuerzo que será necesario para refactorizar los procesos. Por ejemplo, si tus procesos de implementación solo funcionan con tu entorno de origen, es posible que tengas que refactorizarlos para que se dirijan a tu entorno de Google Cloud .
Inyectar configuración de tiempo de ejecución. Puede que estés insertando una configuración de tiempo de ejecución para clústeres, entornos de tiempo 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 asegurarte de que los procesos de inyección de configuración de tiempo de ejecución funcionan en Google Cloud, te recomendamos que evalúes cómo configuras las cargas de trabajo que se ejecutan en tu entorno de origen.
Registro, monitorización y creación de perfiles. Evalúa los procesos de registro, monitorización y creación de perfiles que tienes implementados para monitorizar el estado de tu entorno de origen, las métricas de interés y cómo consumes los datos proporcionados por estos procesos.
Autenticación. 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 herramientas de gestión de la configuración para aprovisionar y configurar recursos en tu entorno de origen.
Evalúa tu infraestructura
Después de evaluar los procesos de implementación y operativos, le recomendamos que evalúe la infraestructura que admite sus cargas de trabajo en el entorno de origen.
Para evaluar esa infraestructura, ten en cuenta lo siguiente:
- Cómo has organizado los recursos en tu entorno de origen. Por ejemplo, algunos entornos admiten una separación lógica entre recursos mediante estructuras que aíslan grupos de recursos entre sí, como organizaciones, proyectos y espacios de nombres.
- Cómo has conectado tu entorno a otros entornos, como entornos locales y otros proveedores de servicios en la nube.
Categorizar las cargas de trabajo
Una vez que hayas completado el inventario, tendrás que organizar tus cargas de trabajo en diferentes categorías. Esta categorización puede ayudarte a priorizar las cargas de trabajo que vas a migrar en función de su complejidad y del riesgo que supone trasladarlas a la nube.
Una matriz de catálogo debe tener una dimensión por cada criterio de evaluación que esté considerando en su 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, puede que te interese saber si una carga de trabajo tiene alguna dependencia o si es sin estado o con estado. Cuando diseñes la matriz del catálogo, ten en cuenta que, por cada criterio que añadas, estarás añadiendo 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 matriz compleja.
Además, junto a cada carga de trabajo, debe añadir un indicador de complejidad de la migración. Este indicador estima la dificultad de migrar cada carga de trabajo. La granularidad de este indicador depende de tu entorno. Por ejemplo, puedes tener tres categorías: fácil de migrar, difícil de migrar o no se puede migrar. Para completar esta actividad, necesita expertos en cada elemento del inventario para estimar su complejidad de migración. Los factores que determinan la complejidad de esta migración son únicos para cada empresa.
Cuando el catálogo esté completo, también podrás crear elementos visuales y gráficos para ayudarte a ti y a tu equipo a evaluar rápidamente las métricas que os interesen. Por ejemplo, dibuja un gráfico que destaque cuántos componentes tienen dependencias o resalte la dificultad de migración de cada componente.
Para obtener información sobre cómo crear un inventario de tus cargas de trabajo, consulta Migration Center: Start an asset discovery (Migration Center: iniciar un descubrimiento de activos).
Ejemplo de catálogo de cargas de trabajo
En este ejemplo se utilizan los siguientes criterios de evaluación, uno por cada eje de la matriz:
- La importancia de una carga de trabajo para la empresa.
- Si una carga de trabajo tiene dependencias o es una dependencia de otras cargas de trabajo.
- Tiempo de inactividad máximo permitido para la carga de trabajo.
- La dificultad de migrar una carga de trabajo.
| Importancia para la empresa | No tiene dependencias ni elementos dependientes | Tiene dependencias o elementos dependientes | Tiempo de inactividad máximo permitido | Dificultad |
|---|---|---|---|---|
| Esencial | Microservicios sin estado | 2 minutos | Fácil | |
| ERP | 24 horas | Difícil | ||
| Carga de trabajo de comercio electrónico | Sin periodos inactivos | Difícil | ||
| Cortafuegos de hardware | Sin periodos inactivos | No se puede mover | ||
| Base de datos SQL | 10 minutos | Fácil | ||
| Repositorios de código fuente | 12 horas | Fácil | ||
| No es esencial | Sitio web de marketing | 2 horas | Fácil | |
| Copias de seguridad y archivado | 24 horas | Fácil | ||
| Servicio de procesamiento por lotes | 48 horas | Fácil | ||
| Servicio de almacenamiento en caché | 30 minutos | Fácil | ||
| Actividades administrativas | 48 horas | Difícil | ||
| Herramienta de CI | 24 horas | Fácil | ||
| Repositorio de artefactos | 30 minutos | Fácil |
Para ayudarte a visualizar los resultados del catálogo, puedes crear elementos visuales 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 migrar, tres de ellas son difíciles de migrar y una no se puede migrar.
Formar a tu organización sobre Google Cloud
Para aprovechar al máximo Google Cloud, tu organización debe empezar a familiarizarse con los servicios, los productos y las tecnologías que tu empresa puede usar en Google Cloud. Tu personal puede empezar con Google Cloud cuentas de prueba gratuitas que contienen créditos para ayudarles a experimentar y aprender. Crear un entorno gratuito para probar y aprender es fundamental para la experiencia de aprendizaje de tu personal.
Tienes varias opciones de entrenamiento:
- Recursos públicos y abiertos: puedes empezar a aprender conGoogle Cloud laboratorios prácticos, series de vídeos, seminarios web de Cloud OnAir y eventos de formación de Cloud OnBoard gratuitos.
- Cursos detallados: si quieres profundizar en el funcionamiento de Google Cloud , puedes asistir a los cursos bajo demanda de Acelerador de conocimientos de Google Cloud o a las Google Cloud especializaciones de formación de Coursera que puedes cursar online a tu ritmo o a la formación en clase que ofrecen nuestros partners de formación autorizados de todo el mundo. Estos cursos suelen durar entre uno y varios días.
- Planes de formación basados en roles: puedes formar a tus ingenieros en función del rol que desempeñen en tu organización. Por ejemplo, puedes formar a tus desarrolladores de cargas de trabajo o a tus operadores de infraestructura para que sepan cómo usar los servicios de Google Cloud de la mejor forma posible.
También puedes certify los conocimientos de tus ingenieros sobre Google Cloud con varias certificaciones de diferentes niveles:
- Certificaciones Associate: un punto de partida para los profesionales que estén iniciándose enGoogle Cloud , que puede abrirles las puertas a las certificaciones Professional, como la certificación Associate Cloud Engineer.
- Certificaciones Professional: si quieres evaluar tus conocimientos avanzados de diseño e implementación de Google Cloud tras años de experiencia, puedes obtener certificaciones como Professional Cloud Architect o Professional Data Engineer.
- Certificaciones de Google Workspace: puedes demostrar tus habilidades de colaboración con las herramientas de Google Workspace mediante una certificación de Google Workspace.
- Certificaciones de Apigee: con la certificación de ingeniero de APIs de Apigee, puedes demostrar tu capacidad para diseñar y desarrollar APIs sólidas, seguras y escalables.
- Certificaciones de desarrolladores de Google: puedes demostrar tus habilidades de desarrollo con las certificaciones de desarrollador asociado de Android (esta certificación se está actualizando) y de especialista en web móvil.
Además de la formación y la certificación, una de las mejores formas de adquirir experiencia con Google Cloud es empezar a usar el producto para crear pruebas de concepto empresariales.
Experimentar y diseñar pruebas de concepto
Para mostrar el valor y la eficacia de Google Cloud, plantee y desarrolle una o varias pruebas de concepto (PoCs) para cada categoría de carga de trabajo de su catálogo. Los experimentos y las pruebas te permiten validar hipótesis y demostrar el valor de la nube a los líderes empresariales.
Como mínimo, tu prueba de concepto debe incluir lo siguiente:
- Una lista completa de los casos prácticos que admiten tus cargas de trabajo, incluidos los poco comunes y los casos extremos.
- Todos los requisitos de cada caso de uso, como los de rendimiento, escalabilidad y coherencia, los mecanismos de conmutación por error y los requisitos de red.
- Una lista de tecnologías y productos que quieras investigar y probar.
Debes diseñar pruebas de concepto y experimentos para validar todos los casos prácticos de la lista. Cada experimento debe tener un contexto de validez preciso, un ámbito, resultados esperados y un impacto empresarial medible.
Por ejemplo, si una de tus cargas de trabajo con uso intensivo de CPU necesita escalarse rápidamente para satisfacer los picos de demanda, puedes realizar un experimento para verificar que una zona puede crear muchos núcleos de CPU virtuales y cuánto tiempo tarda en hacerlo. Si obtienes un valor añadido significativo, como reducir el tiempo de escalado de las nuevas cargas de trabajo en un 95 % en comparación con tu entorno actual, este experimento puede demostrar un valor empresarial instantáneo.
Si quieres evaluar el rendimiento de tus bases de datos locales en comparación con Cloud SQL, Spanner, Firestore o Bigtable, puedes implementar una prueba de concepto en la que la misma lógica empresarial use diferentes bases de datos. Esta prueba de concepto te ofrece una oportunidad de bajo riesgo para identificar la solución de base de datos gestionada adecuada para tu carga de trabajo en varias comparativas y costes operativos.
Si quieres evaluar el rendimiento del proceso de aprovisionamiento de VMs en Google Cloud, puedes usar una herramienta de terceros, como PerfKit Benchmarker, y comparar Google Cloud con otros proveedores de servicios en la nube. Además de generar informes sobre las métricas estándar de rendimiento máximo, como la latencia, el rendimiento y el tiempo de finalización, puede medir el tiempo total que se tarda en aprovisionar recursos en la nube. Por ejemplo, puede que te interese saber cuánto tiempo y esfuerzo se necesitan para aprovisionar muchos clústeres de Kubernetes. PerfKit Benchmarker es un proyecto de la comunidad de código abierto en el que participan más de 500 personas, como investigadores, instituciones académicas y empresas, entre las que se incluye Google.
Calcular el coste total de propiedad
Cuando tengas una visión clara de los recursos que necesitas en el nuevo entorno, podrás crear un modelo de coste total de propiedad que te permita comparar tus costes en Google Cloud con los de tu entorno actual.
Al crear este modelo de costes, debes tener en cuenta no solo los costes de hardware y software, sino también todos los costes operativos de tu centro de datos, como la energía, la refrigeración, el mantenimiento y otros servicios de asistencia. Ten en cuenta que también suele ser más fácil reducir los costes gracias a la escalabilidad elástica de losGoogle Cloud recursos, en comparación con un centro de datos local más rígido.
Un coste que se suele pasar por alto al plantearse migraciones a la nube es el uso de una red en la nube. En un centro de datos, la compra de infraestructura de red, como routers e interruptores, y el cableado de red adecuado son costes únicos que te permiten usar toda la capacidad de la red. En un entorno de nube, hay muchas formas de facturar el uso de la red. En el caso de las cargas de trabajo que requieren muchos datos o que generan un gran volumen de tráfico de red, puede que tengas que plantearte nuevas arquitecturas y flujos de red para reducir los costes de red en la nube.
Google Cloud también ofrece una amplia gama de opciones para escalar de forma inteligente los recursos y los costes. Por ejemplo, en Compute Engine, puedes ajustar el tamaño durante la migración con Migrate for Compute Engine, después de que las máquinas virtuales ya estén en funcionamiento o al crear grupos de instancias con autoescalado. Estas opciones pueden influir considerablemente en los costes de ejecución de los servicios y deben analizarse para calcular el coste total de propiedad.
Para calcular el coste total de los recursos de Google Cloud , puedes usar la calculadora de precios.
Elegir la estrategia de migración de las cargas de trabajo
Evalúa y selecciona la estrategia de migración que mejor se adapte a cada carga de trabajo que quieras migrar. Por ejemplo, tus cargas de trabajo pueden 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 nulo o casi nulo.
- Toleran los tiempos de inactividad, como las cargas de trabajo secundarias o de backend. En el caso de 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 tiempo de inactividad cero o casi 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
Una vez que hayas elegido una estrategia de migración para tus cargas de trabajo, revisa y decide qué herramientas de migración vas a usar.
Hay muchas herramientas de migración disponibles, cada una de ellas optimizada para determinados casos prácticos. Estos son algunos de los usos:
- Estrategia de migración
- Entornos de origen y de destino
- Tamaño de los datos y de la carga de trabajo
- Frecuencia de los cambios en los datos y las cargas de trabajo
- Disponibilidad para usar servicios gestionados para la migración
Para garantizar una migración y un cambio sin problemas, puedes usar patrones de implementación de aplicaciones, orquestación de infraestructuras y aplicaciones de migración personalizadas. Sin embargo, hay herramientas especializadas llamadas servicios de migración gestionados que pueden facilitar el proceso de mover datos, cargas de trabajo o incluso infraestructuras completas de un entorno a otro. Gracias a estas funciones, encapsulan la lógica compleja de la migración y ofrecen funciones de monitorización de la migración.
Definir el plan y la cronología de la migración
Ahora que tienes una visión exhaustiva de tu entorno actual, debes completar tu plan de migración haciendo lo siguiente:
- Agrupar las cargas de trabajo y los datos que se van a migrar en lotes (también llamados sprints en algunos contextos).
- Elegir el orden en el que quieres migrar los lotes.
- Elegir el orden en el que quieres migrar las cargas de trabajo de cada lote.
Como parte de tu plan de migración, te recomendamos que también elabores los siguientes documentos:
- Documento de diseño técnico
- Matriz RACI
- Cronología (por ejemplo, un plan de cuenta atrás)
A medida que adquieras experiencia con Google Cloud, la migración avance y conozcas mejor tu entorno, podrás hacer lo siguiente:
- Refina la agrupación de las cargas de trabajo y los datos que vas a migrar.
- Aumenta el tamaño de los lotes de migración.
- Actualiza el orden en el 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 van a migrar en lotes y definir el orden de migración, evalúa 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 se ejecuta de una forma única en comparación con el resto de tu infraestructura.
- Equipos responsables del desarrollo, la implementación y las operaciones de la carga de trabajo.
- Número, tipo y ámbito de las dependencias de la carga de trabajo.
- Esfuerzo de refactorización para que la carga de trabajo funcione en el nuevo entorno.
- Requisitos de cumplimiento y licencias de la carga de trabajo.
- Requisitos de disponibilidad y fiabilidad de la carga de trabajo.
Las cargas de trabajo que migres primero son las que permiten a tus equipos adquirir conocimientos y experiencia en Google Cloud. Si tu equipo tiene más experiencia y conocimientos sobre la nube, se reducirá el riesgo de que surjan complicaciones durante la fase de migración y las migraciones posteriores serán más fáciles y rápidas. Por este motivo, elegir a los primeros en migrar es fundamental para que la migración se lleve a cabo correctamente.
generar valor empresarial
Si eliges una carga de trabajo que no sea crítica para tu empresa, protegerás tu actividad principal y reducirás el impacto que puedan tener los riesgos y errores que no se hayan detectado mientras tu equipo aprende a usar las tecnologías de la nube. Por ejemplo, si eliges como pionero el componente en el que se implementa la lógica principal de las transacciones financieras de tu carga de trabajo de comercio electrónico, cualquier error durante la migración podría afectar a tu línea de negocio principal. Una mejor opción es la base de datos SQL que admite tus cargas de trabajo o, mejor aún, la base de datos de staging.
Debe evitar las cargas de trabajo que se usen poco. Por ejemplo, si eliges una carga de trabajo que solo utilizan unos pocos usuarios unas cuantas veces al año, aunque sea una migración de bajo riesgo, no aumentará el ritmo de la migración y puede ser difícil detectar y solucionar los problemas.
Casos límite
También debes evitar los casos límite para descubrir patrones que puedas aplicar a otras cargas de trabajo que quieras migrar. Uno de los objetivos principales a la hora de seleccionar un pionero es adquirir experiencia con los patrones habituales de tu organización para poder crear una base de conocimientos. Puedes aplicar lo que has aprendido con estos pioneros al migrar cargas de trabajo en el futuro.
Por ejemplo, si la mayoría de tus cargas de trabajo se han diseñado siguiendo una metodología de desarrollo basado en pruebas y se han desarrollado con el lenguaje de programación Python, no podrás descubrir ningún patrón que puedas aplicar al migrar las cargas de trabajo de Python si eliges una carga de trabajo con poca cobertura de pruebas y desarrollada con el lenguaje de programación Java.
Equipos
Cuando elijas a los pioneros, ten en cuenta los equipos responsables de cada carga de trabajo. El equipo responsable de un producto o servicio pionero debe estar muy motivado y tener ganas de probarlo. Google Cloud Además, los líderes de la empresa deben tener objetivos claros para los equipos pioneros y trabajar activamente para patrocinarlos y apoyarlos durante todo el proceso.
Por ejemplo, un equipo de alto rendimiento que trabaje en la oficina principal y que tenga un historial probado de implementación de prácticas de desarrollo modernas, como DevOps, y disciplinas, como la ingeniería de fiabilidad de sitios, puede ser un buen candidato. Si también tienen patrocinadores de la dirección y objetivos claros para cada migración de carga de trabajo, pueden ser candidatos excelentes.
Dependencias
Además, debes centrarte en las cargas de trabajo que tengan el menor número de dependencias, ya sea de otras cargas de trabajo o de servicios. La migración de una carga de trabajo sin dependencias es más sencilla si tienes poca experiencia con Google Cloud.
Si tienes que elegir cargas de trabajo que tengan dependencias de otros componentes, elige las que estén poco acopladas a sus dependencias. Si una carga de trabajo ya se ha diseñado para la posible falta de disponibilidad de sus dependencias, se pueden reducir los problemas al migrar la carga de trabajo al entorno de destino. Por ejemplo, los candidatos con un acoplamiento flexible 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 hay estrategias para migrar los datos de cargas de trabajo con estado, las cargas de trabajo sin estado rara vez requieren migración de datos. Migrar una carga de trabajo sin estado puede ser más fácil porque no tienes que preocuparte por una fase transitoria en la que los datos estén parcialmente en tu entorno actual y parcialmente en el de destino. Por ejemplo, los microservicios sin reconocimiento del estado son buenos candidatos para ser los primeros en adoptar una tecnología, ya que no dependen de ningún dato local con reconocimiento del estado.
Esfuerzo de refactorización
Una primera migración debe requerir una cantidad mínima de refactorización para que puedas centrarte en la migración en sí y en Google Cloud, en lugar de dedicar mucho tiempo a cambiar el código y la configuración de tus cargas de trabajo. La refactorización debe centrarse en los cambios necesarios para que tus cargas de trabajo se ejecuten en el entorno de destino, en lugar de centrarse en modernizar y optimizar tus cargas de trabajo, lo que se aborda en fases posteriores de la migración.
Por ejemplo, una carga de trabajo que solo requiera cambios en la configuración es una buena opción para empezar, ya que no tienes que implementar ningún cambio en la base de código y puedes usar los artefactos que ya tengas.
Licencias y cumplimiento
Las licencias también influyen en la elección de los primeros en migrar, ya que algunas de tus cargas de trabajo pueden tener licencias con términos que afecten a la migración. Por ejemplo, algunas licencias prohíben explícitamente ejecutar cargas de trabajo en un entorno de nube.
Al examinar los términos de las licencias, no olvides los requisitos de cumplimiento, ya que es posible que tengas requisitos de arrendamiento exclusivo para algunas de tus cargas de trabajo. Por estos motivos, debes elegir cargas de trabajo que tengan la menor cantidad de restricciones de licencias y cumplimiento como pioneras.
Por ejemplo, tus clientes pueden tener el derecho legal de elegir en qué región almacenas sus datos, o bien sus datos pueden estar restringidos a una región concreta.
Disponibilidad y fiabilidad
Las empresas que pueden permitirse un tiempo de inactividad debido a una ventana de cambio son las que se benefician de ser las primeras en adoptar la tecnología. Si eliges una carga de trabajo que tenga requisitos de disponibilidad estrictos, debes implementar una estrategia de migración de datos sin tiempo de inactividad, como Y (escritura y lectura) o desarrollando un microservicio de acceso a datos. Aunque es posible seguir este enfoque, distrae a tus equipos de adquirir la experiencia necesaria con Google Cloud, ya que tienen que dedicar tiempo a implementar estas estrategias.
Por ejemplo, los requisitos de disponibilidad de un motor de procesamiento por lotes pueden tolerar un tiempo de inactividad más largo que la carga de trabajo orientada al cliente de tu sitio de comercio electrónico, donde los usuarios finalizan sus transacciones.
Validar el plan de migración
Antes de empezar a aplicar tu plan de migración, te recomendamos que valides su viabilidad. Para obtener más información, consulta el artículo Prácticas recomendadas para validar un plan de migración.
Siguientes pasos
- Consulta cómo planificar tu migración y sentar las bases en Google Cloud.
- Consulta cuándo pedir ayuda para tus migraciones.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autor: Marco Ferrari | Arquitecto de soluciones en la nube