My approach to this problem is to use Application Gateway as the Layer 7 load balancer to expose and consume the WebApi from the public Internet. In the Application Gateway I can install the certificate and server the content from it. The internal communication between the Application Gateway and the Service Fabric don’t need to be secured. I can have SSL-offload for the WebApi.

To achieve this, we can modify the default ARM template for Service Fabric and instead of deploying a public load balancer we can deploy using an internal load balancer. This will prevent any kind of public traffic to hit any Service Fabric endpoint. We can follow this documentation for the Service Fabric Cluster networking patterns.

Once we have the cluster deploy using the internal load balancer the Service Fabric Explorer URI will be https://10.0.0.250:19080/, the management endpoint is 10.0.0.250:19000.

Application Gateway.

The next step will be to create a new subnet inside the VNET where the Service Fabric cluster is. After the subnet is created, we can deploy the Application Gateway in that newly created subnet. When the Application Gateway is created, in the configuration setting for the Backend pool we need to add the internal IP address for the internal load balancer that the Service Fabric cluster is using.

This will enable the Application Gateway to route the HTTP/HTTPS traffic through the internal load balancer. If the scale set associated with the Service Fabric cluster increase or decrease the number of VMs, this configuration will be transparent for the Application Gateway, making things easy.

We have everything ready to expose the WebApi using the Application Gateway. Application Gateway is connected to the internal IP of the Internal Load Balancer, who is connected to Service Fabic Scale Set. Inside the Application Gateway we need to setup the Listener, Rule and HTTP Setting to map the port 443, upload the certificate and we ready to go.

Service Fabric management API

The internal load balancer is great because we’re sure that all communication is isolated and secure. But when we would like to deploy a new application to the cluster, or update an existing one, we need communication with the Management API as well with the Service Fabric Explorer. This is a problem right now because only devices in the same VNET are the one who can communicate to the internal load balancer. To solve this connectivity issue, we have two options.

First, deploy a Virtual Machine on the VNET where Service Fabric Cluster is. Install the Visual Studio Agent and deploy from there. We’re going to miss the Service Fabric Explorer as well. But we can connect using remote desktop to that VM and browse from there.

Second option is deploying another load balancer, but in this scenario a public one, and explore both the Management API and the Service Fabric Explorer.

Once the public load balancer is created, go to the backend pools and click on add, give a name and select associated to Virtual machine scale set. Select the Scale Set associated with the Service Fabric cluster.

Then map both the 19000 and 19080 ports to make the management API and the Service Fabric Explorer.

Final architecture

This is final architecture for the proposed solution. With two public IP addresses, one with the Application Gateway to expose using SSL the WebApi and the other one to manage the Service Fabric cluster itself. A final option that it’s a more complicated is to have a VPN Gateway in the VNET and connect your local on-prem network. This could be overly complicated depending on your IT department.

Luis Guerrero.]]> https://docs.microsoft.com/archive/blogs/luisguerrero/grficas-de-informacin-del-nuevo-portal-de-azure-ibiza Thu, 10 Dec 2015 03:19:54 GMT https://blogs.msdn.microsoft.com/luisguerrero/2015/12/10/grficas-de-informacin-del-nuevo-portal-de-azure-ibiza/ Cuando se tienen servidores en producción una de las preocupaciones de los administradores IT o devops es saber lo bien (o mal) que están funcionando sus servidores. La forma más rápida de ver si un servidor está saturado o no, es simplemente mirando al consumo de CPU, o en el caso de la aplicación sea muy intensiva de red, echando un vistazo a los bytes enviados en el adaptador de red. También puede ser la memoria libre que tiene disponible la máquina.

Si la maquina tiene un servidor de aplicaciones como IIS, sería interesante poder mostrar información sobre cuantas peticiones por segundo se están ejecutando, cual es la cola de http de ASP.NET. Si por el contrario se tiene un servidor de SQL Server, información de cuantas peticiones activas tiene, la cantidad de re compilaciones de los planes de ejecución, ect.

Información al poder

En todos estos escenarios que antes se han mencionado la información de contadores de rendimiento muestran información de salud del estado de la máquina o del servicio. En ese sentido uno de los problemas que se puede enfrentar un administrador de IT es que tenga que conectarse a todas esas máquinas para extraer esa información haciendo que el proceso sea tedioso.

Aquí es donde entra el portal del Azure (Ibiza) que puede ayudar en esas tareas de monitorización básicas.

Graficas del portal

Cuando se provisiona un servidor, ya sea Windows o Linux, el portal permite obtener información de la máquina para después mostrar esa información en el propio portal.

Linux

En el siguiente ejemplo una máquina de Linux que tiene instalado un servidor de node.js y utiliza pm2 como servidor de aplicaciones para utilizar todos los cores (8) de la máquina.

Como se puede se puede observar esta máquina es Linux, y tiene 8 Cores y 14 Gb de memoria.

