Novedades en VSTS!! …. que impactan a nuestros proyectos Docker

Pues si, retomando los contenidos técnicos y en este caso haciendo seguimiento a las novedades del ultimo Connect, nos topamos con estas (entre otras) que afectan a nuestra herramienta favorita (claro que estoy hablando de Visual Studio Team Services, VSTS):

  • Versionado de tareas (Build Task), esto esta interesante, ahora podremos “congelar” la versión de las tareas a fin de no ser afectados por los cambios que Microsoft haga sobre nuestras dependencias en VSTS, estando en nuestras manos el luego actualizar a la versión mas actual.
  • Crear Builds y Release desde Azure (Portal), algo para simplificar las tareas DevOps , si has visto los articulos publicados veras que tradicionalmente hemos creado nuestras Web Apps desde el portal Azure para luego ir a VSTS a fin de enlazarlo y definir nuestro flujo de Construcción y Despliegue, ahora lo que se nos ofrece es empezar a construir nuestro flujo desde el entorno del Portal de Azure, siendo que luego también estará definido en VSTS, sera motivo de darle un vistazo.
  • Agentes en Linux (Preview), este si es el bombazo, pues tradicionalmente los agentes de compilación que VSTS instancia cada vez que lanzamos un proceso de Integración Continua son Maquinas Virtuales Windows, ahora tenemos la posibilidad de que estos agentes sean generados de manera “elastica” ya sea en Windows o en Linux según el requerimiento de nuestro proceso de Build o de Release, lo cual cambiara radicalmente nuestra forma de trabajo con Docker y otras tecnologías como explicare a continuación.

Como sabrán hace unos meses empece a hacer mis experimentos de despliegue de una aplicación .Net (Core) dentro de Docker, lo cual pude realizar satisfactoriamente luego de mucho esfuerzo, que me llevo a establecer los siguientes pasos: Finish Reading: Novedades en VSTS!! …. que impactan a nuestros proyectos Docker

DevOps: ¿el proceso o la sinergia como objetivo?

Hace un tiempo que vengo metido en el tema de la filosofía DevOps, y es inevitable toparme con concepciones erróneas al respecto:

  • Perfil DevOps = IT Pro con nuevos skills
  • Objetivo DevOps = Automatización y Despliegue continuo
  • DevOps = Agilismo para IT Pros

Esto me quedo en evidencia cuando en una charla, a la que asistí hace pocas semanas, el orador compartió su experiencia en una gran implementación DevOps, donde si bien incluyo en la charla el tema de los conflictos usuales entre Dev y Ops(*), a la hora de aterrizar el tema no hizo el énfasis de que DevOps es búsqueda de sinergias, o sea… personas sobre procesos, eso si, explico un buen pipeline de Entrega Continua y lo que habían conseguido, pero me quede con el regusto de que fue algo como top down (una decisión enteramente planificada desde gerencia) y no partir de mejorar las formas de trabajar.

Este hecho me hizo recordar los tiempos en cuando preparaba mi sesión “El reto del DevOps ágil“, donde a pesar del titulo dejaba abierta la pregunta sobre si DevOps era algo que iba mas allá del agilismo, y no lo pude ver claramente, lo reconozco, pero si partimos del hecho de que DevOps debe entenderse como una conversación de tres etapas en la que las personas se ponen de acuerdo sobre los procesos para finalmente decidir sobre las herramientas a usar, queda claro que el Manifiesto ágil en su principio de “Individuos e interacciones sobre procesos y herramientas” cobra mas fuerza que nunca.

Entonces no es que no haya una definición en si de DevOps, sino que probablemente no te sientas cómodo con el paquete completo o no entendiste The Phoenix Project, así que antes de aceptar algunas definiciones pase un buen tiempo, quedándome con estas:

  • “DevOps es la búsqueda de la sinergia derivada de Desarrolladores trabajando con IT Pros y demás personal de Operaciones”
    Andrew Binstock (Dr. Dobb’s)
  • “Unión de personas, procesos, y productos que facilitan la entrega continua de valor a nuestros usuarios finales”
    Donovan Brown (Microsoft)

devopshumano
Así pues regresamos a la casilla de arranque, debiéndonos quedar claro el punto de partida de toda transformación DevOps debe partir por las personas, el buscar una sinergia tal vez inexistente de momento, pero imprescindible para el logro de los objetivos de la organización, con este punto de partida los procesos para entregar valor llegaran a su debido momento… pero claro, a veces estamos acostumbrados a empezar la casa por el tejado.

