EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE

Transcripción

1 EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE DAVID CHAPPELL OCTUBRE DE 2010 PATROCINADO POR MICROSOFT CORPORATION

2 CONTENIDOS Por qué crear un nuevo modelo de programación?... 3 Las tres reglas del modelo de programación de Windows Azure... 3 Las aplicaciones Windows Azure se crean a partir de uno o más roles... 4 Las aplicaciones Windows Azure ejecutan varias instancias de cada uno de los roles... 5 Las aplicaciones Windows Azure se comportan correctamente cuando se produce un error de instancia de rol... 6 Qué proporciona el modelo de programación de Windows Azure... 7 Conceptos básicos: Fabric Controller... 7 Las ventajas: administración, disponibilidad y escalabilidad mejoradas... 8 Implicaciones del modelo de programación de Windows Azure: qué otros cambios supone? Interacciones con el sistema operativo Interacciones con el almacenamiento persistente Interacciones entre instancias de rol Portar aplicaciones de Windows Server a Windows Azure Conclusión Lecturas adicionales Sobre el autor

3 POR QUÉ CREAR UN NUEVO MODELO DE PROGRAMACIÓN? Miles de desarrolladores en todo el mundo saben cómo crear aplicaciones mediante el modelo de programación de Windows Server. Sin embargo, las aplicaciones escritas para Windows Azure, la plataforma en la nube de Microsoft, no utilizan exactamente este modelo más habitual. Aunque la mayoría de los conocimientos de los desarrolladores de Windows siguen siendo aplicables, Windows Azure cuenta con su propio modelo de programación. Por qué? Por qué no replicar exactamente el familiar mundo de Windows Server en la nube? Las plataformas en la nube de la mayoría de los fabricantes hacen precisamente eso: proporcionan máquinas virtuales (VM) que funcionan como VM locales. Este enfoque, habitualmente denominado Infraestructura como servicio (IaaS), es ciertamente útil y resulta ideal para algunas aplicaciones. Sin embargo, las plataformas en la nube constituyen un nuevo universo y ofrecen la posibilidad de encontrar nuevas formas de resolver los problemas de hoy. En lugar de IaaS, Windows Azure proporciona un nivel superior de abstracción comúnmente conocido como Plataforma como servicio (PaaS). Aunque en muchos aspectos es similar al mundo de Windows local, esta abstracción cuenta con su propio modelo de programación pensado para ayudar a los desarrolladores a crear aplicaciones mejoradas. El modelo de programación de Windows Azure permite mejorar las aplicaciones en tres áreas: Administración: en las tecnologías PaaS, la propia plataforma se encarga de la mayor parte de las tareas de administración. Con Windows Azure, ello implica que la plataforma se encarga automáticamente de tareas como aplicar las revisiones de Windows e instalar las nuevas versiones de software del sistema. El objetivo consiste en reducir el esfuerzo y el costo de administrar el entorno de la aplicación. Disponibilidad: tanto si está planificado como si no, las aplicaciones actuales suelen necesitar tiempo de inactividad para las revisiones de Windows, las actualizaciones, los errores del hardware y otros motivos. No obstante, habida cuenta de la redundancia que permiten las plataformas en la nube, ya no hay razón para aceptar el tiempo de inactividad. El modelo de programación de Windows Azure está diseñado para que las aplicaciones estén permanentemente disponibles, incluso en el caso de que haya que realizar actualizaciones de software o se produzcan errores del hardware. Escalabilidad: los diferentes tipos de aplicaciones que los desarrolladores desean crear para la nube suelen ir dirigidas a administrar un gran número de usuarios. Sin embargo, el modelo de programación de Windows Server tradicional no se diseñó especialmente para admitir aplicaciones en Internet, en cambio, el modelo de programación de Windows Azure está pensado para ello desde el principio. Este modelo, ideado en la era de la nube, está diseñado para que los desarrolladores creen aplicaciones escalables compatibles con los centros de datos masivos. Asimismo, e igualmente importante, este modelo permite a las aplicaciones reducir su capacidad para utilizar únicamente los recursos que necesitan. Tanto si el desarrollador utiliza una tecnología IaaS o una oferta PaaS como Windows Azure, la creación de aplicaciones en plataformas en la nube proporciona numerosas ventajas. Por ejemplo, ambos enfoques permiten pagar únicamente por los recursos informáticos que se utilizan, y ambos evitan la necesidad de tener que esperar a que el departamento de TI de la empresa implemente los servidores. No obstante, a pesar de su importancia, estas ventajas no son las que nos interesa destacar aquí. Lo más importante es dejar claro en qué consiste el modelo de programación de Windows Azure y qué posibilidades ofrece. LAS TRES REGLAS DEL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE Para disfrutar de las ventajas que ofrece, el modelo de programación de Windows Azure impone tres reglas para las aplicaciones: Las aplicaciones Windows Azure se crean a partir de uno o más roles. 3