Pero aun así se puede obtener información muy variada, incluso cuantos bytes se han enviado o recibido desde el adaptador de red y cuantas lecturas y escrituras se han hecho.

Como se puede observar esta máquina es muy intensiva de CPU y red, pero no hace apenas escritas en disco ya que simplemente procesa un html y devuelve el resultado por red.

Windows Server con SQL Server

La siguiente máquina tiene Windows Server 2012 R2 con 16 discos duros adjuntos y tiene 8 Core y 28 Gb de memoria con un SQL Server instalado.

Además de las gráficas de CPU típicas de una maquinas también se puede obtener información sobre el estado del SQL Server que hay instalado y funcionando:

Además de graficas de lecturas y escrituras de discos:

Lo interesante de estas gracias es que no solo se puede obtener esa información sino que se puede personalizar la cantidad de información que se desee. A continuación un detalle de los contadores que se pueden obtener para SQL Server:

SQL Database

Si por el contrario se tiene una base de datos SQL Azure, en mi caso una base de datos P2 de 250DTUs también se puede obtener información muy útil de la base de datos:

Por la información de las gráficas se puede ver que la base de datos está trabajando a toda potencia.

Cloud Services

Si se tiene desplegados Cloud Services también se puede aprovechar de esta información pero agregada de todas las máquinas que se tengas desplegadas. En mi caso dos instancias.

En este escenario los workers no son muy intensivos en CPU pero si mucho en red.

Personalizar el dashboard

Otra de las características del portal es que puedas mostrar esas piezas de información en el portal para configurar el aspecto a tu gusto y mostrar la información que es relevante para ti.

Con lo que un vistazo se puede acceder a información que es relevante para cada usuario que inicia sesión en el portal.

¿Cómo se extrae la información de las máquinas?

Para que esta información esté disponible en el portal, Microsoft instala en las máquinas invitadas un agente que se encarga de recopilar esta información. En el caso de Windows utiliza la infraestructura de contadores de rendimiento para obtener esa información. Cuando se provisiona una máquina virtual Windows se añade una extensión llamada Microsoft.Azure.Diagnostics.IaaSDiagnostics que es la que se encarga de comunicarse con el controlador del Fabric de Azure. Este servicio recopila la información y la almacena en una cuenta de Azure Storage que se ha especificado durante la provisión de la VM.

En el caso de una máquina Linux, los contadores de rendimiento no existen, con lo que hay que utilizar otro mecanismo para obtener la información de rendimiento de la VM. También se instala una extensión que se encarga de recopilar esa información llamada Microsoft.OSTCExtensions.LinuxDiagnostic. Que en última instancia añade un demonio de Linux escrito en Python que se llamad waagent, el cual está disponible el código fuente en GitHub https://github.com/Azure/WALinuxAgent

Luis Guerrero

Technical Evangelist Microsoft Azure

@guerrerotook

Un poco de historia

Para entender por qué son necesarias este tipo de arquitecturas ahora mismo hay que entender que soluciones se creaban antes del Cloud. Estas soluciones no son muy diferentes de las que se generan en el Cloud pero hay que tener en cuenta lo fácil y sencillo que es crear servicios y consumirlos en el Cloud para entender este modelo.

Si se piensa en un despliegue típico de una solución web que utilice un servidor de base de datos sería algo parecido a esto:

Web Frontent

Una aplicación ASP.NET donde todos los usuarios acceden a la misma url www.contoso.com de servicio e inician sesión con sus credenciales. Esta aplicación consume servicios que el servidor de aplicaciones expone donde está la lógica de negocio del frontal web y finalmente esos datos están almacenados en la base de datos.

Base de datos

El esquema de la base de datos no es importante en sí, pero hay que tener en cuenta como se han dado de alta a los diferentes clientes. Normalmente se tendría una tabla que representa a los clientes dados de alta en el servicio y se hacen relaciones con otras tablas para saber qué datos son específicos de cada cliente. El esquema podría ser algo así.

Como se puede observar en el diagrama, se utiliza un discriminador para filtrar los datos que son específicos de un cliente. Siempre se realiza la asociación utilizando la tabla clientes para tener una relación entre tablas que permita mantener una integridad referencial. Los datos que hay en las tablas son datos de todos los clientes en todo momento.

Rendimiento

Con este modelo de desarrollo todos los usuarios finales operan dentro de la misma base de datos, pero en filas diferentes, lo que permite acceder de forma concurrente. Pero al estar todos los usuarios utilizando la misma base de datos el grado de concurrencia de las tablas es bastante grande.

Conforme el número de usuarios va creciendo la concurrencia en la base de datos aumenta. Pero este crecimiento no es lineal, es decir, que algunos clientes grandes tendrán un impacto en el rendimiento de la base de datos más grande que otros clientes más pequeños, haciendo que todos tengan la misma experiencia.

Multi-tenant

Aquí es donde se puede introducir el concepto de multi tenant. La idea es bastante sencilla, en vez de tener una base de datos para todos los clientes, se tiene una base de datos con el mismo esquema para cada cliente.