Update (14/11/2016)

Justo hoy recibí una publicidad para un curso de Implementación DevOps, el temario es el siguiente:

  1. Control de Código Orientado a DevOps
  2. Integración Continua en la Nube
  3. Infraestructura como Código
  4. Soluciones de Entrega Continua
  5. Monitoreo y Supervisión
  6. Contenerización de Aplicaciones
  7. Pruebas de IU Automatizadas

Como se puede ver, enfoque técnico casi al 100%, pero de integración de equipos, búsqueda de objetivos y generación de sinergias.. mas bien poco… o por lo menos una introducción a la problemática que deriva en la necesidad de DevOps… pero no.

(*) Gracias a la traducción de unas laminas que hice de Microsoft Virtual Academy.

¿Por qué debemos generar contenido técnico en español?

Desde hace un tiempo he visto algunas opiniones de informáticos peruanos motivadas en generar contenidos técnicos en… ingles, las razones son varias: hay un publico objetivo mayor, potencialidad de clientes, uno debe esforzarse en aprender la lingua franca, etc… el caso extremo fue el de un programador peruano que en un foro peruano contestaba las preguntas hechas en español… en ingles, según él para motivar a los demás a comunicarse en ingles… en fin (*).

whyLas razones esgrimidas son validas, pero considero que no cubren todos los aspectos a considerar si queremos efectivamente lograr evangelizar y mejorar el ecosistema de nuestros países, esto lo digo porque muchas veces al irnos en una narración en ingles, nuestro contenido puede ser correcto, pero… frio, carente de los matices que pueden hacer atractivo (aparte de necesario) un texto técnico, miren este ejemplo peninsular que me encanta, ¿se dan cuenta? un texto muy muy técnico pero con comentarios coloquiales, dosis de suspenso, y lo mejor no acaba en el post, los comentarios van en esa onda, y es a esa clase de nivel al que debemos aspirar en Latinoamérica, diálogos profundos sin sacrificar la riqueza de nuestro lenguaje, logrando esa proximidad que pueda permitir que alguien se interese en nuestra experiencia al lidiar con la tecnología.

Y si, el ingles es muy necesario (y si vas a publicar un “paper” no te queda otra) y a ciertos contenidos solo podemos acceder en ingles, pero mientras vamos en el camino de aprenderlo, no podemos dejar atrás a quienes tienen potencial informático a la espera de que puedan leer mejor un texto ingles, así que si estamos en la voluntad de compartir lo aprendido o experimentado debemos considerar cual es la manera en la que logramos mayor impacto en nuestro entorno, si como influenciadores logramos motivar a introducirse en las nuevas tendencias de manera profunda, directa, y sobre todo, estableciendo conexión mediante nuestro estilo, habremos ayudado bastante a mejorar la escena local.

(*) Ya el caso extremo es cuando para “reírse” en un texto usen “ha ha ha” en lugar de “ja ja ja” o similares…

Tip: Asignando Nombre DNS a nuestras MV en Azure

Una cosa a la que estábamos acostumbrados desde las primeras versiones de IaaS en Azure, era que en cuanto provisionábamos una MV se nos asignaba inmediatamente un nombre DNS por defecto …. Azure.  Por lo que era sencillo luego apagar la máquina y volver a acceder a ella basándonos en el nombre, esto cambio ligeramente con la introducción de los Resource Groups, siendo que si uno crea una MV usando esta “nueva” modalidad, por mas que uno haya definido un nombre para nuestra MV dicho nombre solo sirve como identificador del servicio dentro de Azure, mas no como parte del alias DNS, por lo que al crear nuestra flamante máquina virtual solo obtenemos la IP respectiva, la cual se perderá si apagamos la máquina y luego la reiniciamos.

Originalmente esto se podía solventar con un script de Resource Manager, pero también hay una forma visual muy sencilla de hacerlo, y para demostrarlo lo haremos desde el principio con una nueva MV de Windows Server 2012, así:

clipboard03

Finish Reading: Tip: Asignando Nombre DNS a nuestras MV en Azure

¡Regresando! Con Docker y algunos tips (1)

Bueno, sí que he estado ausente, pero ha sido por buenas razones, en este lapso me he puesto a experimentar con las versiones finales de .Net Core, la cual ha tenido ciertos cambios con respecto a lo que vimos hace un tiempo, pero lo más importante es que pude participar en el último Docker Con Recap, gracias a la gentil invitación de los amigos de Docker Lima, y como no podía ser de otra manera pude exponer sobre Despliegue de Aplicaciones .Net Core con Docker.

