Trabajando con aplicaciones reales en Windows Azure te das cuenta rápidamente de que necesitas automatizar ciertas tareas, ya que hacerlas de manera manual puede resultar muy pesado y poco productivo; despliegues, actualizaciones, monitorizaciones etc…

Para esta fin los CmdLets de PowerShell para Windows Azure ha sido desde su aparición un gran aliado, aliado que ahora se actualiza a la versión 2.0 que incluye nueva funcionalidad gracias a que Windows Azure ofrece cada vez más APIs de Administración que los desarrolladores podemos utilizar. Claro está, que todo lo que hacen estos CmdLets lo podríamos hacer nosotros mismo.

Tanto la descarga como la documentación sobre su utilización la podéis encontrar aquí.

Las novedades más importantes son los comandos para trabajar con SQL Azure, aquellos que exportan toda las métricas del Storage y los que permiten tratar la información de diagnóstico de las aplicaciones Azure..

Por ejemplo, algunos comandos nuevos son:

Window Azure Storage Analytics

SQL Azure Servers

SQL Azure Firewall Rules

BPOS (Business Productivity Online Suite) es la plataforma de Microsoft de servicios de productividad en la nube previa a Office 365. Con la aparición de Office 365 en Junio de 2011 los usuarios de BPOS pueden programar la  fecha de transición de sus servicios y datos desde BPOS a Office 365. Esta transición es gratuita y para todos las suscripciones de BPOS. Microsoft se encargará de todas las actualizaciones de infraestructura de servidores y de migración de datos, garantizando que la transición sea un proceso sencillo para los clientes.

El motivo de realizar esta transición es que BPOS está construido sobre servidores dedicados adaptados a los requisitos en la nube, mientras que la nueva arquitectura de Office 365 está diseñada para soportar servicios facilitando su gestión y flexibilidad.

Al pasar a Office 365 las suscripciones de BPOS se transformarán en otras de Office 365:

Consulta los planes de Office 365 office365.microsoft.com/office365-plans.aspx.

Las transiciones programadas empezarán a partir de Septiembre de 2011 y se prevé que todos los clientes de BPOS hayan cambiado a Office365 como máximo antes de Septiembre de 2012. Microsoft irá informando de la transición a los clientes entre 60 y 90 días antes de su fecha programada. Aunque Microsoft le puede fijar una fecha, usted puede proponer otra fecha desde el portal de Administración de BPOS.

Una vez fijada la fecha de transición, unas semanas antes irá recibiendo mensajes recordatorios para que vaya preparándose para la transición. Los clientes tendrán que formarse por su cuenta en Office 365 y serán responsables de actualizar en sus equipos locales el software cliente necesario, consulte los requisitos en  http://onlinehelp.microsoft.com/office365-enterprises/es-es/ff652534.aspx.

El proceso de sincronización dura unas 48 horas y se realizará por la noche o durante un fin de semana. Durante el proceso sufrirá cortes en los servicios, podrá estar en contacto frecuente con el equipo de soporte a la transición que le ayudará y escuchará los posibles problemas que encuentre.

Durante el proceso de transición no podrá realizar cambios en los servicios y el administrador recibirá información acerca de las siguientes acciones después de la transición.

Después de la transición, el administrador tendrá que abrir una nueva sesión del portal de administración de BPOS, en ese momento se le redirigirá a la nueva Url de administración en Office 365. Las credenciales del administrador no cambiarán, al iniciar sesión en Office 365 tendrá que validar los datos de facturación y que se han migrado las suscripciones de BPOS a Office365.

Los usuarios finales accederán con su usuario y password de BPOS habitual, Outlook se reconfigurará automáticamente, pero tendrán que cambiar manualmente la url de OWA.

Más información en:

Centro de transición a Microsoft Office 365

Guía de transición para ayudarlo a planificarse y prepararse

Making the transition from BPOS to Office 365

Este mismo domingo los compañeros de Plain Concepts tomamos la iniciativa de dejar de hablar de la nube y decidirnos a ir en busca de ella. Los evangelistas de Microsoft creyeron que haciendo el camino de Santiago llegarían, pero nosotros hemos optamos por subirnos al monte para hacer cima y poner estar más cerca.

Ha sido una jornada dura, algo más de 4 horas de caminata y subida (menos si hubiéramos elegido mejor a nuestro serpa), pero ha merecido la pena. Y claro está, al hacer cumbre hemos tenido que poner la bandera (tendremos que pedir patrocinio a Microsoft) y hacernos las fotos de rigor.

Es una experiencia muy buena que recomiendo para hacer equipo, ahora somos más ágiles :-,,)

Aquí os dejo unas fotos de la jornada:

En esta foto se puede ver Bilbao de fondo, punto desde el cual hemos empezado! Seguro que los que sois de Bilbao ya sabéis dónde hemos estado.

