Windows Azure Taffic Manager

Como era de esperar, el apartado de Virtual Network tenía crecer en cualquier momento :D Una de las novedades que se anunciaron en el MIX 2011 será enmarcada bajo esta sección y se conoce como Windows Azure Traffic Manager. Este servicio va a trabajar conjuntamente con nuestros Hosted Services con un objetivo principal que es controlar el tráfico de nuestros usuarios siguiendo una serie de políticas.

Este producto todavía está en fase CTP (Community Tech Preview) y podemos solicitar el acceso a la misma a través del apartado de betas del portal de Windows Azure:

Antes de ver el servicio, me gustaría aclarar algunas limitaciones que se nos presentan en esta primera CTP:

  • No dispone de SLA, es decir que si en algún momento el mismo es inestable no podemos quejarnos :D
  • El servicio solamente funciona en los slots de producción de los hosted services.
  • A día de hoy no se muestra el estado de los servicios que utilizan el sistema de políticas de tráfico de Windows Azure Traffic Manager.
  • No hay disponible una API para interactuar con el servicio, todo debe hacerse a través del portal de la plataforma.
  • El DNS utilizado ahora, <prefijo>.ctp.trafficmgr.com, será modificado una vez pasada la fase CTP por <prefijo>.trafficmgr.cloudapp.net

Dicho esto, veamos las políticas que nos ofrecen :D

Performance

Imaginaros que tenemos diferentes hosted services desplegados en distintas partes del mundo:

Si bien el servicio puede ser el mismo o bastante similar, lo ideal sería que por temas de rendimiento nuestro sistema fuera capaz de determinar cuál de los hosted services que tenemos desplegados dentro de Windows Azure es el más próximo al usuario. Gracias a esta política podemos conseguir exactamente este comportamiento :) .

Failover

Otro de los escenarios que se nos puede presentar trata de la posibilidad de generar una lista de prioridades donde decidimos cuál de los hosted services prevalece sobre los demás a la hora de aceptar las peticiones de los usuarios, independientemente de dónde estén ubicados geograficamente los mismos.

Round Robin

La planificación Round Robin trata de distribuir de forma equitativa sobre todos los hosted services incluidos dentro de la política, de tal forma que la sobrecarga sea la misma para cada uno de los nodos.

¿Cómo definimos estas políticas?

Para poder utilizar las políticas de Windows Azure Traffic Manager, accedemos al apartado Virtual Network.


Y accedemos a Traffic Manager-> Policies

Pulsamos en el botón Create para crear nuestra primera política. Al hacer esto, nos aparecerá un nuevo cuadro de diálogo:

En esta nueva ventana vamos a poder elegir cuáles son los servicios a los que queremos aplicar una política y cuál va a ser el método de balanceo elegido. En primer lugar seleccionaremos la suscripción sobre la que vamos a trabajar, uno de los métodos de balanceo de carga mencionados anteriormente y los DNS de aquellos servicios que queremos que trabajen conjuntamente.

Por otro lado, podemos establecer un endpoint para la monitorización de nuestros servicios, asegurándonos de esta manera de que todos permanencen online.
Para finalizar, elegimos un prefijo por el cual accederemos a partir de ahora. Este DNS será sobre el que deberemos aplicar el CNAME correspondiente para beneficiarnos del sistema de balanceo. DNS time to live (TTL) se utilizará para poder detectar la caida de uno de los nodos y que Windows Azure Traffic Manager pueda sacarlo del sistema de balanceo hasta que el mismo se recupere. El tiempo mínimo en esta versión CTP es de 30 segundos.

Una vez que hayamos elegido una de las políticas y pulsemos sobre el botón Create nuestro servicio estará listo :D Para probar el mismo, basta con acceder al DNS de Traffic Manager que hayamos elegido :)

Espero que sea de utilidad :D

¡Saludos!

Web Deployment Tool para Windows Azure

Todos los que hemos trabajado con Windows Azure Compute sabemos lo que significa esperar por un despliegue :) Si bien es un requisito indispensable para la puesta en producción, puede resultar más que tedioso a la hora del desarrollo, testing, etcétera. ¡Pero ya no hay de qué preocuparse! Una de las últimas novedades anunciadas en el MIX 2011 fue justamente la posibilidad de realizar despliegues de una forma más rápida gracias a Web Deployment Tool :)