img_2332

Lo interesante de la experiencia fue todo el proceso de ir recopilando información, probar lo que funcionaba y lo que no, en algunos momentos parecía muy difícil, pero felizmente todo salió bien, la demo funciono, así que de lo que se trata ahora es compartir esta experiencia para que podamos replicarla con nuestros proyectos .net Core, así que de eso hablaremos en las próximas entregas, pero antes cubriremos algunos tips que serán de suma utilidad para el trabajo futuro.

Un ajuste final para Docker para Windows

Docker, si… ya hemos hablado de ello, la posibilidad de generar contenedores que fácilmente sean ejecutables en cualquier anfitrión, no pienso dar la enésima explicación al respecto pero si recapitular lo que nosotros como desarrolladores de Windows hemos visto todo este proceso para terminar con un tip imprescindible para nuestro trabajo.

Si pues cuando nos aproximamos a Docker, ya sabíamos que los contenedores solo corrían en máquinas Linux (Windows está próximo a implementar el modelo, pero esa es otra historia) así que parecía lógico que para poder correr Docker en nuestros equipos se haría necesario instalar una Máquina Virtual Linux, el problema es que el año pasado instalar Docker para Windows implicaba si o si utilizar VirtualBox como gestor de virtualización, por lo que si ya uno tenía ciertas máquinas virtuales creadas usando Hyper-V habría que aparcarlas y no usarlas, pues como es sabido un SO Windows solo permite UN hipervisor, así que pues temporalmente desactive mi Hyper-V (en Windows 8, entonces), reactive una antigua instalación de VirtualBox e instale la versión de Docker para Windows respectiva, en corto… no funciono bien, el uso del famoso boot2docker no era nada sencillo, aparte de lento, así que deje suspendido el tema por un tiempo no sin antes haberme configurado una MV en Azure realizando satisfactoriamente un despliegue de .Net Core sobre Docker… pero ya volveremos sobre eso en otra ocasión.

El caso es que casi en paralelo con mi invitación a participar en el Docker Con Recap, leí que la nueva versión de Docker para Windows había dejado de estar en beta, permitiendo que ahora el sistema se valga del hipervisor nativo del SO o sea Hyper-V, así que lo probé y… totalmente sencillo, el instalador creo transparentemente una MV en mi Hyper-V y seguidamente pude usar la consola de Powershell para poder empezar a ejecutar comandos, siendo que ahí me tope con un pequeño problema que es la razón de este post, cuando quise ejecutar (run) algún contenedor de los libremente disponibles obtuve un error indicando que no podía conectarse, investigando pude darme cuenta que solo tenía que indicarle a Docker para Windows que haga uso de un DNS explícito, así:

clipboard01

Nada complicado, por algún momento pensé que tenía que configurar las conexiones de red vinculadas a la máquina virtual “mini…” pero no.. solo era eso, así que nada, ya puedo ejecutar el “hola mundo” y algunas cositas más con una sencillez y transparencia que no fue posible en las épocas de boot2docker.
clipboard02

Con esto el camino empieza…

Y ahora verificando la performance (II)

Ok, esta vez si me he demorado en la segunda parte de esta serie sobre como agregar pruebas de performance a nuestros procesos de despliegue, en nuestro articulo anterior vimos como agregar configurar una prueba de carga sencilla, básicamente registrábamos una URL, el volumen de la prueba y listo… ya podíamos hacer una prueba preliminar que nos podría ser muy útil en algunos casos (como cuando todos los parámetros de una búsqueda están en el QueryString, por ejemplo), pero si queremos mayor granularidad en los parámetros de la prueba la alternativa es usar los Web Performance and Load Test Project que han ido evolucionando y que mediante el uso de Azure nos permiten desde Visual Studio tener unos resultados de prueba muy configurables, así:

Clipboard26

Y eso esta genial, pues nos permite (mediante nuestra cuenta de VSTS) provisionar recursos Azure que hagan la respectiva prueba mientras sea necesario, y que podamos ver dichos resultados desde nuestro Visual Studio, pero… ¿que tal si queremos que esta validación de carga decida si un despliegue ha ido bien o no? Pues eso es lo que trataremos de conseguir en este post.

