Azure Migrate | Claves para migrar al cloud

Todo aquel que pertenezca al sector IT, lleva años leyendo artículos prediciendo que la Nube es el futuro. En España actualmente el 26% de las empresas usan servicios de Computación en la Nube, mientras que la media europea asciende al 36% y en algunos países ya llega al 70%… (Eurostat, 2021) Sin entrar en comparaciones sobre unos países u otros, lo que arrojan estos resultados es que la Nube, no es una tecnología de futuro, es una tecnología de presente. No estar en la Nube a día de hoy, o no tener un plan de adopción de la misma, es retrasar lo inevitable y muy probablmente, estar perdiendo oportunidades de negocio y mejora de procesos ( o dicho de otra manera, dinero).

Renovación de infraestructuras

Creo que los lectores de este artículo estarán de acuerdo en que existe mucho miedo a realizar cambios significativos en la infraestructura. A finales de este año se lanzará la versión 2022 de Windows Server, lo que nos permitirá dejar atrás la hasta entonces última versión, la 2019. A falta de año y medio para el fin de soporte de la versión 2012, nos encontramos clientes que están realizando updates a dicha versión, lo que implícitamente nos lleva a admitir que se siguen usando versiones como 2008 o 2003. Incluso nos hemos encontrado algún Windows Server en su versión 2000 escondido en algún Datacenter.

Es decir, ya tenemos profesionales incorporándose al mercado que ni habían nacido cuando estas últimas versiones salieron al mercado.

¿Te has sentido mayor leyendo estas últimas líneas? Tranquilo, ese no es el foco; lo viejo de verdad comparando el ciclo de vida de la tecnología, es la infraestructura. 

Pero ¿Por qué ocurre esto? Cada vez es más fácil actualizar las versiones de los sistemas operativos y hacerlo tiene muchas ventajas en cuanto a seguridad, estabilidad, soporte… Sin embargo, existen una serie de problemas. El mayor es que las cargas de trabajo que están ejecutándose en esos servidores son demasiado antiguas y actualmente parece demasiado costoso actualizarlas. Puede resultar más económico desarrollar desde cero una aplicación que hacer un upgrade desde versiones muy obsoletas de Net Framework. Pero esa aplicación algún día puede fallar, y depende del momento en que ocurra lo realmente complejo será solucionar el problema que ocasione el fallo e incluso que no haya profesionales que puedan hacerse cargo. ¿Cuál será el coste de tener dicha aplicación parada unas horas o unos días? 

Beneficios de migrar a la nube

Soy consciente de que me he salido del hilo principal del artículo, pero era necesario poner un ejemplo de lo necesario que es renovar nuestra tecnología cada cierto tiempo. Y es por ello por lo que muchas de las nuevas funcionalidades desarrolladas por las empresas nacen en la nube, utilizando alguna de las variopintas tecnologías que nos ofrecen, podemos utilizar contenedores, Bases de datos, Datawarehouses, Web Apps… Estas nuevas cargas de trabajo pueden tener cierta comunicación con las aplicaciones más antiguas, las cuales siguen en servidores en un Datacenter. Por lo tanto, una de las motivaciones de llevar nuestros servidores a la Nube es que los mismos estén cerca de las aplicaciones desarrolladas. Otra de las motivaciones que podemos tener es el ahorro de costes que conlleva subir servidores a Cloud o simplemente la escalabilidad. Pero a estas alturas, creo que las ventajas de migrar a la nube todos las tenemos claras, así que sigamos avanzando.

Sean cuales sean los motivos por lo que se decida migrar un servidor a la nube hay que buscar la mejor manera para realizarlo. Y la buena noticia es que es realmente simple, pero hay una serie de factores a tener en cuenta antes de lanzarse a migrar servidores a cualquier Cloud. Con la experiencia adquirida en Plain Concepts después de migrar más de 1500 servidores a Azure como IaaS en diversos proyectos de ‘Lift and Shift’, y sabiendo que los grandes proveedores Cloud ofrecen soluciones muy similares, creo que los siguientes puntos pueden ser de gran interés.

Cómo migrar a la nube

Servicios Fundacionales

Lo primero que debes tener en cuenta es lo que conocemos como Servicios Fundacionales, son los cimientos de Azure y como todo cimiento si desde un principio no están bien construidos, podemos tener muchos problemas en el futuro. Lo más básico de los servicios fundaciones es cómo organizaremos los recursos que vamos a subir.

