Entendiendo tu aplicación con Visual Studio Code Maps

Cuando requieres de entender las dependencias que tienen los proyectos de tu solución, ya sea entre ellos o con archivos externos, hacerlo por cada uno puede ser bastante engorroso.  Afortunadamente Visual Studio cuenta con una herramienta bastante interesante: Code Maps.

La primera opción que tenemos es ver el panorama general de la solución. Para ello hay que ir al Menú Architecture > Generate Code Map for Solution

Dependiendo del tamaño de la solución tardará más o menos, pero al finalizar deberás ver algo  como esto

Y listo, tenemos una representación visual de los proyectos y sus dependencias. Una de las cosas que más me gustaron es que el mapa incluye hasta los Solution Folders, que muchos usamos para organizar los proyectos, comúnmente en “capas”. Pero en este caso, no nos es de mucha utilidad tenerlo. Lo que vamos a hacer ahora es …. quitarlo. Para ello vamos a la parte derecha en la seccion Filters, y desactivamos la casilla de Solution Folder en la seccion de Code Elements. El resultado debe ser algo parecido a esto

 

Este ejemplo es de un proyecto demo de la implementación de IdentityServer4. Como se puede apreciar, los proyectos no tienen dependencia entre sí, solamente externas. Dependiendo de tu situación actual podrías tener algo como spaghetti (honestamente espero que no sea tu caso)

 

Otro de los atractivos (a mi parecer) de la heramienta es que te muestra el tipo de relación que hay entre los elementos. Para este otro proyecto podemos ver múltiples ejemplos

El código de colores y tipos de línea se encuentra al lado derecho, en el panel “Legend”. Si no esta visible puede mostrarse presionando el botón del mismo nombre en la parte superior del diagrama.

Relaciones

El diagrama actual muestra dos escenarios de relaciones, uno es entre mis “capas” (los Solution Folders) y el otro entre los elementos dentro de ellos. Curiosamente en este ejemplo, si observamos en la esquina inferior izquerda de Auth, encontramos un elemento tan antisocial como el autor, que parece no relacionarse con nadie. ¿Es realmente el caso? Si le damos clic a uno de los elementos del diagrama (en este caso, Hermes.Auth.B2C.dll), podemos notar que nos da la información de sus relaciones con el resto del mundo binario.

Dependencias externas

Adicional a las relaciones, tenemos la opción de ver las dependencias externas.  Siguiendo el ejemplo anterior, al dar click en el elemento Externals, se muestran las lineas de las relaciones específicas que cada proyecto tiene. Pero ¿y si quiero saber cuáles son? En este caso, al acercar el cursor a Externals, aparece una pequeña flecha del lado superior izquierdo. Si la presionas, podrás ver la lista completa de referencias de la solución

Ahora bien, el punto de más utilidad es el siguiente: aquí podemos darnos cuenta, entre otras cosas si en la solución estamos utilizando dos versiones diferentes de un mismo ensamblado, como en este caso:

 

Esto es obviamente posible gracias a la magia negra del GAC, pero no necesariamente quiere decir que sea lo que yo quiero ni la mejor opción. Al poner el cursor sobre el nombre del ensamblado, puedo darme cuenta que estoy usando Microsoft.Owin version 3.1.0 y versión 3.0.1. Puede parecer algo sin importancia, pero cuando salen los errores es uno de los detalles que nos pueden causar más dolores de cabeza.

Y como ya vimos anteriormente, dar clic al elemento nos muestra que proyecto está usando cada dll.

 

Moraleja

Esta herramienta está disponible desde Visual Studio 2015 (los ejemplos aquí son con 2017), en las versiones Pro y Enterprise. Y como moraleja de esta historia tenemos “No confíes en las versiones que los paquetes de nuget descargan”.

 

 

Hacer copy-paste es maligno

Hace poco, hablando con algunos de los desarrolladores de un equipo al que me tocó apoyar por un tiempo, le decía qué hacer copy-paste al momento de estar desarrollando era “del diablo”.

Estuvimos discutiendo un rato al respecto, y me preguntaban si yo nunca lo hacía: mi respuesta fue que la mayoría de las veces no, y las razones son las siguientes:

Estimaciones: La precisión construye credibilidad

Cuando hablamos del desarrollo de software, una de las cosas que al parecer resultan más complicadas es estimar el esfuerzo y tiempo que una tarea va a tardar en completarse, no se diga un proyecto completo. La ambigüedad de los requerimientos iniciales, la experiencia de los involucrados, las herramientas potenciales y la curva de aprendizaje son siempre factores que hacen que los números varíen de persona a persona.