En concreto lo que haremos sera agregar un proyecto de carga a nuestra solución, incluirla en el repositorio y de esta manera valernos de sus archivos para incluir un nuevo tipo de tarea durante nuestro proceso de despliegue, asumiremos que estamos trabajando con una solución Web que ya tiene configurado su repositorio asi como sus procesos de Build y Despliegue como hemos visto en anteriores artículos, ¿ok? Finish Reading: Y ahora verificando la performance (II)

Los dilemas de la Gestión de la Configuración en Entornos de despliegue

Si, se que les debo el como configurar la prueba de performance avanzada, pero en el interin quiero compartir unas reflexiones a propósito de la gestión de la configuración que vino a mi mente durante el DevDays.

Quienes han ido a mis diversas sesiones sobre VSTS o DevOps, sabrán que siempre hago referencia al lio que nos significa el gestionar los parámetros de configuración conforme una aplicación pasa de un entorno, el como manualmente uno tenia que tener mucho cuidado para asegurarse que la aplicación en Producción no apunte a la BD incorrecta, por mencionar el ejemplo mas claro.

Al empezar usar técnicas de Integración y Entrega Continua el primer enfoque que utilice para aliviar estos problemas fue el basarme en las Transformaciones, de esta manera se gestionaba un Web.Config “maestro” (en el caso de Java y Maven el escenario es muy similar solo que en este caso se trata de “pom”s”), que podía ser usado sin problemas en los equipos de desarrollo, pero al momento de efectuar la construcción de una nueva versión el compilador modificaba el Web.Config reemplazando porciones de este con contenidos especialmente definidos en archivos “delta” que contenían las variantes de cada destino al cual se iba a destinar la versión respectiva, en consecuencia ocurrían los siguientes hechos:

  • Se requiere hacer una Build Definition por cada potencial entorno al cual se iba destinar la aplicación, para de esta manera indicar que la construcción cogiera el “delta” correcto.
  • Si una versión puesta en un entorno es aprobada para ser “promovida” a un entorno superior, es necesario que dicha versión haya sido etiquetada o identificada adecuadamente a fin de poder recuperar el código fuente vigente entonces a fin de generar un paquete para el destino indicado.
  • Todos los “deltas” tienen que estar versionados en el código fuente, lo cual puede ser un problema si se desea mantener reserva sobre las cadenas de conexión a los entornos de Producción.

Aun así esto significa un gran avance con respecto a la gestión usual de editar y copiar a mano los archivos de configuración, donde revisas varias veces para ver que todo esta Ok. Otra opción, que no me gusta, es el de gestionar un repositorio (a veces separado del de código fuente) con todos los archivos de configuración de las diversas aplicaciones y que el proceso de despliegue simplemente copie el archivo respectivo en destino, y en algunos casos efectuar las mezclas necesarias de archivos.

La nube viene a significar una mejora en estos problemas, como vimos anteriormente  es muy sencillo configurar para que sea el Entorno (en este caso un Azure Web App, aunque AWS ofrece algo similar en su Elastic Beanstalk) sea quien almacene los mencionados parametros, y mas aun… gestionar ranuras de despliegue que permitan mover de manera sencilla el paquete de un lado a otro (en realidad mediante un cambio de DNS), conservando cada entorno su propio conjunto de parametros, sin que estos tengan que almacenarse en el código fuente.

Muy bien, parte de los problemas simplificados, uno solo creaba una Build Definition con paso de despliegue a un entorno y luego mediante la consola del entorno se encargaba de hacer los respectivos swaps o intercambios de contenidos, pero eso nos dejaba con los siguientes hechos:

  • Se salia fuera del ciclo automatizado de Integración y Entrega Continua para hacer el movimiento entre entornos.
  • Solo funciona en un entorno PaaS, si se trabaja con IaaS u On Premise, esta ventaja esta totalmente fuera de nuestro alcance.
  • Si se trabaja con AWS, hay que tener cuidado con no publicar valores en los archivos de configuración, pues (a diferencia de Azure) las variables definidas en el entorno solo funcionan si NO están definidas en los archivos de configuración, siendo que lo que este en los archivos tiene prioridad sobre el entorno.

El escenario ha mejorado bastante con la introducción de Release Management, que permite manejar el proceso de Build de una manera separada del de Despliegue, para que de esta manera uno genere un paquete, lo despliegue (cogiéndolo de un punto de contacto común), y si luego se aprueba su paso a otro entorno (mediante el flujo de aprobadores que ya hemos visto) el sistema efectuara la copia respectiva del paquete, y claro si seguimos trabajando aprovechando las ventajas de la gestión de parametros en el entorno… pues ya tenemos casi todo solucionado, solo que entre otras cosas… esto sigue siendo valido solo para PaaS.