¿Generaremos suscripciones dedicadas para máquinas IaaS?

Mi recomendación sería generar suscripciones dedicadas para cada entorno de desarrollo de los que dispongamos, lo cual nos permitirá disponer de una buena organización, además teniendo en cuenta el límite de asignaciones de roles por suscripción en Azure es de 2000 (Microsoft, 2021) Si mezclamos tipos de recursos y entornos en la misma suscripción podemos tener un problema.

Organización de recursos

Otra de los aspectos importantes es estructurar los grupos de recursos dentro de cada suscripción (aconsejable crear reglas para su creación) Debemos seguir una estrategia que puede variar dependiendo de quien administre las máquinas, o de alguna agrupación lógica que heredemos desde On Premises. Sea cual sea, lo mejor es definirla antes de comenzar a desplegar los recursos que vayan a necesitar nuestras máquinas.

Topología de red

Por último, debemos decidir la topología de red que utilizaremos para nuestras máquinas, lo más común sería utilizar una topología Hub and Spoke o estrella. Como lo normal no es migrar todas las máquinas en el mismo momento, en la red que trabajará como Hub colocaremos los Gateways ya vayamos a conectar con On Premises mediante un ExpressRoute o conexión una conexión VPN. Si realizamos bien esta conexión, no tendremos necesidad de colocar en un primer momento bastiones ni Firewalls en Cloud, dado que todas las comunicaciones seguirán fluyendo hacia On Premises, donde tendemos nuestros Proxys y Firewalls, las máquinas de Azure no serán accesibles desde internet y sólo podrán ser accedidas como las estuviéramos exponiendo hasta antes de comenzar la migración, la Cloud no será más que una extensión de nuestras redes. 

Cuando ya tengamos toda la infraestructura migrada y queramos deshacernos del datacenter On premises podremos comenzar a desplegar la infraestructura que dotará de seguridad a la red. Por último, debemos tener en cuenta ciertos Appliances como los de Backup, si migramos una máquina y el servidor de Backup sigue en el Datacenter producirá mucha carga en la red, lo mejor es generar otro servicio de Backup en la Nube, ya sea utilizando la misma tecnología u otra de las que nos ofrezca la Nube a la que vamos a migrar. Lo mismo se aplicaría Directorios Activos, servidores DNS… 

Configuración Azure Migrate

Bien, una vez ya tenemos configuradas nuestras suscripciones y redes es el momento de configurar las herramientas necesarias para que las migraciones se lleven a cabo. Cada Cloud tiene su propia herramienta que ofrece servicios de migraciones e incluso en el mercado ofrece alternativas de terceros. En nuestro caso hemos utilizado tanto en el pasado Velostrata como hoy en día Azure Migrate, ambas herramientas utilizan migración por bloques, lo que nos asegura que no se pierde nada de información durante la migración. La máquina que tendremos en la Nube será un clon exacto de la máquina que teníamos en On Premises, aunque es cierto que cuando una máquina inicia en Azure el agente cambia algunos parámetros del registro del sistema operativo, pero no afectan a la operatividad del equipo. El único cambio que se produce en una máquina al ser migrada es un cambio de IP, por lo que siempre tendremos que saber si existe algún registro estático en nuestros DNS o alguna de las cargas de trabajo que se ejecutan contra el servidor migrado tienen IPs estáticas que deberemos cambiar.  

Cada empresa además tiene sus particularidades y tendrá que desarrollar su propio flujo de migración en particular, si tenemos servidores de DNS en la Nube, querremos cambiar los registros en la máquina para que apunten a los que se encuentren en la Nube, y así con el resto de las tecnologías que utilicemos. 

Puede parecer que todo este proceso es un poco largo y en ocasiones algo complejo, pero hasta aquí llega toda la complejidad, una vez tengamos todos los puntos anteriores queda utilizar la herramienta que hayas escogido para la migración y planear un día para subir cuantos servidores queramos, la parte buena es que al utilizar migraciones por bloques normalmente el tiempo de parada de un servidor es menor a una hora, lo que nos permitirá mantener un SLA de 4 nueves aun habiendo trasladado el servidor a otra zona geográfica. Y estos procesos son muy repetitivos, pudiendo automatizarse de tal manera que sea muy sencillo migrar todos los servidores que queramos. ¡Ya no tienes excusa para comenzar a llevar tus servidores a la Nube!