4 Las aplicaciones Windows Azure ejecutan varias instancias de cada uno de los roles. Las aplicaciones Windows Azure se comportan correctamente cuando se produce un error de instancia de rol. Es interesante destacar que Windows Azure también puede ejecutar las aplicaciones que no cumplen todas estas reglas, puesto que no las aplica, sencillamente asume que todas las aplicaciones cumplen las tres. Sin embargo, si decide ejecutar una aplicación en Windows Azure que incumple una o más reglas, recuerde que en realidad la aplicación no estará utilizando el modelo de programación de Windows Azure. A menos que comprenda y siga las reglas del modelo, la aplicación no se ejecutará como sería de esperar. LAS APLICACIONES WINDOWS AZURE SE CREAN A PARTIR DE UNO O MÁS ROLES Tanto si una aplicación se ejecuta en la nube o en su centro de datos, casi siempre se puede dividir en partes lógicas. Windows Azure formaliza estas divisiones en roles. Un rol cuenta con un conjunto de códigos específico, como un ensamblado.net, y define el entorno en el que se ejecuta el código. Actualmente, Windows Azure permite a los desarrolladores crear tres tipos de roles diferentes: Web Role: tal y como su nombre indica, los Web Roles están principalmente diseñados para la lógica que interactúa con el exterior a través de HTTP. El código escrito como Web Role obtiene el contenido a través de Internet Information Services (IIS) y puede crearse mediante varias tecnologías, como ASP.NET, Windows Communication Foundation (WCF), PHP y Java. Rol de trabajador: la lógica escrita como rol de trabajador puede interactuar con el exterior de varias formas, no solamente a través de HTTP. Por ejemplo, un rol de trabajador contiene código que convierte los vídeos a un formato estándar, calcula el riesgo de una cartera de inversiones o realiza algún tipo de análisis de datos. Rol de máquina virtual (VM): un rol VM ejecuta una imagen, un disco duro virtual (VHD), de una máquina virtual Windows Server 2008 R2. Este VHD se crea mediante una máquina Windows Server local y se carga en Windows Azure. Una vez almacenado en la nube, el VHD puede cargarse bajo demanda en un rol VM y ejecutarse. Los tres roles resultan útiles. Sin embargo, puesto que el rol VM es más reciente, las opciones más utilizadas actualmente son los Web Roles y los roles de trabajador. La figura 1 muestra una sencilla aplicación Windows Azure creada con un Web Role y un rol de trabajador. Figura 1: una aplicación Windows Azure se crea desde uno o más roles, como la combinación del Web Role y del rol de trabajador que aquí se ilustra. Esta aplicación puede utilizar un Web Role para aceptar las peticiones HTTP de los usuarios y posteriormente trasladar a un rol de trabajador la tarea que estos le han solicitado, como por ejemplo, cambiar el formato de un archivo de vídeo para que pueda visualizarse. El principal motivo de dividir la tarea en dos partes es que de este modo la aplicación resulta más fácil de escalar. 4

5 Sin embargo, una aplicación Windows Azure también puede constar de un solo Web Role o un solo rol de trabajador, no es preciso utilizar ambos. Una única aplicación puede contener incluso varios tipos de Web Roles y roles de trabajador. Por ejemplo, una aplicación puede contar con un Web Role que implemente una interfaz de explorador creada, por ejemplo, con ASP.NET, y otro Web Role que presente una interfaz de servicios web mediante WCF. Igualmente, una aplicación Windows Azure que realice dos tipos de análisis de datos puede define un rol de trabajador diferente para cada uno. Para no complicar las cosas, asumiremos que la aplicación de ejemplo que hemos descrito tiene tan solo un Web Role y un rol de trabajador. Como parte del proceso de creación de una aplicación Windows Azure, el desarrollador crea un archivo de definición de servicios que nombra y describe los roles de la aplicación. Este archivo también puede especificar otra información, como los puertos que puede escuchar cada rol. Windows Azure utiliza esta información para crear el entorno adecuado para ejecutar la aplicación. LAS APLICACIONES WINDOWS AZURE EJECUTAN VARIAS INSTANCIAS DE CADA UNO DE LOS ROLES Una aplicación Windows Azure consta de uno o más roles. Cuando se ejecuta, una aplicación compatible con el modelo de programación de Windows Azure debe ejecutar al menos dos copias (dos instancias distintas) de cada rol que contiene. Cada instancia se ejecuta como su propia VM, tal y como ilustra la figura 2. Figura 2: las aplicaciones Windows Azure ejecutan varias instancias de cada uno de los roles. Tal y como se ha explicado anteriormente, la aplicación del ejemplo tiene solo un Web Role y un rol de trabajador. El desarrollador puede indicar a Windows Azure el número de instancias que debe ejecutar cada rol a través de un archivo de configuración de servicios (que es distinto del archivo de definición de servicios comentado en la sección anterior). En este caso, el desarrollador ha solicitado cuatro instancias del Web Role de la aplicación y tres instancias de su rol de trabajador. 5