Adicionalmente al momento de discutirlo con otras personas, muchas veces alguna de las partes involucradas caemos en la maldición del conocimiento (no recordar lo que implica desconocer un tema en el que tenemos ya algo de experiencia) lo cual conlleva el desestimar o no comprender las razones para la diferencia de estimación contra las expectativas.

¿Cuántos nueves? Entendiendo el concepto de disponibilidad

Es muy probable que hayas experimentado un sistema caído, ya sea una aplicación en la que has trabajado o algún servicio que consumes. Le ha pasado a Amazon, Netflix, Microsoft, Salesforce, etc. ¿Cuánto tuviste que esperar? o ¿cuánto tus usuarios?

Si al estar construyendo una aplicación le preguntas a tu jefe (o cliente) qué porcentaje de tiempo la aplicación debe estar disponible, lo más seguro es que recibas respuestas como “siempre” o “100% (o más)”.

Aunque no queremos que pasen cosas malas, pasarán: bugs, ataques, fallas de corriente, desastres naturales, etc., son escenarios que pueden afectar un sistema. Esperar que no pases es ingenuo; es mejor pensar en y planear para los fallos, ya que son inevitables.

Disponibilidad (availability) es la capacidad de una aplicación de estar disponible después y a pesar de que un problema ocurre. Repito, no estamos diciendo que no habrá problemas, sino que tan efectivamente podrá recuperarse. Esto significa que tenemos que a) identificar los puntos de falla potenciales y b) crear una estrategia para prevenir que el error se convierta en una falla afectando al usuario (un árbol que cae en el bosque cuando no hay nadie, no hace ruido).

Define primero el tamaño del monstruo

Muchas veces he escuchado a clientes o compañeros desarrolladores decir “Vamos a usar x framework” o “necesitamos x tecnología para el proyecto. El problema es que la mayoría de las veces no existe un análisis previo de la decisión propuesta. Es sólo porque algo está de moda (o es cool) y ya. Como uno de mis anteriores managers decía frecuentemente “Hype and buzzwords are dangerous friends”.

La pregunta principal que debemos hacer es “¿Cuál es el problema que estoy tratando de resolver?”. Es sorprendente la frecuencia en que proponemos soluciones para problemas que apenas conocemos. Estamos ansiosos de brincar a la pelea sin conocer de antemano el tamaño del oponente. ¿Que tal que es un mounstro en lugar de la cosita que habíamos pensado? ¿O lo contrario?

Creando un servicio WCF para Azure Service Fabric (II)

Este post es parte de una serie acerca Service Fabric.

  1. Introducción a Service Fabric
  2. Creando un servicio WCF para Azure Service Fabric

Escribí un artículo para DotNetCurry acerca de WCF y Service Fabric. Pueden encontrarlo aquí.

Introducción a Service Fabric (I)

Este post es parte de una serie acerca Service Fabric.

  1. Introducción a Service Fabric
  2. Creando un servicio WCF para Azure Service Fabric

En el principio (en un tiempo no muy lejano) fue el servidor local y la vida del desarrollador era un caos. El equipo de IT (si no había uno, entonces el desarrollador) era responsable de que el servidor en donde se montaba una aplicación estuviera funcionando como debía. Era su culpa si esto no pasaba.

Después, con el aprovechamiento de la virtualización vino la nube y trajo, entre sus ventajas más notorias, el darnos la oportunidad de culpar transferir la responsabilidad a alguien más

 

¿Qué tiene que ver todo esto con este post? Microsoft Azure Service Fabric es una opción de Platform as a Service construida desde cero para soportar aplicaciones en la nube distribuidas, a gran escala y con alta disponibilidad. Inició como una propuesta para bases de datos en la nube (CloudDB) y actualmente es usada en productos estrella de Microsoft como Cortana, Skype for Business, Power BI, SQL Azure, etc.

Sus principales venajas estan en la facilidad que da a los desarrolladores en manejar elementos que van más allá de la funcionalidad como

  • Actualizaciones escalonadas
  • Log
  • Monitoreo y telemetría de los servicios
  • Manejo de fallas
  • Seguridad

De este modo el desarrollador puede enfocar sus esfuerzos y atencion en el código.

 

Microservicios

