Post cortito para anunciar una noticia bastante esperada, que es la versión Release de Windows Azure AppFabric Caching.

Windows Azure AppFabric Caching es un sistema de caché distribuida, en memoria, que se ofrece como un servicio en la nube.

Un servicio similar ya existía para soluciones on-premise, integrado dentro de Windows Server AppFabric. Ahora tenemos las mismas capacidades y características para aplicaciones que estén en la nube. Se ofrece como un servicio en la nube, por lo que como veremos nos vamos a tener que hacer nada relacionado con las tareas de instalación, configuración o administración…simplemente hacer uso del servicio.

La versión release ofrece 6 tamaños diferentes de caché, entre 128 Mb y 4 Gb.

Si queréis echar un vistazo a qué esta tecnología os recomiendo estos dos enlaces:

Windows Azure AppFabric Caching

[Video] Caché distribuido en Windows Azure

Otro tema importante publicado es el tema de la facturación, facturación que se hará mensual y en función del tamaño de caché que se utilice.

• 128 MB cache for $45.00/month
• 256 MB cache for $55.00/month
• 512 MB cache for $75.00/month
• 1 GB cache for $110.00month
• 2 GB cache for $180.00/month
• 4 GB cache for $325.00/month

Existe un período de promoción que hará que se puede disponer del servicio y no pagar nada de lo consumido desde la fecha actual hasta el 1 de agosto de 2011. Es una promoción en la que puedes darte de alta, eligiendo la caché de 128Mb.

Podéis ver el anuncio original aquí.

Cuando desarrollamos para Windows Azure podemos encontrarnos con distintos escenarios que van desde aplicaciones completamente .NET y aplicaciones que son migraciones de aplicaciones existentes. En ese sentido uno de los dolores de cabeza a la hora de trabajar con Azure son los registros de componentes COM durante el arranque del rol de Azure. Este tipo de problema se soluciona normalmente creando una tarea en el startup del rol que desea consumir ese tipo de componentes COM.

Si por ejemplo nosotros durante el ciclo de ejecución de nuestro rol queremos ejecutar un proceso con elevación, es decir con permisos completos de administrador no podemos hacerlo porque el proceso que hostea la web y el worker role no está elevado, y aunque nosotros lo indiquemos a la hora de ejecutar el proceso eso no va a funcionar.

Es por eso que podemos hacer un pequeño truco para que podamos ejecutar proceso elevados durante nuestro ciclo de ejecución del rol, es decir en cualquier momento, así podemos registrar componentes COM, o llamar a ejecutables del SO de manera mucho más cómoda. Para poder llegar a esa aproximación tenemos que buscar un entorno donde podamos ejecutar nuestras aplicaciones de manera elevada, y ese entorno es el entorno de startup del rol, así que de alguna manera lo que tenemos que tener es un proceso sentinel que se arranque en el startup del rol y que acepte peticiones para ejecutar procesos de manera elevada.

Interesante la iniciativa de Microsoft para promocionar Windows Azure.

A través de esta iniciativa Microsoft pretende que haya más gente que conozca la plataforma y se aproveche de sus beneficios, pero también que aquí pueda surgir buenas ideas, algunas de cuáles se podrán llevar a la práctica con su financiación.

Podéis leer toda la información aquí.

PD: Para empezar a poneros al día con la plataforma os recomiendo el curso que podéis encontrar en este mismo portal, contenido información más actualizada

Importante si te has instalado la última actualización del Sdk de Windows Azure asegurarte si tienes que volver a instalártelo, ya que en la primera versión del mismo había un problema que han resuelto.

En el blog del grupo de Windows Azure podéis ver la información del mismo, a qué afecta y si tenéis que reinstalar el Sdk 14.1.

Hace poco, en el MIX,  ha sido anuncia la versión CTP de Windows Azure Traffic Manager, una herramienta que nos permitirá cubrir ciertos escenarios que hoy en día no era posible cubrirlos con Windows Azure.

Esta herramienta nos permite distribuir el tráfico que recibe nuestra aplicación desde Internet entre dos o más servicios hosteados en Windows Azure, incluso de data centers diferentes, lógicamente, todo accesible desde la misma URL.

Con este sistema, por ejemplo, podría tener mi aplicación desplegada en dos datacenters diferentes, uno en USA y otro en Europa, y hacer que los dos sean accesibles desde la misma URL, pudiendo configurar en qué caso debe contentar uno y en qué caso tiene que contestar otro.

En esencia la funcionalidad es un servicio de DNS, el cuál nosotros podemos configurar:

• Failover: Todo el tráfico se mapea a un servicio. Si éste falla, el tráfico se mapea al servicio que hace de backup.
• Performance: El tráfico se mapea al servicio más cercano, desde el punto de vista de “saltos entre los routers”.
• Round-Robin: Distribuye las peticiones entre servicios de Azure definidos en las políticas.

Para tener acceso a esta funcionalidad es necesario que solicitéis que os la activen, acción que podéis hacer desde el portal de Windows Azure:

Una vez activada la funcionalidad, desde el “Virtual Network” se puede acceder a la nueva funcionalidad que nos ofrecer Traffic Manager.

y crear y configurar las políticas que deseemos; elegir el tipo de balanceo, los servicios implicados etc…