6 Cada instancia de un determinado rol ejecuta exactamente el mismo código. De hecho, con la mayoría de las aplicaciones Windows Azure, cada instancia es idéntica a las demás instancias de ese rol, son intercambiables. Por ejemplo, Windows Azure equilibra automáticamente la carga que requiere HTTP entre las instancias del Web Role de la aplicación. Este equilibrio de carga no admite "sticky sessions" (sesiones pegajosas), por lo que no es posible dirigir todas las peticiones de un cliente a mismo Web Role. No es posible almacenar el estado específico de un cliente, como el carro de la compra, en una instancia de Web Role determinada, puesto que Windows Azure no permite garantizar que esa instancia administre todas las peticiones de un cliente, sino que este tipo de estado debe almacenarse de forma externa, como se explicará más adelante. LAS APLICACIONES WINDOWS AZURE SE COMPORTAN CORRECTAMENTE CUANDO SE PRODUCE UN ERROR DE INSTANCIA DE ROL Una aplicación que sigue el modelo de programación de Windows Azure debe crearse utilizando roles y debe ejecutar dos o más instancias de cada uno de estos. Asimismo, debe comportarse correctamente cuando se produce un error de una de las instancias de rol. La figura 3 ilustra este concepto. Figura 3: las aplicaciones Windows Azure se comportan correctamente incluso cuando se produce un error de una instancia de rol. Aquí, la aplicación que muestra la figura 2 ha perdido dos de sus instancias de Web Role y una de sus instancias de rol de trabajador. Puede ser debido a que los equipos que ejecutaban no funcionen, o quizás a que se ha interrumpido la conexión a la red física de estas máquinas. Independientemente del motivo, el rendimiento de la aplicación se verá afectado, puesto que habrá un menor número de instancias disponibles para realizar esta tarea. Aun así, la aplicación sigue funcionando correctamente. 6

7 Si se produce un error en todas las instancias de un determinado rol, la aplicación dejará de comportarse correctamente, esto es inevitable. Sin embargo, el requisito de funcionar correctamente cuando se producen errores parciales es fundamental en el modelo de programación de Windows Azure. De hecho, el contrato de nivel de servicio (SLA) para Windows Azure requiere la ejecución de al menos dos instancias de cada rol. Las aplicaciones que ejecutan una sola instancia de los roles no pueden disponer de las garantías que proporciona este SLA. La forma más habitual de conseguirlo es hacer que todas las instancias de rol sean equivalentes, como cuando los Web Roles con equilibrio de carga aceptan las peticiones de los usuarios. No obstante, ello no es estrictamente necesario mientras el error de una sola instancia de rol no impida el funcionamiento de la aplicación. Por ejemplo, una aplicación puede utilizar un grupo de instancias de rol de trabajador para almacenar datos en la caché para instancias de Web Role, y que cada instancia de rol de trabajador contenga datos distintos. Si se produce un error de una de las instancias de rol de trabajador, una instancia de Web Role que intente acceder a los datos almacenados en la caché que contenía se comportará igual que si no los encontrara (es decir, obtendrá acceso al almacenamiento persistente para buscar los datos). Es posible que el error ralentice el funcionamiento de la aplicación, pero para el usuario sigue comportándose correctamente. Otro aspecto importante que debe tenerse en cuenta es que aunque la aplicación de este ejemplo contiene solo Web Roles y roles de trabajador, estas también son aplicables a las aplicaciones que utilizan roles VM. Al igual que los otros roles, un rol VM debe ejecutar al menos dos instancias para contar con las garantías de un Windows Azure SLA y la aplicación debe seguir funcionando correctamente aunque se produzca un error en una de ellas. Incluso con los roles VM, Windows Azure todavía proporciona una forma de PaaS, no es IaaS tradicional. QUÉ PROPORCIONA EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE El modelo de programación de Windows Azure está basado en Windows, de modo que la mayor parte de los conocimientos de los desarrolladores de Windows son aplicables a este nuevo entorno. Sin embargo, es diferente del modelo de programación de Windows Server convencional. Así pues, por qué molestarse en entenderlo? Cómo ayuda a crear aplicaciones mejoradas? Para dar respuesta a estas preguntas, primero es necesario explicar un poco más detalladamente algunos aspectos del funcionamiento de Windows Azure. Una vez que los conceptos básicos están claros, comprender cómo el modelo de programación de Windows Azure facilita la creación de software mejorado es muy sencillo. CONCEPTOS BÁSICOS: FABRIC CONTROLLER Windows Azure está diseñado para ejecutarse en centros de datos con muchos equipos. Por consiguiente, las aplicaciones Windows Azure se ejecutan en varias máquinas simultáneamente. La figura 4 muestra un ejemplo sencillo de este tipo de diseño. 7

