Ya hemos hablado muchas veces en esta web de .NET Core, y de cómo ha cambiado muchas cosas respecto a versiones anteriores de la plataforma de desarrollo de Microsoft. Y esto es especialmente cierto en el ámbito del desarrollo web y ASP.NET Core.
Nota: si no tienes claro qué es .NET Core y cómo se relaciona con .NET "tradicional", por favor, antes de seguir lee este artículo.
Sin duda, su aparición ha supuesto el cambio más grande para las tecnologías de desarrollo web de Microsoft desde sus inicios, y tanto es así que, de hecho, es un producto totalmente nuevo, escrito desde cero.
Pero, obviamente, el gigante de Redmond no ha dado este paso por capricho; se trata de una gran inversión que sin duda debía estar justificada.
A continuación, veremos qué motivos llevaron a Microsoft a considerar un proyecto de esta envergadura, así como las características más destacadas que encontramos en este framework.
¿Por qué ASP.NET Core?
Desde sus comienzos, allá por el año 2002, el framework ASP.NET ha incluido todo lo necesario para construir aplicaciones web usando los lenguajes y herramientas de Microsoft. Contenía tanto aspectos de pura infraestructura como marcos de trabajo para el desarrollo de aplicaciones (básicamente Web Forms), y todo construido de forma monolítica.
Una consecuencia de este diseño era que cuando usabas ASP.NET en tus aplicaciones, obligatoriamente debías incluir todo el framework aunque no lo utilizaras por completo. Por ejemplo, aunque tu sitio web fuera una simple página web informativa, cada petición se veía obligada a atravesar un complejo entramado de componentes para generar la respuesta que era finalmente enviada el cliente: módulos, handlers, recuperación de estado de vistas, construcción de árboles de controles, seguridad, gestión de errores, etc. Algunos de estos componentes podían activarse o desactivarse desde el archivo de configuración, pero seguían estando ahí, ocupando memoria y tiempo de proceso en cada petición.
Esta estructura asimismo complicaba bastante la evolución del producto, que debía mantener la mirada hacia atrás para proporcionar la mayor retro-compatibilidad posible. Dado que el diseño del producto no era modular, no era posible actualizar un componente o funcionalidad de forma individual, y la complejidad del framework hacía que los ciclos de aparición de nuevas versiones eran muy largos (¡años!), mientras que se estaba viendo que las tecnologías y tendencias para la web evolucionaban muy rápido. Cada versión añadía características nuevas que contribuían a engordar ese monstruo en el que se había convertido ASP.NET, pero normalmente iban muy por detrás de las necesidades reales del mercado y de la comunidad de desarrolladores.
Cuando Microsoft empezó a construir otros marcos de trabajo basados en ASP.NET (MVC, luego Web API, Web Pages, y más tarde SignalR), comenzaron a darse cuenta de que todos ellos arrastraban una pesada losa: el mastodóntico núcleo de ASP.NET, llamado de forma genérica System.Web. Este núcleo, que conformaba la monolítica infraestructura básica sobre la que corrían todas las aplicaciones basadas en ASP.NET, era enorme, complejo, pesado, muy ligado a tecnologías y servidores de Microsoft, y en muchos aspectos estaba mal diseñado, o al menos no diseñado con los parámetros y buenas prácticas que hoy en día entendemos como razonables.
Y en la práctica, la conclusión a la que llegaron es que todos los nuevos marcos de trabajo estaban limitados por su infraestructura. MVC, Web API o SignalR estaban razonablemente bien construidos y pensados desde un principio para ser muy eficientes, pero su dependencia de ASP.NET no era buena para su evolución ni para la apertura de nuevas fronteras como el salto a entornos multiplataforma, además de suponer un lastre importante en cuanto la velocidad y consumo de recursos de las peticiones, tan importantes en los modernos entornos escalables y servicios en la nube.
El siguiente diagrama refleja la pila de tecnologías web de Microsoft con ASP.NET 4.x:
OWIN y Katana vinieron al rescate hace algún tiempo como los aislantes que necesitábamos entre los marcos de trabajo de alto nivel y la infraestructura, y las últimas versiones de los frameworks más jóvenes como Web API y SignalR los utilizaron de forma correcta para desvincularse totalmente de System.Web. Esta independencia hizo posible que pudieran alojarse servicios Web API o SignalR en cualquier tipo de proceso (aplicación web, servicio Windows, aplicación de consola…) y que fueran muy eficientes.
Sin embargo, conseguir lo mismo con MVC era mucho más complejo, y hasta su versión 5 continuó completamente atado a System.Web (ASP.NET 4.x) porque internamente lo utilizaba en demasiados puntos.
Era el momento de romper la baraja
En Noviembre de 2012, en el marco del evento Visual Studio Connect(), Microsoft presentó públicamente los detalles sobre lo que sería la próxima versión de ASP.NET, todavía en aquél momento llamada "ASP.NET vNext" o, internamente, "Project K". La idea era partir desde cero y crear una infraestructura ligera, modular, y capaz de ejecutarse tanto sobre .NET framework tradicional como en el nuevo .NET Core que comenzaba también a aparecer en el horizonte (y todavía no se llamaba así), abriendo la puerta a posibilidades inimaginables hasta el momento, como la ejecución multiplataforma, y a un rendimiento sin precedentes.
Como referencia, se estima que una petición típica en ASP.NET clásico (4.x) puede requerir un mínimo de 30Kb de memoria en el servidor para ser procesada, frente a los 2Kb de que se ocuparían en ASP.NET Core. Seguro que puedes imaginar la repercusión que puede tener esto en cuanto a aprovechamiento de recursos de un servidor en un sitio web con una carga media o alta.
Para nosotros los desarrolladores, el coste de acceder a estas ventajas está bien claro: ASP.NET Core rompe con las versiones anteriores en muchos aspectos. De hecho, es un entorno nuevo que tenemos que aprender y en el que tenemos que acostumbrarnos a trabajar.
Espero que esto te haya ayudado a entender por qué Microsoft ha tenido que crear ASP.NET Core y el camino que se ha recorrido hasta llegar aquí.
En un próximo artículo, la semana próxima, contaré cuáles son las principales novedades de ASP.NET Core y qué nos ofrece frente a ASP.NET tradicional. ¡Hasta entonces!
Fecha de publicación: