Un proyecto estándar de migración a la nube consta de un conjunto definido de pasos:
1. Justificación de TI y prueba de una necesidad comercial. La justificación puede ser evitar el bloqueo del proveedor, el ciclo de renovación de la licencia de software o hardware de arrendamiento del centro de datos, la velocidad de escala, el TCO o el descuento de la nube pública, etc. Por lo general, cuando hay una justificación clara, no es un problema probar la necesidad comercial.
2. Definición del alcance del proyecto. En este paso se definen una persona responsable (jefe de proyecto) y aplicaciones/recursos específicos.
3. Fase de migración a la nube.
4. Autopsia.
Es normal que durante el proceso de migración haya momentos en los que tenga recursos ejecutándose tanto en la nube de origen como en la de destino.
Es posible que algunos de los recursos ya se hayan migrado, algunos todavía pueden estar en una cola o incluso no estar definidos para la migración y seguir ejecutándose en una nube de origen.
Pero hay un caso interesante cuando migras algunos recursos (en algunos casos cientos o miles de máquinas) y necesitas pagar por ellos dos veces.
Lograr una gestión de costes eficaz tiene que ver con la optimización y el seguimiento.
Con un conjunto de políticas, principios y procesos implementados, las empresas pueden apaciguar a las partes interesadas y garantizar que sus gastos en la nube permanezcan bajo control.
Si su factura de gastos en la nube es una sorpresa cada vez que la recibe, simplemente no está aprovechando todas las herramientas de control de costos que existen.
Cuando las empresas definen qué trasladar a la nube, normalmente piensan en categorías de aplicaciones, departamentos o recursos completos. Los consultores o proveedores de migración experimentados siempre recomendarán dividir los recursos en partes de 30 a 50 máquinas virtuales y migrar por fases. Por un lado, reduce el riesgo, por el otro, ayuda exactamente a explotar la burbuja. Idealmente, una sola aplicación debe estar en una sola porción. En ese caso, puede migrar y probar toda la parte granular de su sistema y evitar problemas de localidad de datos. Recuerde que el tráfico en la nube entre regiones y saliente no es gratuito y es bastante costoso. Es mejor pensar en eso antes de recibir su primera factura en la nube 🙂
La causa raíz de la burbuja está en ‘replicación -> prueba’ -> alcance de transición. Cuando migra algún fragmento, lleva algún tiempo replicar los datos, definir cómo tomará los incrementos (mejor de forma automatizada con ACURA Migration & DR de Hystax), cómo probar el fragmento en una nube de destino y programar una ventana de mantenimiento para ejecutar la transición. Y esas 3 fases forman la burbuja. Almacena los datos en dispositivos de bloque o en un almacenamiento de objetos, ejecuta máquinas virtuales en una nube de destino y paga por la computación. En la mayoría de los casos, las migraciones de prueba pueden ejecutarse durante 1 a 3 semanas (pueden ser incluso más) hasta que un equipo propietario de la aplicación migrada valide que todo está bien en una nube de destino y que no hay degradación del rendimiento u otros problemas. . Y si migra varios fragmentos en paralelo, la burbuja crecerá.
Entonces, cómo evitar la burbuja…
1. En primer lugar, identifica tu ritmo de migración. Sea muy franco consigo mismo, es exactamente cómo aprender una nueva habilidad: muy lento al principio y mucho mejor después de algunas iteraciones.
2. Defina una cola de aplicaciones/fragmentos. Póngalo en el calendario de su proyecto de migración.
3. Descubra una forma de replicar máquinas virtuales sin tiempo de inactividad y sin volver a replicarlas todo el tiempo. Hay docenas de herramientas que lo hacen y le ahorran tiempo y dinero, ya que paga menos por el almacenamiento.
4. Comuníquese con los equipos que poseen los fragmentos o las aplicaciones. Defina los criterios de aceptación y el proceso de transición con ellos, cuanto antes empiecen a pensar en eso, más preparados estarán cuando llegue el momento. Defina franjas horarias en las que necesiten probar la migración. Este es el paso más importante ya que las pruebas explotan la burbuja y, por lo general, los equipos no tienen idea de cómo probar las aplicaciones, cuáles son los componentes y quién es el propietario de las máquinas individuales.
5. Defina el período de espera: cuánto tiempo esperará hasta que elimine las máquinas virtuales migradas del entorno de origen. No olvide que, por un lado, necesita algún plan de respaldo si algo sale mal con las máquinas virtuales y las aplicaciones en una nube de destino y, por otro lado, aún paga (directa o indirectamente) por las máquinas en el lado de origen.
6. Cierra las pruebas en cuanto veas que el equipo no está preparado o no es su derecho prioritario. Si no están motivados, simplemente perderán el tiempo (equivalente a dinero en nubes públicas) o, lo que es peor, tomarán una decisión (aceptar o rechazar) en función de algunos criterios extraños y, o bien, procederán a utilizar las máquinas en una nube de origen o se dará cuenta de que hubo problemas cuando las máquinas virtuales de origen ya se habrían eliminado. Reiterar con su gerente o alta gerencia para ajustar las prioridades de ambos equipos.
7. Si pasan las pruebas, proceda con la transición. Elimine todas las instantáneas y pruebe las migraciones para las aplicaciones migradas. No olvides poner en marcha el reloj del tiempo de espera por ellos.
8. Revisa tus estimaciones de ritmo y ajusta tu horario.
Tendrá una especie de doble burbuja en cualquier proyecto de migración, pero puede controlar qué tan grande será mediante una planificación y comunicación adecuadas con las aplicaciones y los propietarios de las máquinas virtuales. Solo las personas valientes migran toda la infraestructura en una sola ejecución, las personas inteligentes planifican y lo hacen en partes y fases.
Cuide la resiliencia de TI de su empresa con el galardonado software de Migracion y recuperación ante desastres