Ventajas

Con este mecanismo en el que se tiene una base de datos por cada cliente, permite que si se está usando Azure SQL como base de datos, se pueda escalar cada base de datos de forma independiente entre los clientes consiguiendo así distintos niveles de servicio. De esta manera si se tiene un cliente muy grande con muchos usuarios se podrá elegir una base de datos P4 de 500 DTU y si tiene un cliente pequeño una edición S1 de 20 DTU, pero ambas bases de datos tienen el mismo esquema. De esta manera el coste de operaciones relacionadas con el servicio se puede predecir y se puede cambiar en base a las necesidades del cliente, ya que, Azure SQL permite cambiar de nivel hacia arriba y hacia abajo en todo momento.

Además, se pueden tener escenarios de testeo A/B con los clientes para futuras versiones de la aplicación, haciendo así que los clientes puedan tener diferentes versiones de la aplicación.

Inconvenientes

El modelo multi-tenant no son sólo ventajas, sino que también plantea ciertos desafíos. Uno de los más importantes es la estrategia de actualización de los esquemas / datos de las bases de datos. Como es sabido, con bases de datos en producción con clientes accediendo al sistema, hacer modificaciones en el esquema de la base de datos puede ser un proceso doloroso, si eso lo multiplicamos por todas las bases de datos, el problema puede ser enorme.

En ese sentido, herramientas como Entity Framework Code First y su tecnología de migraciones, hacen posible que cada cambio en el esquema se pueda hacer hacia adelante y hacia atrás de forma pseudo automatizada.

En los escenarios de Cloud la clave siempre es la automatización, piense por ejemplo cual sería el proceso de provisiona un nuevo cliente, se debería de crear una base datos vacía, y en el caso de que se utilice Entity Framework actualizar la base de datos de destino con el esquema y datos necesarios.

Implementación

Para hacer posible que este escenario hay que hacer ciertas modificaciones en el código fuente para dar cabida a este escenario.

El primer cambio de todos consiste en tener un mecanismo que permita identificar al usuario. Este mecanismo se puede implementar de varias maneras, como por ejemplo a través de la url. En este ejemplo:http://cliente1.miservicio.com/ o http://www.miservicio.com/cliente1

En ambas urls, el nombre del cliente forma parte de la url que permite que desde la tecnología de servidor que elijamos seamos capaces de identificar el cliente. Esto también se puede hacer a través de una cookie que se establezca en el proceso de login del usuario final.

¿Para qué se necesita identificar al cliente?

En el desarrollo tradicional que se introducía al principio del artículo, normalmente la cadena de conexión a la base de datos sería una constante en el código fuente o el fichero de configuración. En el caso de ASP.NET el fichero web.config.

Pero en este nuevo escenario la cadena de conexión cambia dependiendo del cliente que este consumiendo el servicio, con lo que tener una única cadena de conexión no es algo que funcione a priori.

Lo que hay que hacer es, en el paso más temprano del ciclo de vida de una petición http identificar al cliente, ir a una base de datos de infraestructura a buscar los datos de conexión del cliente y establecer esa información de forma ambiental durante toda esa petición. De esta manera cuando se quiera establecer una conexión con la base de datos, no se lee el valor de configuración, sino que se obtiene de esta variable ambiental.

Base de datos de infraestructura

En el párrafo anterior se especificaba que hay que usar una base de datos de infraestructura. Esta base de datos, que será común a todos los clientes contiene información del propio servicio, es decir, que clientes están provisionados y cuantos usuarios tienen asociados al servicio. De esa manera en esa base de datos se encontrará una tabla llamada Clients, donde cada una de las filas representa uno de los clientes provisionados. Un posible ejemplo sería este:

De esta manera con el mecanismo anterior de identificación lo que hay que hacer es buscar una fila en la que el nombre cliente coincida con el segmento de la url. Cuando se encuentre el cliente, el siguiente paso es establecer el valor de la cadena de conexión en una variable que se pueda usar durante toda la petición.

Demo en ASP.NET

Para implementar el ejemplo de multi-tenant en ASP.NET utilizando el patrón de urls basads en http://www.miservicio.com/cliente1 (esto se puede cambiar en cualquier momento), se podría hacer de esta manera.

En el ciclo de vida de una petición de ASP.NET hay un evento que se produce cuando empieza la petición que es el momento adecuado para detectar, que cliente es e ir a la base de datos de infraestructura para detectar la cadena de conexión a la base de datos.

private void OnBeguinRequest(object sender, EventArgs e)
{
    HttpContext context = HttpContext.Current;
    var clientId = context.Request.Url.Segments.LastOrDefault();
    using (MultitenantDbContext dbContext = new MultitenantDbContext())
    {
        var client = dbContext.TentanUsers
            .Where(p => p.Name == clientId)
            .Select(p => p).FirstOrDefault();
        if (client != null)
        {
            context.Items[ClientConnnextionStringKey] = client.ConnnectionString;
        }
        else
        {
            throw new InvalidOperationException("Client not found");
        }
    }
}

Así de esta manera, en un único punto se detecta el cliente, se almacena esa información en la colección de elementos de contexto de Http actual de ASP.NET. En otro tipo de lenguajes o runtimes, la forma de hacer esto, puede variar, pero la idea es la misma.

El siguiente paso es utilizar esta cadena de conexión en el punto que sea necesario, por ejemplo en un controlador donde que se quiera acceder a datos para un determinado cliente.

public ActionResult Index()
{
    string connextionString = 
    (string)this.HttpContext.Items[MvcApplication.ClientConnnextionStringKey];
    using (ClientDbContext context = new ClientDbContext(connextionString))
    {

    }
    return View();
}

Conclusiones

Esta es una primera aproximación para un escenario multi tenant. A partir de aquí se puede evolucionar el concepto, para un despliegue más complejo. Como se comentó al principio del artículo, gracias a la API de administración del portal de Azure, se puede automatizar el proceso de creación de las base de datos de SQL Azure en el caso de que se tenga que provisionar un nuevo cliente.

Luis Guerrero Guirado.

Technical Evangelist Microsoft Azure.

@guerrerotook

Cómo funciona el servicio de Azure Storage Blobs

Como cualquier otro servicio de Azure Storage utiliza una API REST que permite interactuar con el servicio. La URL define el recurso al que se quiere acceder.

Como se puede observar en la imagen hay tres tipos de artefactos. La cuenta, el contendor y el nombre del fichero. Estos tres artefactos serán los que tengan la responsabilidad de orquestar correctamente el acceso al servicio, y en el caso de este artículo, el particionado.

¿Por qué es importante el particionado?

Cuando se construye un servicio en la nube, uno de los aspectos importantes es la escalabilidad y el rendimiento del mismo. Cuando se tiene un servicio que acepta millones de peticiones cada hora, hay que tener en cuenta como el servicio va a responder bajo esa demanda de operación.

En ese sentido, la misma lógica impera cuando se diseña un servicio para on-premises. Imagina por un momento que todas peticiones de tu aplicación web están siendo servidas por la misma máquina, en vez de tener un sistema que distribuya las peticionas a través de unos recursos preexistentes de máquinas que contengan tu mismo recurso. Ese mismo concepto es el que hay detrás del particionado, es involucrar a diferentes servidores físicos para que ejecuten la operación que el usuario ha solicitado. Conforme más servidores, menos será la latencia y mayor la capacidad de respuesta del servicio.

El esquema de las direcciones de Storage Blob

En formato de las urls de Azure Storage Blob se puede resumir en dos opciones principalmente.

https://myaccount.blob.core.windows.net/mycontainer/myblob.jpg

En esta primera opción el nombre del contenedor de mycontiner y el nombre del blob es myblob.jpg. Los nombres de los contenedores no pueden contener caracteres en mayúscula, así que solo puede ser en minúscula.

https://myaccount.blob.core.windows.net/mycontainer/1/2/3/file.txt 

En este ejemplo el nombre del contenedor es igual mycontainer, pero el nombre del fichero es 1/2/3/file.txt. Es decir, el nombre del blob contiene también las barras simulando un sistema de archivo.

¿Cómo son las particiones calculadas?

Si se lee la documentación oficinal de producto, http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx, se comenta que la partición para lo blobs se calcula en base al nombre del contenedor + nombre del blob. Es decir, que, para nuestro ejemplo anterior, sería mycontainer + myblob.jpg.

Así que peticiones que tengan diferentes llaves de partición serán distribuidas a través de diferentes servidores. El único inconveniente es que pierde la capacidad de hacer transacciones atómicas entre múltiples blobs.

Entendiendo esto, ahora surge la siguiente pregunta, que es clave para entender el algoritmo de particionado.

¿Cómo tengo que nombrar mis blobs para maximizar el uso de particiones?

La estrategia de nombre debería de ser algo como esto:

a/b/c/d/e/f/{n}/file.txt

Siendo {n} el elemento que se va incrementando en el tiempo y que permite a los servidores de partición de Azure Storage almacenar correctamente los blobs de tu cuenta de almacenamiento. El orden de {n} es lexicográfico, con lo que te interesa que vaya incrementándose en base de los caracteres, también tiene como consecuencia que se no se calcula en base a un hash. Por cambiar un valor no vas a tener una partición completamente diferente, sino que posiblemente será la misma.

En el siguiente ejemplo se muestra un posible esquema y cómo utilizarlo.

Si para generar esa secuencia de elemento de {n} se utiliza la fecha para ir incrementando el nombre de los blobs, se tendría algo como esto:

30 de agosto del 2015
mycontainer/1/2/20150830/(Guid.NewGuid()).txt <- Todas las transacciones 
de Storage irían aquí, a un servidor de particiones
31 de agosto del 2015
mycontainer/1/2/20150830/(Guid.NewGuid()).txt <- este path ya no es usado 
por el servidor de particiones
mycontainer/1/2/20150831/(Guid.NewGuid()).txt <- Todas las transacciones 
de Storage irían aquí, a un servidor de particiones
1 de septiembre del 2015
mycontainer/1/2/20150830/(Guid.NewGuid()).txt <- este path ya no es usado 
por el servidor de particiones
mycontainer/1/2/20150831/(Guid.NewGuid()).txt <- este path ya no es usado 
por el servidor de particiones
mycontainer/1/2/20150701/(Guid.NewGuid()).txt <- Todas las transacciones 
de Storage irían aquí, a un servidor de particiones

Las peticiones se distribuirían de la manera antes expuesta, y aunque se ha utilizado un valor incremental para el nombre del blob, es se te ha hecho de manera que los servidores de particionado no lo utilizan y al final utiliza todos el mismo servidor. Con lo que si se tuviera que haber leído esos tres ficheros en el mismo día, el mismo servidor respondería y el rendimiento del servicio se vería afectado.

Sin embargo, si se utiliza este otro mecanismo para nombrar a los blobs:

mycontainer/1/2/1/(Guid.NewGuid).txt
mycontainer/1/2/2/(Guid.NewGuid).txt
mycontainer/1/2/3/(Guid.NewGuid).txt
mycontainer/1/2/4/(Guid.NewGuid).txt

Incluso poniendo un prefijo previo al nombre del fichero:

mycontainer/1/2/1/Storage(Guid.NewGuid).txt
mycontainer/1/2/2/Storage(Guid.NewGuid).txt
mycontainer/1/2/3/Storage(Guid.NewGuid).txt
mycontainer/1/2/4/Storage(Guid.NewGuid).txt

Se conseguiría que, para acceder a esos cuatro ficheros, que hasta 4 servidores se involucrasen en las respuestas haciendo que los tiempos de repuesta fuera mucho menores.

También se puede utilizar una estrategia con la fecha del día, pero en vez de poner solamente el año, el mes y el día, se debería de utilizar el valor en ticks de la fecha, pero para asegurarte de que se hace una distribución sobre un 10% del total, se le da la vuelta al valor del string que representa los ticks, y se tendría algo como esto:

Valor en Ticks de la hora: 635767287458393685
Valor del revés:           586393854782767536
Valor en Ticks de la hora: 635767287468351710
Valor del revés:           017153864782767536

Se puede observar que la parte de la izquierda de los valores del revés, son los caracteres de la derecha de la fecha, que son los valores que más oportunidad tienen de cambiar conforme avanza el tiempo.

De esta manera se tiene una evolución de que todos los ficheros que se agreguen tendrán una distribución del 10% sobre los demás.

Conclusión

Elegir una buena estrategia de particionado lo es todo para conseguir el mejor resultado del servicio. Dependiendo del tipo de aplicación que se esté desarrollando eso puede ser crítico o no, así que merece la pena dedicarle un poco de tiempo para entender cómo afectará eso al servicio.

Luis Guerrero.

Technical Evangelist Microsoft Azure

@guerrerotook

http://azure.archive.ubuntu.com/ubuntu/ vivid-updates/main 

Esta url no es la estándar que se suele utilizar en la distribución de Ubuntu ya que la estándar es:

http://archive.ubuntu.com/ubuntu/ vivid-updates/main

Microsoft ha personalizado la imagen de Ubuntu para que se descargue las imágenes de ese servidor que tienen un tramo de Azure. Si se hace un petición con nslookup para esa dirección DNS.

C:\Users\>nslookup azure.archive.ubuntu.com

Server:
Address:

Non-authoritative answer:
    Name: ubu-n-eur.cloudapp.net
    Address: 168.63.58.192
    Aliases: azure.archive.ubuntu.com
             ubuntu-archive.trafficmanager.net

Al final de todo aparece que uno de los alias de esta dirección DNS es ubuntu-archive.trafficmanager.net esta dirección forma parte del servicio de Traffic Manager, que permite distribuir el trafico dependiendo de varias opciones.

http://azure.microsoft.com/en-us/services/traffic-manager/

Así la gente que utiliza las maquinas virutales de Ubuntu internamente en Azure, tienen en el datacenter local donde se conectan una copia de los archivos de Ubuntu, ahorrando tráfico de Internet y recursos.

Luis Guerrero.

Technical Evangelist Microsoft Azure.

@guerrerotook

Esto es lo que aparecen como descripción en el GitHub oficial de proyecto donde se puede encontrar el proyecto de código fuente. Pero Vorlon.js es mucho más y en este artículo se va a mostrar cómo empezar a trabajar y crear plugins para proyectos concretos.

Instalación

Vorlon.js es una librería disponible en npm (el gestor de paquetes de node.js) y como tal la forma de instalarse es a través de este gestor de paquetes.

$ npm i -g vorlon