8 Figura 4: Fabric Controller de Windows Azure crea instancias de los roles de una aplicación en diferentes máquinas para después supervisar su ejecución. Tal y como muestra la figura 4, todos los equipos de un centro de datos de Windows Azure se administran a través de una aplicación llamada Fabric Controller. Fabric Controller es a su vez una aplicación distribuida que se ejecuta a través de varios equipos. Cuando un desarrollador da a Windows Azure una aplicación a ejecutar, proporciona el código de los roles de esta junto con la definición de los servicios y los archivos de configuración de servicios para dicha aplicación. Entre otras cosas, esta información indica a Fabric Controller el número de instancias que debe crear. Fabric Controller elige una máquina física para cada instancia, crea una VM en dicha máquina e inicia la ejecución de la instancia. Como ilustra la figura, las instancias de rol de una aplicación se distribuyen entre las diferentes máquinas de este centro de datos. Una vez que ha creado estas instancias, Fabric Controller las supervisa. Si se produce un error de instancia de cualquier índole, ya sea hardware o software, Fabric Controller iniciará otra instancia para ese rol. Aunque estos errores pueden provocar que el recuento de instancias de la aplicación descienda por debajo de la petición del desarrollador, Fabric Controller siempre iniciará las instancias necesarias para mantener el número objetivo para cada uno de los roles de la aplicación. Asimismo, aunque la figura 4 muestra solo los Web Roles y roles de trabajador, los roles VM se administran de la misma forma, con cada una de las instancias del rol ejecutándose en una máquina física distinta. LAS VENTAJAS: ADMINISTRACIÓN, DISPONIBILIDAD Y ESCALABILIDAD MEJORADAS Las aplicaciones que se crean mediante el modelo de programación de Windows Azure puede resultar más fácil de administrar y ofrecer mayor disponibilidad y escalabilidad que los creados en los servidores Windows tradicionales. Vale la pena analizar cada uno de estos atributos. 8

9 Las ventajas en administración de Windows Azure derivan principalmente de Fabric Controller. Como todos los sistemas operativos, Windows debe revisarse, al igual que el resto de software del sistema. Para ello, en los entornos locales es preciso contar con recursos humanos. Sin embargo, en Windows Azure, el proceso está totalmente automatizado: Fabric Controller administra las actualizaciones para las instancias de Web Role y de rol de trabajador (aunque no para las instancias de rol VM). Cuando es necesario, también actualiza los servidores Windows subyacentes, aquellos que se ejecutan en VM. Ello permite reducir los costos, ya que no es necesario que los administradores realicen esta función. Poder reducir costos gracias a una menor necesidad de administración es bueno. Incrementar la disponibilidad de las aplicaciones también es bueno, por lo que el modelo de programación de Windows Azure ayuda a mejorarla de varias formas. Formas de mejorar la disponibilidad: Protección frente a los errores de hardware. Dado que cada aplicación está compuesta de varias instancias de cada rol, los errores de hardware (un error del disco, un error de la red o un servidor que no responde) no dejarán la aplicación inoperativa. Para que contribuir a que ello sea posible, Fabric Controller no elige las máquinas para las instancias de una aplicación de forma aleatoria, sino que coloca varias instancias del mismo rol en diferentes dominios de error. Un dominio de error es un conjunto de hardware (equipos, conmutadores y otros) que comparte un único punto de error. Por ejemplo, todos los equipos de un dominio de único punto de error pueden depender del mismo conmutador para conectarse a la red. Por ello, un solo error de hardware no puede detener el funcionamiento de una aplicación. Es posible que la aplicación pierda algunas instancias temporalmente, pero seguirá funcionando correctamente. Protección frente a los errores de software. Además de los errores de hardware, Fabric Controller también puede detectar los errores de software. Si el código de una instancia no responde o si la VM en la que se ejecuta deja de funcionar, Fabric Controller iniciará solo el código o bien, si es necesario, otra VM para ese rol. Aunque la tarea que realizaba la instancia cuando se produjo el error se pierda, la nueva instancia formará parte de la aplicación desde el momento en que empiece a ejecutarse. Capacidad de actualizar aplicaciones sin tiempo de inactividad. Las aplicaciones necesitan actualizaciones, ya sea para llevar a cabo el mantenimiento de las rutinas o bien para instalar una nueva versión. Las aplicaciones creadas mediante el modelo de programación de Windows Azure pueden actualizarse mientras se ejecutan, sin necesidad de detener su funcionamiento. Para que ello sea posible, se colocan varias instancias para cada uno de los roles de la aplicación en diferentes dominios de actualización (que son distintos de los dominios de error anteriormente descritos). Cuando es preciso implementar una nueva versión de la aplicación, Fabric Controller puede apagar las instancias de un dominio de actualización, actualizar el código de las mismas y crear otras instancias con el código nuevo. Una vez que estas instancias se están ejecutando, puede hacer lo mismo con las instancias del siguiente dominio de actualización, y así sucesivamente. Mientras que es posible que los usuarios vean diferentes versiones de la aplicación durante este proceso según la instancia con la que interactúen, la aplicación como un todo seguirá estando disponible en todo momento. Capacidad de actualizar Windows y otro software de soporte sin tiempo de inactividad de la aplicación. Fabric Controller asume que todas las aplicaciones Windows Azure siguen las tres reglas anteriormente expuestas, de modo que sabe que puede apagar algunas de las instancias de la aplicación cuando sea necesario, actualizar el software del sistema subyacente e iniciar las nuevas instancias. Al realizar estas tareas por bloques, sin apagar todas las instancias de un rol a la vez, es posible actualizar Windows y demás software mientras se ejecuta la aplicación. 9