Este método tiene algunas restricciones de las cuales debemos ser conscientes:

  1. El web role sólo puede tener una instancia desplegada.
  2. Los cambios son temporales, es decir, si el servicio se reinicia o el mismo falla y debe ser desplegado en otro servidor del data center, los cambios que hayamos subido a través de esta herramienta se perderán.
  3. Debido a los dos puntos anteriores, Web Deployment Tool está pensado para el desarrollo y el testing y en ningún caso para entornos de producción.

Dicho esto, vamos a configurar nuestro servicio para poder utilizar la herramienta :D

Configuración

En primer lugar, debemos actualizar el SDK de Windows Azure a la última versión conocida como Windows Azure SDK 1.4 Refresh con fecha de release el 11 de Abril de este año.

Abrimos una solución Cloud y hacemos clic sobre la opción “Publish…” del proyecto Windows Azure. Al actualizar la versión del SDK tenemos una nueva opción disponible como se muestra en la siguiente imagen:


Tal y como se indica en la misma, para que esta esté disponible debemos habilitar primeramente la conexión remota, como expliqué en un post anterior.

Una vez que hayamos configurado Remote Desktop y hayamos habilitado el check para el Web Deploy, debemos desplegar la solución una primera vez para comenzar a utilizar la herramienta. Cuando la subida haya finalizado estaremos listos para una primera prueba :D

¿Cómo se utiliza Web Deployment Tool?

Realizamos el cambio que creamos oportuno en un web role de nuestra solución y una vez que tengamos modificado el mismo seleccionamos la opción Publish… del Web Role (No del proyecto de Windows Azure) donde se nos presentará la siguiente imagen:


Si nos fijamos en la imagen anterior, el método de publicación sería a través de Web Deploy, Service URL estaría apuntando al DNS de la plataforma Azure a través del puerto 8172, haciendo uso del servicio MsDeploy.axd y como nombre del Site indicaríamos el nombre de la instancia o frontal del hosted service

más el nombre del sitio web, definido en el ServiceDefinition.csdef:

Por último, como credenciales para poder realizar el despliegue debemos indicar las mismas que utilizamos para la conexión remota.

¡Listo! A partir de este momento todo queda configurado para el despliegue instantaneo con Web Deploy :D Para subir los cambios bastará con pulsar sobre Publish y en cuestión de segundos estarán reflejados en el cloud.

Espero que sea de utilidad :)

¡Saludos!

Deshabilitar Storage Emulator para una solución

Como ya hemos comentado en algunas ocasiones, los servicios de la plataforma Windows Azure son totalmente independientes unos de otros. Por ello, en algunas ocasiones no es necesario tan siquiera simular tanto Compute Emulator como Storage Emulator a la vez. Es más puede resultar algo molesto tener la necesidad de crear una base de datos para simular un servicio que ni siquiera vamos a utilizar.

Para deshabilitar Storage Emulator para un proyecto en concreto, desde Visual Studio 2010 seleccionamos con el botón derecho el proyecto de Windows Azure y seleccionamos la opción Properties.

Dentro de las propiedades, accedemos al apartado Development y modificamos a False la opción Start Windows Azure Storage Emulator.

¡Listo! Ya podemos ejecutar nuestro entorno local sin necesidad de ejecutar Storage Emulator :)

Espero que sea de utilidad :D

¡Saludos!

Servicios asmx en Windows Azure

La semana pasada tuvo lugar en Madrid el evento Windows Azure Camps, donde los asistentes consiguieron una visión general de los servicios disponibles a día de hoy en la nube de Microsoft. En él varios de los asistentes tenían cierta inquietud sobre la posibilidad de subir servicios web asmx a la plataforma Windows Azure.

Respecto a esta cuestión, la recomendación general es la migración de nuestros servicios a Windows Communication Foundation por varios motivos:

  • Trabajaremos con .NET Framework 4.0
  • Windows Communication Foundation nos permite desacoplar la lógica de la configuración propia de la comunicación.
  • Podremos hacer uso de Intellitrace tanto en local como en la nube.
  • Dispondremos de más bindings para aumentar nuestras posibilidades de comunicación entre distintos clientes.
  • Etcétera

Si por el motivo que sea no se considera viable la migración y aun así deseamos seguir trabajando con asmx, la solución es bastante sencilla :) Abrimos Visual Studio 2010 en modo administrador y creamos una nueva solución desde el proyecto Windows Azure Project.

En este caso no seleccionamos ningún role de los que nos ofrece la plantilla de Visual Studio. Pulsamos OK para continuar. La solución debe tener el siguiente aspecto:

El siguiente paso sería añadir un proyecto Web Service. Si hacemos clic con el botón derecho sobre la solución y seleccionamos Add -> New Project… las opciones que nos mostrará serán las siguientes:

Como podemos ver, no aparece ninguna solución para el tipo Web Service. Al principio del post comentaba que una de las ventajas de trabajar con WCF era que podíamos hacer uso de la última versión del framework. Si prestamos algo más de atención a esta ventana, comprobamos que sólo nos está mostrando aquellos proyectos disponibles para la última versión, por lo que la solución es bastante fácil :D

Cambiamos el combo superior para que filtre por la versión 3.5 del framework y ya podremos seleccionar el tipo ASP.NET Web Service Application.

Una vez añadido a la solución, basta con seleccionar la carpeta Roles de Windows Azure Project y hacer clic sobre Add -> Web Role project in solution donde nos aparecerá nuestro servicio asmx como opción ;)

Si quisiéramos añadir un proyecto existente, podríamos seguir los mismos pasos comentados en el post Subir un proyecto existente a Windows Azure.

Espero que sea de utilidad :D

¡Saludos!

Mad.Nug: Desarrollando para Windows Phone 7, desde una idea hasta el marketplace.

Este mes desde Madriddotnet queremos ofreceros la oportunidad de una primera toma de contacto con el nuevo sistema operativo para móviles de Microsoft: Windows Phone 7. Para ello, contamos con la ayuda de Josue Yeray, que nos explicará nociones básicas de la plataforma y nos guiará paso a paso en la creación de una aplicación RSS que posteriormente subiremos al marketplace.

El evento tendrá lugar el 18 de Mayo en Aula Vulcan. Para conocer más información sobre el evento podéis acceder al siguiente enlace.

¡Nos vemos pronto! :D

¡Saludos!

Subir un proyecto existente a Windows Azure

Una de las preguntas que me llegan a través del formulario de contacto es qué es lo necesario para subir una aplicación que ya tenemos implementada, en este caso con Web Forms, a la plataforma Windows Azure. En realidad, un proyecto para la nube contiene todos aquellos proyectos que componen nuestra aplicación y además un proyecto relacionado con la plataforma en el cual se define qué rol tiene el resto de proyectos de nuestra solución.

Cuando creamos una solución de tipo Cloud una de las ventanas que nos aparece es la siguiente:

En ella podemos seleccionar qué tipo de aplicaciones queremos implementar, desde aplicaciones web a aplicaciones en segundo plano. Sin embargo, uno de los escenarios más comunes es cuando no tenemos nada que implementar sino que únicamente queremos acondicionar su subida a la nube. En ese caso, no seleccionamos ninguno de los roles ofrecidos y pulsamos directamente en el botón OK. De esta forma, estamos pidiendo a Visual Studio 2010 crear una solución con un proyecto del tipo cloud sin ningún rol asociado.

Si en este momento tratáramos de ejecutar el proyecto, pulsando F5, Visual Studio nos devolvería el siguiente error:

En él se nos está avisando de que actualmente no hay ningún rol asociado al proyecto y que al menos es requerido uno del tipo web, worker o virtual machine. Llegado a este punto, debemos añadir  aquel proyecto(s) a la solución que queramos subir a Windows Azure Platform desempeñando uno de los roles.

Al igual que en cualquier solución convencional, copiamos/cortamos el proyecto que queramos añadir a la solución

y lo pegamos dentro de la carpeta del proyecto cloud.

Para que este aparezca dentro de la solución, hacemos clic con el botón derecho a nivel de solución y seleccionamos Add => Existing project…

y localizamos el archivo del proyecto que acabamos de mover dentro de la solución cloud.

Si bien este ya aparece dentro de la ventana Solution Explorer, todavía no forma parte del servicio que será desplegado en la nube. Para finalizar la configuración, debemos hacer clic con el botón derecho sobre la carpeta Roles y seleccionar Add => Web Role Project in solution…

Acto seguido nos aparecerá un cuadro de diálogo donde podremos seleccionar aquellos proyectos que encajen dentro de cualquiera de los roles existentes a día de hoy en la plataforma de Windows Azure.

Por otro lado habrá proyectos, por ejemplo de tipo Class Library, que no serán necesarios subirlos a la nube como tal sino únicamente las dlls resultantes del mismo.

Como nota adicional, es importante que nos aseguremos de que todas las librerías utilizadas en los proyectos ya existentes fuera de la plataforma y que queramos desplegar estén disponibles en la nube. Como solución podemos modificar las propiedades de las mismas como Copy Local = true o bien utilizar Startups.

Espero que sea de utilidad :D

¡Saludos!