Migracin de un entorno web tradicional a la nube:

En los das de hoy, donde la nube ofrece muchos privilegios de cara a costes frente a la construccin y el mantenimiento de los entornos propios de alta disponibilidad y escalabilidad. No podemos dejar de reconocer, que esta migracin nunca ser del todo automtica y queremos esclarecer los posibles problemas y soluciones a los que nos deberamos enfrentar si queremos migrar nuestro entorno web tradicional a la nube. Viniendo de administrar y mantener entornos web en alta disponibilidad, nos encontramos que el primer problema que tenemos es el manejo de las sesiones del usuario. Tratndose de un usuario autentificado o no, el desarrollador utiliza las sesiones para guardar aquellos datos del usuario cuyo valor sea sensible para mostrar uno u otro contenido (o no mostrar, aunque entramos en el mundo de sesiones autentificadas), y que son necesarios en cada peticin que hace el usuario al servidor. Pongmonos en el caso de cualquier servidor de correo con interfaz web, en funcin del usuario autentificado, el programador almacenar en sesin aquellos datos del usuario requeridos por l, para luego mostrarle en cada peticin sus datos (en este caso correos). En ms de una ocasin nos hemos encontrado con que un programador no es consciente de donde se almacenan estas sesiones, sino que abstrados dentro de su entorno de desarrollo, cuentan con ello como algo habitual que siempre estar ah, pero a veces ni conoce donde se almacenan. Por defecto, en casi cualquier framework web, nos encontramos que el modo por defecto es la memoria RAM del ordenador. Dentro del desarrollo bajo asp.net, tanto en webforms, como en MVC, nos encontramos por defecto el valor "INPROC" que corresponde al uso de la RAM de la mquina. Hay otras opciones como el almacenamiento en base de datos, pero que rpidamente nos damos cuenta de lo que penalizara el rendimiento de la aplicacin, por lo que sera muy raro encontramos un entorno de produccin con un buen nmero de usuarios usando este modo. Centrndonos en el que las sesiones van en memoria de la mquina, ya podemos avanzar en que en un entorno de alta disponibilidad donde al menos tengamos dos mquinas como frontales atendiendo peticiones, tendremos un balanceador de carga, que se encargar de enviar a cada mquina las mismas peticiones en las que inici la sesin el usuario (y se creo la sesin en memoria del servidor), porque si no se producira un corte de la sesin del usuario dado que la mquina no encuentra en memoria los datos del usuario. El balanceador se encarga de esnifear las peticiones y almacenar en su memoria, que mquina corresponde por cada peticin. Aqu ya podemos hablar de la nube y decir que todas las instancias de los webroles de azure carecen de memoria, o mejor dicho, de su posible uso para las variables de sesin. Como solucin tenemos la existencia de la cach de azure, la cual nos parece ineficiente para ciertos entornos, adems de cara. El objetivo de este post no es de hablar de la cach de Azure, pero slo mencionaremos que lo mximo que ofrecen son 4 GB y que no es escalable de manera automtica, o sea, que si nos

falta cach en un momento, no podemos programar su aumento como si podemos programar la escalabilidad de levantar otra instancia para poder atender ms peticiones. La solucin del uso de las sesiones en SQL de Azure, ya hablamos que penalizara el rendimiento de la aplicacin, y en nuestro caso aumentara los costos. Quizs esta sera la nica manera de una migracin de un entorno web tradicional a la nube sin cambios en la aplicacin, pero tenemos otra mejor solucin que implica mejores costos y rendimiento. Para esto deberamos almacenar las sesiones en tablas de storage, que sern igual de accesibles por cualquier instancia de la aplicacin que tengamos corriendo, sin necesidad de un balanceador de carga como en los entornos adicionales. Para esto slo tendramos que desarrollar en entornos microsoft un session custom provider para aplicaciones de entornos microsoft, o un conjunto de clases que realice las mismas funciones en otros entornos. En entornos microsoft, sera simplemente modificar en el web config de la aplicacin el sesin state con un custom provider. No deberamos hacer ningn tipo ms de modificacin en todo el desarrollo de la aplicacin, ms que incorporar la clase que implemente el session custom provider. En este enlace de la MSDN encontraris lo necesario para su implementacin http://msdn.microsoft.com/en-us/library/ms178587.aspx. Ahora slo podramos encontrar un problema si los 150GB que ofrece de mximo una base de datos de SQL AZURE se pueden quedar cortos para tu aplicacin. Pero podemos aventurar que al igual que el mximo hasta hace no mucho eran menos de 150 GB, en un futuro estamos seguros que la cantidad de almacenamiento de SQL AZURE crecer. Con esto podemos concluir que migrar a un entorno cloud desde un sistema web tradicional no supone un coste extra adicional en el desarrollo de la misma, y s podemos asegurar que los costes de despliegue y mantenimiento de la misma sern mucho menores. Si el lector quiere un coste real de un sistema tradicional mnimo de alta disponibilidad contra los costes de este mismo sistema en Azure, estaremos encantados de escribir un nuevo post.

Javier Franco