En el ultimo DevDays tuve la ocasión de conversar con el gran Donovan Brown, el cual me ayudo con unos detalles de Release Management que no había configurado del todo bien, y en adición a ello le resumí brevemente sobre el enfoque de uso de Azure Web Apps para guardar parametros, y me dijo que es una buena opción para soluciones no complejas, pues solo podemos guardar AppSettings y Cadenas de Conexión, siendo que si requerimos grabar una entrada compleja (como la configuración de Redis) esto solo podríamos hacerlo mediante archivos de configuración, y como de nuevo esto nos regresa al tema de las transformaciones y las build independientes, me sugirió revisar el concepto de tokenización.

Investigando, pude entender (gracias a este interesante articulo) que mediante la tokenización lo que se pretende es que se despliegue un archivo de configuración con marcas (tokens) que luego en el proceso de despliegue (no en la compilación, ojo) sean sobreescritas por parámetros definidas en la Release Definition, resultando en que el web.config (por ejemplo) que llega al entorno destino ya tiene todos los valores correctos para dicho entorno, siendo que estos valores ya no son gestionados por el repositorio de código fuente, sino por el motor de Entrega Continua (en nuestro caso VSTS, pero el concepto es aplicable a otros motores), esta tendencia recién esta avanzando pero se simplifica mucho ahora que es posible definir tareas personalizadas a nuestro VSTS (y me imagino que ya habrá algún plugin Jenkins que logre el mismo efecto), ya que de momento no vienen de serie… pero eso no quita que en un futuro el proceso de tokenización venga de serie, de momento… tocara toquetear un poco… en el caso de ser necesario (cuando no se este usando PaaS y/o necesitemos gestionar valores complejos).

Asi pues, siempre hay formas de mejorar y afinar la solución para casos no cubiertos plenamente ¿qué otras opciones se les ocurren para estos dilemas?

 

Y ahora verificando la performance (I)

Varias cosas han pasado desde que empezamos a probar en nuevo modelo de Builds en VSTS, primero creamos una build sencilla que desplegaba a una Azure Web App, luego probamos como usar los Resource Groups para desplegar entornos, luego retiramos el paso de despliegue de la Build para trasladarlo a Release Management luego de su integración con VSTS, y hace poco agregamos Sonar como parte del proceso de análisis de nuestro código dentro de la compilación.

Y como el ciclo de evolución del proceso DevOps nunca para, en esta ocasión veremos como hacer algo a lo que le he tenido bastante respeto desde la época de las builds con el modelo XAML, en este caso la evaluación de la performance y estabilidad de nuestras aplicaciones web desplegadas.

En corto, la posibilidad de probar nuestras aplicaciones Web precede aun a .Net, recuerdo cuando probé Web Application Stress Tool (Homer) para hacer unas pruebas sencillas sobre ASP Clásico, de ahí le perdí el rastro pero la cosa se puso interesante desde Visual Studio 2013 se permite que los tests de carga se basen en las capacidades de la nube, lo cual significa que durante nuestras pruebas se provisionaran las maquinas virtuales que hagan falta para cubrir la cantidad usuarios y peticiones deseadas, esto ya lo había probado desde Visual Studio (revisar aquí y aquí), con buen resultado, pero… ¿como hacer que estas pruebas se ejecuten cuando se produzca cierto tipo de despliegue?

Antes de proseguir hay algunas consideraciones a tener en cuenta:

Los recursos que Azure provisiona para efectuar estas pruebas tienen un costo (si se va por encima de los minutos de carga incluidos con nuestra suscripción de VSTS) por lo que hay que tener cuidado de no lanzar estas pruebas por cada commit que los desarrolladores efectúen, así que la sugerencia general seria tener un sitio de DEV donde se despliegue continuamente pero sin efectuar las pruebas de cargar, luego definiríamos un sitio QA (por ejemplo) al cual se desplegara ya sea de manera manual o de manera programada el contenido existente en DEV (con Release Management lo que se despliega son paquetes que no necesariamente son recién compilados) y al efectuar ese despliegue se lanzaran las pruebas de carga, las cuales si son exitosas indicar que en el proceso de despliegue esta listo para ser sometido a aprobación (si lo hemos definido así) para decidir su pase a otro entorno.

