PRESENTACIÓN DE WINDOWS AZURE

PRESENTACIÓN DE WINDOWS AZURE DAVID CHAPPELL DICIEMBRE DE 2009 PATROCINADO POR MICROSOFT CORPORATION

CONTENIDO Visión general de Windows Azure... Servicio de informática... Servicio de almacenamiento... La estructura... Utilización de Windows Azure: escenarios... Crear una aplicación web escalable...... Crear una aplicación de procesamiento paralelo... 1 Crear una aplicación web escalable con procesamiento en segundo plano... 1 Crear una aplicación web con datos relacionales... 1 Utilizar almacenamiento cloud desde una aplicación interna u hospedada... 1 Comprensión de Windows Azure: una visión más detallada... 1 Desarrollar aplicaciones de Windows Azure... 1 Examinar el servicio de informática... 1 Examinar el servicio de almacenamiento... 1 Blobs... 1 Tablas... Colas... 2 Examinar la estructura... 2 Próximos pasos... 2 Conclusiones... 2 Más información... 2 Acerca del autor... 2 1

VISIÓN GENERAL DE WINDOWS AZURE La informática cloud ya llegó. Ejecutar aplicaciones en PC dentro de un centro de datos con acceso desde Internet puede traer muchas ventajas. Pero sin importar dónde se ejecuten, las aplicaciones se crean en una especie de plataforma. Para las aplicaciones internas, esta plataforma por lo general incluye un sistema operativo, una forma de almacenar datos y posiblemente más. Las aplicaciones que se ejecutan en el cloud necesitan una base similar. El objetivo de Microsoft Windows Azure es ofrecer esto. Al formar parte de la plataforma Windows Azure más amplia, Windows Azure es la base para ejecutar aplicaciones de Windows y almacenar datos en el cloud. El Gráfico 1 demuestra esta idea. Gráfico 1: las aplicaciones de Windows Azure se ejecutan en centros de datos de Microsoft y pueden accederse a través de Internet. Como se muestra en el gráfico, Windows Azure se ejecuta en PC dentro de centros de datos de Microsoft. En lugar de proporcionar software que los clientes de Microsoft pueden instalar y ejecutar en sus propias PC, Windows Azure es un servicio: los clientes lo utilizan para ejecutar aplicaciones y almacenar datos en PC con acceso desde Internet de Microsoft. Esas aplicaciones pueden ofrecer servicios a empresas, consumidores o ambos. A continuación se mencionan algunos ejemplos de tipos de aplicaciones que pueden crearse en Windows Azure: Un proveedor de software independiente (ISV) podría crear una aplicación para usuarios comerciales, un método que por lo general se refiere a Software como servicio (SaaS). Los ISV pueden utilizar Windows Azure como base para varias aplicaciones SaaS orientadas a los negocios. Es posible que un ISV cree una aplicación SaaS para consumidores. Windows Azure se encuentra diseñado para brindar soporte a software muy ampliable y, por lo tanto, es posible que una empresa 2

que planifica dirigirse al gran mercado de consumidores lo elija como plataforma para una nueva aplicación. Las empresas pueden usar Windows Azure para crear y ejecutar aplicaciones que utilicen sus propios empleados. Mientras que esta situación pueda no necesitar la enorme escala de una aplicación para consumidores, la confiabilidad y la capacidad de administración que ofrece Windows Azure pueden convertirlo en una opción atractiva. Sin importar lo que realice una aplicación de Windows Azure, la plataforma ofrece los mismos componentes fundamentales, como se demuestra en el Gráfico 2. Gráfico 2: Windows Azure cuenta con 3 partes principales: el servicio de informática, el servicio de almacenamiento y la estructura. Como lo sugieren sus nombres, el servicio de informática ejecuta aplicaciones, mientras que el servicio de almacenamiento almacena datos. El tercer componente, la estructura de Windows Azure, ofrece una forma común para administrar y monitorear aplicaciones que utilizan esta plataforma cloud. El resto de esta sección presenta cada una de estas partes. SERVICIO DE INFORMÁTICA El servicio de informática de Windows Azure puede ejecutar diferentes tipos de aplicaciones. Un objetivo muy importante de esta plataforma, no obstante, es brindar soporte a aplicaciones que cuentan con una gran cantidad de usuarios simultáneos (en realidad, Microsoft ha manifestado que creará sus propias aplicaciones SaaS en Windows Azure, por lo que se ha impuesto altas expectativas). Lograr este objetivo al aumentarse (ejecutar en PC cada vez más grandes) no resulta posible. Por el contrario, Windows Azure se encuentra diseñado para brindar soporte a aplicaciones que puedan ampliarse, que ejecuten varias copias del mismo código en muchos servidores genéricos. Para lograrlo, una aplicación de Windows Azure puede tener varias instancias, cada una de las cuales se ejecute en su propia PC virtual (VM). Cada VM se proporciona a través de un hipervisor (basado en Hyper- V) que se haya modificado para su uso en un cloud de Microsoft, y ofrezca una interfaz de Windows para la instancia que contiene. Para ejecutar una aplicación, un desarrollador accede al portal de Windows Azure a través de su explorador web e inicia sesión con una ID de Windows Live. Luego, elige crear una cuenta de hosting para ejecutar aplicaciones, una cuenta de almacenamiento para almacenar datos o ambas. Una vez que el 3

desarrollador crea una cuenta de hosting, puede cargar su aplicación especificando cuántas instancias ésta necesita. Luego, Windows Azure crea las VM necesarias y ejecuta la aplicación. En la primera versión de Windows Azure, se encuentran disponibles dos diferentes tipos de instancias para que utilicen los desarrolladores: instancias de rol web e instancias de rol de trabajo. El Gráfico 3 demuestra esta idea. Gráfico 3: una aplicación de Windows Azure puede consistir en instancias de rol web y/o instancias de rol de trabajo, cada una de las cuales se ejecuta en su propia PC virtual de Windows. Como su nombre lo sugiere, una instancia de rol web puede aceptar las solicitudes HTTP o HTTPS entrantes. Para permitir esto, se ejecuta en una VM que incluye Internet Information Services (IIS) 7. Los desarrolladores pueden crear instancias de rol web a través de ASP.NET, Windows Communication Foundation (WCF) u otra tecnología.net que trabaje con IIS. A su vez, los desarrolladores pueden crear aplicaciones en código nativo, en donde no se requiere utilizar.net Framework. Esto significa que también pueden cargar y ejecutar otras tecnologías, como PHP y Tomcat basado en Java. Y como se demuestra en el Gráfico 3, Windows Azure ofrece balanceo de carga de hardware integrado para distribuir pedidos en todas las instancias de rol web que forman parte de la misma aplicación. Al ejecutar varias instancias de una aplicación, Windows Azure permite que ésta se amplíe. Debido a que el balanceo de carga de Windows Azure no permite crear una afinidad con una instancia de rol web específica, no obstante, no existe una forma de garantizar que varios pedidos del mismo usuario se enviarán a la misma instancia. Por consiguiente, las instancias de rol web no deben tener estado. Cualquier estado específico del cliente debe ingresarse en el almacenamiento de Windows Azure o enviarse al cliente luego de cada pedido. Las instancias de rol de trabajo son similares, pero no iguales a las de rol web. La gran diferencia reside en que las instancias de rol de trabajo con cuentan con IIS configurado, por lo que éstas no se hospedan por 4

