PRESENTACIÓN DE WINDOWS AZURE

PRESENTACIÓN DE WINDOWS AZURE DAVID CHAPPELL OCTUBRE DE 2010 PATROCINADO POR MICROSOFT CORPORATION

CONTENIDO Información general sobre Windows Azure... 2 Compute... 4 Storage... 6 Fabric Controller... 7 Red de entrega de contenido... 9 Connect... 10 Uso de Windows Azure: escenarios... 12 Creación de una aplicación web escalable... 12 Creación de una aplicación de procesamiento paralelo... 13 Creación de una aplicación web escalable con procesamiento en segundo plano... 14 Creación de una aplicación web con datos relacionales... 15 Migración de una aplicación web on-premises con datos relacionales... 17 Uso del almacenamiento en la nube desde una aplicación on-premises u hospedada... 18 Descripción de Windows Azure: enfoque más detallado... 18 Creación de aplicaciones de Windows Azure... 19 Análisis del servicio Compute... 19 Análisis del servicio Storage... 20 Blobs... 20 Tablas... 22 Colas... 23 Análisis de Fabric Controller... 25 Perspectivas de futuro... 26 Conclusiones... 27 Lecturas adicionales... 27 Sobre el autor... 27 1

INFORMACIÓN GENERAL SOBRE WINDOWS AZURE Han llegado las aplicaciones en la nube. Ejecutar aplicaciones y almacenar datos en máquinas de un centro de datos al que se obtiene acceso a través de Internet puede suponer muchas ventajas. No obstante, independientemente del lugar en el que se ejecuten, las aplicaciones se basan en algún tipo de plataforma. Para las aplicaciones on-premises, tales como las que se ejecutan en el centro de datos de una organización, esta plataforma suele incluir un sistema operativo, algún método para almacenar datos y posiblemente otras funciones. Las aplicaciones que se ejecutan en la nube necesitan una base parecida. El objetivo de la plataforma Windows Azure es proporcionar esta base. Como parte de la plataforma Windows Azure más grande, Windows Azure constituye la base para ejecutar aplicaciones y almacenar datos en la nube. La figura 1 ilustra esta idea. Empresas Consumidores Internet Aplicaciones Datos Windows Azure Centros de datos de Microsoft Figura 1: Las aplicaciones de Windows Azure se ejecutan en centros de datos de Microsoft y se obtiene acceso a las mismas a través de Internet. En lugar de proporcionar software que los clientes de Microsoft pueden instalar y ejecutar por sí mismos en sus propios equipos, Windows Azure hoy en día es un servicio: los clientes lo usan para ejecutar aplicaciones y almacenar datos en máquinas a las que se obtiene acceso a través de Internet y que son propiedad de Microsoft. Dichas aplicaciones pueden proporcionar servicios a empresas, a consumidores o a ambos. A continuación se muestran ejemplos de los tipos de aplicaciones que pueden crearse en Windows Azure: Un fabricante de software independiente (ISV) podría crear una aplicación destinada a usuarios empresariales, un enfoque al que se hace referencia a menudo como software como servicio (SaaS). Windows Azure se diseñó, en parte, para proporcionar soporte a las aplicaciones SaaS propias de Microsoft, de modo que los ISV puedan usarlo como base para una variedad de software empresarial en la nube. 2

Un ISV puede crear una aplicación SaaS dirigida a los consumidores en lugar de las empresas. La plataforma Windows Azure está diseñada para dar soporte a software muy escalable, por lo que una empresa que tiene como objetivo un mercado con muchos consumidores puede usarla como plataforma para una nueva aplicación. Las empresas pueden usar Windows Azure para crear y ejecutar aplicaciones usadas por sus propios empleados. Si bien esta situación probablemente no requerirá la enorme escala de una aplicación destinada a los consumidores, la confiabilidad y capacidad de administración que ofrece Windows Azure puede hacer que esta plataforma sea una opción atractiva. Para dar soporte a las aplicaciones y los datos en la nube, Windows Azure cuenta con cinco componentes, como indica la figura 2. Aplicaciones y datos CDN Connect Compute Storage Fabric Controller Figura 2: Windows Azure cuenta con cinco componentes principales, Compute, Storage, Fabric Controller, CDN y Connect. Los componentes son los siguientes: Windows Azure Compute: ejecuta aplicaciones en la nube. Estas aplicaciones ven un entorno de Windows Server, aunque el modelo de programación de Windows Azure no sea exactamente igual que el modelo Windows on-premises. Storage: almacena datos binarios y estructurados en la nube. Fabric Controller: implementa, administra y supervisa las aplicaciones. Fabric Controller también gestiona las actualizaciones al software del sistema en toda la plataforma. Red de entrega de contenido (CDN): acelera el acceso global a los datos binarios de Windows Azure Storage al mantener copias en caché de éstos en todo el mundo. Connect: permite crear conexiones de nivel IP entre los equipos on-premises y las aplicaciones de Windows Azure. En el resto de esta sección se ofrece una introducción a cada una de estas tecnologías. 3

COMPUTE Windows Azure Compute puede ejecutar aplicaciones de muchos tipos. Sin embargo, haga lo que haga una aplicación, primero deberá implementarse como uno o más roles. A continuación, Windows Azure suele ejecutar varias instancias de cada rol, usando el equilibrio de carga integrado para distribuir las solicitudes entre ellas. La figura 3 ilustra su aspecto. Instancias de Web Role Instancias de rol de trabajador Instancias de rol de VM IIS Equilibrador de carga HTTP/HTTPS, TCP Máquinas virtuales Aplicaciones y datos CDN Connect Compute Storage Fabric Controller Figura 3: Una aplicación de Windows Azure en ejecución consta de cualquier combinación de instancias de Web Role, rol de trabajador y rol de máquina virtual (VM). En la versión actual de Windows Azure, los programadores pueden elegir entre tres tipos de roles: Los roles web están diseñados principalmente para facilitar la creación de aplicaciones web. Cada instancia de Web Role tiene preconfigurado Internet Information Services (IIS) 7, de modo que la creación de aplicaciones mediante ASP.NET, Windows Communication Foundation (WCF) u otras tecnologías web es sencilla. Asimismo, los programadores pueden crear aplicaciones en código nativo, no siendo necesario usar.net Framework. Esto significa que los programadores también pueden instalar y ejecutar tecnologías distintas de Microsoft, incluidas PHP y Java. Los roles de trabajador están diseñados para ejecutar una variedad de código basado en Windows. La mayor diferencia entre un Web Role y un rol de trabajador es que este último no tiene configurado IIS, por lo que el código que ejecutan no lo hospeda IIS. Un rol de trabajador puede, por ejemplo, ejecutar una simulación, gestionar el procesamiento de vídeo o hacer casi cualquier otra cosa. Con frecuencia, una aplicación interactúa con los usuarios a través de un Web Role y luego pasa las tareas a un rol de trabajador para su procesamiento. Nuevamente, los programadores pueden usar.net Framework u otro software que se ejecuta en Windows, incluidas tecnologías distintas de las de Microsoft. 4