Subiendo poco a poco…

Cerca de la cima ya.

La foto de rigor para demostrar que hemos hecho cumbre y dejar contentos a los patrocinadores…eso sí, igual deberíamos haber pedido primero patrocinio.

Buenas vistas, ya tenemos en mente la siguiente cumbre, un poquito más alta la próxima.

Esta un poquito más abajo, desde el punto de partida, justo antes de dirigirnos a comer!

Como ya os comenté es un post anterior varios evangelistas de Microsoft están haciendo el camino de Santiago en bicicleta y parando en algunas ciudades para hacer eventos sobre Cloud Computing.

Aunque podéis ver y seguir su día a día a través de http://www.elcaminoalanube.com , en este post os pongo algunas fotos del evento que se celebró esta semana pasada en Logroño; del evento, de la comida después de evento y alguna más para que veáis la caravana dónde duermen y guardan todo los materiales del evento.

Y aunque veías a Fernando enseñar la cabeza por la puerta de la caravana prometo que él cogió también la bicicleta mientras la caravana se iba a la meta a esperarles!

La llegada de Azure nos acerca a los programadores la problemática de la alta escalabilidad y sistemas distribuidos. En Azure no desarrollamos para un proceso en una máquina, nuestros desarrollos podrán estar en múltiples máquinas a las que realmente no sabremos de antemano donde se ejecutará cada petición. A esto tenemos que agregarle que en Azure disponemos de distintos tipos de “servicios” que podemos desarrollar (Web Roles y Worker roles), cada uno de esto roles se ejecutará en procesos de instancias distintas por lo que en muchas ocasiones será necesario que tengamos que implementar algún tipo de comunicación entre los distintos procesos.

Existen varias técnicas de comunicación entre los roles de Azure dependiendo si queremos realizarlo Online u Offline:

• Online, la comunicación se hace en el momento, el que inicia el mensaje espera hasta que el destino termine de procesarlo.
• Offline, el destino se entera del mensaje en algún momento pero no sabemos cuando exactamente y el que inicia el mensaje lo envía pero no espera a que termine de procesarlo.

Si elegimos la forma Offline disponemos de varios mecanismo para almacenar el mensaje todos ellos basados en un almacenamiento temporal, el más utilizado son las colas de Azure o Queue. De manera que uno proceso va introduciendo los mensajes en una cola de mensajes. Por otro lado habrá otro proceso leyendo los mensajes introducidos en la cola. Encontrará un ejemplo en el Training Kit de Azure en el capítulo “Exploring Windows Azure Storage”.

Para hacer una comunicación Online podemos recurrir al  uso de servicios WCF, de manera que uno de los roles iniciará el servicio WCF para leer mensajes y otro rol lo llame. En este caso el rol que origina la llamada al servicio WCF esperará hasta que termine la ejecución del servicio o se produzca un timeout.

Para facilitar este concepto hemos desarrollado el proyecto “Azure Sample Communication Rol” en Codeplex de libre descarga.

A continuación se indican los pasos que hemos seguido para hacer el proyecto:

Desde Visual Studio 2010 creamos el proyecto HelloInterRoles de tipo Cloud –> Windows Azure Project y agregamos dos tipos de roles:  ASP.net Web rol y Worker Rol.

Creamos un proyecto HelloService de tipo “Empty project” que utilizaremos para agregar las clases que definan e implementen el funcionamiento del servicio WCF.

Agregamos un nuevo elemento del tipo “WCF Service” con el nombre HellloService. visual Studio nos creará dos ficheros, IHellloService.cs con la interfaz del servicio y HellloService.cs con la implementación. Agregue al proyecto las siguientes referencias del GAC Microsoft.WindowsAzure.ServiceRuntime.dll

En la clase IHelloService añada el siguiente método

    [ServiceContract]
    public interface IHellloService
    {
        [OperationContract]
        string RoleName();
    }

En la clase HelloService escriba el siguiente código que devuelve el identificador de la instancia de Azure que está ejecutando en ese momento el código.

 public class HellloService : IHellloService
 {
        /// <summary>
        /// Return the current Role name of WorkerRoles
        /// </summary>
        /// <returns></returns>
        public string RoleName()
        {
            return RoleEnvironment.CurrentRoleInstance.Id;
        }
 }

Para facilitar la carga del servicio se agregará otra clase HelloProxy con el método GetUrlFormat para devolver la dirección del servicio WCF y el método GetAProxy que conecta con el servicio WCF:

