En este artículo profundizaremos algo más sobre este servicio.

¿Qué ofrece Windows Azure Compute?

Windows Azure Compute nos proporciona un entorno para nuestras aplicaciones. De esta manera podremos centrarnos en el desarrollo de las mismas y abstraernos de la mayor parte de la administración, tanto de los servidores de pre producción como de producción.

Nuestras aplicaciones serán alojadas en máquinas virtuales dentro de los data center de Microsoft, con Windows Server 2008 R2 Enterprise de 64 bits como sistema operativo. Dependiendo de las necesidades de nuestras aplicaciones, la plataforma nos ofrece distintos tamaños de máquinas virtuales:

Tipo de apliaciones

En cuanto a las aplicaciones, podemos señalar dos tipos bien diferenciados:

¿Por dónde empiezo?

En este artículo vamos a centrarnos en .NET pero es importante saber que podemos desarrollar aplicaciones en cualquier otro lenguaje, como por ejemplo Java, Ruby o PHP. Para obtener más información al respecto tenemos disponible el siguiente enlace.

Hasta la versión 1.2 del SDK las versiones del IDE soportadas eran Visual Studio 2008 y 2010. Sin embargo, con la última actualización del SDK a la versión 1.3, en la actualidad solamente está disponible para la versión 2010 de Visual Studio y Visual Studio Express. Para descargar las herramientas necesarias tenemos dos opciones: Realizar la instalación través de Windows Platform Installer o bien mediante la descarga directa.

Una vez instalado, iniciamos Visual Studio 2010 con privilegios de administrador. Iniciamos la creación de un nuevo proyecto donde podemos ver un nuevo apartado para las aplicaciones de tipo Cloud.

Seleccionamos Windows Azure Project y modificamos el nombre del proyecto a HelloCloud. Hacemos clic en el botón OK para continuar con el asistente.

Como comentábamos en el apartado anterior, podemos dividir las aplicaciones en dos tipos: Web role y Worker role. Llegados a este punto podemos elegir cuales son los roles que queremos añadir a nuestro desarrollo:

• ASP.NET Web Role: Añade un proyecto del tipo Web Application.
• ASP.NET MVC 2 Web Role: Si bien a día de hoy ya podemos disfrutar de la versión 3 de ASP.NET MVC, cuando se publicó la última versión del SDK la última versión correspondía con ASP.NET MVC 2.
• WCF Service Web Role: Proyecto para crear servicios utilizando Windows Communication Foundation.
• Worker Role: Plantilla que nos permite la creación de aplicaciones que se ejecutan en segundo plano.
• CGI Web Role: Este rol está pensado específicamente para aplicaciones de tipo FastCGI. El ejemplo por excelencia es la creación de sitios PHP.

Para este ejemplo utilizaremos la primera opción. Si quisiéramos modificar el nombre del proyecto podemos hacerlo a través del lápiz situado a la derecha de aquellos que estén agregados:

Pulsamos OK para aceptar el Web role seleccionado y que proceda a generar la solución. Una vez finalizada la carga de los proyectos vemos que tenemos el siguiente resultado:

Como podemos ver, existen algunos cambios respecto a un proyecto Web Application. En primer lugar vemos que existe un nuevo proyecto en la parte superior que fundamentalmente se encargar de recopilar toda la información relativa al entorno cloud:

La carpeta Roles contendrá un archivo por cada proyecto que posteriormente deba desplegarse en Windows Azure. Si hacemos doble clic sobre WebRole1 podemos visualizar la configuración para ese rol en concreto:

La primera pestaña está destinada a una configuración muy general del rol. En ella podemos establecer el nivel de confianza que la plataforma va a utilizar para ejecutar la aplicación (Será importante tener Full trust si queremos ejecutar código no manejado como c++ por ejemplo), el número de instancias que queremos que sirvan nuestra aplicación, el tamaño de la máquina virtual, el protocolo de inicio que vamos a utilizar para las peticiones y un último apartado para habilitar y almacenar las trazas para el diagnóstico.