Los roles de máquina virtual (VM) ejecutan una imagen de Windows Server 2008 R2 proporcionada por el usuario. Entre otras cosas, un rol de VM a veces puede ser de utilidad a la hora de trasladar una aplicación de Windows Server on-premises a Windows Azure. Para enviar una aplicación a Windows Azure, los programadores pueden usar el portal de Windows Azure. Junto con la aplicación, envían la información de configuración que indica a la plataforma el número de instancias de cada rol que se debe ejecutar. A continuación, Windows Azure Fabric Controller crea una máquina virtual para cada instancia y ejecuta el código para el rol adecuado en ella. Como indica la figura 3, las solicitudes de los usuarios de las aplicaciones se pueden realizar mediante protocolos como, por ejemplo, HTTP, HTTPS y TCP. Lleguen como lleguen las solicitudes, se realiza un equilibrio de la carga de éstas entre todas las instancias de un rol. El equilibrador de carga no permite crear una afinidad con una instancia de rol en particular (no se admiten sesiones permanentes), por lo que se puede garantizar que varias solicitudes del mismo usuario se envíen a la misma instancia de un rol. Esto implica que las instancias de rol de Windows Azure no deberían mantener su estado por sí mismas entre solicitudes. En cambio, cualquier estado específico del cliente debe escribirse en Windows Azure Storage, almacenarse en SQL Azure (otro componente de la plataforma Windows Azure) o mantenerse externamente de algún otro modo. Los programadores pueden usar cualquier combinación de instancias de Web Role, de trabajador y de VM para crear una aplicación de Windows Azure. Si la carga de la aplicación aumenta, puede usar el portal de Windows Azure para solicitar instancias adicionales de cualquiera de los roles de su aplicación. Si la carga disminuye, puede reducir el número de instancias en ejecución. Windows Azure también expone una API que permite que todo esto se lleve a cabo a nivel de programación (no es necesario intervenir manualmente para cambiar el número de instancias en ejecución), pero la plataforma no escala automáticamente las aplicaciones en función de su carga. Para crear aplicaciones de Windows Azure, un programador usa los mismos lenguajes y herramientas que para cualquier aplicación de Windows. Puede escribir un Web Role mediante ASP.NET y Visual Basic, por ejemplo, o usar WCF y C#. De forma parecida, puede crear un rol de trabajador en uno de estos lenguajes.net, trabajar directamente en C++ sin.net Framework o usar Java. Además, si bien Windows Azure proporciona complementos para Visual Studio, no es necesario usar este entorno de desarrollo. Un programador que tiene instalado PHP, por ejemplo, puede optar por usar otra herramienta para escribir aplicaciones. Para permitir la supervisión y depuración de aplicaciones de Windows Azure, cada instancia puede llamar a una API de registro que escribe información en un registro común para toda la aplicación. Los programadores también pueden configurar el sistema para recopilar contadores de rendimiento para una aplicación, medir el uso de la CPU, almacenar volcados de memoria si falla y mucho más. Esta información se guarda en Windows Azure Storage y los programadores pueden escribir código para examinarla. Por ejemplo, si una instancia de rol de trabajador se bloquea tres veces en una hora, un código personalizado puede enviar un mensaje de correo electrónico al administrador de la aplicación. La capacidad de ejecutar código es una parte fundamental de una plataforma en la nube, pero no es suficiente. Las aplicaciones también necesitan un almacenamiento persistente. Satisfacer esta necesidad es el objetivo del servicio Windows Azure Storage, que se describe a continuación. 5

STORAGE Las aplicaciones usan los datos de distintas formas. Por consiguiente, el servicio Windows Azure Storage proporciona varias opciones. La figura 4 muestra las opciones. Blobs Tablas Colas HTTP/HTTPS, OData Aplicaciones y datos CDN Connect Compute Storage Fabric Controller Figura 4: El servicio Windows Azure Storage proporciona blobs, tablas y colas. La forma más sencilla de almacenar datos en Windows Azure Storage es usar blobs. Un blob contiene datos binarios y, como se sugiere en la figura 4, tiene una jerarquía simple. Cada contenedor puede incluir uno o más blobs. Los blobs pueden ser de gran tamaño (hasta un terabyte) y pueden tener metadatos asociados, como por ejemplo, información acerca del lugar en el que se ha tomado una fotografía JPEG o quién es el cantante de un archivo MP3. Además, los blobs proporcionan el almacenamiento subyacente para las unidades de Windows Azure, un mecanismo que permite a una instancia de rol de Windows Azure interactuar con el almacenamiento persistente como si fuera un sistema NTFS local. Los blobs son muy adecuados para algunas situaciones, pero son demasiado poco estructurados para otras. A fin de permitir que las aplicaciones usen datos de forma más específica, Windows Azure Storage proporciona tablas. No deje que el nombre le confunda, no se trata de tablas relacionales. Los datos que contiene cada una en realidad se almacenan en un grupo de entidades que contiene propiedades. Además, en lugar de usar SQL, una aplicación puede consultar los datos de una tabla mediante las convenciones que define OData. Este método permite disponer de un almacenamiento ampliable (ampliación mediante la distribución de datos entre varias máquinas) de manera más eficaz que la que sería posible mediante una base de datos relacional estándar. En realidad, una única tabla de Windows Azure puede contener miles de millones de entidades que incluyen terabytes de datos. Los blobs y las tablas se centran en almacenar y obtener acceso a los datos. La finalidad de la tercera opción de Windows Azure Storage, las colas, es bastante distinta. Una de las funciones principales de las 6

colas es proporcionar un método para que las instancias de Web Role puedan comunicarse de forma asíncrona con las instancias de rol de trabajador. Por ejemplo, un usuario puede enviar una solicitud para realizar una tarea que requiere muchos procesos a través de una interfaz web implementada por un Web Role de Windows Azure. La instancia de Web Role que recibe esta solicitud puede escribir un mensaje en una cola describiendo el trabajo que debe llevarse a cabo. Una instancia de rol de trabajador que espera en esta cola puede leer el mensaje y ejecutar la tarea especificada. Los resultados pueden devolverse a través de otra cola o gestionarse de otro modo. Independientemente de cómo se almacenen los datos (en blobs, tablas o colas), toda la información incluida en Windows Azure Storage se replica tres veces. Esta réplica permite la tolerancia a errores, ya que perder una copia no es muy grave. No obstante, el sistema proporciona un elevado nivel de coherencia, por lo que una aplicación que inmediatamente lee datos que acaba de escribir obtiene los datos que acaba de escribir. Windows Azure también mantiene una copia de seguridad de todos los datos en otro centro de datos de la misma parte del mundo. Si el centro de datos que contiene la copia principal no está disponible o se destruye, esta copia de seguridad permanece accesible. El acceso al servicio Windows Azure Storage puede realizarse a través de aplicaciones de Windows Azure, una aplicación on-premises o una aplicación que se ejecuta en un proveedor de servicios de hosting u otra plataforma en la nube. En todos estos casos, los tres estilos de Windows Azure Storage usan las convenciones de REST para identificar y exponer los datos, como se muestra en la figura 4. Para los nombres de los blobs, las tablas y las colas, se usan URI, y a todos ellos se obtiene acceso a través de operaciones HTTP estándar. Para ello, un cliente.net puede usar una biblioteca proporcionada por Windows Azure aunque no es obligatorio; una aplicación también puede realizar llamadas HTTP sin formato. Puede resultar de gran utilidad crear aplicaciones de Windows Azure que usen blobs, tablas y colas. Las aplicaciones que dependen de almacenamiento relacional pueden, en cambio, usar SQL Azure, que es otro componente de la plataforma Windows Azure. Las aplicaciones que se ejecutan en Windows Azure (o en otros lugares) pueden usar esta tecnología para obtener un acceso familiar basado en SQL al almacenamiento relacional de la nube. FABRIC CONTROLLER Todas las aplicaciones de Windows Azure y todos los datos de Windows Azure Storage se encuentran en algún centro de datos de Microsoft. Dentro de dicho centro de datos, el conjunto de máquinas dedicadas a Windows Azure y el software que ejecutan se administran mediante Fabric Controller. La figura 5 ilustra esta idea. 7

