Nuevamente, eso no implica que todo lo desplegaremos en Azure. La idea no es tener únicamente SaaS sino también S+S. Así que por ejemplo las aplicaciones que hoy en día corren dentro de una organización (on-premises) podrían almacenar datos en la nube o usar otros servicios de la misma. Aplicaciones que corren en el escritorio o teléfonos móviles pueden usar los servicios de la nube para hacer sincronización de datos.
Toda esta maravilla requiere de aplicaciones que la exploten! Y para lograr dichas aplicaciones, necesitamos de una plataforma para construirlas. Esta plataforma es provista por Windows Azure y está compuesta por un grupo de tecnologías que nos proveen servicios a nosotros como desarrolladores.
Componentes de Azure
En Windows Azure básicamente encontramos tres componentes principales:
Windows Azure
Ambiente basado en Windows (en esta edición es Server 2008), para ejecutar aplicaciones y almacenar datos en los centros de datos de Microsoft.
SQL Azure
Provee servicios de datos basados en SQL Server
.NET Services
Infraestructura distribuida para usar con aplicaciones locales y hospedadas en la nube.
Estos componentes los podemos apreciar en la siguiente ilustración. En este post exploraremos en detalle el componente WIndows Azure (Cómputo y Storage) y posteriormente observaremos Sql Azure y .NET Services.
Comencemos entonces con Windows Azure:
Como podemos observar en la gráfica, este componente se subdivide en tres elementos: la estructuta principal o Fabric, el componente de cómputo y el componente de almacenamiento (storage). Empecemos viendo en detalle el componente de cómputo.
Servicios de Cómputo
Windows Azure corre sobre una gran cantidad de máquinas, todas ubicadas en los datacenter de Microsoft y accesibles vía internet. Todas estas máquinas conforman un todo que le da el poder y escalabilidad necesarios. Aunque al principio solo se iban a poder ejecutar aplicaciones .NET hoy en día, esta plataforma permite ejecutar aplicaciones nativas de Windows (esto lógicamente comprende todos los lenguajes de programación tradicionales que hoy en día sirvan para correr aplicaciones sobre Windows Server 2008). En Windows Azure, una aplicación típicamente tiene múltiples instancias y cada una corre una copia de todo o una parte de la aplicación. Cada instancia corre en su propia máquina virtual. Estas VMs están sobre Windows Server 2008 x64. Las aplicaciones se instancian en uno de dos roles, según escoja el desarrollador. Web Role, o Worker Role:
El Web Role corre sobre IIS7 y acepta los llamados HTTP o HTTPS (tecnologías: ASP.NET, WCF, todas las que trabajen con IIS). El balanceo de carga es automático, gracias al Load Balancer incluido en la plataforma. El Worker Role no puede aceptar peticiones directas desde el mundo exterior. Típicamente estos roles adquieren sus entradas a través de colas en el Windows Azure storage. Estos mensajes sí pueden provenir de una aplicación exterior o de un Web Role. Son procesados y la respuesta se puede poner en una cola, o enviarse directamente al mundo exterior (esto último sí es permitido). Independientemente del tipo de rol en una VM, siempre existe un Agente de Azure que permite la interacción del rol con el resto de la aplicación y la plataforma. Aunque es algo que puede cambiar en el futuro, en la actualidad Windows Azure mantiene una relación 1:1 entre VMs y cores físicos de procesador. Esto obviamente garantiza el performance de la aplicación que sea predictible (cada instancia tiene su propio core dedicado; esto también significa que no hay un límite arbitrario en el tiempo de proceso concedido a una instancia en especial). Sin embargo si se desea aumentar el performance, el dueño de la aplicación podría decidir crear más instancias de la misma, solo modificando el archivo de configuración. De esta manera, Windows Azure detecta el requerimiento y ajusta una nueva VM con su respectivo core. Si en algún momento alguna instancia falla, Azure lo detecta e inicia una nueva.
Esto genera una notoria implicación: Para ser escalable, las instancias de Windows Azure Web role, deben ser stateless (no manejar estado en sesión o aplicación por ejemplo). Todo estado requerido ha de ser escrito en los mecanismos de storage de Windows Azure, o pasados al usuario final por medio de cookies por ejemplo. Además debido al load balancer, no hay forma de garantizar que múltiples peticiones de un mismo usuario sean enviadas a un mismo Web Role. Este tipo de implicaciones hace que el pasar aplicaciones a la nube o crearlas destinadas para ellas, no sea completamente transparente comparado con el modelo on-premises. Sin embargo, los cambios son muy sutiles (usar ADO.NET Data Services –compatible con Azure Storage-, tener en cuenta el modelo de colas para los Worker Role, etc.) Por esto, para los desarrolladores, trabajar con Windows Azure, es muy similar a crear aplicaciones tradicionales Windows. Microsoft provee templates para Visual 2008 que permiten crear Web Roles, Worker Roles y combinaciones de los dos. Los desarrolladores son libres de usar cualquier lenguaje de programación Windows. Todo esto viene en un SDK de Azure que también contiene una versión de ambiente Windows Azure que corre en la máquina del desarrollador. Este ambiente es conocido como Windows Azure Development Fabric e incluye Windows Azure Storage, un agente Windows Azure y todo el resto de tecnologías que requiere una aplicación para correr en la nube. Un desarrollador puede crear y depurar su aplicación usando este simulacro local y luego desplegar la aplicación a Windows Azure, cuando ésta esté lista, aunque en la nube hay cosas que son realmente diferentes. Por ejemplo, no es posible hacer el attach de un debugger a una aplicación en la nube. Así que básicamente para hacer el debugging de una aplicación en la nube, el mecanismo principal sería la escritura a los logs de Windows Azure, vía el agente de Azure. Otros servicios provistos incluyen por ejemplo el envío de mensajes desde los agentes a Windows Azure, quien los captura y reenvía por medio de emails, mensajería instantánea o cualquier otro mecanismo especificado. Además también se puede especificar a Windows Azure que detecte fallas automáticamente y envíe alertas. También está disponible información acerca de consumo de recursos tales como tiempo de proceso, ancho de banda entrante y saliente y almacenamiento.
Cuando el desarrollador ha depurado completamente su aplicación de manera local, ésta ha de ser instalada en un proceso de dos etapas. Primero se sube la aplicación al área de staging en Azure. En este momento, la aplicación queda identificada con un nombre DNS que tiene la forma <GUID>.cloudapp.net, donde <GUID> representa un identificador asignado por Windows Azure. Este nombre es asociado con una dirección IP virtual (VIP) que identifica al balanceador de carga a través del cual la aplicación será accedida. En el momento en que se decide pasar ya la aplicación a producción, se usa el portal de Windows Azure para solicitar el paso a producción. En este caso, Azure automáticamente cambia la entrada en sus servidores DNS para asociar la VIP con el nombre de producción que el desarrollador ha escogido; por ejemplo: myapp.cloudapp.net. (Es posible usar un nombre de dominio personalizado, sencillamente creando un DNS alias usando un CNAME estándar). Otro punto para resaltar aquí: las IPs reales de las aplicaciones jamás son reveladas.
Esto brinda un fuerte componente de seguridad.
Servicios de Almacenamiento
Esta parte de la plataforma también provee un tipo de almacenamiento: Azure Storage. Que es distinto a SQL Azure (otra parte de la plataforma). El almacenamiento Azure no es relacional. Su lenguaje de consulta tampoco es SQL. Es un almacenamiento mucho más sencillo, pero más escalable y más rápido que un almacenamiento relacional. Básicamente hay tres tipos de almacenamiento Azure:
1. BLOBS: (Binary Large Objects). Prácticamente, archivos. Los requerimientos de File System de nuestras aplicaciones en la nube, se suplen con los blobs. Un blob puede ser de hasta 50Gb de espacio y se encuentra dividido en bloques, de manera que cuando se hacen transferencias y ocurren fallos, la transferencia puede continuar desde el último bloque transferido correctamente.
2. Tablas: Los Blobs son la opción justa para algunas situaciones. Pero para otras son muy poco estructurados. Son muy sencillos de entender; pero para permitir a las aplicaciones trabajar con datos de una manera más formal se proveen las tablas. Estas tablas no son tablas relacionales y tienen su complejidad: De hecho, a pesar de que se llaman tablas, los datos que ellas contienen realmente se encuentran almacenados en una jerarquía simple de entidades que contienen propiedades. Cada propiedad tiene un nombre, un tipo y un valor. Varios tipos son permitidos incluidos: Binary, Bool, DateTime, Double, GUID, Int, Int64 y String. Una propiedad puede tomar diferentes tipos dependiendo de los valores almacenados en ella. De hecho, no hay obligación de que todas las propiedades en una entidad tengan el mismo tipo. El tamaño para cada entidad puede ser de hasta 1MB y siempre es accesada como una unidad. Cuando se lee una entidad se retornan todas sus propiedades y al escribir una, esto se hace atómicamente de manera que se reemplazan todas sus propiedades. Y en vez de usar SQL, una aplicación accesa los datos de una tabla usando las convenciones definidas por ADO.NET Data Services (no ADO.NET convencional), o REST. La razón para este tipo de solución, es que nos permite escalar el almacenamiento de una forma tal, que podemos distribuir nuestros datos en distintas máquinas (muchas más de las que se posibilitan con bases de datos relacionales tradicionales); de hecho, una sola tabla en SQL Azure puede ser de terabytes!
3. QUEUES: Los blobs y las tablas están enfocados en almacenamiento y acceso de datos. La tercera opción en Windows Azure son las colas, que tienen un propósito muy distinto. Una función principal de las colas es proveer un mecanismo para que las instacias de tipo Web Role se puedan comunicar con las instancias de tipo Worker role. En la siguiente gráfica, se describe el funcionamiento de las colas. En un escenario típico, un rol acepta trabajos de los usuarios (paso 1). Para pasar esos requerimientos a los worker role, se escribe un mensaje en la cola (paso 2). Este mensaje, puede ser de hasta 8kb y es posible usarlo para que contenga URIs apuntanto a blobs o entidades en tablas en caso de que se requiera transmitir más información. El worker lee los mensajes de su cola (paso 3) y ejecuta el trabajo como tal. Una vez leído el mensaje, éste no se borra. En vez de esto, el mensaje se hace invisible a otros lectores por un período de tiempo (por defecto 30 seg). Cuando el worker ha completado su trabajo, en ese momento se borra explícitamente de la cola. (paso 5) Separar las instancias web de las worker tiene sentido porque libera al usuario de tener que esperar a que una tarea larga sea procesada y también hace la escalabilidad más simple, dado que solo sería necesario agregar más instancias. Pero por qué hacer que las instancias borren explícitamente los mensajes? Esto se hace para manejar fallos. De esta manera si un worker que está haciendo el trabajo indicado falla, el mensaje no se borrará de la cola. Así que cuando vuelva a estar visible, el mensaje reaparece en la cola para ser leído por otro worker. Y de esta manera se proteje el mensaje de fallos.
Independientemente del tipo de almacenamiento, todo dato almacenado es replicado tres veces, para garantizar redundancia de datos y tolerancia a fallos.
El storage de Windows Azure puede ser accedido por aplicaciones de Windows Azure o cualquier otra. En ambos casos, todos los tres tipos de storage pueden consultarse a través de REST. Todo es nombrado usando URIs y accesado con operaciones HTTP estándares. No obstante, un cliente .NET podría usar ADO.NET Data Services o LINQ para acceder más cómodamente a esta información. Pero un cliente java usaría REST estándar. Por ejemplo, un blob puede ser leído con un HTTP GET contra un URI formateado así:
http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName>
De manera similar, una consulta sobre una tabla sería:
.table.core.windows.net/?$filter=http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query>
y una cola se accesaría:
.queue.core.windows.net/http://<StorageAccount>.queue.core.windows.net/<QueueName>
La Estructura (Fabric)
Todas las aplicaciones de Windows Azure y todos sus datos en el Storage, residen en alguno de los centros de datos de Microsoft. Dentro de ese centro de datos, el conjunto de máquinas dedicadas a Windows Azure se organizan en una fábrica tal como lo muestra la siguiente gráfica:
Tal como se aprecia, la Estructura Azure es un gigantesco grupo de máquinas administrado por un componente de software llamado Fabric Controller. Este controlador es replicado a través de un grupo de 5 a 7 máquinas y es dueño de todos los recursos en la estructura: computadoras, switches, balanceadores de carga y más. Dado que el controlador se comunica con un “Fabric Agent” en cada máquina, también tiene información de cada aplicación en la estructura. Como punto a resaltar, puedo mencionar que el Storage también aparece ante el controlador como una aplicación más. Así que el controlador no conoce los detalles del storage; esto último indica obviamente que el almacenamiento es autocontrolado. Es decir; el Storage, es solo una aplicación más dentro de la estructura, que se administra autónomamente.
Este amplio conocimiento le da la capacidad al Fabric Controller de cumplir múltiples funciones como monitorear todas las aplicaciones que están corriendo y de esta manera ser capaz de dar información en vivo, de qué es lo que está pasando en la estructura. Administra los sistemas operativos teniendo en cuenta aspectos como las actualizaciones de los Windows Server 2008 que corren en las VMs de Azure. También decide dónde deben correr las aplicaciones, escogiendo los servidores físicos para optimizar la utilización del hardware. Para lograr esto, el controlador depende del archivo de configuración que es subido con cada aplicación a la nube. Este archivo provee una descripción basada en XML de las necesidades de la aplicación: cuántos roles web necesitará, cuantos roles de trabajo y otros detalles. Cuando el controlador recibe una nueva aplicación, éste usa su archivo de configuración para determinar cuántos roles de cada tipo ha de crear. Una vez creadas estas VMs, el controlador las monitorea. Si una aplicación requiere 5 instancias de Web Role y una muere, el controlador automáticamente reiniciará una nueva.
Esta creación de instancias debe realizarse inteligentemente. Por ejemplo, suponiendo que además de las 5 instancias web el desarrollador pide cuatros instancias worker. Una asignación ingenua podría poner todas estas instancias en máquinas en el mismo rack servidos por el mismo switch. Si el rack o el switch fallara, la aplicación entera quedaría no disponible. Dadas las metas de alta disponibilidad de Windows Azure, hacer que una aplicación dependa de puntos sencillos de falla como este, no es una buena idea.
Para evitar esto, el controlador agrupa las máquinas en conjuntos llamados “Dominios de Falla”. Cada dominio es parte de un data center que independizaría las fallas únicamente a su contenido. Eso se ilustra en la siguiente gráfica:
En este ejemplo sencillo, la aplicación está corriendo en dos instancias Web y el datacenter está dividido en dos Dominios de Falla. Cuando el controller despliega la aplicación, se establece una instancia de Web Role en cada uno de los dominios. Este arreglo significa que una falla en el hardware no va a provocar que toda la aplicación se caiga.
Hasta aquí vimos todo lo relacionado al componente de Windows Azure. En mi post Stairway to Azure (4): Sql Azure y .NET Services, veremos la descripción de estos otros dos componentes.
Excelente tu artículo...muy clara la explicación. gracias!!!
Muchas Gracias!
Muy buenos posts! felicitaciones!!!
Gracias José Luis!