IIS. Por el contrario, son ejecutables por sí mismas. Se permite ejecutar un servidor web, y es posible instalar un servidor web Apache en un rol de trabajo, pero resulta más posible que una instancia de rol de trabajo funcione como un trabajo en segundo plano. Por ejemplo, es posible que una aplicación utilice instancias de rol web para aceptar pedidos de usuarios y luego los procese más adelante utilizando instancias de rol de trabajo. De forma similar, una aplicación que selecciona entre grandes cantidades de datos de forma paralela puede utilizar muchas instancias de rol de trabajo para realizar la tarea. Un desarrollador puede utilizar solo instancias de rol web, solo instancias de rol de trabajo o una combinación de ambas para crear una aplicación de Windows Azure. Si aumenta la carga de la aplicación, puede utilizar el portal de Windows Azure para pedir más instancias de rol web, más instancias de rol de trabajo o más de ambas para su aplicación. Si disminuye la carga, puede reducir la cantidad de instancias en funcionamiento. Para cerrar por completo la aplicación, el desarrollador puede cerrar todas las instancias de rol web y rol de trabajo. Windows Azure también exhibe una API, la cual permite que todo esto se realice de forma programática (la cantidad de instancias en funcionamiento no requiere intervención manual), pero la plataforma no amplía aplicaciones de forma automática en función de sus cargas. Las VM que ejecutan las instancias de rol web y rol de trabajo también ejecutan un agente de Windows Azure, como se demuestra en el Gráfico 3. Este agente exhibe una API relativamente simple, la cual permite que una instancia interactúe con la estructura de Windows Azure. Por ejemplo, una instancia puede utilizar el agente para encontrar la raíz de un recurso de almacenamiento local en la instancia de la VM donde se ejecuta. Para crear aplicaciones de Windows Azure, un desarrollador utiliza los mismos lenguajes y las mismas herramientas que usa en cualquier aplicación de Windows. Puede crear un rol web utilizando, por ejemplo, ASP.NET y Visual Basic, o a través de WCF y C#. De forma similar, puede crear un rol de trabajo en uno de estos lenguajes.net, trabajar directamente en C++ sin.net Framework o utilizar Java. Y mientras Windows Azure ofrece complementos para Visual Studio, no se requiere utilizar este entorno de desarrollo. Por ejemplo, un desarrollador que haya instalado PHP posiblemente decida utilizar otra herramienta para crear aplicaciones. Para permitir que se monitoreen y se depuren aplicaciones de Windows Azure, cada instancia puede solicitar una API de registro que ingrese información a un registro común de aplicaciones. Un desarrollador también puede configurar el sistema para reunir contadores de rendimiento para una aplicación, medir el uso de su CPU, almacenar fallos si existieren y más. Esta información se guarda en el almacenamiento de Windows Azure y el desarrollador tiene la libertad de crear un código para examinarla. Por ejemplo, si una instancia de rol de trabajo falla tres veces en una hora, el código personalizado puede enviar un correo electrónico al administrador de la aplicación. Advierta que Windows Azure no lo ofrece por sí mismo; de lo contrario, permite que las aplicaciones generen y almacenen los datos que puede utilizar un desarrollador para crear este tipo de servicio. Resulta importante advertir que un desarrollador no puede proporcionar su propia imagen de VM para que se ejecute Windows Azure. Por el contrario, la plataforma ofrece y conserva su propia versión de Windows. Los desarrolladores se enfocan en la creación de aplicaciones que se ejecutan en Windows Azure. Además, esas aplicaciones pueden ejecutarse solo en modo de usuario: no se permite el acceso de administrador. Esta restricción permite que Windows Azure actualice el sistema operativo en cada VM sin preocuparse si la aplicación ha realizado modificaciones a nivel de sistema. En lugar de requerir que los 5

desarrolladores instalen revisiones de Windows, por ejemplo, Windows Azure se ocupa de esto. El objetivo es permitir que las aplicaciones se ejecuten de forma continua mientras se minimiza el esfuerzo administrativo requerido. La capacidad para ejecutar el código es una parte fundamental de la plataforma cloud, pero no es suficiente. Las aplicaciones a su vez necesitan un almacenamiento persistente que conserve la información, aun cuando no se encuentran en funcionamiento. Cubrir esta necesidad es el objetivo del servicio de almacenamiento de Windows Azure, lo cual se describe a continuación. SERVICIO DE ALMACENAMIENTO Las aplicaciones trabajan con datos de diferentes formas. Por consiguiente, el servicio de almacenamiento de Windows Azure ofrece varias opciones. El Gráfico 4 muestra las opciones. Gráfico 4: el almacenamiento de Windows Azure ofrece blobs, tablas y colas. La forma más sencilla de almacenar datos en Windows Azure es a través de blobs. Un blob contiene datos binarios y, como sugiere el Gráfico 4, existe una jerarquía simple: una cuenta de almacenamiento puede contar con uno o más contenedores, cada uno de los cuales incluye uno o más blobs. Los blobs pueden ser grandes y pueden tener metadatos asociados, como información sobre dónde se realizó una fotografía JPEG o quién es el intérprete de un archivo MP3. Los blobs también ofrecen un almacenamiento en segundo plano para XDrives, un mecanismo para visualizar almacenamiento persistente como si fuera una unidad local. Los blobs son adecuados para algunas situaciones, pero son demasiado desestructurados para otras. Para permitir que las aplicaciones trabajen en una forma más escalable, el almacenamiento de Windows Azure proporciona tablas. No se deje llevar por conclusiones erróneas por el nombre: éstas no son tablas relacionales. De hecho, aunque se denominen tablas, los datos que contiene cada una en realidad se almacenan en un grupo de entidades que incluyen propiedades. Y en lugar de utilizar SQL, una aplicación 6