10 La disponibilidad es importante para la mayoría de las aplicaciones, ya que el software no es útil si no se ejecuta cuando se necesita, pero la escalabilidad también cuenta. El modelo de programación de Windows Azure permite a los desarrolladores crear aplicaciones más escalables de dos formas: Mediante la creación y el mantenimiento automático de un determinado número de instancias de rol. Como ya se ha explicado, el desarrollador indica a Windows Azure el número de instancias que debe ejecutar de cada rol y Fabric Controller crea y supervisa las instancias solicitadas. Ello simplifica en gran medida la escalabilidad: solo hay que indicar a Windows Azure lo que se necesita. Habida cuenta de que esta plataforma en la nube se ejecuta en centros de datos de gran tamaño, obtener el nivel de escalabilidad que necesita una aplicación no suele ser problemático. Proporcionando una forma de modificar el número de instancias de rol que se ejecutan para una aplicación en funcionamiento: para las aplicaciones cuya carga varía, la escalabilidad es más complicada. Configurar el número de instancias una sola vez no es una buena solución, puesto que las diferentes cargas pueden hacer que la instancia ideal aumente o disminuya sustancialmente. Para resolver esta situación, Windows Azure proporciona un portal web para las personas y un API para las aplicaciones, a fin de que sea posible modificar el número de instancias de los roles con la aplicación en funcionamiento. Simplificar la administración de las aplicaciones e incrementar su disponibilidad y escalabilidad es útil, por lo que el modelo de programación de Windows Azure suele ser una buena opción. Sin embargo, como se ha mencionado anteriormente, también es posible ejecutar en Windows Azure aplicaciones que no siguen este modelo. Supongamos, por ejemplo, que se crea una aplicación con un solo rol, lo cual está permitido, pero solo se ejecuta una única instancia de este, con lo que se incumplen la segunda y la tercera regla. Si el motivo es ahorrar dinero, ya que en Windows Azure es preciso pagar cada instancia en ejecución, se debe tener presente que Fabric Controller no sabrá que esta aplicación no sigue las tres reglas. Así pues, apagará esta instancia en momentos imprevisibles para revisar el software subyacente y reiniciar otra. Para los usuarios, ello significa que la aplicación estará inoperativa de vez en cuando, ya que no hay ninguna otra instancia que pueda tomar el relevo. No se trata de un error de Windows Azure; sino de un aspecto fundamental del funcionamiento de esta tecnología. Para disfrutar de todas las ventajas que ofrece Windows Azure es preciso cumplir las reglas de este modelo de programación. Trasladar aplicaciones de Windows Server a Windows Azure puede resultar algo más trabajoso, tal y como se detalla más adelante en este artículo. Sin embargo, para las nuevas aplicaciones, los motivos para utilizar el modelo de Windows Azure son obvios. Por qué no crear una aplicación que resulte más económica de administrar? Por qué no crear una aplicación que no necesite tiempo de inactividad? Por qué no crear una aplicación fácil de escalar? Con el tiempo, parece evidente pensar que se crearán cada vez más aplicaciones utilizando el modelo de programación de Windows Azure. IMPLICACIONES DEL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE: QUÉ OTROS CAMBIOS SUPONE? Crear aplicaciones para Windows Azure significa seguir las tres reglas de su modelo de programación. Sin embargo, con seguir estas reglas no es suficiente, hay otros aspectos del entorno del desarrollador que también deben adaptarse. Los cambios que el modelo de programación de Windows Azure introduce en el entorno de desarrollo más amplio pueden agruparse en tres áreas: Interacción de las instancias de rol con el sistema operativo. Interacción de las instancias de rol con el almacenamiento persistente. Interacción de las instancias de rol con otras instancias de rol. 10