Una vez que se ha instalado Vorlon.JS a nivel global el siguiente paso es ejecutarlo para poder acceder al dashboard de Vorlon.JS.

$ vorlon
The Vorlon server is running

Esta es una captura del dashboard de Volor.JS ejecutándose en local. Al estar basado en node.js y en socket.io se puede ejecutar en cualquier entorno independientemente del tipo de sistema operativo.

Depurando una aplicación web

El siguiente paso con Vorlon.JS ya que el dashboard se está ejecutando es depurar una aplicación web, para hacer eso Vorlon.JS utiliza socket.io para crear un canal persistente entre la aplicación web de destino y el servidor de Vorlon.JS.

Así que la manera para inyectar el código es añadiendo una referencia de la librería de Vorlon.JS en la web que se quiera depurar. En el contexto de esta demo que ese está haciendo, el servidor se está ejecutando en http://localhost:1337/ por lo que la librería está en

http://localhost:1337/vorlon.js

Esta es la dirección que se tiene que agregar en la aplicación web para empezar a depurarla. En este ejemplo voy a crear una nueva aplicación de ASP.NET MVC desde Visual Studio 2015 para hacer la prueba de cómo depurar una aplicación web.

Antes de continuar con la demo, comentar que al ser Vorlon.JS una aplicación hecha en node.js este servidor se puede ejecutar en cualquier máquina, local o incluso de nube. Por ejemplo, se puede tener desplegado en Azure utilizando una máquina virtual de Ubuntu, en la que se ejecuta el servidor. Así todo el equipo puede utilizar esa máquina para poder depurar.

Depurando la primera web

En este caso lo que hay que hacer es en el fichero del proyecto de ASP.NET localizado en Views/Shared/_Layout.cshtml es incluir esta referencia para que se pueda depurar esta aplicación en concreto.

<script type="text/javascript" 
src="http://vorlonjs-server.cloudapp.net/vorlon.js" >
</script>

A partir de ese instante en la consonla de Vorlon.JS aparecerá identificado el cliente y se podrán acceder a características concretas.

Características de Vorlon.JS

Estas son las características que Vorlon.JS ofrece actualmente:

DOM Explorer

Un explorador del árbol de objetos del navegador, permitiendo que se pueda mostrar todo los nodos que actualmente están en la aplicación, es decir, que si se produce un cambio en los nodos, se añaden o se modifican, esos cambios aparecerán en la consola igualmente.

Si se selecciona un elemento, se puede mostrar información sobre los pares de nombre valor de los estilos que se están aplicando actualmente.

Además, en el menú de la derecha se pueden añadir nuevas propiedades para en el caso de querer aplicar una nueva propiedad se puede hacer desde ahí, y ese cambio se aplicará directamente sobre ese elemento de la aplicación que se está depurando.

Cuando se selecciona un elemento del nodo en el dashboard de Vorlon.JS este elemento se destaca en la Web de origen para tener claro que se está seleccionando.

Modernizr

La siguiente pestaña se trata de Modernizr, una librería de JavaScript que permite comprobar características concretas que soporta el navegador. En vez que detectar si el navegador es Internet Explorer, Microsoft Edge, Google Chrome o Mozilla Firefox, lo que se hace es preguntar sobre una característica en concreto, como por ejemplo si soporta la etiqueta canvas de HTML5.

Pues bien, esta pestaña inyecta en la web, Modernirz con todas las opciones y analiza que características dispone en navegador donde se está ejecutando esta aplicación. Esto puede ser muy útil, si se está desarrollando aplicaciones web para dispositivos móviles y se desea saber las características del navegador donde se está ejecutando la aplicación.

Object Explorer

La ultima pestaña puede ser una de las más útiles de todo Vorlon.JS porque permite mostrar todos los objetos de JavaScript que se encuentra a nivel de window. Esto resulta tremendamente útil, si se está desarrollando una aplicación web en la que JavaScrip tiene una presencia muy fuerte y alguno de los objetos no se ha inicializado correctamente y se desea ver el estado. Por ejemplo, si está haciendo una operación y sé que quiere saber cuál es el estado del objeto una vez ejecutada esta operación, se puede utilizar la parte del filtrado para buscar ese objeto por el nombre y así ver el valor de los campos de ese objeto.

También permite saber que funciones tienen los objetos del navegador,

Por ejemplo, en esta captura de pantalla se está mostrando los métodos que contiene el objeto console disponible para Internet Explorer 11 en Windows 10, así los desarrolladores podrían saber que funciones dispone un navegador, de un dispositivo móvil.

Vorlon.js en dispositivos móviles

Como se ha comentado en varias ocasiones una de las cosas más interesantes de Vorlon.JS es poder utilizarlo para depurar aplicaciones web en dispositivos móviles, por eso se ha utilizado un Nokia Lumia 1520 ejecutando Windows 10 Mobile (Build 10080) con Project Spartan para mostrar como se puede depurar una aplicación web que está desplegada en Azure http://vorlonjsdemo.azurewebsites.net/