puede acceder a los datos de una tabla utilizando las convenciones establecidas por ADO.NET Data Services. La razón de este enfoque aparentemente idiosincrático es que permite ampliar el almacenamiento (ampliar al distribuir datos en muchas PC) con mayor eficacia que una base de datos relacional estándar. De hecho, una sola tabla de Windows Azure puede contener miles de millones de entidades que incluyan terabytes de datos. Los blobs y las tablas se enfocan en almacenar datos y acceder a ellos. La tercera opción del almacenamiento de Windows Azure, las colas, tiene un fin diferente. Una de las principales funciones de las colas es ofrecer una manera para que las instancias de rol web se comuniquen con las instancias de rol de trabajo de forma asincrónica. Por ejemplo, es posible que un usuario ingrese un pedido para realizar tareas intensivas de informática a través de la página web implementada por un rol web de Windows Azure. La instancia de rol web que recibe este pedido puede crear un mensaje en la cola, el cual describa el trabajo a realizar. Una instancia de rol de trabajo que se encuentra en espera en esta cola puede leer el mensaje y realizar la tarea que especifica. Cualquier resultado puede devolverse a través de otra cola o manejarse de otra manera. Sin importar cómo se almacenan los datos, en blobs, tablas o colas, toda la información que se encuentra en el almacenamiento de Windows Azure se replica tres veces. Esta réplica permite tolerancia de fallos, ya que extraviar una copia no se considera grave. No obstante, el sistema ofrece una consistencia sólida, por lo que una aplicación que lee inmediatamente los datos que ha creado se garantiza que regrese lo que creó. Windows Azure también conserva una copia de seguridad de todos los datos en otro centro de datos en la misma parte del mundo. Si el centro de datos que contiene la copia principal no se encuentra disponible o está destruido, esta copia de seguridad conserva su disponibilidad. El almacenamiento de Windows Azure puede accederse a través de una aplicación de Windows Azure, a través de una aplicación que se ejecute de forma interna dentro de una organización o por una que se ejecute en un hoster o en otra plataforma cloud. En estos casos, los tres estilos de almacenamiento de Windows Azure utilizan las convenciones de REST para identificar y exhibir datos, como lo sugiere el Gráfico 4. Los blobs, las tablas y las colas se denominan utilizando URI y se acceden a través de operaciones HTTP estándar. Un cliente.net puede utilizar las librerías de ADO.NET Data Services para realizar eso, pero no es obligatorio; una aplicación también puede realizar llamadas HTTP iniciales. Crear aplicaciones de Windows Azure que utilicen blobs, tablas y colas puede resultar útil. Pero muchas aplicaciones en la actualidad acuden al almacenamiento relacional, lo cual no forma parte de Windows Azure. No obstante, esta opción se ofrece a través de SQL Azure Database, otro componente de la plataforma de Windows Azure. Las aplicaciones que se ejecutan en Windows Azure (o en otras plataformas) pueden utilizar esta tecnología para obtener acceso conocido basado en SQL al almacenamiento relacional del cloud. LA ESTRUCTURA Todas las aplicaciones de Windows Azure y todos los datos que se encuentran en su almacenamiento residen en algún centro de datos de Microsoft. Dentro de ese centro de datos, el conjunto de PC con Windows Azure se organiza en una estructura. El Gráfico 5 demuestra esta idea. 7

Gráfico 5: el controlador de estructura interactúa con las aplicaciones de Windows Azure a través del agente de estructura. Como se demuestra en el gráfico, la estructura de Windows Azure consiste en un grupo (grande) de PC, las cuales se administran a través del software denominado controlador de estructura. El controlador de estructura se replica en un grupo de cinco a siete PC y posee todos los recursos de la estructura: PC, conmutadores, balanceo de carga y más. Ya que se puede comunicar con un agente de estructura de todas las PC, también conoce todas las aplicaciones de Windows Azure en esta estructura (curiosamente, el controlador de estructura considera al almacenamiento de Windows Azure como simplemente otra aplicación, y no puede visualizar los detalles de la réplica ni la administración de datos). Este amplio conocimiento permite que el controlador de estructura realice varias tareas útiles. Monitorea todas las aplicaciones en funcionamiento, por ejemplo, y ofrece un panorama actual de lo que sucede en la estructura. Administra los sistemas operativos, mientras que se ocupa de ciertas cosas como la aplicación de revisiones de la versión de Windows Server que se ejecuta en las VM con Windows Azure. También decide dónde deberían ejecutarse las nuevas aplicaciones, eligiendo los servidores físicos para optimizar el uso de hardware. Para realizar esto, el controlador de estructura depende del archivo de configuración que se encuentra cargado con cada aplicación de Windows Azure. Este archivo proporciona una descripción basada en XML sobre lo que necesita la aplicación: cuántas instancias de rol web, cuántas instancias de rol de trabajo y más. Cuando el controlador de estructura recibe esta nueva aplicación, utiliza este archivo de configuración para determinar cuántas VM con rol web y de trabajo se deben crear. 8

Una vez creadas las VM, el controlador de estructura monitorea cada una. Si una aplicación requiere cinco instancias de rol web y una de ellas falla, por ejemplo, el controlador de estructura automáticamente reiniciará una nueva. De forma similar, si la PC en la que la VM se ejecuta falla, el controlador de estructura iniciará una nueva instancia del rol web o de trabajo en una nueva VM de otra PC, reiniciando el balanceo de carga según sea necesario para dirigirse a la nueva PC. En la primera versión de Windows Azure, la estructura ofrece cuatro tamaños de VM para que los desarrolladores elijan entre ellos. Las opciones son: Pequeña, con un CPU de un solo núcleo de 1.6 GHz, memoria de 1.75 GB y almacenamiento de instancias de 225 GB Mediana, con una CPU de doble núcleo de 1.6 GHz, memoria de 3.5 GB y almacenamiento de instancias de 490 GB Grande, con una CPU de cuatro núcleos de 1.6 GHz, memoria de 7 GB y almacenamiento de instancias de 1.000 GB Extra grande, con una CPU de ocho núcleos de 1.6 GHz, memoria de 14 GB y almacenamiento de instancias de 2.040 GB Advierta que cada instancia cuenta con uno o más núcleos de procesador exclusivos. Esto significa que el rendimiento de las aplicaciones es predecible y no existe un límite arbitrario sobre cuánto tiempo puede ejecutarse una instancia. Por ejemplo, una instancia de rol web puede tomar el tiempo que sea necesario para manejar un pedido de un usuario, mientras que la instancia de rol de trabajo puede computar el valor de pi a un millón de dígitos. UTILIZACIÓN DE WINDOWS AZURE: ESCENARIOS Resulta importante comprender los componentes de Windows Azure, pero no es suficiente. La mejor forma de comprender esta plataforma es ver ejemplos sobre cómo se utiliza. De este modo, esta sección abarca cinco escenarios centrales para utilizar 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 y utilizar almacenamiento cloud desde una aplicación interna u hospedada. CREAR UNA APLICACIÓN WEB ESCALABLE Suponga que una organización desea crear una aplicación web con acceso desde Internet. La elección común hoy en día es ejecutar esa aplicación en un centro de datos dentro de la organización o en un hoster. En muchos casos, no obstante, una plataforma cloud como Windows Azure es una mejor opción. Por ejemplo, si la aplicación necesita manejar una gran cantidad de usuarios simultáneos, lo mejor sería crearla en una plataforma expresamente diseñada para brindarle soporte. El soporte intrínseco de las aplicaciones y datos ampliables que ofrece Windows Azure puede manejar más grandes cargas que las tecnologías web más convencionales. O imagine que la carga de la aplicación variará de forma significativa, con picos ocasionales entre largos períodos de escaso uso. Por ejemplo, un sitio de venta de tickets en línea puede mostrar este patrón, de la misma forma que los sitios de video de noticias con 9