Almacenamiento Instancias de rol Agente de entramado Agente de entramado Fabric Controller Aplicaciones y datos CDN Connect Compute Storage Fabric Controller Figura 5: Fabric Controller interactúa con las aplicaciones de Windows Azure a través del agente del entramado. Fabric Controller es, en sí, una aplicación distribuida que se replica entre un grupo de máquinas y controla todos los recursos de su entorno; equipos, conmutadores, equilibradores de carga y mucho más. Dado que puede comunicarse con un agente de entramado en cada equipo, también sabe qué aplicaciones de Windows Azure hay en este entramado. (Curiosamente, Fabric Controller ve Windows Azure Storage como cualquier otra aplicación y, por consiguiente, los detalles de la administración y replicación de datos no son visibles para el controlador). Este amplio conocimiento permite a Fabric Controller realizar varias tareas muy útiles. Supervisa todas las aplicaciones en ejecución, por ejemplo, mostrando una imagen de qué ocurre en cada momento en el entramado. También decide si deben ejecutarse nuevas aplicaciones y elige los servidores físicos para optimizar el uso de hardware. Para ello, Fabric Controller se basa en la información de configuración que se carga con cada aplicación de Windows Azure. Este archivo proporciona una descripción basada en XML de todo lo que necesita la aplicación: número de instancias de Web Role, número de instancias de rol de trabajador, etc. Cuando Fabric Controller implementa una nueva aplicación, utiliza este archivo de configuración para determinar el número de VM que se debe crear. Una vez que se hayan creado las VM, Fabric Controller supervisa cada una de ellas. Si una aplicación requiere cinco instancias de Web Role y una de ellas falla, por ejemplo, Fabric Controller reiniciará automáticamente una nueva. De forma parecida, si la máquina en la que se ejecuta una VM falla, Fabric Controller iniciará una nueva instancia de Web Role o de trabajador en una nueva VM en otra máquina y restablecerá el equilibrador de carga según sea necesario para apuntar a esta nueva VM. Actualmente, Windows Azure proporciona a los programadores cinco tamaños de VM entre los que elegir. 8

Las opciones son: Extrapequeña, con una CPU de un núcleo de 1,0 GHz, 768 MB de memoria y 20 GB de almacenamiento de instancias. Pequeña, con una CPU de un núcleo de 1,6 GHz, 1,75 GB de memoria y 225 GB de almacenamiento de instancias. Mediana, con una CPU de dos núcleos de 1,6 GHz, 3,5 GB de memoria y 490 GB de almacenamiento de instancias. Grande, con una CPU de cuatro núcleos de 1,6 GHz, 7 GB de memoria y 1.000 GB de almacenamiento de instancias. Extragrande, con una CPU de ocho núcleos de 1,6 GHz, 14 GB de memoria y 2.040 GB de almacenamiento de instancias. Una instancia extrapequeña comparte un núcleo de procesador con otras instancias extrapequeñas. Sin embargo, para el resto de tamaños, cada instancia cuenta con un núcleo compartido o más. Esto significa que el rendimiento de las aplicaciones puede predecirse, sin ningún límite arbitrario sobre el tiempo durante el que se puede ejecutar una instancia. Una instancia de Web Role, por ejemplo, puede tardar todo el tiempo que sea necesario para gestionar una solicitud de un usuario, mientras una instancia de rol de trabajador puede procesar el valor de pi en millones de dígitos. En el caso de los roles web y de trabajador (pero no los roles de VM), Fabric Controller también administra el sistema operativo de cada instancia. Esto incluye tareas como, por ejemplo, la aplicación de revisiones del sistema operativo y la actualización de otro software del sistema. De este modo, los programadores pueden centrarse exclusivamente en la creación de aplicaciones, ya que no tendrán que preocuparse de la administración de la plataforma en sí. Sin embargo, es importante comprender que Fabric Controller siempre supone que se ejecutan dos instancias de cada rol. De este modo, puede cerrar una de ellas para actualizar su software sin tener que cerrar toda la aplicación. Por este motivo, entre otros, no es buena idea ejecutar una sola instancia de cualquier rol de Windows Azure. RED DE ENTREGA DE CONTENIDO Un uso común de los blobs es almacenar información a la que se obtendrá acceso desde lugares muy distintos. Supongamos, por ejemplo, una aplicación que sirve vídeos a clientes Flash, Silverlight o HTML 5 de todo el mundo. Para mejorar el rendimiento en situaciones de este tipo, Windows Azure proporciona una red de entrega de contenido (CDN). La CDN almacena copias de un blob en sitios más cercanos a los clientes que usan los datos del blob. La figura 6 ilustra esta idea. 9

Blobs Windows Azure Aplicaciones y datos CDN Connect Compute Storage Fabric Controller Figura 6: La CDN de Windows Azure almacena en caché copias de blobs de todo el mundo, proporcionando a los usuarios acceso más rápido a esa información. La figura no debe interpretarse de manera literal. En realidad, Windows Azure CDN tiene muchas más ubicaciones de almacenamiento en caché que las que se muestran, pero el concepto es correcto. La primera vez que un usuario obtiene acceso a un blob, la CDN almacena una copia del mismo en una ubicación geográficamente cercana a dicho usuario. La próxima vez que se obtenga acceso al blob, su contenido se enviará desde la memoria caché en lugar del lugar original más remoto. Por ejemplo, supongamos que Windows Azure se usa para proporcionar vídeos de los eventos deportivos de un día a un público lejano. El primer usuario que obtenga acceso a un vídeo concreto no disfrutará de las ventajas que ofrece la CDN, ya que el blob todavía no se ha almacenado en caché en una ubicación más cercana. Sin embargo, todos los demás usuarios dentro de la misma zona geográfica obtendrán un mejor rendimiento, ya que el uso de la copia en caché permite que el vídeo se cargue con mayor rapidez. CONNECT Ejecutar aplicaciones en la nube de Microsoft es de gran utilidad. Sin embargo, las aplicaciones y los datos que se usan en las organizaciones no desaparecerán en un futuro cercano. Por consiguiente, conectar de manera eficaz los entornos on-premises con Windows Azure es importante. Windows Azure Connect está diseñado para ayudar en esto. Al proporcionar una conectividad de nivel de IP entre una aplicación de Windows Azure y máquinas que se ejecutan fuera de la nube de Microsoft, esta combinación puede ser más fácil de usar. La figura 7 ilustra esta idea. 10

Aplicaciones y datos Instancias de rol Agente de extremo IPsec Equipo Windows local Windows Azure Compute Aplicaciones y datos CDN Connect Compute Storage Fabric Controller Figura 7: Windows Azure Connect permite una comunicación de nivel de IP entre una máquina Windows on-premises y una aplicación de Windows Azure. Como muestra la figura, el uso de Windows Azure Connect requiere la instalación de un agente de extremo en cada equipo on-premises que se conecta a una aplicación de Windows Azure. (Dado que la tecnología depende de IP v6, actualmente el agente de extremo está disponible solo para Windows Server 2008, Windows Server 2008 R2, Windows Vista y Windows 7). Además, la aplicación de Windows Azure debe configurarse para funcionar con Windows Azure Connect. De este modo, el agente puede usar IPsec para interactuar con un rol concreto de dicha aplicación. Tenga en cuenta que no se trata de una red privada virtual (VPN) completa. Si bien Microsoft ha anunciado la intención de ofrecer esta capacidad, Windows Azure Connect es una solución más sencilla. La configuración no requiere ponerse en contacto con el administrador de red, por ejemplo. Lo único que se necesita es capacidad para instalar el agente de extremo en la máquina local. Además, este método oculta la posible complejidad de configurar IPsec, ya que de ello se encarga Windows Azure Connect. Una vez configurada la tecnología, los roles de una aplicación de Windows Azure parecen estar en la misma red IP que la de la máquina on-premises. Esto permite lo siguiente: Una aplicación de Windows Azure puede obtener acceso directo a una base de datos on-premises. Por ejemplo, supongamos que una organización traslada una aplicación de Windows Server existente creada mediante ASP.NET a un Web Role de Windows Azure. Si la base de datos que usa esta aplicación debe permanecer en las instalaciones locales, una conexión de Windows Azure Connect puede permitir a la aplicación (que ahora se ejecuta en Windows Azure) obtener acceso a la base de datos on-premises, como lo ha hecho siempre. Ni siquiera hace falta modificar las cadenas de conexión. 11