Con estas consideraciones en mente procederemos con nuestra primera prueba para lo cual no sera necesario usar Visual Studio simplemente agregar un paso adicional a nuestro proceso de despliegue, esto es porque a veces lo que nos interesa es simplemente ver que tan bien resiste una URL en concreto a cierta petición.

Para esto vamos a la pestaña de Release de nuestra instalación de VSTS, elegimos nuestro plan actual, seleccionamos el “entorno lógico” sobre el cual agregaremos nuestra prueba de carga y agregamos el Step de Cloud-based Web Performance Test, así:

Clipboard01

Clipboard02

Ok, ahora toca parametrizar el paso para lo cual dejaremos los parámetros mas o menos así, en breve explicare el significado de cada parámetro:

Clipboard06

Antes de proseguir prestemos atención al parámetro Registered connection, lo que ocurre es que cada prueba de carga se hace con cargo a los recursos y facturación de una cuenta de VSTS y podría darse el caso de que la organización tenga mas de una instancia de VSTS, así que corresponde indicar explícitamente dicha cuenta, así que hagamos clic sobre el enlace que dice Manage, que nos abrirá una nueva pestaña en el navegador para agregar un Endpoint (como ya hicimos anteriormente para enlazar Sonar y la cuenta de Azure), y en este caso elegiremos Generic, así:

Clipboard04Y llenamos los parametros de configuración de nuestra instancia de VSTS, pero ojo, al hacerlo deberemos utilizar los datos de nuestra conexión alterna a VSTS, algo de lo que hablamos hace tiempo cuando empezamos a trastear con Git.

Clipboard05

Listo, ya hemos enlazado nuestra prueba de carga a nuestra cuenta de VSTS,  personalmente yo agregaria un checkbox que permita usar la instancia actual y no hacer nada mas, pero siempre es bueno tener una conexión alterna a VSTS especialmente de cara a la integración con herramientas de terceros en Git.

Ok, antes de grabar repasemos los parámetros que estamos configurando:

  • Registered connection: como lo vimos, la instancia de VSTS sobre la cual se hara la facturación de esta prueba de carga.
  • Website Url: La dirección que vamos a probar, en este caso estoy probando la raiz del site (o mejor dicho del slot) en que acabo de hacer el despliegue, cabe indicar que tranquilamente podria haber colocado cualquier URL interna de nuestro site, o peor aun, una URL totalmente externa no manejada por nosotros, pero eso no queremos ¿verdad?
  • Test Name: El nombre con el que identificaremos a esta prueba.
  • User Load: La cantidad de usuarios supuestos que se estarán conectando a nuestra URL.
  • Run Duration (sec): El tiempo de duración de la prueba.
  • Load Location: La zona geográfica de Azure desde donde se hará la prueba, es muy interesante y conveniente hacer la prueba desde una zona que no sea la que aloja a nuestro site, en mi caso la URL esta alojada en East-2, así que la prueba la estoy lanzando desde West.

Marcamos Enabled y grabamos, ya estamos listos para empezar, asi que lo mas sencillo sera hacer un cambio en nuestro codigo fuente, lanzar una nueva Build manualmente, o si queremos divertirnos relanzar un paquete antiguo al ciclo de Release, en todo caso esperamos un poco y veamos cuando nuestra Release se empieza a ejecutar y llega al paso que hemos agregado:

Clipboard08

Para después terminar:

Clipboard09Normalmente pasaríamos a aprobar o rechazar esta Release, pero ahora me interesa conocer los resultados de nuestra prueba, así que vamos a la pestaña Tests, y elegimos la opción LoadTest, para luego seleccionar la prueba mas reciente (en mi caso tengo algunas pruebas anteriores, pero si es la primera vez deberías tener una sola prueba en tu lista).

Clipboard10

Y así entramos a un detalle de los resultados de la prueba:

Clipboard11

Notemos algo interesante, aparentemente nuestra prueba salio ok (o sea, no hubo errores 500 o timeouts) pero el panel nos indica 2 errores, así que veamos el detalle:

Clipboard12

En mi caso el mensaje de error dice “The value 85.10138 exceeds the warning threshold value of 75“, lo cual nos viene a indicar no un error en el sitio que estamos probando sino un exceso en la capacidad de la instancia provisionada para hacer la prueba, esto apunta a que forzamos la maquina dandole 250 usuarios concurrentes, lo cual se relaciona a las pocas opciones de configuración que ofrece este tipo de prueba.