El apartado Settings será nuestro equivalente en la nube a la sección appSettings del archivo de configuración de la aplicación utilizado hasta ahora. Debido a que el archivo web.config no podrá ser modificado, a no ser que realicemos un despliegue nuevo, es importante almacenar en esta sección todas aquellas propiedades dinámicas que pueden ser susceptibles de cambio.

Endpoints será el encargado de registrar todos aquellos puntos de entrada que vayan a estar disponibles para interactuar con nuestra aplicación.

Local storage es un apartado donde podemos reservar directorios dentro de la instancia de la máquina virtual que se está ejecutando. Este apartado puede ser muy eficaz para ser usado como caché, almacenamiento de archivos temporales, etcétera.

Para configurar un directorio elegiremos un nombre, el tamaño máximo del espacio (el tamaño mínimo es 1 MB) y si queremos que ese espacio se limpie cuando el rol se recicle, es decir, si se reinicia, se actualiza el S.O, etcétera.

El apartado de Certificates tiene como objetivo asociar aquellos certificados disponibles a través de la plataforma. Un ejemplo de uso para este apartado es registrar aquellos certificados que estarán asociados a las peticiones HTTPS.

Por último, Virtual Network solamente se utilizará para aquellas aplicaciones que requieran conexión con servidores on premise a través de Windows Azure Connect.

Una vez que hemos repasado toda la configuración disponible a través de pestañas, podemos decir que ServiceConfiguration.cscfg y ServiceDefiniton.csdef almacenan de manera conjunta la misma información mostrada en los apartados anteriores en formato XML :-)

Por otro lado, dentro de la aplicación web aparece un nuevo archivo llamado WebRole.cs. Este archivo es el punto de entrada a la aplicación donde frecuentemente podemos encontrar parámetros de configuración iniciales.

Para este ejemplo, solamente vamos a modificar sutilmente el código del Default.aspx , para mostrar el nombre del servidor que está sirviendo esta página.

<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebRole1._Default" %>

<asp:Content ID="HeaderContent" runat="server" ContentPlaceHolderID="HeadContent">
</asp:Content>
<asp:Content ID="BodyContent" runat="server" ContentPlaceHolderID="MainContent">
<h2>
Welcome to ASP.NET!
</h2>
<p>
<%:Server.MachineName %>
</p>
<p>
You can also find <a href="http://go.microsoft.com/fwlink/?LinkID=152368&clcid=0x409"
title="MSDN ASP.NET Docs">documentation on ASP.NET at MSDN</a>.
</p>
</asp:Content>

Entorno de pruebas

Para evitar el gasto innecesario a la hora de probar nuestras aplicaciones, el equipo de Windows Azure Platform nos ha proporcionado un entorno de pruebas en local para simular el despliegue de nuestra aplicación en la nube :-) Este entorno está divido en dos: Compute Emulator para simular los roles que hemos implementado y Storage Emulator para el servicio Windows Azure Storage, del cual hablaremos en los próximos artículos.

Centrándonos en Compute Emulator, cuando arrancamos la aplicación desde Visual Studio 2010 de forma automática ejecutará los dos entornos de simulación. Para acceder a los mismos basta con pulsar sobre el siguiente icono de la barra de tareas con el botón derecho:

Si pulsamos sobre Show Compute Emulator UI podemos visualizar la interfaz de este emulador:

En él visualizamos los desarrollos que están siendo simulados. En este caso concreto vemos nuestra solución HelloCloud con el WebRole1 que creamos anteriormente. El círculo de color verde se trata de la instancia que tenemos iniciada para nuestra aplicación. En realidad estas instancias se tratan del número de máquinas virtuales que queremos que sirvan los desarrollos. Por cada instancia que tengamos iniciada tendremos una consola donde nos informa del estado de la misma así como las trazas que hayamos registrado.

Resumén

En este artículo hemos visto qué es necesitamos para crear una aplicación apta para Windows Azure, cuáles son los parámetros de configuración existentes así como el entorno de emulación de plataforma en local.

En el próximo artículo veremos cómo desplegar nuestra aplicación en los data centers de Microsoft.