public class HelloProxy
    {

        /// <summary>
        /// Return the URL string to connect to WCF service
        /// </summary>
        /// <param name="Ip"></param>
        /// <returns></returns>
        public static string GetUrlFormat(IPEndPoint Ip)
        {
            return string.Format("net.tcp://{0}/HellloService", Ip);
        }

        /// <summary>
        /// Return a instance of WCF service
        /// </summary>
        /// <param name="Url"></param>
        /// <returns></returns>
        public IHellloService GetAProxy(string Url)
        {
            NetTcpBinding binding = new NetTcpBinding(SecurityMode.None);
            EndpointAddress endpointAddress = new EndpointAddress(Url);

            return new ChannelFactory<IHellloService>
                (binding, endpointAddress).CreateChannel();
        }

    }

Una vez definido el servicio tendrá que iniciarlo desde los Worker Roles al iniciarse la instancia. Desde el proyecto “WorkerRole” edite el fichero “WorkerRole.cs”.

Agregue una variable global a la clase de tipo ServiceHost que tendrá una referencia al listener del servicio WCF:

private ServiceHost host;

Modifique los eventos  OnStart y OnStop para iniciar y parar respectivamente el servicio WCF

        public override bool OnStart()
        {
            ServicePointManager.DefaultConnectionLimit = 12;

            StartWCFService();

            return base.OnStart();
        }

        public override void OnStop()
        {

            try
            {
                // if WCF service was opened then i''m going to close it
                if (host != null && host.State == CommunicationState.Opened)
                    host.Close();
            }
            catch(Exception ex) {
                Trace.WriteLine("Exception: " + ex.Message, "Information");
            }

            base.OnStop();
        }

Agregue el método StartWCFService y abra una conexión de la clase ServiceHost:

        /// <summary>
        /// Initialize the WCF service
        /// </summary>
        private void StartWCFService()
        {
            try
            {
                IPEndPoint ipEndPoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["HelloService"].IPEndpoint;
                host = new ServiceHost(typeof(HellloService));
                NetTcpBinding binding = new NetTcpBinding(SecurityMode.None);
                host.AddServiceEndpoint(typeof(IHellloService), binding, String.Format("net.tcp://{0}/HellloService", ipEndPoint));

                host.Open();
            }
            catch (Exception ex)
            {
                Trace.WriteLine(ex.Message, "Error");
                throw;
            }
            Trace.WriteLine("WCF Hello service running...");
        }

Agregue el método StopWCFService  para cerrar la conexión de la clase ServiceHost:

        /// <summary>
        /// Stop the WCF service
        /// </summary>
        private void StopWCFService()
        {
            if (host != null)
            {
                try
                {
                    host.Close();
                }
                catch (Exception ex)
                {
                    Trace.WriteLine(ex.Message, "Error");
                    host.Abort();
                    throw;
                }
            }
        }

En este punto los Worker roles iniciarán el servicio WCF al arrancarse, quedaría agregar la llamada al servicio desde una instancia remota en este caso desde la instancia ASP.NEt web rol. Faltaría agregar un EndPoint al Worker Role para que Azure habilite un puerto de comunicación entre los roles. En este caso agregue un Endpoint de tipo “Internal” y protocolo “tcp”.

Desde el proyecto Web Role, agregue una páginas apx, agregue un control  de ASP.NETdel tipo ListBox para registrar los nombres devueltos por las llamadas a los servicios WCF de cada uno de los Worker roles.

Agregue un botón de ASP.net desde el que se realizará la llamada con el siguiente código:

        /// <summary>
        /// Event button, call to WCF Worker roles
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        protected void Button1_Click(object sender, EventArgs e)
        {
            try
            {
                // Read all Worker roles instances
                foreach (RoleInstance instance in RoleEnvironment.Roles["WorkerRole1"].Instances)
                {
                    try
                    {
                        // Retrieve the Worker role URL
                        IPEndPoint ipEndPoint = instance.InstanceEndpoints["HelloService"].IPEndpoint;
                        HelloService.HelloProxy proxy = new HelloService.HelloProxy();

                        // retirve a WCF instance
                        HelloService.IHellloService service = proxy.GetAProxy(HelloService.HelloProxy.GetUrlFormat(ipEndPoint));

                        // Call to WCF method
                        string roleName = service.RoleName();
                        ListBox1.Items.Add(roleName);
                    }
                    catch(Exception exConnection)
                    {
                        ListBox1.Items.Add(string.Format("Exception {0}: {1}", instance.Id, exConnection.Message));
                    }
                }
            }
            catch (Exception ex)
            {
                LabelError.Text = ex.Message;
            }
        }

Por último, quedaría probar el proyecto desde el emulador de Azur, desde Visual Studio 2010 pulse F5 para que se inicie el Azure Emulator y se despliegue sobre el el paquete del proyecto. Si pulsa con el botón derecho sobre el icono de Azure Emulator aparecerá un menú con la opción “Show compute emulator UI”, al seleccionarlo se mostrará una ventana donde podrá comprobar el estado de sus instancias locales.

Descarga el proyecto desde : http://azuresamplecommunica.codeplex.com/