Listo, sencillo y ya podemos empezar a sacar conclusiones, pero como verán esta prueba es muy sencilla y en adición al ya mencionado problema del threshold no permite saber si por ejemplo el comportamiento es diferente desde un browser u otro, desde un tipo de red, etc, para lograr este tipo de análisis lo que se nos ofrece es la posibilidad de crear un test muy detallado desde dentro de Visual Studio y que cuando se efectúe el despliegue Visual Studio Team Services pueda “leer” todos estos parámetros archivados y ejecutar tras bastidores las pruebas programadas, esto sera tema de nuestro próximo post, de momento sugiero familiarizarse con este tipo de prueba, pues los conceptos siguen siendo validos cuando los escalemos, aparte de que estas pruebas tienen su lugar si  hacemos peticiones Get que luego repercuten a nuestra BD, o queremos probar la mejora si usamos un servicio de cache, etc.

Espero sus comentarios 😉

Actualizando la Gestión de la Configuración de ASPNET CORE con Azure

Hace medio año conversábamos acerca de la potencialidad que Microsoft nos empezaba a ofrecer para desarrollar aplicaciones para plataformas Linux y Mac, en el caso Web la iniciativa se llamo ASP NET 5, y en ese sentido se presento una manera para acceder de manera transparente a los valores de configuración (antiguamente manejados por los Web.config) para no tener que preocuparnos si se guardaban dichos valores en un archivo JSON o si por el contrario estábamos guardando dichos valores mediante la consola que Azure nos da para gestionar las Web Apps.

Pues bien, en este lapso varias cosas han transcurrido, y una de ellas es que ASP.NET 5 ahora se llama ASP.NET Core, decisión de Microsoft que ayuda a tener claridad para entender que “este” .Net que corre de manera multiplataforma no es la “siguiente versión” luego de .NET 4.X, así que correspondía regresar al desarrollo puro y duro para verificar si nuestra clase Helper seguía funcionando,  como es lógico habiendo pasado de una versión beta a una release candidate, las API se han actualizado por lo cual algunos de los metodos que se utilizaban ya no funcionan o funcionan de manera diferente, asi que correspondió hacer el ejercicio de revisar el código y dejarlo operativo.

De igual manera aproveche la ocasión para incorporar algo que se me quedo pendiente: soporte para cadenas de conexión, de esta manera seguiremos teniendo (como en ASP.NET 4x) la opción de trabajar en desarrollo con una BD local, y en entornos de despliegue (QA, PROD, etc) con una conexión gestionada por el entorno de Azure, evitando de esta manera trabajar con las ya conocidas Transformaciones, de esta manera si antes teníamos un fragmento de codigo asi:

 services.AddEntityFramework()
                .AddSqlServer()
                .AddDbContext<ApplicationDbContext>(options =>
                    options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]));

Con el uso de nuestro HelperConfig quedaria asi:

            services.AddEntityFramework()
                .AddSqlServer()
                .AddDbContext<ApplicationDbContext>(options =>
                    options.UseSqlServer(HelperConfig.GetConnectionString(Configuration, "DefaultConnection")));

Y de esta manera seria posible acceder de manera transparente al valor de la cadena de conexión que podria estar en nuestro JSON, asi:

  "Data": {
    "DefaultConnection": {
      "ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=aspnet5-WebTestConfig2-b1ec5227-eb73-448b-86ee-63e3746185e7;Trusted_Connection=True;MultipleActiveResultSets=true"
    }
  },

O, como mencionamos antes, en la consola de Azure:

ConnectionsStrings

Todo esto lo he subido a GitHub junto a un proyecto Web sencillo (vamos, la aplicación por defecto de Visual Studio 2015) para que uds lo descarguen y revisen su funcionamiento, particular atención merecen los siguientes archivos:

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Helper.cs (la clase HelperConfig en si y todo lo necesario para que funcione)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/appsettings.json (Los AppSettings y Connection Strings involucrados)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Startup.cs (Clase de arranque que prepara la Inyección de Dependencias e invoca a HelperConfig.GetConnectionString)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Controllers/HomeController.cs (Controlador que hace uso de HelperConfig.GetAppSettings)

En los próximos días explicare un poco mas de este pequeño proyecto, espero que les sea de utilidad y no se olviden de enviarme sus comentarios.

 