interesantes historias ocasionales, aplicaciones que se utilizan mayormente en ciertos momentos del día y más. Ejecutar este tipo de aplicación en un centro de datos convencional requiere que siempre se cuente con suficientes PC para manejar los picos, aún cuando muchos de esos sistemas no se utilizan la mayor parte del tiempo. Si, por el contrario, la aplicación se crea en Windows Azure, la organización que la utiliza puede aumentar la cantidad de instancias que usa solo cuando es necesario, y luego reducirla a una menor cantidad. Ya que el costo de Windows Azure se basa en el uso (usted paga por hora por cada instancia), es posible que sea más accesible que mantener muchas PC que no se utilizan. Para crear una aplicación web escalable en Windows Azure, un desarrollador puede utilizar roles web y tablas. El Gráfico 6 muestra una simple ilustración sobre cómo funciona. Gráfico 6: una aplicación web escalable puede utilizar instancias de rol web y tablas. En el ejemplo que aquí se muestra, los clientes son exploradores y, por lo tanto, la lógica de la aplicación puede implementarse a través de ASP.NET u otra tecnología web. También es posible crear una aplicación web escalable que exhiba servicios web REST y/o basados en SOAP utilizando WCF. En ambos casos, el desarrollador especifica cuántas instancias de la aplicación deben ejecutarse, y el controlador de estructura de Windows Azure crea esta cantidad de VM. Según lo descripto anteriormente, el controlador de estructura también monitorea estas instancias, lo cual se asegura de que la cantidad solicitada siempre se encuentre disponible. Para el almacenamiento de datos, la aplicación utiliza las tablas de almacenamiento de Windows Azure, las cuales ofrecen almacenamiento ampliable que puede manejar enormes cantidades de datos. CREAR UNA APLICACIÓN DE PROCESAMIENTO PARALELO Las aplicaciones web escalables son útiles, pero no son lo único bueno que ofrece Windows Azure. Imagine a una organización que ocasionalmente necesita mucha potencia en informática para una 10

aplicación de procesamiento paralelo. Existen muchos ejemplos sobre esto: brindar servicios en una empresa de efectos especiales para películas, desarrollo de nuevas drogas en una empresa farmacéutica, modelado financiero en un banco, entre otros. Mientras es posible mantener un gran grupo de PC para cubrir esta necesidad ocasional, a su vez resulta costoso. Windows Azure, por el contrario, puede ofrecer estos recursos según sea necesario al ofrecer una especie de compute cluster a pedido. Un desarrollador puede utilizar roles de trabajo para crear este tipo de aplicación. Y ya que no es la única opción, las aplicaciones paralelas por lo general utilizan grandes conjuntos de datos, los cuales pueden estar almacenados en los blobs de Windows Azure. El Gráfico 7 muestra una simple ilustración sobre cómo funciona este tipo de aplicación. Gráfico 7: una aplicación de procesamiento paralelo puede utilizar una instancia de rol web, muchas instancias de rol de trabajo, colas y blobs. En el escenario que se muestra aquí, el trabajo paralelo se realiza a través de varias instancias de rol de trabajo que se ejecutan de forma simultánea, y cada una utiliza datos de blobs. Ya que Windows Azure no impone límites sobre cuánto tiempo puede ejecutarse una instancia, cada una puede realizar una cantidad arbitraria de trabajos. Para interactuar con esta aplicación, el usuario acude a una sola instancia de rol web. A través de esta interfaz, el usuario puede determinar la cantidad de instancias de trabajo que debe ejecutarse, iniciar y detener estas instancias, obtener resultados y más. La comunicación entre la instancia de rol web y las instancias de rol de trabajo se basa en las colas de almacenamiento de Windows Azure. A su vez, se puede acceder a esas colas directamente a través de una aplicación interna. En lugar de acudir a una instancia de rol web que se ejecuta en Windows Azure, como se demuestra aquí, el usuario puede interactuar con las instancias de rol de trabajo desde una aplicación interna a través de las colas. Cualquiera sea la forma en que se realiza, el resultado es el mismo: mucha potencia de procesamiento a pedido. 11

CREAR UNA APLICACIÓN WEB ESCALABLE CON PROCESAMIENTO EN SEGUNDO PLANO Probablemente sea lo más adecuado decir que la mayoría de las aplicaciones que se crean en la actualidad ofrece una interfaz de navegación. Pero mientras aquellas que solo aceptan y responden a los pedidos del explorador son útiles, a su vez son limitadas. Existen muchas situaciones en las que el software con acceso desde la Web también necesita iniciar trabajos que se ejecuten en segundo plano, sin importar la parte de pedidos/respuestas de la aplicación. Por ejemplo, imagine una aplicación web para compartir videos. Necesita aceptar pedidos del explorador, tal vez de una gran cantidad de usuarios simultáneos. Algunos de esos pedidos cargarán nuevos videos, y cada uno de ellos debe procesarse y almacenarse para que pueda accederse más adelante. No tendría sentido obligar al usuario a esperar mientras se realiza este proceso. Por el contrario, la parte de la aplicación que acepta los pedidos del explorador debería poder iniciar una tarea en segundo plano que efectúe este trabajo. Los roles web y de trabajo de Windows Azure pueden utilizarse en conjunto para abordar este escenario. El Gráfico 8 muestra cómo funciona este tipo de aplicación. Gráfico 8: una aplicación web escalable con procesamiento en segundo plano puede utilizar todas las capacidades de Windows Azure. Al igual que la aplicación web escalable que se mostró anteriormente, esta aplicación utiliza algunas instancias de rol web para manejar los pedidos de los usuarios. Para brindar soporte a una enorme cantidad de usuarios simultáneos, también utiliza tablas para almacenar información. Para el procesamiento en segundo plano, acude a las instancias de rol de trabajo al enviarles tareas a través de colas. En este ejemplo, esas instancias de trabajo funcionan con datos de blobs, pero otros enfoques también son posibles. 12

Este ejemplo muestra cómo la aplicación puede utilizar todas las capacidades básicas que incluye Windows Azure: instancias de rol web, instancias de rol de trabajo, blobs, tablas y colas. Mientras que no todas las aplicaciones necesitan todo eso, resulta indispensable que todas se encuentren disponibles para brindar soporte a escenarios más complejos como éste. CREAR UNA APLICACIÓN WEB CON DATOS RELACIONALES Los blobs, las tablas y las colas resultan adecuados para algunas situaciones. Para otras situaciones, sin embargo, los datos relacionales resultan más eficaces. Suponga que una empresa desea ejecutar una aplicación en Windows Azure. Es posible que esta aplicación no necesite la escala masiva que admiten las tablas de Windows Azure. Por el contrario, sus creadores pueden optar por utilizar el enfoque relacional que ya conocen con herramientas de generación de informes conocidas. En un caso como éste, la aplicación puede utilizar Windows Azure junto con SQL Azure Database, como se muestra en el Gráfico 9. Gráfico 9: una aplicación de Windows Azure puede utilizar SQL Azure Database para trabajar con datos relacionales. SQL Azure Database ofrece un gran subconjunto de funciones de SQL Server como un servicio cloud administrado. Las aplicaciones pueden crear bases de datos, ejecutar consultas de SQL y más, pero no se requiere administrar el sistema de base de datos en el hardware donde se ejecuta: Microsoft se ocupa de eso. Se accede a SQL Azure Database a través del protocolo de Flujo de datos tabulares (TDS), como la versión interna de SQL Server. Esto permite que una aplicación de Windows Azure acceda a los datos relacionales utilizando mecanismos tradicionales como ADO.NET. Y ya que SQL Azure Database es un servicio cloud, su costo se basa en el uso, como en el almacenamiento de Windows Azure. Debido a que Windows Azure y SQL Azure Database ofrecen copias cloud de sus pares internos, resulta directo migrar el código y los datos de este tipo de aplicación entre los dos entornos. Las cosas no son 13

