Migrando de .NET Framework a Open Source
En este artículo explicaremos las consideraciones que se deben tener en cuenta en el momento momento de realizar una migración de una aplicación escrita en .NET Framework a una tecnología open source.
Aquí entregaremos detalles sobre los dos tipos de migración: aplicaciones de escritorio y aplicaciones WCF.
Ten en cuenta que .NET Core o .NET es la propuesta open source más reciente de Microsoft para ofrecer la portabilidad de aplicaciones en todos los sistemas operativos. Por lo anterior, será esta la primera opción de migración y en la que más daremos contexto de herramientas, compatibilidad y consideraciones al momento de querer migrar.
Como herramientas te daremos una explicación del .Net API Portability Analyzer, .NET upgrade assitant, AWS Porting Assistant for .NET para que tengas una idea de cómo puedes usarlas.
También podrás darte a una idea de cual seria la eficiencia operacional al migrar una aplicación a open.
Aplicaciones de escritorio
Las aplicaciones creadas usando como arquitectura base el .NET Framework, específicamente Windows Forms y Windows Presentation Foundation (WPF), fueron migradas a .NET; sin embargo, siguen siendo tecnologías exclusivas de Windows.
Existen herramientas que permiten ver la portabilidad entre .NET Framework y .NET, tales como:
- .NET API Portability Analyzer
Es una extensión de Visual Studio que ayuda a analizar el código fuente de un proyecto determinando para revisar si es viable la potabilidad a .NET Core o .NET.
Esta extensión se puede encontrar usando la opción de “administrar extensiones” del Visual Studio, usando la categoría “en línea”.
Para utilizarla debes elegir la opción Analyze Assembly Portability del menu Analyze o directamente sobre el explorador de soluciones:
Este análisis arrojará un informe en formato Excel, donde se muestran los porcentajes de portabilidad que tiene el código:
- .NET Upgrade Assistant
Es una herramienta de línea de comandos que ayuda a actualizar las aplicaciones de Windows Forms de .NET Framework a .NET 6.
Para instalar esta herramienta, globalmente, usamos el siguiente comando:
dotnet tool install -g upgrade-assistantPara iniciar el análisis de nuestro código, nos debemos ubicar en la ruta donde se encuentra nuestra solución y ejecutamos el siguiente comando:
upgrade-assistant analyze <Nombre de la Solución>
Para realizar la actualización propuesta usando este asistente, ejecutamos el siguiente comando:
upgrade-assistant upgrade <Nombre de la Solución>
Durante la ejecución de la actualización, la herramienta irá solicitando al usuario algunos requerimientos para poder concluir con la actualización del código.
Es importante destacar que el objetivo de estas dos herramientas es actualizar las aplicaciones que están desarrolladas en .NET Framework a .NET 5+; sin embargo, como mencionamos anteriormente, las aplicaciones solo pueden ser ejecutadas en sistemas operativos Windows.
Para migrar a una tecnología Open Source, se debe considerar, en la mayoría de los casos, una reescritura del código a otro lenguaje como Java, Python o Elixir.
Si se está considerando realizar la reescritura a otro lenguaje, esta es una buena oportunidad para tener en cuenta practicas basadas en Cloud Native.
Aplicaciones Windows Communication Foundation (WCF)
Esta tecnología no es compatible con .NET Core y/o .NET 5+; pero existen alternativas que pueden ser usadas para migrarlas. Uno de los proyectos que permite usar WCF en .NET es CoreWCF.
CoreWCF es un proyecto Open Source soportado por la .NET Foundation y su propósito es habilitar las características como Servicios SOAP en tecnologías superiores a .NET Core 3.0.
A continuación, explicaremos los pasos que debemos seguir para la migración de un Servicio SOAP .Net Framework a .NET usando AWS Porting Assistant para .NET
- Requisitos Previos
A) Máquina de desarrollador con Visual Studio instalado.
B) Instalar AWS Porting Assistant para .NET
C) Para este ejemplo usaremos el siguiente código publicado en GitHub
- Primeros Pasos
Configuremos el AWS Porting Assistant para .NET:
1) Abrimos la opción “Settings” y posteriormente hacemos click en “Add a Named Profile”.
2) En esta opción ingresamos los siguientes valores: Profile name, AWS access key ID y AWS secret access key.
3) Localizamos la solución del proyecto (.sln) al cual vamos a realizar el análisis de portabilidad y hacemos click en “Assess” o “Evaluación”.
Ahora bien, entendamos más a fondo los resultados de esta evaluación. En la pestaña de Projects o Proyectos se visualiza el desglose de las incompatibilidades y las acciones por proyecto, como se puede ver en la siguiente imagen.
La pestaña Project References o Referencias del proyecto muestra una vista gráfica de las dependencias del paquete.
En la pestaña de NuGet packages o paquetes de Nuget encontraremos detalles de las dependencias compatibles e incompatibles y los reemplazos sugeridos, si están disponibles.
En la pestaña APIs se enumeran las referencias que son incompatibles, en cuales paquetes se encuentran y cuántas veces se hace referencia a ellas dentro del proyecto.
También se pueden ver las sugerencias para el reemplazo de aquellas APIs incompatibles.
Ahora ejecutemos la portabilidad de los proyectos. Para esto, en la pestaña de Projects o Proyectos, seleccionamos los proyectos a los cuales le queremos realizar la portabilidad y hacemos click en “Port Project”.
Luego visualizaremos una ventana emergente que nos indica dónde deseamos guardar el resultado de la portabilidad.
Seleccionamos la ubicación en la cual deseamos guardar el proyecto y hacemos click en “Save”.
Posteriormente se muestra una pantalla con la información de los proyectos a los que se les realizará la portabilidad.
Para ejecutar el proceso de portabilidad hacemos click en “Port” y, una vez se finalice el proceso, tendremos como resultado la siguiente pantalla donde indica que culminó exitosamente:
Sin embargo, seguramente se tendrán que hacer algunos ajustes manuales de los resultados obtenidos con esta herramienta.
Mono Project como alternativa Open Source
Mono Project nace en el 2004 para ofrecer portabilidad a las aplicaciones desarrolladas sobre .NET Framework.
La iniciativa “Mono” surge porque las aplicaciones desarrolladas sobre el framework son compatibles para ejecutarse solamente en ambientes windows.
A algunos fanáticos de Microsoft les gusto tanto, que aprovecharon cuando la compañía publicó su arquitectura de ejecución CLR (Common language Runtime) para implementarla en Linux, y se pusieron en la tarea de reescribir toda la biblioteca de clases de .NET framework.
Si bien la compatibilidad en la ejecución de las aplicaciones sobre Linux no es de un 100 %, con algunos ajustes a tu aplicación y con ciertas consideraciones esta podría ser una opción muy viable para hostear tu aplicación sobre un sistema operativo open.
Eficiencia Económica de una Migración a Open Source
Las migraciones de un ambiente licenciado a un ambiente Open Source traen con ellas un beneficio económico representativo; y a continuación lo explicamos brevemente con un caso de estudio o prueba de concepto realizado en la nube usando Amazon Web Services como proveedor de servicios.
Caso de Estudio
Para este caso de estudio se tiene como base un servicio WCF escrito en .NET Framework, ejecutándose en sistema operativo Windows y usando Internet Information Services (IIS) como servidor web para hostear el servicio.
El mayor esfuerzo para lograr una eficiencia económica esta focalizado en cambiar las intancias EC2 actuales a un ambiente Linux usando Mono Project para hostear la aplicación.
- Arquitectura de proyecto licenciado.
En esta arquitectura los recursos utilizados son 2 instancias EC2 basadas en imagenes Windows, tal como se plantea en el siguiente diagrama:
- Arquitectura de proyecto Open Source
Para la arquitectura Open Source todos los recursos permanecen de la misma forma sustituyendo únicamente las instancias de Windows a Linux, tal como se plantea en el siguiente diagrama:
Para un estimado de los costos de cada arquitectura ingresamos a AWS Pricing Calculator y buscamos el servicio EC2 para configurar el estimado.
Como referencia seleccionaremos la región US East (N. Virginia)
El tipo de instancia usada en cada arquitectura es t3a.medium.
Los costos pueden variar según la estrategia de precios que se seleccione; para esta prueba de concepto usaremos EC2 Instance Savings Plans con una reservación de términos a 1 año.
Usando un sistema operativo Windows Server, el costo estimado es de 34 dólares mensuales. Sin embargo, si se usa un sistema operativo Linux el costo estimado es de 20 dólares mensuales.
Esto representa un ahorro estimado mensual de 58.8% y, como usamos una estrategia de precios con vencimientos de términos de un año, se traduce en un ahorro anual de 168 dólares por cada instancia.