El dominio de una aplicación de Windows Azure se puede unir al entorno local. De este modo, los usuarios locales dispondrán de un inicio de sesión único a la aplicación en la nube. También permite a la aplicación usar cuentas y grupos de Active Directory existentes para el control de acceso. Hacer que la nube se adapte al entorno local de hoy en día es una cuestión importante. Al permitir una conectividad directa de nivel IP, Windows Azure Connect facilita esta tarea para las aplicaciones de Windows Azure. USO DE WINDOWS AZURE: ESCENARIOS Comprender los componentes de Windows Azure es importante, pero no suficiente. La mejor manera de comprender lo que puede hacer esta plataforma es analizar algunos ejemplos de cómo se puede usar. Por consiguiente, en esta sección se analizan varios escenarios sobre el uso de Windows Azure: crear una aplicación web escalable, crear una aplicación de procesamiento paralelo, crear una aplicación web con procesamiento en segundo plano, crear una aplicación web con datos relacionales, migrar una aplicación web on-premises con datos relacionales y usar el almacenamiento en la nube de una aplicación onpremises o una aplicación hospedada. CREACIÓN DE UNA APLICACIÓN WEB ESCALABLE Supongamos que una organización desea crear una aplicación web a la que se pueda obtener acceso a través de Internet. La opción habitual de hoy en día es ejecutar dicha aplicación en un centro de datos de la organización o en un proveedor de servicios de hosting. En muchos casos, no obstante, una plataforma en la nube como Windows Azure es una opción más adecuada. Por ejemplo, si la aplicación debe gestionar un número elevado de usuarios simultáneos, tiene sentido crearla en una plataforma diseñada expresamente para admitir esta situación. El soporte intrínseco que proporciona Windows Azure para las aplicaciones y datos escalables puede gestionar cargas mucho mayores que las tecnologías web convencionales. O supongamos que la carga de la aplicación va a variar significativamente, con picos ocasionales en medio de largos períodos de uso inferior. Por ejemplo, podría mostrar este patrón un sitio de procesamiento de pedidos en línea, un sitio de vídeos de noticias con historias importantes ocasionales, una aplicación que se usa principalmente en determinadas horas del día, etc. Ejecutar este tipo de aplicación en un centro de datos convencional requiere tener suficientes máquinas a mano para manejar los picos, aún cuando la mayoría de dichos sistemas no se usen casi nunca. Si, en lugar de ello, la aplicación se crea en Windows Azure, la organización que la ejecuta puede expandir el número de instancias que usa solo cuando es necesario y luego pasar de nuevo a un número inferior. La capacidad de compartir de Windows Azure se basa en el uso (se paga por hora para cada instancia), por lo que es muy probable que esto sea mucho más económico que mantener muchas máquinas que casi no se usen. Para crear una aplicación web escalable en Windows Azure, un programador puede usar roles web y tablas. La 8 ilustra esta situación. 12

Aplicación web escalable Instancia de Web Role Tablas Usuarios Figura 8: Una aplicación web escalable puede usar instancias de Web Role y tablas. En el ejemplo que se muestra aquí, los clientes son navegadores y, por consiguiente, la lógica de la aplicación puede implementarse mediante ASP.NET u otra tecnología web. También es posible crear una aplicación web escalable que expone servicios web basados en REST o SOAP mediante WCF y, a continuación, llamar a esos servicios desde, por ejemplo, un cliente Silverlight. En cualquier caso, el programador especifica cuántas instancias de Web Role deberían ejecutarse y Windows Azure Fabric Controller crea el mismo número de VM. Como se ha descrito anteriormente, Fabric Controller también supervisa estas instancias y se asegura de que el número solicitado siempre esté disponible. Para el almacenamiento de datos, la aplicación usa tablas de Windows Azure Storage, que proporcionan un almacenamiento ampliable horizontalmente capaz de gestionar grandes volúmenes de datos. CREACIÓN DE UNA APLICACIÓN DE PROCESAMIENTO PARALELO Las aplicaciones web escalables son útiles, pero no son la única situación en las que Windows Azure tiene sentido. Supongamos, por ejemplo, una organización que ocasionalmente necesita mucha potencia de procesamiento para una aplicación de procesamiento paralelo. Se pueden citar varios ejemplos al respecto: diseño de modelos financieros en un banco, representación en una empresa de efectos especiales para películas, nuevos desarrollos de medicamentos en una empresa farmacéutica, etc. Si bien es posible mantener un gran clúster de máquinas para satisfacer esta necesidad ocasional, ello también resulta caro. Windows Azure, en cambio, puede proporcionar estos recursos en función de las necesidades y ofrecer un tipo de clúster de procesamiento a petición. Los programadores pueden usar roles de trabajador para crear este tipo de aplicación. Y, si bien no es la única opción, las aplicaciones paralelas suelen usar conjuntos de datos de gran tamaño, que también pueden almacenarse en blobs de Windows Azure. La 9 ilustra este tipo de aplicación. 13

Aplicación de procesamiento paralelo Instancia de Web Role Colas Instancia de Web Role Blobs Usuario Figura 9: Una aplicación de procesamiento paralelo puede usar una instancia de Web Role, varias instancias de rol de trabajador, colas y blobs. En el escenario que se muestra aquí, el trabajo paralelo se realiza mediante distintas instancias de rol de trabajador que se ejecutan simultáneamente y que usan datos de blob. Dado que Windows Azure no impone ningún límite en cuanto al tiempo durante el que una instancia puede ejecutarse, cada una puede realizar una cantidad arbitraria de trabajo. Para interactuar con la aplicación, el usuario se basa en una única instancia de Web Role. A través de esta interfaz, el usuario puede determinar cuántas instancias de rol de trabajador deben ejecutarse, iniciar y detener dichas instancias, obtener resultados, etc. La comunicación entre la instancia de Web Role y las instancias de rol de trabajador se basa en colas de Windows Azure Storage. Dada la cantidad masiva de potencia de procesamiento disponible en la nube, es probable que este nuevo método transforme la informática de alto rendimiento. Por ejemplo, Microsoft Windows HPC Server ahora permite crear un clúster de equipos mediante instancias de rol de trabajador de Windows Azure junto con servidores físicos on-premises o en lugar de ellos. Sea cual sea el método, la explotación de esta nueva fuente de potencia de procesamiento tiene sentido en un gran número de situaciones. CREACIÓN DE UNA APLICACIÓN WEB ESCALABLE CON PROCESAMIENTO EN SEGUNDO PLANO Probablemente sea justo afirmar que la mayor parte de las aplicaciones que se crean hoy en día proporcionan una instancia de navegador. Sin embargo, aunque las aplicaciones que simplemente aceptan y responden solicitudes de navegador son de gran utilidad, también son limitadas. Hay muchas situaciones en las que el software al que se obtiene acceso a través de la web debe iniciar tareas que se ejecutan en segundo plano, independientemente de la parte de solicitud/respuesta de la aplicación. Supongamos, por ejemplo, una aplicación web para compartir vídeo. Debe aceptar solicitudes de navegador, probablemente de un número elevado de usuarios simultáneos. Algunas de estas solicitudes cargarán nuevos vídeos, y cada vídeo debe procesarse y almacenarse para un acceso posterior. No tendría 14

sentido hacer que el usuario espere durante este procesamiento. En lugar de ello, la parte de la aplicación que acepta solicitudes de navegador debería poder iniciar una tarea en segundo plano que se ocupara de este trabajo. Los Web Roles y los roles de trabajador pueden usarse conjuntamente para dar solución a este escenario. La figura 10 ilustra el aspecto de una aplicación de este tipo. Aplicación web escalable con proceso en segundo plano Tablas Instancia de Web Role Colas Instancia de Web Role Blobs Usuarios Figura 10: Una aplicación web escalable con procesamiento en segundo plano puede usar varias capacidades de Windows Azure. Como ocurre con la aplicación web escalable mostrada anteriormente, esta aplicación usa varias instancias de Web Role para gestionar solicitudes de usuario. Para admitir un número elevado de usuarios simultáneos, también usa tablas para almacenar información de perfil. Para el procesamiento en segundo plano, se basa en instancias de rol de trabajador, a las que pasa tareas a través de las colas. En este ejemplo, las instancias de rol de trabajador usan datos de blob, pero también pueden usarse otros métodos. En este ejemplo se muestra cómo una aplicación podría combinar muchas de las capacidades básicas que expone Windows Azure: instancias de Web Role, instancias de rol de trabajador, blobs, tablas y colas. Asimismo, aunque no se muestre en la figura, una aplicación de vídeo compartido también podría usar Windows Azure CDN para acelerar el acceso. Si bien no todas las aplicaciones necesitan la totalidad de estas capacidades, es muy importante que todas estén disponibles para admitir casos más complejos como éste. CREACIÓN DE UNA APLICACIÓN WEB CON DATOS RELACIONALES Los blobs y las tablas de Windows Azure son adecuados para algunas situaciones. No obstante, para muchas otras es mejor usar datos relacionales. Por ejemplo, supongamos que una empresa desea crear y ejecutar una aplicación para sus propios empleados en Windows Azure. Quizás la aplicación tendrá una vida útil corta o imprevisible, por lo que no vale la pena asignar un servidor en el centro de datos de la 15