¿Estamos mirando todo el panorama al ir a Cloud o implementar DevOps?

Siendo que poco a poco las tendencias de cloud y DevOps tienden a alcanzar la madurez, he percibido una tendencia que va tomando forma en cuanto al “gusto” de los involucrados mas allá de lo existente en cuanto a herramientas y proveedores.

Por un lado lo que he percibido en estos meses, es que la mayoría de ofertas de trabajo que involucran el termino “cloud” se orientan a perfiles provenientes del ámbito sysadmin/IT pro, siendo que se piden skills vinculados a la gestión de infraestructura física (cableado, almacenamiento, etc) y relativamente poco con respecto a la gestión de las plataformas ya existentes en el mercado, y si algo en cuanto a lo que corresponde a la gestión de maquinas virtuales.

Por otro lado desde que le he tomado interés a lo que es el movimiento DevOps es evidente notar que la mayor atracción va hacia herramientas que tienden automatizar y facilitar la gestión de maquinas virtuales (Puppet, Chef, Vagrant, etc), esto por la necesidad de ser capaz de regenerar exactamente el entorno en que corre nuestra aplicación (de ahí el impacto que tiene el concepto de Infraestructura como código), pero como sabemos eso tiene cierto limite debido al peso que puede llegar a tener una MV así como el tiempo que se tarda en levantar una por mas automatizado que este su creación, de ahí el jale que tiene la propuesta de Docker, contenedores que solo contienen lo necesario para correr la aplicación (delegando buena parte de la carga al SO anfitrión) y así efectuar de manera sencilla un redespliegue de la aplicación…. con entorno y todo.

Si bien todo esto no deja de ser un avance, tengo la opinión de que no se esta teniendo una visión integral de las alternativas que se disponen en la actualidad, hace unas semanas estuve en una conversación con el responsable de una aplicación sectorial en una corporación, llegado el momento se nos indico que dentro de la organización se le ofrecía como opción (aparte del usual hardware “real” y maquinas virtuales) efectuar los desarrollos y/o despliegues correspondientes a su departamento.. en la nube! wow… pero en la conversación quedo claro que su responsable de infraestructura solo le había explicado las posibilidades existentes en IaaS y por ende.. solo el como era posible provisionar sus aplicaciones en MV alojadas en la nube,  mas no aclarando las posibilidades de que su BD se gestionara como servicio PaaS, y probablemente tampoco la posibilidad de hacer lo mismo con sus aplicaciones Web, con el consiguiente potencial ahorro que se podria conseguir para su organización.

Es que claro, somos criaturas de costumbres y probablemente nos sea mas natural trasladar el ya conocido modelo de Maquinas Virtuales de nuestros servidores a la nube, pero en el camino no debemos perder de vista si efectivamente es esa la mejor solución tanto en costos como facilidad de administración, siendo que PaaS nos provee de una abstracción que simplifica la administración y escalamiento y dándonos opciones para buen rango de nuestras necesidades de desarrollo, y si, claro que hay escenarios en que nuestro requerimiento (necesidad de ser “híbridos”, sistemas legados o stack tecnológico muy especifico) va mas allá de los esquemas que nos dan modelos PaaS como Azure App Service o Amazon Elastic Beanstalk pero valorar el modelo correcto es un ejercicio que debemos hacer necesariamente antes de la toma de decisiones.

Lo mismo con el caso de nuestras necesidades de Integración y Entrega Continua, el crecimiento de Docker abre nuevas posibilidades a la hora de regenerar entornos, pero no debemos dejar de tener en cuenta si de veras vamos a estar regenerando entornos periódicamente como parte del proceso, pues hacerlo no es trivial, hace poco desplegué una aplicación sencilla usando Docker a Azure y por el peso tardó bastante (ojo, estamos hablando de cientos de megas por contenedor) en hacerse el despliegue, en ese sentido no dejo de cuestionarme de si efectivamente para esa necesidad es o no mejor provisionar mi aplicación en una plataforma gestionada en vez de una MV o un contenedor, igual si que necesite hace IaaS pero antes debo decidirlo adecuadamente; claro esto no quita que siempre debemos procurar gestionar adecuadamente los archivos de creación de entornos (como hicimos con Resource Manager).

Así pues, nos corresponde tener una visión integral de las tecnologías que van surgiendo y usarlas de la manera mas optima posible, no basándonos unicamente en lo que es mas cercano a lo que ya conocemos de tiempo.