11 En esta sección se analizan las tres. INTERACCIONES CON EL SISTEMA OPERATIVO En el caso de una aplicación que se ejecuta en una máquina Windows Server típica, el administrador de la máquina es quien tiene el control. Puede reiniciar las VM o la máquina en las que se ejecutan, instalar revisiones de Windows y hacer todo lo necesario para que el equipo esté disponible. Sin embargo, en Windows Azure, todos los servidores son propiedad de Fabric Controller. Esta aplicación es la que decide cuándo deben reiniciarse las máquinas o las VM y, en el caso de los Web Roles o los roles de trabajo (aunque no para los roles VM), Fabric Controller también instala revisiones y otras actualizaciones del software del sistema en todas las instancias. Este enfoque proporciona grandes ventajas, como ya se ha comentado, pero también genera restricciones. Dado que Fabric Controller es el propietario de las máquinas físicas y virtuales que utilizan las aplicaciones Windows Azure, puede hacer con ellas lo que considere necesario. Ello implica que dejar que una aplicación Windows Azure modifique el sistema en el que se ejecuta (es decir, ejecutarse en modo administrador y no en modo usuario) presenta algunos problemas. Habida cuenta de que Fabric Controller puede modificar el sistema operativo a su discreción, no es posible garantizar que los cambios que una instancia de rol realiza en el sistema en el que se ejecuta no se sobrescribirán. Además, las máquinas virtuales (y físicas) específicas en las que se ejecuta una aplicación cambian con el tiempo. Ello implica que todos los cambios que se realicen en el entorno local predeterminado deberán volver a realizarse cada vez que se ejecute una instancia de rol. En su primera versión, Windows Azure no permitía a las aplicaciones modificar los sistemas en los que se ejecutaban, las aplicaciones solo se ejecutaban en modo usuario. Esta restricción se ha suavizado (ya que actualmente tanto los Web Roles como los roles de trabajador ofrecen al desarrollador la opción de ejecutar aplicaciones en modo administrador), pero el modelo de programación en general sigue siendo el mismo. Si se desea crear una aplicación Windows Azure, hay que entender cómo actúa Fabric Controller y tenerlo en cuenta a la hora de diseñar las aplicaciones. INTERACCIONES CON EL ALMACENAMIENTO PERSISTENTE Las aplicaciones no son solo código, también utilizan datos. Así, al igual que el modelo de programación debe cambiar para que las aplicaciones estén más disponibles y escalables, también debe cambiar la forma en que se almacenan y se obtiene acceso a los datos. Los cambios importantes son los siguientes: El almacenamiento debe ser externo a las instancias de rol. Aunque cada instancia es su propia VM con su sistema de archivos, los datos que se almacenan en estos sistemas de archivos no se convierten en persistentes automáticamente. Si se produce un error de una instancia, es posible que se pierdan los datos que contiene. Ello implica que para que las aplicaciones funcionen correctamente cuando se producen errores, los datos deben almacenarse de forma persistente fuera de las instancias de rol. De este modo, otra instancia de rol puede obtener acceso a datos que se hubieran perdido si se hubieran almacenado localmente en la instancia en la que se ha producido el error. El almacenamiento debe replicarse. Al igual que una aplicación Windows Azure ejecuta varias instancias de rol para contar con una alternativa cuando se producen errores, el almacenamiento de Windows Azure debe proporcionar varias copias de datos. De lo contrario, al producirse un solo error, los datos ya no estarían disponibles, lo cual no es aceptable en las aplicaciones de alta disponibilidad. El almacenamiento debe tener la capacidad de administrar un gran volumen de datos. Los sistemas relacionales tradicionales no son necesariamente la mejor solución para administrar grandes conjuntos de datos. Dado que Windows Azure está diseñado en parte para las aplicaciones de alta escalabilidad, 11

12 debe proporcionar mecanismos de almacenamiento para administrar datos a esta escala. Para ello, la plataforma ofrece blobs para almacenar datos binarios junto con un enfoque distinto de SQL llamado tablas para almacenar grandes conjuntos de datos estructurados. La figura 5 ilustra estas tres características y muestra la forma en que el almacenamiento de Windows Azure interactúa con una aplicación. Figura 5: mientras que las aplicaciones ven una única copia, el almacenamiento de Windows Azure replica todos los blobs y las tablas tres veces. En este ejemplo, una aplicación Windows Azure utiliza dos blobs y una tabla del almacenamiento de Windows Azure. La aplicación ve cada uno de los blobs y las tablas como una sola entidad, pero en realidad el almacenamiento de Windows Azure mantiene tres instancias para cada uno. Estas copias se distribuyen entre diferentes máquinas físicas, las cuales, al igual que las instancias de rol, se hallan en diferentes dominios de error. Ello mejora la disponibilidad de la aplicación, dado que los datos todavía son accesibles aun cuando algunas copias no estén disponibles. Y, puesto que los datos persistentes se almacenan fuera de las instancias de rol de la aplicación, si se produce un error de instancia solo se pierden los datos que utilizaba en el momento en que se produjo el error. El modelo de programación de Windows Azure requiere que una aplicación se comporte correctamente cuando se produce un error de instancia de rol. Para ello, cada una de las instancias de una aplicación debe almacenar todos los datos persistentes en el almacenamiento de Windows Azure o en otro mecanismo de almacenamiento externo (como SQL Azure, el servicio basado en nube de Microsoft para datos relacionales). Sin embargo, existe otra opción que vale la pena mencionar: las unidades de Windows Azure. Como se ha descrito anteriormente, es posible que los datos que una aplicación escribe en el sistema de archivos local de su propia VM se pierdan cuando dicha VM deje de ejecutarse. Las unidades de Windows Azure cambian esta dinámica, ya que utilizan un blob para proporcionar almacenamiento persistente para el sistema de archivos de una determinada instancia. Estas unidades tienen algunas limitaciones, puesto que, por ejemplo, solo puede leer y escribir en una unidad de Windows Azure una instancia a la vez, mientras que las demás instancias de la aplicación disponen únicamente de acceso de lectura, pero puede resultar útil en algunos casos. 12