Aunque es normalmente asociado con microservicios, las ventajas de Service Fabric pueden aprovecharse en aplicaciones multi-capa, APIs, etc. Pero, ¿qué es son los microservicios?.  Aunque no hay una definición estándar, normalmente se caracterizan por separar la funcionalidad de una aplicación en partes más pequeñas. Estas partes son versionadas de manera independiente, pueden ser de cualquier tecnología, escalables y orientados resolver una parte concreta del problema que se está atacando. Es importante dejar claro que monolítico no es malo ni microservicios bueno. Todo depende del escenario y contexto.

Al ser distribuidos de manera independiente en nodos (contenedores, servidores, máquinas virtuales) diferentes agrupados dentro de un cluster en donde se lleva a cabo el proceso de réplica y partición, cada microservicio puede escalarse según sus necesidades propias.

 

Cluster

Service Fabric puede correr del mismo modo en Microsoft Azure, otras nubes como AWS e incluso en nubes privadas, ya sea en Linux o Windows. Incluso al momento del desarrollo, los componentes utilizados son iguales, lo que facilita el moverse de un entorno a otro cuando sea necesario. Esto es debido a que los componentes estan pensados para ser estandres y no es necesario realizar modificaciones de acuerdo al ambiente en donde se ejecute. El cluster provee un nivel de abstracción entre la aplicación y la infraestructura en que se ejecuten.; es un conjunto de nodos con los componentes instalados y configurados para comunicarse entre sí. Las principales características del cluster son

  • Puede soportar miles de nodos
  • Puede cambiarse dinámicamente
  • Es una unidad de aislamiento

 

Servicios

Service fabric provee un conjunto de servicios para facilitar la administración:

Cluster manager

Encargado de las operaciones referentes al cluster. Por default puede manejarse por medio de REST usando el puerto 19800 en HTTP y con TCP por el puerto 19000 usando Powershell.

Failover manager

Encargado de detectar cuando nuevos nodos se agregan al cluster, cuando se quitan, o cuando alguno falla y rebalancear para asegurar alta disponibilidad de los servicios.

Naming

Mapea los servicios con los endpoints, de manera que puedan comunicarse entre si.

Fault Analysis

Ayuda a introducir fallas a los servicios de manera que puedan probarse escenarios distintos de manera controlada.

Image Store

Contiene los bits de los servicios, el master del cual se hacen las copias que se replican en los nodos.

Upgrade

A cargo de actualizar los componentes de Service Fabric, exclusivamente en Azure.

 

Programming models

Cuando se trabaja con Service Fabric, se tienen 3 opciones para crear los servicios

Reliable services

Provee una manera simple de integrarse con Service Fabric cuando se crean los servicios, beneficiandose de las herramientas de plataforma.

Reliable actors

Construido sobre Reliable Services, es un framework que trabaja con unidades single-threaded llamadas Actors, basadas en el patrón de diseño con el mismo nombre.

Guest executable

Es sólo eso, un ejecutable que puede publicarse en un cluster sin integrarse completamente con la plataforma; Service Fabric sólo se asegura de que se encuentre corriendo. No importa el lenguaje, por lo que es una buena opción para llevar aplicaciones existentes.

Aplicaciones y servicios

Una aplicación es básicamente un conjunto de servicios, los cuales se definen en el archivo ApplicationManifest.xml; en términos de Service Fabric, a esto se le se denomina Application Type. De él creamos una instancia denominada Application Instance, que es la que contactamos en tiempo de ejecución, muy similar al concepto de clase e instancia en programación orientada a objetos. Del mismo modo pasa con Service Type y Service instance, además de que se compone de 3 partes: código, datos y configuración.

Cada uno de estos elementos tiene su propia versión, es decir puedo tener la versión 2.1.1 de mi Aplicación que se compone de 1 servicio con versión 1.0.0.

 


Con esto termina la introduccion; estos son los conceptos básicos de Service Fabric en los que nos basaremos para los siguientes tutoriales.

App de galleta de la suerte creada con Azure Functions usando Twilio y Sendgrid outputs

Una de las ventajas más grandes de trabajar con Azure Functions es poder hacer fácilmente prototipos de aplicaciones. Para este post voy a crear una aplicación de Galleta de la suerte bastante simple, que enviará una frase por email usando Sendgrid y por SMS usando Twilio. La app se compone de tres piezas

  • Página de Front-end usando HttpTrigger
  • Request POST procesado con HttpTrigger
  • Queue procesado usando el Trigger de Azure Queue Storage