exactamente las mismas: es probable que el código de Windows Azure realice el inicio de sesión a través de un mecanismo solo de cloud, por ejemplo; sin embargo, el cloud y el entorno interno son bastante similares. La portabilidad es útil cada vez que resulta conveniente crear una aplicación cuyo código y datos puedan residir ya sea de forma interna o en el cloud. UTILIZAR ALMACENAMIENTO CLOUD DESDE UNA APLICACIÓN INTERNA U HOSPEDADA Mientras que Windows Azure ofrece una gama de capacidades, a veces una aplicación necesita solo una de ellas. Por ejemplo, imagine una aplicación interna u hospedada que requiera almacenar una enorme cantidad de datos. Es posible que una empresa desee archivar, por ejemplo, correos electrónicos antiguos, por lo cual ahorra dinero en almacenamiento mientras que aun mantiene al correo accesible. Un sitio web de noticias que se ejecuta en un hoster puede requerir una ubicación escalable y accesible de forma global para almacenar grandes cantidades de textos, gráficos, videos e información de perfiles sobre sus usuarios. Un sitio de uso compartido de fotografías puede desear evitar los desafíos que implica almacenar su información mediante un tercero confiable. Todas estas situaciones pueden abordarse a través del almacenamiento de Windows Azure. El Gráfico 10 demuestra esta idea. Gráfico 10: una aplicación interna u hospedada puede utilizar los blobs y las tablas de Windows Azure para almacenar sus datos en el cloud. Como lo muestra este gráfico, una aplicación interna u hospedada puede acceder directamente al almacenamiento de Windows Azure. Mientras que es posible que este acceso sea más lento que trabajar con un almacenamiento local, también puede resultar más accesible, más escalable y más confiable. Para algunas aplicaciones, esta compensación definitivamente resulta conveniente. Y aunque no se muestre en el gráfico, las aplicaciones pueden utilizar SQL Azure Database de la misma manera. 14

Brindar soporte a los cinco escenarios que se describen en esta sección (aplicaciones web escalables, aplicaciones de procesamiento paralelo, aplicaciones web escalables con procesamiento en segundo plano, aplicaciones web con almacenamiento relacional y aplicaciones no cloud que acceden al almacenamiento cloud) es un objetivo fundamental para Windows Azure. A medida que crece la plataforma cloud, no obstante, también aumentan los problemas que aborda. Los escenarios aquí descriptos son importantes, pero no son el fin de la historia. COMPRENSIÓN DE WINDOWS AZURE: UNA VISIÓN MÁS DETALLADA Comprender el funcionamiento de Windows Azure requiere conocer las tareas básicas de la plataforma y luego visualizar los escenarios típicos en los que pueden aplicarse esas tareas. No obstante, esta tecnología abarca mucho más. Esta sección ofrece una visión más profunda sobre algunos de sus aspectos más interesantes. DESARROLLAR APLICACIONES DE WINDOWS AZURE Para los desarrolladores, crear una aplicación de Windows Azure se asemeja a crear una aplicación de Windows tradicional. Según lo descripto anteriormente, la plataforma admite aplicaciones.net y aquellas creadas a través de un código sin administración, a fin de que un desarrollador pueda utilizar lo que más se ajuste a su problema. Para simplificar estas tareas, Windows Azure proporciona plantillas de proyectos de Visual Studio para crear roles web, roles de trabajo y aplicaciones que combinen ambos roles. Una diferencia evidente entre los entornos cloud e internos es que las aplicaciones de Windows Azure no se ejecutan de forma local. Esta diferencia permite que el desarrollo resulte más desafiante. Para atenuar esto, Microsoft ofrece la estructura de desarrollo, una versión del entorno de Windows Azure que se ejecuta en la PC de un desarrollador. El Gráfico 11 muestra cómo funciona. Gráfico 11: la estructura de desarrollo ofrece una copia local de Windows Azure para desarrolladores. 15

La estructura de desarrollo se ejecuta en una sola PC con Windows Server 2008, Windows 7 o Windows Vista. Emula la funcionalidad de Windows Azure en el cloud, completa con roles web, roles de trabajo y todas las opciones de almacenamiento de Windows Azure. Un desarrollador puede crear una aplicación de Windows Azure, implementarla en la estructura de desarrollo y ejecutarla de la misma forma que las aplicaciones reales. Por ejemplo, puede determinar cuántas instancias de cada rol deben ejecutarse, utilizar colas para comunicarse entre estas instancias y realizar prácticamente todo lo que sea posible utilizando Windows Azure (en realidad, es muy probable crear una aplicación de Windows Azure sin haberlo usado nunca en el cloud). Una vez desarrollada la aplicación y evaluada localmente, el desarrollador puede cargar el código y su archivo de configuración a través del portal de Windows Azure, y luego ejecutarla. EXAMINAR EL SERVICIO DE INFORMÁTICA Es posible que le agrade permitir que Microsoft elija en qué centro de datos residirá su aplicación y su información. Pero es más probable que necesite mayor control. Suponga que sus datos necesitan permanecer dentro de la Unión Europea por razones legales, o tal vez muchos de sus clientes se encuentran en Norteamérica. En este tipo de situaciones, desea poder especificar dónde se ejecuta su aplicación y dónde almacena sus datos. Para posibilitarlo, Windows Azure permite que un desarrollador indique en qué centro de datos debe ejecutarse una aplicación y dónde debe almacenarse su información. También puede determinar que un grupo específico de aplicaciones y datos (incluso datos de SQL Azure Database) debe residir en el mismo centro de datos. En principio, Microsoft ofrece centros de datos de Windows Azure en los Estados Unidos, Europa y Asia, y habrá más en el futuro. Dondequiera que se ejecute, una aplicación de Windows Azure puede instalarse y encontrarse disponible para sus usuarios a través de un proceso de dos pasos. Primero, un desarrollador carga la aplicación al área temporal de la plataforma. La terminal HTTP/HTTPS de la aplicación en etapas cuenta con un nombre DNS del formato <GUID>.cloudapp.net, en donde <GUID> representa un identificador único de forma global asignado por Windows Azure. Este nombre DNS se asocia a la dirección IP virtual (VIP) que identifica el balanceo de carga de Windows Azure, a través del cual puede accederse a la aplicación. Cuando el desarrollador se encuentra listo para darle vida a la aplicación, utiliza el portal de Windows Azure para pedir que se ubique en producción. Luego, Windows Azure cambia mínimamente la entrada de su servidor DNS para asociar la VIP de la aplicación con el nombre DNS de producción que ha elegido, como myazureservice.cloudapp.net. Para utilizar un dominio personalizado en lugar del dominio cloudapp.net de Microsoft, el dueño de la aplicación de Windows Azure puede crear un alias DNS utilizando un CNAME estándar. Resulta conveniente mencionar algunos elementos de este proceso. En primer lugar, ya que el intercambio de VIP es mínimo, la aplicación en funcionamiento puede actualizarse a una nueva versión sin causar tiempos de inactividad. Esto resulta importante para muchos tipos de servicios cloud. En segundo lugar, advierta que durante este proceso las direcciones IP reales de las VM de Windows Azure, y las PC físicas en las que se ejecutan las VM, nunca quedan expuestas. También es conveniente mencionar que este proceso de dos pasos no es la única opción. También es posible implementar una aplicación directamente en producción sin pasar por etapas. 16