Esta imagen muestra el navegador, con la selección del detalle recuadrado en rojo donde se muestra lo que está ahora mismo seleccionado en el DOM Explorer de Vorlon.JS.

Vorlon.JS es un proyecto Open Source

Uno de los atractivos de Vorlon.JS, además de ser Open Source, es la posibilidad de crear plugins para extender la funcionalidad que se ofrece de base. De hecho está construido de tal manera que las tres características que se han visto en el artículo con plugins del cual se dispone el código fuente. http://www.vorlonjs.com/plugins/

Todo el código fuente de Vorlon.JS está hecho en TypeScript (http://www.typescriptlang.org/) lo que permite que para hacer un plugin utilizando orientación a objetos, en este ejemplo se ha creado una clase en TypeScript que hereda de Plugin, así se tiene un mecanismo consistente para poder crean plugins con un contrato de operaciones bien definido, que al final de todo generará JavaScript.

https://github.com/MicrosoftDX/Vorlonjs/blob/master/Plugins/Vorlon/plugins/objectExplorer/vorlon.objectExplorer.ts

Próximos pasos

Vista la flexibilidad y potencia que tiene Vorlon.JS empezar a utilizarlo es muy fácil y cómodo, se ejecuta en cualquier plataforma, se puede desplegar en cualquier Cloud (aunque en este articulo se haya mostrado Azure) y permite depurar cualquier dispositivo, aplicación y navegador.

Solamente existe algo parecido con el Remote Debuggin de Android en Google Chrome, pero solo funciona para el navegador de Chrome (no para el navegador del sistema de Android), y requiere tener Android 4.4+, si tienes iOS o Windows Phone no puedes depurar tus aplicaciones.

Si estás creando aplicaciones basadas en Cordova o PhoneGap definitivamente esta librería es un aliado para ti.

Luis Guerrero.

Technical Evangelist Microsoft Azure.

@guerrerotook

Lo más sencillo

La forma de empezar a bloquear código para asegurarse de que el código sólo es ejecutado por un único Thread es envolver ese código con la palabra reservada lock (en C#), un ejemplo de ese código se puede encontrar a continuación.

public class LockExample
{
    private object syncLock = new object();
    
    public void MethodWithLock()
    {
        lock(syncLock)
        {
            // código
        }
    }
}

De este tipo de bloqueo se pueden encontrar variantes, pero que en esencia son lo mismo. Utilizando el atributo MethodImpl con el valor de MehtodImplOptions.Synchronized se consigue el mismo resultado que es bloquear todo el cuerpo de la función utilizando la palabra reservada lock. La diferencia es que cuando el método es de instancia se utiliza el objeto this para señalar el bloqueo, mientras que cuando el método es estático se utiliza el typeof de la clase para hacer el bloqueo.

MethodImpl para métodos de instancia

Este código que utiliza MethodImpl,

[MethodImpl(MethodImplOptions.Synchronized)]
public void MethodWithLock()
{
}

Es exactamente igual a:

public void MethodWithLock()
{
    lock(this)
    {
    }
}

MethodImpl para método estáticos

Para los método estáticos utilizar MethodImpl

public class LockExample
{
    [MethodImpl(MethodImplOptions.Synchronized)]
    public static void MethodWithLock()
    {
    }
}

Es igual a escribir el siguiente código:

public class LockExample
{
    public static void MethodWithLock()
    {
        lock (typeof(LockExample))
        {
        }
    }
}

Como se ha comentado anteriormente este tipo de bloqueos no son recomendables en ningún caso, porque aumenta la granularidad del bloqueo y no se tiene un control sobre las operaciones de lectura o escritura de las variables que se desea acceder. Además, en caso de excepción no está claro si el bloqueo se libera o se queda para siempre.

Queda también comentar que en caso concreto del bloqueo para los métodos estáticos además se puede incurrir en un comportamiento muy peculiar del CLR que se llama Marshal-by-bleed.

Marshal-by-bleed

.NET Framwork soporta marshalling de objetos entre dominios de aplicación llamado marshal-by-bleed. Esto significa que cuando se tienen varios dominios de aplicación dentro del mismo proceso de .NET entre estos dominios de aplicación, si no se ha especificado de LoaderOptimization, los ensamblados firmados con un nombre fuerte (strong name) serán compartidos entre los dominios de aplicación. Pues bien, eso puede llevar a que la referencia en memoria de objetos estáticos referenciados desde un GCRoot pueda ser el mismo entre varios dominios de aplicación. En efecto prácticos, la llamada a typeof(String) puede ser la misma referencia entre dominios de aplicación. Sabiendo esto si el código de más arriba la clase que se utiliza como bloqueo en el atributo MethodImpl es una clase que forma parte de un ensamblado firmado con un nombre fuerte, el hecho de utilizar ese objeto puede hacer que el mismo código ejecutado en otro dominio de aplicación diferente (dentro del mismo proceso) bloquee el otro dominio de aplicación. Así de esta manera se están produciendo bloqueos a través de dominios de aplicación, una situación que es bastante complicada de detectar en aplicaciones en producción.

Para más información Unai Zorilla escribió un artículo en 2009 con un ejemplo sobre esto (http://geeks.ms/blogs/unai/archive/2009/02/08/marshall-by-bleed-explained.aspx) también Joe Duffy escribió sobre esto en 2006 (http://joeduffyblog.com/2006/08/21/dont-lock-on-marshalbybleed-objects/)

Mejorando el código concurrente

Como se ha visto en los anteriores ejemplos, este tipo de código no es la mejor solución para controlar el acceso a métodos o variables. Otra opción es utiliza la clase Monitor, que permite entre otras cosas poner un timeout para que en caso de que el bloqueo dure demasiado tiempo, tener un mecanismo para poder abortarlo.

Otra opción para aumentar la granularidad de los bloqueos es utilizar una clase que permita tener diferentes patrones de acceso a recursos compartidos. Uno de los más utilizados es un escritor varios lectores, que se basa en la idea de tener una único thread escribiendo un varios leyendo a la vez. Para hacer eso dentro de .NET Framework hay una clase llamada ReaderWriterLockSlim que permite justamente crear este patrón.

En el siguiente código se protege el acceso a una variable entera para que se pueda leer desde muchos threads pero sólo se pueda escribir desde uno.

public class MultipleReadsOneWriter
{
    private volatile int value;
    private ReaderWriterLockSlim rwls;
    
    public MultipleReadsOneWriter()
    {
        rwls = new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion);
    }
    
    public int ReadValue()
    {
        int result = default(int);
        rwls.EnterReadLock();
        try
        {
            result = value;
        }
        finally
        {
            rwls.ExitReadLock();
        }
        return result;
    }
    
    public void WriteValue(int number)
    {
        rwls.EnterWriteLock();
        try
        {
            value = number;
        }
        finally
        {
            rwls.ExitWriteLock();
        }
    }

    public void WriteValueIfEqual(int compare, int number)
    {
        rwls.EnterUpgradeableReadLock();
        try
        {
            int current = value;
            if (current == compare)
            {
                rwls.EnterWriteLock();
                try
                {
                    value = number;
                }
                finally
                {
                    rwls.ExitWriteLock();
                }
            }
        }
        finally
        {
            rwls.ExitUpgradeableReadLock();
        }
    }
}

Algunos detalles interesantes sobres este código. La clase ReaderWriterLockSlim tiene métodos para poder bloquear para sólo lectura, sólo escritura y también para una lectura que tiene posibilidad de actualizarse a una escritura. De esta manera se controla mucho mejor las lecturas y escritura de una variable.

Otro detalle interesante de código es que cualquier interacción sobre las llamadas de la clase ReaderWriterLockSlim está envuelta entre un try/finally que permite asegurarse que siempre se vaya a llamar a la funciona de salida de la operación actual. Esto es muy importante porque evita que se tengan bloqueos huérfanos que nunca se liberen.

Luis Guerrero.

Technical Evangelist Microsoft Azure.

@guerrerotook

Este mes de septiembre volvemos desde Microsoft España cargados de eventos de Azure, así que si quieres publicar tu web en Azure o aprender cómo se despliega una máquina virtual es tú momento:

• Madrid 9 de septiembre: Laboratorios técnicos de Azure https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592549&Culture=es-ES
• Barcelona 16 de septiembre: Azure Dev_Camp: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592609&Culture=es-ES
• Madrid 17 de septiembre: Azure Dev_Camp: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592607&Culture=es-ES
• Sevilla 23 de septiembre: Azure Dev_Camp: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592610&Culture=es-ES
• Valencia 25 de septiembre: Azure Dev_Camp: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592611&Culture=es-ES
• Madrid 29 de septiembre: Laboratorios técnicos de Azure: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592550&Culture=es-ES

Bonus Point!

Curso de Introducción al desarrollo de videojuegos con Unity3D en Barcelona el 18 de septiembre 15:00 a 20:00

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032592606&Culture=es-ES

Nos vemos en la nube!

Luis Guerrero.

@guerrerotook

• Gestión de artefactos de trabajo basados en una metodología ágil.
• Product Backlog ítems
• Work ítems
• User stories
• Bugs
• Features
• Impediment
• Un repositorio de código fuente basado en Git o en Team Foundation Control Servcice
• Un sistema de compilación de código fuente
• La capacidad de realizar integración continúa con tu plataforma de nube, como Microsoft Azure.
• Monitorización de tu aplicación por parte del servidor (.NET y Java) por parte de cliente con una analítica basada en Javascript.

Todo eso lo puedes tener con Visual Studio Online y en este webcast puedes echar un vistazo general a todas estas características.

Si estás interesado en más información no dudes en poner un comentario o ponerte en contacto directamente conmigo.

Saludos. Luis.