empresa. O bien, quizás la aplicación debe implementarse lo más rápido posible y no se puede esperar a que el departamento de TI interno proporcione un servidor. Quizás incluso la organización considera que la ejecución de la aplicación en Windows Azure será más sencilla y económica. Sea cual sea el motivo, es probable que esta aplicación no necesite la capacidad de escala masiva que permiten las tablas de Windows Azure. En su lugar, los creadores puede que prefieran usar el enfoque relacional que ya conocen y completarlo con herramientas de creación de informes que les resulten familiares. En un caso como éste, la aplicación podría usar Windows Azure junto con SQL Azure, como se muestra en la figura 11. Nueva aplicación web con datos relacionales Instancia de Web Role SQL Azure Usuarios Figura 11: Una aplicación de Windows Azure puede usar SQL Azure para trabajar con datos relacionales. SQL Azure proporciona un subconjunto grande de funciones de SQL Server, incluida la generación de informes, como un servicio en la nube administrado. Las aplicaciones pueden crear bases de datos, ejecutar consultas SQL y mucho más, pero no es necesario administrar el sistema de bases de datos ni el hardware en el que se usa, ya que Microsoft se ocupa de ello. El acceso a una base de datos de SQL Azure se realiza a través del protocolo Flujo TDS (Tabular Data Stream), como ocurre con la versión on-premises de SQL Server. Esto permite a una aplicación de Windows Azure obtener acceso a datos relacionales mediante mecanismos conocidos como Entity Framework y ADO.NET. Además, dado que SQL Azure es un servicio en la nube, su cobro se basa en el uso. Windows Azure y SQL Azure proporcionan servicios análogos en la nube a sus homólogos on-premises, por lo que es muy fácil trasladar código y datos para una aplicación de este tipo entre los dos mundos. Aunque no son idénticos (la aplicación de Windows Azure debe poder ejecutar varias instancias, por ejemplo), el entorno en la nube y el local son muy similares. Esta portabilidad es útil cuando tiene sentido crear una aplicación cuyo código y datos pueden existir de forma local o en la nube. 16

MIGRACIÓN DE UNA APLICACIÓN WEB ON-PREMISES CON DATOS RELACIONALES Supongamos que en lugar de crear una nueva aplicación web para Windows Azure, una organización desea trasladar una aplicación de Windows Azure Server existente a la plataforma en la nube. Un método posible es mediante el uso del rol de VM de Windows Azure. La imagen tiene un aspecto muy similar al del caso anterior, como se indica en la figura 12. Aplicación web local migrada con datos relacionales Instancia de rol de VM SQL Azure Usuarios Figure 12: Algunas aplicaciones on-premises se pueden migrar a Windows Azure mediante el rol de VM y SQL Azure. Para usar un rol de VM, una organización crea un disco duro virtual (VHD) a partir de una máquina onpremises que ejecuta Windows Server 2008 R2. A continuación, esta imagen puede cargarse a Windows Azure y ejecutarse dentro de un rol de VM. Como se muestra en la figura, la aplicación podría obtener acceso a datos relacionales en SQL Azure. Otra opción es dejar sus datos almacenados localmente y acceder a ellos directamente desde Windows Azure Connect, como se ha descrito anteriormente. El rol de VM puede ser de gran utilidad. Sin embargo, es importante comprender que trasladar una aplicación de Windows Azure Server a Windows Azure podría requerir más de su simple empaquetado en un VHD y ejecución en un rol de VM. En primer lugar, recuerde que Windows Azure Fabric Controller supone que siempre hay al menos dos instancias de cada rol en ejecución. (De hecho, para cumplir con el contrato de nivel de servicio de Windows Azure esto es obligatorio). Recuerde también que Windows Azure establece el equilibrio de carga de todas las solicitudes de usuario entre todas las instancias de un rol. Si la aplicación que se está migrando se ha diseñado para funcionar de esta manera (por ejemplo, porque ya se ejecuta en una granja de servidores web con equilibrio de carga), podrá ejecutarse correctamente en Windows Azure sin tener que realizar cambios importantes. Sin embargo, si la aplicación espera ejecutar una sola instancia, es probable que necesite algún cambio de diseño para que se ejecute correctamente en Windows Azure. 17

USO DEL ALMACENAMIENTO EN LA NUBE DESDE UNA APLICACIÓN ON-PREMISES U HOSPEDADA Windows Azure proporciona una amplia gama de capacidades, pero a veces una aplicación sólo necesita algunas de ellas. Supongamos, por ejemplo, una aplicación on-premises u hospedada que deba almacenar una cantidad significativa de datos. Una empresa podría querer archivar correo electrónico antiguo, por ejemplo, para ahorrar dinero en el almacenamiento y seguir teniendo acceso al correo. Un sitio web de noticias que se ejecute en un proveedor de servicios de hosting podría necesitar un lugar escalable y de acceso global para almacenar grandes cantidades de texto, gráficos, vídeo e información de los perfiles de sus usuarios. Un sitio usado para compartir fotografías podría platearse delegar la carga asociada al almacenamiento de información en un proveedor externo de confianza. Windows Azure Storage responde a todas estas situaciones, como ilustra la figura 13. Blobs Tablas Aplicación local u hospedada Figura 13: Una aplicación on-premises u hospedada puede usar blobs o tablas de Windows Azure para almacenar sus datos en la nube. Como se ha mencionado anteriormente, una aplicación on-premises u hospedada puede obtener acceso directamente a Windows Azure Storage. Si bien el acceso probablemente sea más lento que el que ofrece el almacenamiento local, también es probable que sea más económico, más escalable y más confiable. Para algunas aplicaciones, esto realmente compensa. Y aunque no se muestre en la figura, las aplicaciones pueden usar SQL Azure del mismo modo. DESCRIPCIÓN DE WINDOWS AZURE: ENFOQUE MÁS DETALLADO Para comprender Windows Azure, es necesario conocer los conceptos básicos de la plataforma y examinar después los escenarios típicos en los que éstos pueden aplicarse. No obstante, esta tecnología ofrece mucho más. En esta sección se profundiza en algunos de los aspectos más interesantes. 18