Una vez que la aplicación se encuentra disponible, sus usuarios pueden requerir una forma para identificarse. Para hacerlo, Windows Azure permite que los desarrolladores utilicen cualquier mecanismo de autenticación basado en HTTP que deseen. Una aplicación ASP.NET puede utilizar un proveedor de membresía para almacenar sus ID de usuario y contraseña, por ejemplo, o puede utilizar otro método, como el servicio Live ID de Microsoft. Las aplicaciones de Windows Azure también pueden utilizar Windows Identity Foundation (WIF) para implementar identidades basadas en reclamos. La opción queda a discreción del creador de la aplicación. En general, crear aplicaciones seguras requiere la utilización de certificados. Para permitirlo, Windows Azure ofrece un almacenamiento de certificados, lo cual permite que una aplicación utilice diferentes certificados para distintos fines. Por ejemplo, una aplicación puede utilizar un certificado para su terminal SSL, y otro para firmar pedidos que realiza a otro servicio. Los nuevos certificados pueden implementarse de forma individual a este almacenamiento: no se requiere cargar una nueva versión de la aplicación. Una vez que se ejecuta, una instancia de rol puede usar API de Windows Azure a fin de detectar la topología de la aplicación de la que forma parte. En otras palabras, cualquier instancia puede detectar terminales internas expuestas por las otras instancias de rol web y/o de trabajo que forman parte de la misma aplicación. Una vez que tiene esta información, una instancia puede establecer comunicación directa con aquellas instancias a través de WCF u otro mecanismo, una opción conocida como comunicación entre roles. Entre otras cosas, esto permite que un desarrollador instale una tecnología de caché distribuida, como memoria caché en roles de trabajo, y luego se comunique directamente con esa caché desde los roles web en la misma aplicación. Para permitir la administración de las aplicaciones de Windows Azure en funcionamiento, la plataforma ofrece una API de administración de servicios. Esta interfaz REST permite que un cliente remoto implemente aplicaciones de Windows Azure, monitoree los recursos que utilizan esas aplicaciones, modifique la cantidad de instancias de roles en funcionamiento y más. EXAMINAR EL SERVICIO DE ALMACENAMIENTO Para utilizar el almacenamiento de Windows Azure, el desarrollador primero debe crear una cuenta de almacenamiento. Para controlar el acceso a la información en esta cuenta, Windows Azure otorga a su creador una clave secreta. Cada pedido que realiza una aplicación a la información en esta cuenta de almacenamiento (blobs, tablas y colas) posee una firma creada con esta clave secreta. En otras palabras, la autorización se realiza a nivel de cuenta (aunque los blobs tienen otra opción que se describe más adelante). El almacenamiento de Windows Azure no proporciona listas de control de acceso ni otra forma más escalable para controlar quién se encuentra autorizado a acceder a los datos que contiene. Blobs Los grandes objetos binarios (blobs) por lo general son justo lo que necesita una aplicación. Ya sea que incluyan video, audio, mensajes de correo electrónico archivados o cualquier otra cosa, permiten que las aplicaciones almacenen y accedan a los datos de una forma muy general. Para utilizar blobs, un desarrollador primero crea uno o más contenedores en alguna cuenta de almacenamiento. Cada uno de estos contenedores puede incluir uno o más blobs. 17

Para identificar un blob específico, una aplicación puede suministrar una URI del siguiente formato: http://<storageaccount>.blob.core.windows.net/<container>/<blobname> <StorageAccount> es un solo identificador que se asigna cuando se crea una nueva cuenta de almacenamiento, mientras que <Container> y <BlobName> son los nombres de un contenedor específico y un blob que se encuentra dentro de él. Los contenedores no pueden unificarse (pueden contener solo blobs, no otros contenedores), por lo que resulta imposible crear una jerarquía de blobs. Incluso se permite que el nombre de un blob contenga un /, por lo que un desarrollador puede crear la ilusión de una jerarquía si así lo desea. Los blobs pueden tener dos formatos: Blobs en bloque, cada uno de los cuales puede incluir datos de hasta 200 gigabytes. Para que su transferencia sea más eficaz, un blob en bloque se subdivide en bloques. Si falla, se puede reanudar la transmisión con el bloque más reciente en lugar de enviar todo el blob nuevamente. Una vez que todos los bloques de un blob se han cargado, se puede comprometer todo el blob a la vez. Blobs en páginas, que pueden ser de un terabyte cada uno. Un blob en páginas se divide en páginas de 512 bytes, y una aplicación puede leer y crear páginas individuales de forma aleatoria en el blob. Cualquiera sea el tipo de blob que poseen, los contenedores pueden marcarse como privados o públicos. Para los blobs en un contenedor privado, los pedidos de lectura y creación deben firmarse utilizando la clave de la cuenta de almacenamiento del blob. Para los blobs en un contenedor público, solo se deben firmar los pedidos de escritura; cualquier aplicación puede leer el blob. Esto puede resultar útil en situaciones como la realización de videos, fotos u otros datos desestructurados que por lo general se encuentran disponibles en Internet. También es posible crear firmas de acceso compartido para aplicaciones o usuarios individuales. Es posible que los pedidos para leer, crear o eliminar un blob específico deban contar con una firma en particular, lo cual permite un control de acceso más escalable a los datos del blob. Una aplicación de blobs común es almacenar información a la que se accederá desde distintas ubicaciones. Imagine una aplicación que ofrece videos a clientes de Flash o Silverlight de todo el mundo. Para mejorar el rendimiento en este tipo de situaciones, Windows Azure ofrece una red de entrega de contenido (CDN). La CDN almacena copias de un blob en sitios cercanos a las aplicaciones que utilizan los datos del blob. El resultado es un mejor rendimiento para los blobs que se acceden con frecuencia desde ubicaciones distribuidas. Otro aspecto importante de los blobs es la función que desempeñan al admitir XDrives. Para entender lo que es esta función, primero advierta que las instancias de rol web y las de trabajo pueden acceder al sistema de archivos local de sus VM. De forma predeterminada, no obstante, este almacenamiento no es persistente. Cuando se cierra una instancia, la VM y su almacenamiento local desaparecen. Sin embargo, montar un XDrive para la instancia puede hacer que el blob en páginas parezca una unidad local, completo con un sistema de archivos NTFS. Las escrituras al XDrive pueden realizarse de forma inmediata al blob en segundo plano. Cuando no se ejecuta la instancia, estos datos se almacenan de forma persistente en el blob en páginas, listos para montarse nuevamente. A continuación se mencionan las formas en que pueden utilizarse los XDrives: 18

Un desarrollador puede cargar un disco duro virtual (VHD) que contenga un sistema de archivos NTFS, luego montar este VHD como XDrive. Esto ofrece una forma directa para migrar datos del sistema de archivos entre Windows Azure y un sistema de Windows Server interno. Un desarrollador de Windows Azure puede instalar y ejecutar un sistema de base de datos MySQL en una instancia de rol de Windows Azure utilizando un XDrive como almacenamiento en segundo plano. Tablas Los blobs son fáciles de comprender (son tan sólo una base de bytes) pero las tablas son un poco más complejas. El Gráfico 12 muestra cómo las partes de una tabla se ajustan conjuntamente. Gráfico 12: las tablas ofrecen almacenamiento basado en entidades. Según lo muestra el gráfico, cada tabla contiene una cantidad de entidades. Una entidad cuenta con cero o más propiedades, cada una con un nombre, un tipo y un valor. Se admite una variedad de tipos, incluso binaria, Bool, DateTime, Double, GUID, Int, Int64 y String. Una propiedad puede poseer diferentes tipos en distintos momentos según el valor almacenado en ella, y no se requiere que todas las propiedades de una entidad tengan el mismo tipo: el desarrollador puede realizar lo que le resulte más conveniente para su aplicación. Sin importar lo que contenga, una entidad puede tener un tamaño máximo de un megabyte y siempre se puede acceder como una unidad. La lectura de una entidad devuelve todas sus propiedades, y su escritura puede reemplazar todas sus propiedades. También es posible actualizar un grupo de entidades dentro de una sola tabla de forma mínima, lo cual garantiza que todas las actualizaciones sean exitosas o fallen. 19