13 INTERACCIONES ENTRE INSTANCIAS DE ROL Cuando una aplicación se divide en varias partes, estas normalmente necesitan interactuar entre sí. En una aplicación Windows Azure, esta interacción se expresa como una comunicación entre instancias de rol. Por ejemplo, es posible que una instancia de Web Role acepte peticiones de los usuarios y que, a continuación, las traslade a una instancia de rol de trabajador para que las siga procesando. La forma en la que se produce esta interacción difiere ligeramente de lo que sucede en las aplicaciones Windows convencionales. Otro factor que es preciso tener en cuenta es que es muy frecuente que todas las instancias de un rol sean equivalentes y, por lo tanto, intercambiables. Ello significa que cuando una instancia de Web Role transfiere alguna tarea a una instancia de rol de trabajador, no debería importarle a cuál de ellas lo transfiere. De hecho, la instancia de Web Role no debería depender de ningún aspecto específico de instancia como, por ejemplo, la dirección IP de una instancia de rol de trabajador, para comunicarse con dicha instancia. Es preciso utilizar mecanismos más genéricos. La forma más habitual de comunicación entre las instancias de rol y las aplicaciones Windows Azure es mediante las colas de Windows Azure. El Gráfico 6 ilustra esta idea. Figura 6: las instancias de rol pueden comunicarse mediante colas; cada una replica tres veces el mensaje que contiene. En este ejemplo, una instancia de Web Role recibe tareas de un usuario de la aplicación como, por ejemplo, alguien que realiza una petición desde un explorador (paso 1). A continuación, esta instancia crea un mensaje que contiene esta tarea y la escribe en una cola de Windows Azure (paso 2). Estas colas se implementan como parte del almacenamiento de Windows Azure y, al igual que los blobs y las tablas, cada cola se replica tres veces, tal y como se muestra en esta figura. Como es habitual, ello proporciona tolerancia a errores, con lo que se garantiza que los mensajes de la cola seguirán estando disponibles aunque se produzca un error. 13

14 A continuación, una instancia de rol de trabajador lee el mensaje de la cola (paso 3). Obsérvese cómo a la instancia de Web Role que creó el mensaje no le importa qué instancia de rol de trabajador lo recibe, en esta aplicación todas son equivalentes. Esa instancia de rol de trabajador realiza la tarea que solicita el mensaje (paso 4) y, posteriormente, lo elimina de la cola (paso 5). Este último paso, eliminar el mensaje de la cola, es diferente de lo que sucede normalmente con las tecnologías de puesta en cola. En Microsoft Message Queuing (MSMQ), por ejemplo, una aplicación puede realizar una lectura dentro de una transacción atómica. Si la aplicación deja de funcionar antes de finalizar la tarea, la transacción se anula y el mensaje reaparece en la cola automáticamente. Este enfoque garantiza que todos los mensajes que se envían a una cola MSMQ se entregan una vez exactamente en el orden en el que se envió. Las colas de Windows Azure no admiten lecturas transaccionales, por lo que no garantizan la entrega una vez exactamente ni por orden de envío. En el ejemplo de la figura 6, el rol de trabajador podría acabar de procesar el mensaje y, a continuación, dejar de responder justo antes de eliminarlo de la cola. Si ello sucede, el mensaje reaparecerá automáticamente tras un periodo de tiempo de inactividad, y otra instancia de rol de trabajador lo procesará. A diferencia de MSMQ, las colas de Windows Azure proporcionan semántica ATP (por lo menos una vez), es decir, un mensaje debe leerse y procesarse una o más veces. Ello plantea una pregunta obvia: por qué las colas de Windows Azure no admiten lecturas transaccionales? La respuesta a es que las transacciones requieren un bloqueo, de modo que forzosamente ralentizan el funcionamiento (sobre todo con la réplica de mensajes que proporcionan las colas de Windows Azure). Habida cuenta de los objetivos principales de la plataforma, los diseñadores optaron por el enfoque más escalable y rápido. La mayoría de las veces, las colas son la mejor forma de comunicación entre las instancias de rol de una aplicación. Sin embargo, las instancias también pueden interactuar directamente, sin pasar por una cola. Para que ello sea posible, Windows Azure proporciona una API que permite que una instancia detecte las demás instancias de la misma aplicación que cumplen determinados requisitos, para posteriormente enviar una petición directamente a una de ellas. En el caso más habitual, es decir, cuando todas las instancias de un rol son equivalentes, el autor de la llamada debe elegir una instancia objetivo aleatoriamente del conjunto que le propone la API. Ello no siempre es cierto, ya que puede ser que un rol de trabajador implemente una caché en memoria con datos específicos para cada instancia de rol, de manera que el autor de la llamada tenga que obtener acceso a una instancia en concreto. No obstante, a menudo, lo mejor es tratar a todas las instancias de un rol como intercambiables. PORTAR APLICACIONES DE WINDOWS SERVER A WINDOWS AZURE Si se desea crear una aplicación Windows Azure nueva, es preciso seguir las reglas del modelo de programación de Windows Azure. Sin embargo, para portar una aplicación existente de Windows Server a Windows Azure, esta deberá seguir las mismas reglas. Asimismo, es posible que la aplicación necesite cambiar la forma de interactuar con el sistema operativo, la forma de utilizar el almacenamiento persistente y la forma en que sus componentes interactúan entre sí. La facilidad con la que puedan realizarse estos cambios depende de cada aplicación. A continuación, se proporcionan algunos ejemplos representativos: 14