CREACIÓN DE APLICACIONES DE WINDOWS AZURE Para los programadores, crear una aplicación de Windows Azure es como crear una aplicación de Windows tradicional. Dado que la plataforma admite aplicaciones.net y aplicaciones creadas mediante código no administrado, los programadores pueden usar lo que sea más adecuado para su problema. Para facilitar las cosas, Visual Studio proporciona plantillas de proyecto para crear aplicaciones de Windows Azure. También es posible cargar aplicaciones directamente de Visual Studio a Windows Azure. Una de las diferencias obvias entre el entorno de la nube y el entorno local es que las aplicaciones de Windows Azure no se ejecutan localmente. Esta diferencia puede dar lugar a que el desarrollo sea más complejo. Para ayudar a mitigar esta situación, Microsoft proporciona Development Fabric, una versión del entorno de Windows Azure que se ejecuta en la máquina de un programador. Development Fabric se ejecuta en un solo escritorio o servidor. Emula la funcionalidad de Windows Azure en la nube, junto con Web Roles, roles de trabajador, roles de VM y las tres opciones de Windows Azure Storage. Un programador puede crear una aplicación de Windows Azure, implementarla en Development Fabric y ejecutarla de forma muy parecida a cualquier otra aplicación. Puede determinar cuántas instancias de cada rol deben ejecutarse, por ejemplo, usar colas para establecer comunicación entre estas instancias y hacer todo lo que es posible realizar mediante Windows Azure. Una vez que la aplicación se haya desarrollado y probado localmente, el programador puede cargar el código y su información de configuración, y ejecutarla. Independientemente de la forma en la que se haya creado, una aplicación de Windows Azure suele ponerse a disposición en la nube mediante un proceso de dos pasos. En primer lugar, el programador carga la aplicación en el área de ensayo de la plataforma. Cuando el programador está preparado para lanzar la aplicación, usa el portal de Windows Azure para solicitar que la aplicación pase a producción. Este cambio entre ensayo y producción se puede realizar sin tiempo de inactividad, lo que permite actualizar una aplicación en ejecución a una versión nueva sin interrumpir a los usuarios. La aplicación de ensayo tiene un nombre DNS con el formato <GUID>.cloudapp.net, donde <GUID> representa un identificador único global asignado por Windows Azure. Para el nivel de producción, el programador elige un nombre DNS en el mismo dominio, como miservicioazure.cloudapp.net. Para usar un dominio personalizado en lugar del dominio cloudapp.net de Microsoft, el propietario de la aplicación puede crear un alias de DNS mediante un CNAME estándar. Una vez que se pueda obtener acceso a la aplicación desde el exterior, es muy probable que sus usuarios deban identificarse de algún modo. Para ello, Windows Azure permite a los programadores usar cualquier mecanismo de autenticación basado en HTTP. Por ejemplo, una aplicación ASP.NET podría usar un proveedor de pertenencia a grupos para almacenar su propio identificador de usuario y contraseña o podría usar algún otro método, como el servicio Windows Live ID de Microsoft. Las aplicaciones de Windows Azure también pueden usar Windows Identity Foundation (WIF) para implementar la identidad basada en notificaciones. El creador de la aplicación es libre de seleccionar la opción que más le interese. ANÁLISIS DEL SERVICIO COMPUTE Como la mayoría de las tecnologías, Windows Azure Compute ha evolucionado desde su versión original. Por ejemplo, inicialmente el Web Role y el rol de trabajador solo se podían ejecutar en modo de usuario. 19

Sin embargo, hoy en día ambos proporcionan una opción de privilegios elevados que permite a las aplicaciones ejecutarse en modo de administración. Esto puede ser de gran utilidad para las aplicaciones que necesitan instalar un componente COM, por ejemplo; algo que planteaba problemas en la primera versión de Windows Azure. Sin embargo, todas las instancias en ejecución de un Role Web o un rol de trabajador comienzan desde cero: el sistema operativo subyacente en su VM es una imagen estándar definida por Windows Azure. Esto significa que las instalaciones de software que realice el rol deberán aplicarse cada vez que se cree una instancia nueva. Esto no presenta ningún problema en instalaciones sencillas, como la adición de un único componente COM. Sin embargo, supongamos que la instancia necesita instalar una variedad de software para su funcionamiento. Realizar esta tarea cada vez que se cree la instancia de rol probablemente resulte demasiado lento. Evitar esta circunstancia es el objetivo principal de los roles de VM. En lugar de que tener que realizar varias instalaciones al crear una instancia, se puede incluir todo el software necesario en un VHD y utilizarlo para crear una instancia de rol de VM. Este método puede resultar bastante más rápido que usar un Web Role o un rol de trabajador con privilegios elevados. También puede ser la solución adecuada cuando el proceso de instalación requiera una intervención manual, cosa que Windows Azure no permite. Otro cambio con respecto a la versión original de Windows Azure es que la plataforma admite ahora acceso a través del protocolo de escritorio remoto (RDP). Esta opción puede ser de utilidad a la hora de realizar depuraciones y permite a los programadores obtener acceso directo a una instancia específica. No obstante, este proceso no debe usarse para la infraestructura de escritorio virtual (VDI), ya que Windows Azure actualmente no está diseñado para este tipo de escenario. Desde la versión original de la tecnología se han incorporado otros aspectos importantes de Windows Azure Compute. Por ejemplo, Windows Azure permite a los programadores indicar el centro de datos en el que debe ejecutarse una aplicación y la ubicación en la que deben almacenarse sus datos. También pueden especificar si un grupo determinado de aplicaciones y datos (incluidos los datos de la base de datos de SQL Azure) debe residir en el mismo centro de datos. Inicialmente, Microsoft proporciona centros de datos de Windows Azure en Estados Unidos, Europa y Asia, y existen otros en perspectiva. ANÁLISIS DEL SERVICIO STORAGE Para usar Windows Azure Storage, en primer lugar un programador debe crear una cuenta de almacenamiento. A fin de controlar el acceso a la información de esta cuenta, Windows Azure asigna una clave secreta a su creador. Cada solicitud que realice una aplicación en relación con la información de esta cuenta de almacenamiento (blobs, tablas y colas) incluye una firma creada con esta clave secreta. Dicho de otro modo, la autorización se lleva a cabo en el nivel de cuenta (aunque los blobs ofrecen otra opción, como se describe más adelante). Windows Azure Storage no proporciona listas de control de acceso ni ningún otro método más específico para controlar quién está autorizado a obtener acceso a los datos que contiene. Blobs Los objetos binarios de gran tamaño (blobs) a menudo son lo único que necesita una aplicación. Independientemente de que contengan vídeo, audio, mensajes de correo electrónico archivados o 20

cualquier otro tipo de información, permiten a las aplicaciones almacenar datos y obtener acceso a ellos de forma muy generalizada. Para usar blobs, el programador crea primero uno o más contenedores en una cuenta de almacenamiento. Cada uno de estos contenedores puede contener uno o más blobs. Para identificar un blob en particular, una aplicación puede especificar un URI con el siguiente formato: http://<cuentaalmacenamiento>.blob.core.windows.net/<contenedor>/<nombreblob> <CuentaAlmacenamiento> es un identificador único que se asigna al crear una cuenta de almacenamiento, mientras que <Contenedor> y <NombreBlob> son los nombres de un contenedor específico y un blob dentro de dicho contenedor. Los blobs tienen dos formatos: Blobs de bloque, que pueden contener cada uno hasta 200 gigabytes de datos. Para que su transferencia sea más eficiente, un blob de bloque se subdivide en bloques. Si se produce un error, la retransmisión puede reanudarse desde el bloque más reciente, en lugar de tener que enviar de nuevo todo el blob. Una vez que se hayan cargado todos los bloques del blob, el blob puede confirmarse a la vez en su totalidad. Blobs de página, que pueden tener hasta un terabyte de tamaño cada uno. Un blob de página se divide en páginas de 512 bytes, y una aplicación puede leer y escribir páginas individuales de forma aleatoria en el blob. Independientemente del tipo de blob que contengan, los contenedores pueden marcarse como privados o públicos. En el caso de los blobs de un contenedor privado, las solicitudes de lectura y escritura deben firmarse mediante la clave de la cuenta de almacenamiento del blob. Si los blobs se encuentran en un contenedor público, solo deben firmarse las solicitudes de escritura; cualquier aplicación puede leer el blob. Esta circunstancia puede resultar de utilidad en situaciones tales como establecer la disponibilidad general en Internet de vídeos, fotografías u otros datos no estructurados. De hecho, Windows Azure CDN solo funciona con los datos almacenados en contenedores de blobs públicos. Otro aspecto importante de los blobs es el papel que desempeñan para admitir unidades de Windows Azure. Para comprender este papel, es necesario tener claro que las instancias de rol tienen libre acceso al sistema de archivos local. De forma predeterminada, este almacenamiento no es persistente: cuando se cierra la instancia, la VM y su almacenamiento local desaparecen. Sin embargo, montar una unidad de Windows Azure para la instancia puede hacer que un blob de página tenga el aspecto de una unidad local, con un sistema de archivos NTFS. Los datos escritos en la unidad pueden escribirse inmediatamente en el blob subyacente. Cuando una instancia no se encuentra en ejecución, estos datos se almacenan de forma persistente en el blob de página, listos para ser montados de nuevo. Entre las distintas formas de usar unidades, cabe destacar las siguientes: Un programador puede cargar un VHD que contenga un sistema de archivos NTFS y luego montar el VHD como unidad de Windows Azure. Esto ofrece un método directo para desplazar datos del sistema de archivos entre Windows Azure y un sistema Windows Server on-premises. Un programador de Windows Azure puede instalar y ejecutar un sistema de bases de datos MySQL en una instancia de rol de Windows Azure, usando una unidad de Windows Azure como almacenamiento subyacente. 21

