Windows Azure: introducción al entorno de tiempo de ejecución
Hay mucho que aprender al desarrollar aplicaciones para una nueva plataforma como Windows Azure. Éste es un cuento paso a paso de la experiencia de un desarrollador.
Jose Barreto
Hace poco aprendí a desarrollar, probar e implementar una aplicación de Windows Azure. Había escuchado mucho acerca de Windows Azure y vi muchas experiencias contadas por otras personas, pero quería experimentarlo en primera persona y validar lo que me habían contado. La versión de Visual Studio 2010 fue el último empujón que necesitaba para comenzar.
En este artículo describiré cómo creé e implementé una aplicación de ejemplo. Ésta siempre es una buena manera de lanzarse al agua con una tecnología nueva y me obligó a vivir todo el ciclo de vida de una aplicación en Windows Azure.
Mi experimentación se vio simplificada por el hecho de que anteriormente había desarrollado aplicaciones de ASP.NET, porque una aplicación de Windows Azure sigue la misma arquitectura, con funciones web (front-end web) y funciones de trabajador (servicios de back-end). La herramienta principal para desarrollar aplicaciones de Windows Azure y aplicaciones regulares de ASP.NET también es la misma: Visual Studio. Ya había instalado la versión final de Visual Studio 2010 en mi equipo con Windows 7 y también había agregado IIS como un componente opcional de mi sistema operativo.
Además de Visual Studio 2010 e IIS, también descargué las herramientas de Windows Azure, las cuales agregaron plantillas adicionales para el desarrollo de Windows Azure. Me interesaba comprender mejor el entorno en que se ejecutan las aplicaciones de Windows Azure. Sé en general que se trata de máquinas virtuales y que deben funcionar bien para sus aplicaciones, independientemente de sus detalles específicos de configuración, pero sentía curiosidad por saber cómo las implementaba Windows Azure. Como una persona con conocimientos en infraestructura de TI, siempre me interesa saber cómo es este tipo de implementación por dentro.
Para llegar ahí, decidí escribir una aplicación que acusara información acerca del sistema de archivos de la máquina en que se ejecuta: cosas sencillas como qué unidades existen y cuáles son sus características (tipo, sistema de archivos, tamaño total y espacio disponible). También agregué la capacidad de consultar carpetas y archivos, para poder entender qué existía dónde. En la Figura 1 se muestra aquello con lo que terminé.
.jpg)
Figura 1 Aplicación de informe de sistema de archivos de ejemplo en Windows Azure.
Nada complicado, como puede ver, sólo lo suficiente para comprender la experiencia de desarrollo, pasar por el proceso de implementación y tener las herramientas para entender el entorno de tiempo de ejecución de Windows Azure.
C# por la nube
Crear la aplicación fue bastante sencillo. Creé un proyecto nuevo con C# y seleccioné el proyecto de nube. Para no complicarlo, usé una función web única de ASP.NET pata mi proyecto de servicios de nube.
Luego arrastré algunos controles, agregué cierto código y comencé a probarlo. El proceso de desarrollo en su totalidad se ejecuta a nivel local, así que ni siquiera hay necesidad de tener una cuenta Windows Azure en ese punto. Tampoco estaba usando ningún almacenamiento de Windows Azure, así que era simplemente una función web sin dependencias externas. No era una aplicación normalmente muy útil, pero mi objetivo era crear algo así como un glorificado “Hola, mundo” para comenzar.
Como tenía todo .NET Framework de Microsoft disponible, escribir el código no fue difícil en absoluto.. Para obtener la información de las unidades, por ejemplo, usé System.IO namespace.
protected void btnDrives_Click(object sender, EventArgs e)
{
DriveInfo[] diAll = DriveInfo.GetDrives();
string strDrive = "";
foreach (DriveInfo diOne in diAll)
{
strDrive = "Drive " + diOne.Name + " Type:" + diOne.DriveType.ToString();
if (diOne.IsReady)
{
strDrive = strDrive + " Volume:" + diOne.VolumeLabel + " FS:" + diOne.DriveFormat.ToString() + " Total:" + diOne.TotalSize.ToString() + " Free:" + diOne.AvailableFreeSpace.ToString();
}
txtAdd(strDrive);
}
}
Aparte de que tuve que ejecutar Visual Studio como administrador, todo lo demás casi no presentó contratiempos en términos de desarrollo y depuración local de la aplicación. Visual Studio inició de manera automática el Entorno de simulación de Windows Azure a nivel local cuando ejecuté mi aplicación (consulte la Figura 2). Pude configurar puntos de interrupción, ver mi código en ejecución paso a paso y así sucesivamente. No hubo sorpresas.
.jpg)
Figura 2 Así se veía mi aplicación cuando se ejecutó en el Entorno de simulación de Windows Azure.
Implementación de aplicaciones de Azure
Quizás la parte más difícil para mí, al ser nuevo en Windows Azure, fue saber exactamente qué necesitaba para implementar mi aplicación. Una vez que crea su servicio en la UI web de Windows Azure, alcanza un punto en que puede implementar la aplicación.
Cuando hace clic en el botón Implementar, se le indica que proporcione dos archivos (un archivo de paquete de aplicaciones y un archivo de ajustes de configuración) junto con un Nombre de implementación de servicio. Había poco más en términos de sugerencias sobre cómo generarlos.
Después de pasar un tiempo en el entorno de Visual Studio, no pude encontrar la manera adecuada de crear esos archivos o incluso saber cuáles serían sus extensiones. Allí fue cuando tuve que consultar la documentación de Windows Azure por primera vez. Hasta este punto, me las había ido arreglando sobre la marcha. Resulta que tiene que hacer clic con el botón secundario en el proyecto Nube para encontrar la opción “Publicar …” para generar un paquete para Windows Azure.
Esto creará los dos archivos requeridos, un Paquete de servicios de nube (.cspkg) y una Configuración de servicios de nube (.cscfg). La opción “Publicar …” abre una ventana de Windows Explorer con la carpeta correcta (vea la Figura 3) así como una ventana de Internet Explorer con la URL correcta de Windows Azure.
.jpg)
Figura 3 La ventana de Windows Explorer se abrió con la opción “Publicar …”.
Una vez que ingresé todo, el servicio se publicó en segundos. Después de eso, al hacer clic en “Ejecutar” se implementó la aplicación. Allí es cuando la máquina virtual (VM) que contiene la aplicación en ejecución se aprovisiona y comienza. Ese paso tarda unos cuantos minutos.
Ejecución del servicio
El estado del servicio pasó de “Inicializando” a “Ocupado” a “Listo”. Después de eso, la implementación se completó y ejecutar el servicio significó simplemente pulsar la URL del sitio web en http://servicename.cloudapp.net.
Finalmente estaba listo para inspeccionar algunas de las características de la VM de Windows Azure en que se ejecutaba mi servicio. Primero, enumeré las unidades del sistema. Resulta que la VM tenía tres unidades (C:, D: y E:) como mostré en la Figura 1. Luego usé la aplicación para mirar las carpetas específicas y los archivos de cada unidad. Después de investigar más en detalle, llegué a una conclusión acerca de las tres unidades diferentes, que aparecen en la Figura 4.
Figura 4 Así es cómo se analizaba el almacenamiento en tres unidades.
.jpg)
Sí encontré documentación pertinente a la cantidad de almacenamiento que se puede especificar por VM. El tamaño predeterminado (pequeño) le ofrece 250GB de almacenamiento local. Ése era el tamaño de mi VM. Puede elegir otras más grandes con 500GB, 1000GB y 2000GB de almacenamiento local.
Sin embargo, no encontré documentación de este desglose entre las tres unidades (ni siquiera documentación de ningún tipo acerca de las tres unidades, punto). Sólo puedo decirle que los números de la Figura 4 fueron verdaderos para la implementación específica de mi aplicación en ese momento.
Si planea usar almacenamiento temporal local en su aplicación, debe consultar ladocumentación para Recursos de almacenamiento local. Aparentemente, estos recursos de almacenamiento local residen en la unidad C:, Pero debe usar la API para encontrar la ruta local exacta que se debe usar.
Si necesita almacenamiento permanente, debe buscar las muchas opciones que ofrece Windows Azure, incluidos blobs, tablas, colas, unidades y bases de datos de SQL Azure. Puede obtener acceso a ellos a través de API y no se almacenan como parte de su almacenamiento local de VM de Windows Azure.
Aspectos esenciales del almacenamiento provisional
Una última cosa que encontré interesante fue el proceso para implementar versiones adicionales de la aplicación. Windows Azure le permite colocar la nueva versión en un área de “almacenamiento provisional” aparte. Esto posibilita ejecutar y probar la nueva versión almacenada provisionalmente con una URL temporal mientras que la versión más antigua continúa en ejecución con la URL principal.
Cuando está seguro de que la versión está bien, puede simplemente cambiar los entornos almacenados provisionalmente y de producción. Esto se hace rápidamente, porque ambos entornos están completamente implementados en ese punto y en efecto sólo intercambia las dos URL. Si resulta que su versión nueva tiene algún problema, también puede revertir el intercambio rápidamente.
Empaquetado para la nube
Si está familiarizado con ASP.NET, la creación de aplicaciones en Windows Azure no es muy diferente, una vez que ya domina un par de conceptos adicionales. Aprendí mucho acerca de la manera en que se empaquetan las aplicaciones de Windows Azure y también comprendí los pasos de la implementación en más detalle.
Quedé conforme con mi experimento, al haber implementado mi primera aplicación de Windows Azure y obtenido más información acerca del tiempo de ejecución de Windows Azure en el proceso. Comprendí mejor las diferentes unidades que usan las VM de Windows Azure y pude entender los detalles de su implementación en mayor profundidad. No es que usted tenga que comprender estos detalles para implementar sus aplicaciones, pero a un desarrollador nunca le molesta comprender más a fondo lo que va por dentro.
.jpg)
Jose Barreto* es un destacado administrador de programas del equipo del servidor de archivos, parte de la división de servidores y nube de Microsoft. Se graduó en Informática en la Universidade Federal do Ceara en Brasil el año 1989 y se mudó a Estados Unidos en 2000. Barreto se unió a Microsoft el año 2002 en California y se trasladó al campus Redmond en 2007.*