Las tablas de almacenamiento de Windows Azure son diferentes a las tablas relacionales en varias formas. De forma más evidente, no son tablas en el sentido usual. A su vez, no se puede acceder a ellas a través de ADO.NET ordinario ni tampoco admiten consultas de SQL. Y las tablas de almacenamiento de Windows Azure no utilizan esquemas: las propiedades de una entidad pueden ser de varios tipos y éstos pueden modificarse con el tiempo. La pregunta es la siguiente: Por qué? Por qué no se admiten tablas relacionales ordinarias con las consultas de SQL estándar? La respuesta surge del objetivo principal de Windows Azure, que es admitir aplicaciones de escalabilidad masiva. Las bases de datos relacionales tradicionales pueden ampliarse y manejar cada vez más usuarios al ejecutar el DBMS en PC más grandes. Pero para admitir grandes cantidades de usuarios simultáneos, se debe ampliar, pero no aumentar, el almacenamiento. Para permitir esto, el mecanismo de almacenamiento necesita simplificarse: las tablas relacionales tradicionales con SQL estándar ya no trabajan. Lo que se necesita es el tipo de estructura que ofrecen las tablas de Windows Azure. Utilizar tablas requiere la consideración de los desarrolladores, pues las estructuras relacionales conocidas no pueden aplicarse sin ser modificadas. Sin embargo, se debe utilizar este enfoque para crear aplicaciones muy escalables. Permite que los desarrolladores no se preocupen por el escalamiento: solo crean nuevas tablas, agregan nuevas entidades y Windows Azure se encarga del resto. También elimina una parte del trabajo que se necesita para mantener un DBMS, pues Windows Azure lo hace por usted. El objetivo es permitir que los desarrolladores se enfoquen en sus aplicaciones en lugar de los mecanismos para almacenar y administrar grandes cantidades de datos. Como todo lo demás en el almacenamiento de Windows Azure, las tablas se acceden mediante REST. Una aplicación.net puede utilizar ADO.NET Data Services o Consulta integrada de lenguaje (LINQ) para realizar esto, y ambos ocultan las solicitudes HTTP en segundo plano. Cualquier aplicación, ya sea.net u otra, también puede realizar estos pedidos de forma directa. Por ejemplo, una consulta sobre una tabla específica se expresa como un HTTP GET sobre una URI con el siguiente formato: http://<storageaccount>.table.core.windows.net/<tablename>?$filter=<query> Aquí, <TableName> especifica la tabla que se consulta, mientras que <Query> contiene la consulta que se ejecutará sobre esta tabla. Si la consulta ofrece una gran cantidad de resultados, un desarrollador puede obtener un token de continuación que puede pasar a la siguiente consulta. Realizar esto repetidamente permite recuperar el conjunto de resultados completo en fragmentos. Las actualizaciones presentan otro problema: Qué sucede si varias aplicaciones intentan actualizar la misma entidad al mismo tiempo? Actualizar una entidad requiere su lectura, el cambio de sus contenidos al modificar, agregar y/o eliminar propiedades, y luego la escritura de la entidad actualizada en la misma tabla. Suponga que dos aplicaciones leen la misma entidad, la modifican y la escriben. Qué sucede? La respuesta predeterminada es que la aplicación cuya escritura llega primero será la exitosa. La escritura de la otra aplicación fallará. Este enfoque, un ejemplo de simultaneidad optimista, se basa en los números de versiones que mantienen las tablas de Windows Azure. Por otro lado, una aplicación puede actualizar una entidad sin condiciones, lo cual garantiza que sus modificaciones serán escritas. Las tablas de Windows Azure no son la opción adecuada para todos los escenarios de almacenamiento, y utilizarlas requiere que los desarrolladores aprendan cosas nuevas. Sin embargo, para las aplicaciones que necesitan la escalabilidad que ofrecen, las tablas son la elección adecuada. 20

Colas Mientras que las tablas y los blobs en principio tienen la función de almacenar y acceder a los datos, el principal objetivo de las colas es permitir la comunicación entre diferentes partes de una aplicación de Windows Azure. Como todo lo demás en el almacenamiento de Windows Azure, las colas se acceden mediante REST. Las aplicaciones de Windows Azure y las externas hacen referencia a una cola al utilizar una URI con el siguiente formato: http://<storageaccount>.queue.core.windows.net/<queuename> Como ya se ha descripto, un uso común de las colas es permitir la interacción entre las instancias de rol web y las de rol de trabajo. El Gráfico 13 muestra cómo funciona. Gráfico 13: los mensajes pueden colocarse en cola, retirarse de la cola, procesarse y luego eliminarse de ella de forma explícita. En un escenario típico, se ejecutan varias instancias de roles web, cada una aceptando trabajos de los usuarios (paso 1). Para transferir ese trabajo a las instancias de rol de trabajo, una instancia web escribe un mensaje en una cola (paso 2). Este mensaje, que puede tener hasta ocho kilobytes, puede contener una URI que apunte a un blob o a una entidad en una tabla, u otra cosa, según lo desee la aplicación. Las instancias de trabajo leen mensajes de esta cola (paso 3), luego realizan el trabajo que pide el mensaje (paso 4). Es importante advertir, no obstante, que leer un mensaje de una cola en realidad no lo elimina. Por el contrario, hace que el mensaje se encuentre oculto para otros lectores por un tiempo determinado (que es de 30 segundos de forma predeterminada). Cuando la instancia de trabajo ha finalizado el trabajo que pedía este mensaje, debe eliminar de forma explícita el mensaje de la cola (paso 5). Separar las instancias de rol web de las de rol de trabajo es lo adecuado. El usuario no necesita esperar a que se procese una tarea extensa, y también simplifica la escalabilidad: tan sólo agregue más instancias. Pero por qué se debe hacer que las instancias eliminen mensajes de forma explícita? La respuesta es que eso permite manejar fallas. Si la instancia de rol de trabajo que recupera un mensaje lo maneja de forma exitosa, eliminará el mensaje mientras éste aún se encuentra oculto; es decir, dentro de su marco de 30 segundos. Si una instancia de rol de trabajo retira un mensaje de la cola, entonces fallará antes de que se 21