Tablas El concepto de blob es muy fácil de entender (es simplemente un bloque de bytes). Sin embargo, las tablas son un poco más complejas. La figura 14 ilustra las distintas partes de una tabla. Tabla Tabla Tabla... Entidad Entidad Entidad... Propiedad Propiedad Propiedad... Nombre Tipo Valor Figura 14: Las tablas proporcionan almacenamiento basado en entidades. Como se muestra en la figura, cada tabla contiene varias entidades. Una entidad puede no contener ninguna propiedad o contener varias, cada una con un nombre, un tipo y un valor. Se admite una variedad de tipos de propiedad, como Binary, Bool, DateTime, Double, GUID, Int, Int64 y String. Una propiedad puede tener varios tipos en momentos distintos, en función del valor que almacena, y no existe ningún requisito que establezca que todas las propiedades de una entidad deban ser del mismo tipo. Los programadores tienen la libertad de hacer lo que consideren más apropiado para la aplicación. Independientemente de la información que contenga, una entidad puede alcanzar hasta un megabyte de tamaño, y el acceso a ella se realiza como si se tratara de una unidad. Al leer una entidad, se devuelven todas sus propiedades y, cuando se escribe una, pueden sustituirse todas sus propiedades. También es posible actualizar automáticamente un grupo de entidades de una única tabla, lo que garantiza que todas las actualizaciones se realicen correctamente o todas fallen. Las tablas de Windows Azure Storage presentan varias diferencias en relación con las tablas relacionales. La más evidente es que no son tablas en el sentido habitual de la palabra. Además, no es posible obtener acceso a ellas mediante ADO.NET ordinario, ni admiten consultas SQL. Asimismo, las tablas de Windows Azure Storage no aplican ningún esquema; las propiedades de una entidad pueden ser de distintos tipos y dichos tipos pueden cambiar con el tiempo. La pregunta más obvia es: por qué? Por qué no se admiten simplemente tablas relacionales normales con consultas SQL estándar? 22

La respuesta está en objetivo principal de Windows Azure de admitir aplicaciones escalables masivamente. Las bases de datos relacionales tradicionales pueden escalarse y gestionar un número creciente de usuarios si se ejecuta DBMS en máquinas cada vez mayores. No obstante, para admitir realmente números elevados de usuarios simultáneos, el almacenamiento debe escalarse horizontalmente, no verticalmente. Para que esto sea posible, el mecanismo de almacenamiento debe ser más simple: las tablas relacionales tradicionales con SQL estándar no son adecuadas para este propósito. Lo que se necesita es el tipo de estructura que proporcionan las tablas de Windows Azure. El uso de tablas requiere un replanteamiento por parte de los programadores, ya que los conceptos relacionales conocidos no pueden aplicarse si no se modifican. Aun así, para crear aplicaciones muy escalables, este enfoque tiene sentido. No es necesario que los programadores se preocupen por la ampliación, simplemente deben crear nuevas tablas, agregar nuevas entidades y dejar que Windows Azure se ocupe de todo lo demás. También se elimina gran parte del trabajo necesario para el mantenimiento de un DBMS, ya que Windows Azure se encarga de ello. El objetivo es permitir que los programadores se concentren en su aplicación, en lugar de ocuparse de la mecánica del almacenamiento y la administración de grandes cantidades de datos. Como ocurre con todos los componentes de Windows Azure Storage, el acceso a las tablas se realiza mediante REST. Para ello, la aplicación.net puede usar los Servicios de datos de WCF y ocultar las solicitudes HTTP subyacentes. Cualquier aplicación,.net o de otro tipo, también es libre de realizar estas solicitudes directamente. Por ejemplo, una consulta en una tabla concreta se expresa como HTTP GET para un URI que tiene el formato siguiente: http://<cuentaalmacenamiento>.table.core.windows.net/<nombretabla>?$filter=<consulta> Aquí, <NombreTabla> especifica la tabla que se consulta, mientras que <Consulta> contiene la consulta que debe ejecutarse en esta tabla. Si la consulta devuelve un número elevado de resultados, un programador puede obtener un token de continuación que puede pasarse a la siguiente consulta. Repetir esta acción permite recuperar el conjunto completo de resultados en bloques. Las tablas de Windows Azure no son la elección correcta para todos los escenarios de almacenamiento y, para poder usarlas, los programadores deben aprender nuevos conceptos. Aun así, estas tablas sí son adecuadas para las aplicaciones que necesitan la escalabilidad que proporcionan. Colas Mientras que las tablas y los blobs están concebidos básicamente para almacenar datos y obtener acceso a los mismos, el objetivo principal de las colas es permitir la comunicación entre distintas partes de una aplicación de Windows Azure. Como ocurre con todos los componentes de Windows Azure Storage, el acceso a las colas se realiza mediante REST. Para hacer referencia a una cola, tanto las aplicaciones de Windows Azure como las aplicaciones externas usan un URI con el formato siguiente: http://<cuentaalmacenamiento>.queue.core.windows.net/<nombrecola> Como se ha descrito anteriormente, uno de los usos comunes de las colas es permitir la interacción entre instancias de Web Role e instancias de rol de trabajador. La figura 15 ilustra su aspecto. 23

1) Recibir tarea Instancia de Web Role 3) Eliminar mensaje de la cola Instancia de rol de trabajador 4) Realizar tarea 2) Poner mensaje en cola 5) Eliminar mensaje En cola Figura 15: Los mensajes se ponen en cola, se quitan de la cola, se procesan y se eliminan explícitamente de la cola. En un escenario típico se ejecutan varias instancias de Web Role y cada una acepta trabajo de los usuarios (paso 1). Para pasar dicho trabajo a las instancias de rol de trabajador, una instancia de Web Role escribe un mensaje en una cola (paso 2). Este mensaje, que puede tener hasta ocho kilobytes de tamaño, puede contener un URI que apunta a un blob o una entidad, o algún otro elemento según la aplicación. Las instancias de rol de trabajador leen los mensajes de esta cola (paso 3) y realizan el trabajo solicitado por el mensaje (paso 4). No obstante, es importante tener en cuenta que al leer un mensaje de una cola, dicho mensaje no se elimina realmente. En su lugar, el mensaje pasa a ser invisible para otros lectores durante un período específico de tiempo (el valor predeterminado es 30 segundos). Cuando la instancia de rol de trabajador haya finalizado el trabajo que solicita el mensaje, debe eliminarlo explícitamente de la cola (paso 5). Tiene sentido separar las instancias de Web Role de las instancias de rol de trabajador. Ello evita que el usuario deba esperar a que finalice el proceso de una tarea larga y también simplifica la escalabilidad; basta con agregar más instancias de cualquiera de los tipos. Pero, por qué las instancias deben eliminar los mensajes explícitamente? La respuesta es que ello permite gestionar los errores. Si la instancia de rol de trabajador que recupera un mensaje lo gestiona satisfactoriamente, eliminará el mensaje mientras éste sigue invisible, es decir, en el período de tiempo de 30 segundos. No obstante, si una instancia de rol de trabajador quita un mensaje de la cola, se bloquea antes de completar el trabajo que especifica el mensaje y no lo elimina de la cola. Cuando venza el tiempo de espera de visibilidad, el mensaje volverá a aparecer en la cola y lo leerá otra instancia de rol de trabajador. El objetivo es asegurarse de que cada mensaje se procese como mínimo una vez. Como se indica en esta descripción, las colas de Windows Azure Storage no tienen la misma semántica que las colas de Microsoft Message Queuing (MSMQ) ni otras tecnologías parecidas. Por ejemplo, un sistema de colas convencional puede ofrecer una semántica de "primero en entrar, primero en salir" y entregar cada mensaje una única vez. Las colas de Windows Azure Storage no realizan promesas de este tipo. Como se acaba de describir, un mensaje podría entregarse varias veces y no existe garantía alguna de que los mensajes se entreguen en ningún orden en particular. Las cosas son distintas en la nube y los programadores deberán adaptarse a dichas diferencias. 24