15 Una aplicación ASP.NET, con varias instancias con distribución de carga que comparten el estado almacenado en SQL Server. Este tipo de aplicación se porta fácilmente a Windows Azure, con cada instancia de la aplicación convertida en una instancia de un Web Role o un rol de trabajador. Las aplicaciones de esta índole no usan "sticky sessions", lo cual facilita su adaptación a Windows Azure. (No obstante, es posible utilizar el estado de sesión ASP.NET, ya que Windows Azure proporciona una opción para almacenar el estado de sesión de forma persistente en tablas del almacenamiento de Windows Azure). Y portar una base de datos SQL Server a SQL Azure suele ser bastante sencillo. Una aplicación ASP.NET con varias instancias que mantiene un estado por instancia y se basa en "sticky sessions". Dado que mantiene un estado específico de cliente en cada instancia entre peticiones, esta aplicación necesitará algunos cambios. Windows Azure no admite "sticky sessions", de modo que para que la aplicación se ejecute en esta plataforma en la nube habrá que volver a diseñar cómo administra el estado. Un cliente Silverlight o Windows Presentation Foundation (WPF) que obtiene acceso a servicios WCF que se ejecutan en un nivel intermedio. Si los servicios no mantienen el estado por cliente entre llamadas, portarlos a Windows Azure resulta sencillo. El cliente seguirá ejecutándose en los escritorios de los usuarios como normalmente, pero ahora llamará a servicios que se ejecutan en Windows Azure. Sin embargo, si los servicios actuales mantienen el estado por cliente, deberán volverse a diseñar. Una aplicación con una única instancia que se ejecuta en Windows Server que mantiene el estado en su propia máquina. Tanto si los clientes son exploradores como si no, actualmente la mayoría de las aplicaciones de empresa se crean de este modo, y para que funcionen correctamente en Windows Azure siempre será preciso modificar el diseño. Es posible que esta aplicación se pueda ejecutar en una única instancia de rol VM sin modificarla, pero a los usuarios probablemente no les gustará demasiado. En primer lugar, porque el Windows Azure SLA no es aplicable a las aplicaciones con una sola instancia. Además, recuerde que Fabric Controller puede reiniciar la máquina en cualquier momento en la que la instancia se ejecute para actualizar el software de esta. La aplicación no tiene ningún control cuando esto sucede, lo cual podría ser justo en mitad de la jornada laboral. Habida cuenta de que no hay una segunda instancia que pueda tomar el relevo (la aplicación no se creó para que siguiera las reglas del modelo de programación de Windows Azure), no estará disponible durante un tiempo, de modo que las personas que estén utilizándola deberán interrumpir su trabajo mientras se reinicia la máquina. Aunque el rol VM facilita la migración de un binario Windows Server a Windows Azure, lo cual no garantiza que la aplicación se ejecute correctamente en su nuevo entorno. Asimismo, la aplicación debe cumplir las reglas del modelo de programación de Windows Azure. Una aplicación Visual Basic 6, que obtiene acceso directamente a la base de datos SQL Server, es decir, una aplicación de cliente-servidor tradicional. Para que esta aplicación se ejecute en Windows Azure es muy probable que se deba volver a escribir la lógica de negocios del cliente. Aunque es posible que se pudiera portar la base de datos (incluidos los procedimientos almacenados) a SQL Azure y redirigir los clientes a esta nueva ubicación, el componente del escritorio de la aplicación no se ejecutará en Windows Azure sin modificaciones. Windows Azure no proporciona una interfaz de usuario local ni tampoco admite el uso de Servicios de Escritorio remoto (anteriormente Terminal Services) para proporcionar interfaces de usuario remoto. Windows Azure permite a los desarrolladores crear aplicaciones mejoradas. Sin embargo, para disfrutar de estas mejoras, es preciso realizar cambios, por lo que portar el software existente a esta nueva plataforma puede requerir cierto esfuerzo. Para poder tomar buenas decisiones es necesario comprender el valor de negocio potencial y tener en cuenta los aspectos técnicos que implica portar una aplicación a Windows Azure. 15

16 CONCLUSIÓN Las plataformas en la nube ofrecen un mundo nuevo con un sinfín de posibilidades. Con esta idea, el modelo de programación de Windows Azure permite a los desarrolladores crear aplicaciones más fáciles de administrar, con mayor disponibilidad y escalabilidad, que las creadas en el entorno Windows Server tradicional. Para ello, es preciso cumplir tres reglas: Las aplicaciones Windows Azure se crean a partir de uno o más roles. Las aplicaciones Windows Azure ejecutan varias instancias de cada uno de los roles. Las aplicaciones Windows Azure se comportan correctamente cuando se produce un error de instancia de rol. Para utilizar este modelo de programación correctamente también es necesario comprender los cambios que implica en la forma en que las aplicaciones interactúan con el sistema operativo, utilizan el almacenamiento persistente y se comunican entre instancias de rol. Sin embargo, los desarrolladores que estén dispuestos a hacerlo, disfrutarán de unas ventajas innegables. Aunque no es la solución ideal para todos los casos, el modelo de programación de Windows Azure puede resultar útil si se desea crear aplicaciones más fáciles de administrar que ofrezcan mayor disponibilidad y escalabilidad. LECTURAS ADICIONALES Presentación de Windows Azure: Presentación de la plataforma Windows Azure: SOBRE EL AUTOR David Chappell es director de Chappell & Associates ( en San Francisco, California. A través de sus conferencias, escritos y consultoría, ayuda a los profesionales de software de todo el mundo a comprender, usar y tomar mejores decisiones sobre las nuevas tecnologías. 16