complete el trabajo que especifica ese mensaje; no eliminará el mensaje de la cola. Cuando finalice el tiempo de visibilidad, el mensaje reaparecerá en la cola y luego otra instancia de rol de trabajo lo leerá. El objetivo es garantizar que cada mensaje se procese al menos una vez. Como se describe aquí, las colas del almacenamiento de Windows Azure no tienen la misma semántica que las colas de Microsoft Message Queuing (MSMQ) u otras tecnologías más conocidas. Por ejemplo, un sistema de cola convencional puede ofrecer semántica de entrada y salida, por lo que entrega cada mensaje por única vez. Las colas de almacenamiento de Windows Azure no ofrecen esas promesas. Como se ha descripto, un mensaje puede entregarse varias veces y no existe garantía de entregar mensajes en un orden específico. Todo es distinto en el cloud y los desarrolladores necesitarán adaptarse a esas diferencias. EXAMINAR LA ESTRUCTURA Para un desarrollador de aplicaciones, Windows Azure consiste en servicios de informática y almacenamiento. Pero ninguno de estos servicios puede funcionar sin la estructura de Windows Azure. Al unificar un centro de datos con muchas PC en un conjunto coherente, la estructura ofrece una base para todo el resto. Según lo descripto anteriormente, el controlador de estructura posee todos los recursos en un centro de datos específico de Windows Azure. También es se encarga de asignar instancias de aplicaciones y almacenamiento a PC físicas. Es importante realizar esto con inteligencia. Por ejemplo, suponga que un desarrollador solicita cinco instancias de rol web y cuatro instancias de rol de trabajo para esta aplicación. Una simple asignación puede ubicar todas estas instancias en PC del mismo rack que reciben servicio del mismo conmutador de red. En caso de que falle el rack o el conmutador, toda la aplicación pierde su disponibilidad. Al proporcionar los objetivos de alta disponibilidad de Windows Azure, hacer que una aplicación dependa de puntos de falla como éstos no sería conveniente. Para evitarlo, el controlador de estructura agrupa las PC que contiene en varios dominios por falla. Cada dominio por falla forma parte del centro de datos, en donde una sola falla puede cerrar el acceso a todo lo que incluye ese dominio. El Gráfico 15 demuestra esta idea. 22

Gráfico 15: el controlador de estructura ubica distintas instancias de una aplicación en diferentes dominios por falla. En este sencillo ejemplo, la aplicación ejecuta solo dos instancias de rol web y el centro de datos se divide en dos dominios por falla. Cuando el controlador de estructura implementa esta aplicación, ubica una instancia de rol web en cada uno de los dominios por falla. Este método implica que una sola falla de hardware en el centro de datos no puede afectar a toda la aplicación. A su vez, recuerde que el controlador de estructura considera al almacenamiento de Windows Azure como otra aplicación; el controlador no maneja la réplica de datos. Por el contrario, esto lo realiza la aplicación de almacenamiento, lo cual garantiza que las réplicas de cualquier blob, tabla y cola utilizadas por esta aplicación se ubican en distintos dominios por falla. Mantener el funcionamiento de una aplicación en caso de fallas del hardware es útil, pero no es suficiente. Recuerde que una aplicación en funcionamiento puede actualizarse en el lugar. Una aplicación verdaderamente confiable, el tipo de aplicación que desea admitir Windows Azure, no debería necesitar cerrarse para realizar esto. Para permitirlo, Windows Azure agrupa instancias de aplicaciones en dos o más dominios de actualización. El Gráfico 16 muestra cómo funciona. 23

Gráfico 16: agrupar una aplicación en distintos dominios de actualización permite que ésta continúe funcionando mientras se actualiza. Cuando se actualiza un código de la aplicación, el controlador de estructura lo realiza en un dominio de actualización a la vez. En el ejemplo que muestra el Gráfico 16, el controlador de estructura primero cierra instancias 1 y 2 de la aplicación X, actualiza sus códigos, luego las reinicia desde el nuevo archivo ejecutable. Luego puede cerrar las instancias 3 y 4 de la aplicación, actualizar sus códigos y reiniciarlas desde el nuevo archivo ejecutable. El objetivo es mantener a la aplicación en continuo funcionamiento, aun mientras se actualiza. Los usuarios pueden advertir la actualización; el tiempo de respuesta de la aplicación podrá aumentar cuando algunas de sus instancias se cierran, por ejemplo, y distintos usuarios accederán a diferentes versiones de la aplicación durante la actualización. Sin embargo, desde el punto de vista del usuario, la aplicación conserva su disponibilidad de forma continua. No confunda los dominios de actualización, una propiedad de una aplicación, con dominios por falla, una propiedad del centro de datos. No obstante, ambos tienen el mismo propósito de alcance global: permitir que la estructura mantenga el funcionamiento de las aplicaciones de Windows Azure en todo momento. PRÓXIMOS PASOS En la Conferencia de Desarrolladores Profesionales de fines de 2009, Microsoft anunció que planifica agregar más funciones a Windows Azure en 2010, incluso: Un mecanismo para que los clientes instalen y ejecuten aplicaciones existentes en Windows Azure. 24

El nombre de código de Microsoft "Sydney", lo cual permite que las instancias de Windows Azure se conecten en un entorno interno a través de IPsec. Esto permitirá que los clientes consideren a las aplicaciones de Windows Azure como aplicaciones que se ejecutan en una sucursal. El fin de ambos cambios es ampliar el atractivo de la tecnología. Simplificar la migración de aplicaciones existentes a Windows Azure tiene un atractivo evidente, mientras que las extensiones Sydney simplificarán aún más la utilización de las aplicaciones de Windows Azure desde dominios de Windows internos. Al agregar estas capacidades, Microsoft desea lograr que esta plataforma cloud sea útil en una más amplia gama de situaciones. CONCLUSIONES Ejecutar aplicaciones y almacenar datos en el cloud es la opción adecuada para muchas situaciones. Las tres partes de Windows Azure, el servicio de informática, el servicio de almacenamiento y la estructura, trabajan en conjunto para hacerlo posible. Junto con el entorno de desarrollo de Windows Azure, SQL Azure Database y el resto de su plataforma, ofrecen una forma para que los desarrolladores de Windows se adapten a este nuevo mundo. En la actualidad, las plataformas cloud son una opción un poco extraña para muchas organizaciones. No obstante, ya que todos nosotros obtenemos experiencia con Windows Azure y otras plataformas cloud, este nuevo enfoque comenzará a resultar menos extraño. Con el tiempo, podríamos esperar aplicaciones basadas en cloud, y las plataformas cloud en las que se ejecutan, para desempeñar una función cada vez más importante en el mundo del software. MÁS INFORMACIÓN Página de inicio de la plataforma de Windows Azure http://www.microsoft.com/windowsazure Presentación de la plataforma de Windows Azure, David Chappell http://go.microsoft.com/fwlink/?linkid=158011 Blobs de Windows Azure: programar almacenamiento de blobs http://download.microsoft.com/download/d/6/e/d6e0290e-8919-4672-b3f7-56001bdc6bfa/windows%20azure%20blob%20-%20dec%202008.docx Tablas de Windows Azure: programar almacenamiento de tablas http://download.microsoft.com/download/3/b/1/3b170ff4-2354-4b2d-b4dc- 8FED5F838F6A/Windows%20Azure%20Table%20-%20Dec%202008.docx Colas de Windows Azure: programar almacenamiento de colas http://download.microsoft.com/download/5/2/d/52d36345-bb08-4518-a024-0aa24d47bd12/windows%20azure%20queue%20-%20dec%202008.docx 25

ACERCA DEL AUTOR David Chappell es el director de Chappell & Associates (www.davidchappell.com) en San Francisco, California. A través de sus conferencias, escritos y consultoría, permite que las personas de todo el mundo comprendan, utilicen y tomen mejores decisiones sobre nuevas tecnologías. 26