Tips para el desarrollo de aplicaciones en Windows Azure

  • Article

En este post estaré acumulando una serie de tips apropiados para un mejor desarrollo de aplicaciones Web para Azure.

5. Ignorar los Errores del contexto de datos de Windows Azure producidos por el 404:

En Windows Azure podemos acceder al almacenamiento a través de REST. REST funciona a través de HTTP. Así que cuando consultamos un registro de una tabla y éste no se encuentra, el servicio nos retorna 404 (Not Found) Y entonces el contexto de datos que usamos para representar en memoria los datos de las tablas entonces genera una excepción a raíz de ese 404. Entonces para solventar esto tenemos dos opciones. La primera, manejar la excepción y la segunda sería ignorar este tipo de error, pues sabremos que se trata de un registro en una tabla no encontrado. Así que en la consulta lo que se haría sencillamente es observar la cantidad de registros retornados (count):

 context.IgnoreResourceNotFoundException=true;

Donde context es el objeto heredado de TableServiceContext a través del cual estamos accediendo a las tablas de Azure.

4. Escoja puntos cruciales para hacer programación alternativa

En algunos casos ud., querrá que su aplicación corra con los mínimos cambios independientemente de si está en un hosting tradicional o si está en el Cloud. Cosas que pueden cambiar, son por ejemplo los orígenes de las variables de configuración. Como lo vimos en el punto 3, una aplicación en cloud, generalmente tiene sus variables de configuración en caliente, puestas en el archivo de configuración del servicio, mientras en un hosting tradicional, esto se hace en el Web.config. Podemos usar la propiedad

 RoleEnvironment.IsAvailable

Para chequear si estamos corriendo en Azure (true) o no (false) de esta manera, determinar por ejemplo cuál de los archivos de configuración chequear para traer una variable.

Por ejemplo:

    1:  string enterprise =

    2:    RoleEnvironment.IsAvailable ?

    3:    RoleEnvironment.GetConfigurationSettingValue("EnterpriseName") :

    4:    ConfigurationManager.AppSettings.Get("EnterpriseName");

3. Web.Config o ServiceConfiguration.cscfg

Tanto las aplicaciones Web como los servicios de Cloud (CS) tienen archivos de configuración que permiten en teoría hacer modificaciones en caliente sobre los servicios sin tener que recompilarlos.

Pero por qué en teoría?

En teoría, porque cuando el sitio Web está en Azure, no tenemos la posibilidad de acceder al Web.Config como es tradicional en los hosters clásicos. En general, los archivos de las instancias de cómputo (Web.Role, Worker Role) no son accesibles por ejemplo con un FTP. Así que lo que tendríamos que hacer, es una aplicación que modifique los Web.Config internamente y lo peor de todo, hacer que se ejecute en todas las instancias Web que estemos corriendo. Como ven, no es muy práctico.

Entonces la opción sería editar el Web.Config y re empaquetar de nuevo el sitio y volverlo a subir… tedioso no?

Afortunadamente, tenemos el archivo ServiceConfiguration.cscfg. Éste sí es accesible desde el portal del desarrollador de Windows Azure y lo podemos bien sea editar allí en vivo o subir independientemente con la nueva versión que queramos.

Entonces lo que recomiendo es que si en su aplicación ud. tiene variables de configuración que cambian mucho durante la ejecución de la misma, éstas sean puestas en el archivo de configuración del servicio. Por otro lado si son variables que solo cambian de compilación en compilación, entonces está bien dejarlas en el Web.Config.

Recordemos que tanto el Web.Config como el ServiceConfiguration.cscfg son fácilmente accesibles en un proyecto de Cloud. Además es posible generar rutinas de programación que decidan ir a buscar las variables de configuración a uno u otro archivo dependiendo de cómo lo haya desplegado: hosted o en cloud.

2. Subir datos a las tablas de Azure

Esta operación puede tener tres connotaciones:

  • Subir dos o tres registros

  • Subir batch de cientos o algunos miles de registros

  • Subir miles y miles de registros:

    • Considere escribir una rutina usando el API del Storage de Windows Azure

Si usa Cloud Storage Studio, y está subiendo datos en español, es posible que el archivo plano que esté subiendo o el CSV que use para esto no se presente adecuadamente luego de cargarlo en la herramienta. Así que las tildes y eñes por ejemplo se le mostrarán como símbolos extraños y así subirán a la nube. Esto se soluciona fácilmente, usando archivos de texto o CSV grabados con la codificación UNICODE.

1. Desarrolle la parte visual del sitio web sin Azure

Suena curioso que para programar mejor para Azure, les de este consejo. Pero es muy apropiado en la medida de las posibilidades. A qué me refiero?

Todo lo que tiene que ver con el debugging y por supuesto el deployment de una aplicación Web en Windows Azure, trae de por sí, una estrecha relación con IIS, que es el servidor que se activa con los Web Roles.

Por eso, cada vez que ejecutamos la aplicación Web para Azure, se hace todo un deployment del sitio al IIS de manera automática.

Si nuestra máquina es lo suficientemente rápida, esto puede que no sea ninguna molestia. De lo contrario si puede llegar a tomar más tiempo que hacer un simple debug usando el servidor Cassini incluido en Visual Studio.

Sin embargo lo más importante durante el proceso de debug, es que las actualizaciones que hagamos a las páginas aspx o en general a cualquier recurso que haga parte del sitio mientras éste se está ejecutando en desarrollo, no se ve reflejado de inmediato en éste despliegue, debido a que como las fuentes ya están en un directorio virtual dentro del IIS, los cambios que hacemos por fuera no se ven reflejados sino hasta que se hace un nuevo despliegue, por lo que es necesario detener la aplicación y volver a ejecutar el despliegue; cosa que aunque es automática consume más tiempo que cuando usando el Cassini actualizamos las páginas en caliente para ver los cambios de inmediato. Esto es muy útil a la hora de refinar la apariencia gráfica de las páginas.

Por esto es que recomiendo trabajar las interfaces gráficas del sitio web de manera separada a Azure. Esto nos va a dar mucha más agilidad en este proceso. Cuando ya tengamos lo suficientemente estables estas páginas, podremos ya asociarlas a un Web Role y entonces refinar la integración con Cloud, lo que puede implicar cambiar ciertos métodos o valores quemados en la forma mientras ésta se diseñó.