Los últimos años me los he pasado en su mayoría o bien migrando sistemas o facilitando la migración de dichos sistemas creando aplicaciones para ello. Hoy vamos a hablar de migrar aplicaciones
Índice
1 - Migrar de un monolito a microservicios
En este post no voy a entrar a discutir en si debemos migrar a microservicios o no, los costes adicionales que tiene, etc para ello tengo otros posts. Aquí vamos a hablar sobre qué tener en cuenta, a la hora de migrar.
Para este supuesto vamos a imaginarnos el supuesto donde tenemos una aplicación monolítica enorme, en nuestro caso, ya que es sencillo de imaginar, una tienda.
1.1 - Elección de elementos a migrar
Ahora tenemos dos opciones, o migramos a microservicios o dejamos lo que hay donde está y todo el desarrollo nuevo lo hacemos en microservicios.
Lo ideal es una mezcla, todo lo nuevo va a estar en microservicios, pero lo antiguo debemos seleccionarlo, lo más lógico es elegir elementos que tienen mucho uso pero que no son cruciales si fallan.
Por ejemplo, en una tienda, migrar el sistema de pagos puede ser más peligroso que migrar el sistema de envío de email. Pese a que ambos tienen un uso similar, si el sistema de pagos falla, las consecuencias son mucho peores que si un email no se envía.
Cada sistema va a tener sus propias características y necesita un análisis antes de dicha elección.
1.2 - Uso de la infraestructura y automatización
Antes de ponerte a programar lógica de negocio, tienes que tener el sistema listo para soportar la integración continua y el despliegue automático. Necesitas si o si CICD para que tu sistema funcione, cuando solo tienes un monolito y despliegas una vez cada 6 meses, alguien lo puede hacer de forma manual, si vas a tener decenas de servicios, no.
1.3 - Observabilidad y monitorización
Instrumentar la observabilidad también es un punto muy importante que podemos introducir en la parte de infraestructura. Ya que para desplegar cualquier elemento debemos estar seguros que la monitorización y los logs llegan a un sitio centralizado donde podemos verlos sin problemas.
De no ser así lo más posible es que terminemos con unos dolores de cabeza enormes intentando encontrar algún bug sin tener visibilidad sobre este.
1.3 - Cross cutting concerns
Ahora que has decidido migrar a microservicios te habrás dado cuenta de que tenemos código que se repite en prácticamente cada microservicio. Repetir algo alguna vez pues no pasa nada, pero cuando sabes que lo vas a necesitar si o si en muchos sitios, lo suyo es abstraerlo y ponerlo en un lugar común.
A estas abstracciones les solemos llamar crosscutting concerns, aunque en cada empresa a la que vas tendrán diferentes nombres. Luego hay empresas donde cualquier persona puede modificar las abstracciones y empresas donde solo un equipo puede. En mi opinión lo mejor es que cualquiera pueda modificar dicha abstracción, pero que un equipo esté a cargo del mantenimiento, y sean responsables de, entre otras cosas, arreglar el código.
Ejemplos muy comunes de este tipo de abstracciones son el tema de la configuración de la autenticación, si la empresa es grande y usas servicios de AWS/Azure es posible que tus buckets/storage o incluso las tablas de la base de datos tengan que tener cierto nombre para mantener consistencia, todo esto se configura a través de una abstracción, dando al desarrollador la menor cantidad de opciones posibles.
Lo mismo sucede para el tema de monitoreo, logs, etc. En esta web creamos un curso sobre sistemas distribuidos donde vimos algunas de las abstracciones más comunes en empresas.
1.4 - Migra de forma gradual
El punto final es que migres de forma gradual. Por sentido común, migra poco a poco, no es necesario que migres todo el sistema de un golpe, incluso puedes migrar sin tener que modificar el monolito.
Hoy en día hay técnicas que permiten comprobar la url y redirigir al nuevo sistema en vez de al propio monolito.
Esto quiere decir que puedes dejar el monolito sin tocar, sin tener que cambiar nada y únicamente con configuración de tu proveedor de servicios o en tu API Gateway redirigir al sistema nuevo, de cara al usuario nada cambia pues la URL puede seguir siendo la misma, y en caso de que algo no funcione bien, siempre puedes volver a usar el monolito sin problema.
Cuando vas a migrar de un monolito a un microservicio, no elimines el código del monolito hasta que puedas garantizar que todo ha funcionado como debería.
Y ten siempre el plan B de volver al microservicio, lo cual se puede hacer muy sencillo si tienes un servicio de feature flags.
2 - Migrar entre versiones o lenguajes
Otro tipo de migración que es muy común es migrar ya bien sea de un lenguaje a otro o entre versiones del mismo lenguaje, principalmente se suelen hacer por mejoras de rendimiento, ya que suelen ser cambios que no afectan directamente al usuario.
En mi caso la gran mayoría de estas migraciones han sido dentro de .NET en concreto migrando de .NET Framework y de .NET.
Cada lenguaje o versión va a tener sus características específicas, así que lo que vamos a hacer es centrarnos en tre framework/core
2.1 - Migrar de .NET Framework a .NET
Hoy en día estamos ya por C# 12 como version LTS o por C# 13 si usas versiones cortas.
La última versión de .NET Framework usa C# 7.3, lo que viene siendo 6 versiones menos que la versión actual, y como puedes imaginar lleva muchos cambios.
Asumiendo que tienes todo el código corriendo y funcionando correctamente en .NET Framework, lo primero que tendremos que hacer si queremos migrar a .NET es asegurarnos de que los clientes que estamos utilizando y las librerías sean compatibles con .NET (core).
Por ejemplo, desde tu servicio, estas llamando a otro, para ello usas un cliente HTTP generado desde la app que llamas, ese cliente, si fue creado junto a la app, es muy probable que sea un cliente en net framework. Si vas a migrar tu app a .NET tendrás que crear un nuevo cliente, o actualizar el existente, Idealmente utilizando .NET Standard, para que así sea compatible con tu nuevo servicio y sea compatible con .NET Framework, así si hay que modificar algo, únicamente tienes que modificar dicho paquete.
Una vez tienes detectadas las dependencias directas, debes asegurarte de que todos los paquetes funcionan en .NET, pero no solo eso, asegurate de que funcionan para Linux*.
* Personalmente siempre que he migrado de .NET Framework a NET, también hemos pasado de Windows a Linux, ya que mantener la aplicación cuesta una fracción del precio. Eso conlleva a que para algunas librerías hayamos tenido que buscar alternativas que sí funcionen en Linux.
Si hay más equipos en tu empresa que hayan migrado, no dudes en contactarles, pues es posible que tu encuentres problemas inesperados que dichos equipos ya encontraron y solucionaron.
Este tipo de migraciones suele tener problemas con las dependencias, donde una dependencia depende de otra que a su vez depende de otra… no es la mejor experiencia, pero ánimo.
3 - Refactorizar y migrar al mismo tiempo
Una de las preguntas que te vas a hacer es si merece la pena migrar y aprovechar la migración para mejorar el código.
La respuesta es que no, normalmente migrar es bastante tedioso y lleva suficientes problemas, especialmente si los proyectos viejos no han estado mantenidos y se han ido poniendo parches uno encima de otro.
Lo recomendable es migrar, copiando el máximo código posible, y luego al terminar, crear un ticket diferente, el cual se encargará de la refactorización si fuera necesario. Tener test, tanto unitarios como de integración es crucial para poder hacer la refactorización.
