Me sirve en Development Environment, pero no en Azure!

Este post estará dedicado a recopilar las posibles causas por las cuales una aplicación Windows Azure corre bien en desarrollo, pero no puesta en el cloud.

1. Aplicaciones basadas en la hora: Recuerden muy bien que la hora de los servidores en Windows Azure, no es la misma que aquella que uds. tienen en sus máquinas de desarrollo. Bueno, a menos que vivan sobre el meridiano de Greenwich. Para ser más explícitos, la hora de estos servidores es UTC. Mientras que por ejemplo Colombia es UTC-5. Así que tengan esto en sus cuentas.

2. La cultura por defecto en los servidores de Azure, puede variar con respecto a la de sus máquinas. En Azure es por defecto en-US, con todo lo que esto conlleva con respecto a determinación del punto decimal y demás. Si ustedes por ejemplo tienen una rutina que convierte strings en números decimales, tengan muy en cuenta que los símbolos de separación de decimales por ejemplo pueden cambiar y la aplicación se comportará distinto. Esto puede pasar con fechas, etc.

3. Por defecto Windows Azure no maneja variables de sesión ni aplicación distribuidas. Así que si observan que los valores de estas variables desaparecen cuando tienen más de una instancia en la nube, piensen que es hora de adquirir los servicios de AppFabric para poder tener este caché distribuido y que sus aplicaciones se comporten igual en la nube. Por qué pasa esto? Cuando hacemos un request, nos contesta por ejemplo el WebRole A. Allí iniciamos la variable de sesión MiIngenuaVariable. Luego volvemos a hacer un request, pero esta vez el LoadBalancer lo envía al WebRole B. Estos WebRoles, no comparten la memoria y solo fueron iguales al principio de la ejecución del servicio. Luego cada uno comenzó a tener una historia distinta. Entonces cuando consultamos la variable MiIngenuaVariable, claro, estará en NULL.

4. Creé un pdf, lo grabe en el disco duro del servidor y luego cuando lo llamé ya no estaba? Juas! Muchos me han llegado con ese problema y es muy parecido al anterior. Recuerden que no se comparte el estado cuando tenemos varias instancias. Entonces una instancia no tiene ni idea de lo que hemos grabado en el disco duro de otra. Así pues, la solución es que los archivos que requieran ser consultados luego, los graben en el Blob Storage, donde quedarán con una dirección única accesible desde cualquier instancia o desde cualquier parte del universo que posea internet.

5. Los cambios que hago en mi despliegue se revierten! Despliego mi servicio, luego ejecuto una rutina para modificar unos archivos de configuración (bien sea incluida en el servicio, o a través de RDP). Luego al otro día, esos archivos de configuración ya no están como los dejé y el servicio me falla!!! Eso pasa, porque en Windows Azure las máquinas ocasionalmente se reinician y vuelven a su estado original; esto es producto de patchs que se aplican, o reinicios determinados por el AppFabric al ver que una instancia se está comportando necia, o no quiere responder educadamente. En esots casos, la instalación vuelve a quedar idénticamente a como estaba la primera vez. No esperes encontrar tus modificaciones en caliente! Se espera que a futuro cercano los VM Role de Windows Azure tengan estas capacidades. Se llamarán VM Role Persistentes. Por ahora, lo recomendado obviamente es que estos valores de configuración sean almacenados en el archivo ServiceConfiguration, que es una archivo separado del paquete de despliegue, por lo que sus valores permanecerán una vez sean modificados, aun cuando se reinicien las instancias. Lo mejor de todo, es que estos valores se pueden cambiar “en caliente” de una manera muy sencilla desde el portal de Windows Azure.

6. La aplicación me trae los datos más rápido de mi SQL Server local que de SQL Azure! Por caridad, espero que no hayan puesto en Azure la DB de SQL Azure en North US y luego la aplicación en South Central! Imagínense la cantidad de espacio que han de recorrer sus datos antes de llegar al destino! Usen siempre el mismo grupo de afinidad! Para Colombia y Sur América en general, es mejor siempre poner todo en South Central US.

Otros ejemplos que vaya encontrando los iré anexando a esta guía. Keep on coding!