ANÁLISIS DE FABRIC CONTROLLER Para los programadores de aplicaciones, Compute y Storage son los componentes más importantes de Windows Azure. Sin embargo, ninguno de ellos puede funcionar sin Fabric Controller. El entramado combina un centro de datos lleno de máquinas en una unidad coherente y proporciona la base para todo lo demás. Como se ha descrito anteriormente, Fabric Controller posee todos los recursos de un centro de datos concreto de Windows Azure. También se encarga de asignar aplicaciones a máquinas físicas. Es muy importante hacerlo de forma inteligente. Supongamos, por ejemplo, que un desarrollador solicita cinco instancias de Web Role y cuatro instancias de rol de trabajador para su aplicación. Una asignación ingenua sería colocar todas estas instancias en máquinas del mismo bastidor servidas por el mismo conmutador de red. Si el bastidor o el conmutador fallaran, la aplicación dejaría de estar disponible en su totalidad. Si tenemos en cuenta los objetivos de alta disponibilidad de Windows Azure, hacer que una aplicación dependa de puntos únicos de error como éstos no sería lo más adecuado. Para evitar esta situación, Fabric Controller agrupa las máquinas que posee en distintos dominios de error. Cada dominio de error forma parte del centro de datos en el que un único error puede cerrar el acceso a todo lo contenido en dicho dominio. La figura 16 ilustra esta idea. Aplicación Instancia de Web Role 1 Instancia de Web Role 2 Storage Réplica 1 Storage Réplica 2 Fabric Controller Dominio de error Dominio de error Figura 16: Fabric Controller coloca distintas instancias de una aplicación en dominios de error distintos. En este simple ejemplo, la aplicación ejecuta solo dos instancias de Web Role y el centro de datos está dividido en dos dominios de error. Cuando Fabric Controller implementa esta aplicación, coloca una instancia de Web Role en cada uno de los dominios de error. Esta disposición implica que un único error de hardware en el centro de datos no puede bloquear toda la aplicación. Asimismo, no podemos olvidar 25

que Fabric Controller ve Windows Azure Storage como cualquier otra aplicación; el controlador no gestiona la replicación de datos. En su lugar, la aplicación de almacenamiento se ocupa de esta replicación y se asegura de que las réplicas de blobs, tablas y colas que usa la aplicación se encuentren en distintos dominios de error. Permitir que una aplicación siga ejecutándose a pesar de los errores de hardware es útil, pero no es suficiente. Para que una aplicación sea realmente confiable (el tipo de aplicación objetivo de Windows Azure) no debería ser necesario cerrarla para su actualización. Una manera de hacerlo es mediante el método descrito anteriormente que implica cambiar una versión existente de una aplicación a una versión nueva. Otra opción es depender de los dominios de actualización de Windows Azure. Mediante este método, Fabric Controller asigna diferentes instancias de los roles de una aplicación a distintos dominios de actualización. Para implementar una versión nueva de la aplicación, Fabric Controller implementa código nuevo por cada dominio de actualización. Cierra las instancias de rol de un dominio, actualiza el código para el rol y, a continuación, inicia instancias nuevas. El objetivo es mantener la aplicación en continua ejecución, aun cuando se esté actualizando. Es posible que los usuarios perciban que se está realizando una actualización, ya que el tiempo de respuesta de la aplicación aumentará cuando se cierren algunas de sus instancias, por ejemplo, y distintos usuarios obtengan acceso a diferentes versiones de la aplicación durante la actualización. Aun así, desde el punto de vista del usuario, la aplicación en su totalidad sigue estando disponible de forma continua. No se deben confundir los dominios de actualización, que son propiedad de una aplicación, con los dominios de error, que son propiedad del centro de datos. No obstante, ambos tienen el mismo objetivo de seguridad: ayudar a Fabric Controller a mantener las aplicaciones de Windows Azure en constante ejecución. PERSPECTIVAS DE FUTURO Microsoft ha anunciado su intención de agregar más funciones a Windows Azure en 2011, entre las que se incluyen: Windows Azure Platform Appliance, una combinación de hardware y software que permitirá a los proveedores de servicios de hosting y a las empresas ejecutar Windows Azure en sus propios centros de datos. Almacenamiento en caché de contenido dinámico de CDN: hoy en día, Windows Azure CDN solo funciona con datos de blob. La futura funcionalidad permitirá a la CDN almacenar en caché contenido creado dinámicamente mediante una aplicación de Windows Azure. Creación de instantáneas de rol de VM: en su versión original, el rol de VM de Windows Azure no guarda los cambios que se realizan en el volumen del sistema operativo durante su ejecución. La creación de instantáneas cambiará este comportamiento y proporcionará una manera de guardar periódicamente el estado del volumen en el almacenamiento persistente. Mayor compatibilidad con Java: si bien en la actualidad Windows Azure puede ejecutar aplicaciones Java, Microsoft aumentar la compatibilidad. Las futuras mejoras incluyen rendimiento optimizado de Java, mayor compatibilidad para herramientas basadas en Eclipse y un conjunto más completo de bibliotecas Java para Windows Azure. 26

Como siempre, el objetivo de estas mejoras es ampliar la utilidad de la plataforma en la nube para incluir mayor variedad de situaciones. CONCLUSIONES Ejecutar aplicaciones y almacenar datos en la nube es la opción adecuada para muchas situaciones. Los distintos componentes de Windows Azure se combinan para hacerlo posible. Junto con el entorno de desarrollo de Windows Azure, SQL Azure y el resto de la plataforma Windows Azure, proporcionan un puente para que los programadores de Windows puedan cambiar a este nuevo mundo. Hoy en día, las plataformas en la nube siguen siendo una opción todavía exótica para la mayoría de las organizaciones. No obstante, a medida que vayamos adquiriendo experiencia en Windows Azure y en otras plataformas en la nube, este nuevo método dejará de parecer tan extraño. Con el tiempo, cabe esperar que las aplicaciones basadas en nube, así como las plataformas en la nube sobre las que se ejecutan, desempeñen un papel cada vez más importante en el mundo del software. LECTURAS ADICIONALES Página principal de la plataforma Windows Azure http://www.microsoft.com/windowsazure Introducción a la plataforma Windows Azure, David Chappell http://go.microsoft.com/fwlink/?linkid=158011 Blobs de Windows Azure: programación del almacenamiento de blobs http://go.microsoft.com/fwlink/?linkid=153400 Tablas de Windows Azure: programación del almacenamiento en tablas http://go.microsoft.com/fwlink/?linkid=153401 Colas de Windows Azure: programación del almacenamiento en colas http://go.microsoft.com/fwlink/?linkid=153402 SOBRE EL AUTOR David Chappell es director de Chappell & Associates (www.davidchappell.com) en San Francisco (California, EE. UU.). A través de sus conferencias, escritos y consultoría, ayuda a personas de todo el mundo a comprender, usar y tomar mejores decisiones sobre las nuevas tecnologías. 27