Reflexiones a proposito del #CentenarioPUCP (2): La Ingeniería Informática en perspectiva

Habiendo ya comentado respecto a lo que significa mi alma mater en el contexto actual, toca reflexionar sobre la situación actual de nuestra especialidad, la Ingeniería Informática, su perfil, su evolución y sobre todo sus retos a futuro.

17499173_1885665281678573_8201655322192449166_n Finish Reading: Reflexiones a proposito del #CentenarioPUCP (2): La Ingeniería Informática en perspectiva

Microservicios: claro y simple

Desde hace tiempo hemos escuchado mucho sobre la conveniencia de usar Microservicios para el desarrollo de aplicaciones frente al esquema “monolitico” tradicional, de hecho la primera exposición seria que tuve sobre el tema fue durante el Agiles 2015, donde Maria Gomez dio un excelente charla planteando el esquema, de la cual comparto y recuerdo la facilitación gráfica respectiva:

_DSC3014

Desde entonces muchas dudas afloran ¿entonces ya no tendremos transacciones ACID? ¿como validamos la consistencia? ¿como deberemos modelar los datos? lo cual sumado a las ventajas ofrecidas por Docker hace necesario tener las bases teóricas claras para acometer este tipo de desarrollos.

En ese sentido, junto al lanzamiento de Visual Studio 2017, Microsoft presento una aplicación de referencia, basada en Contenedores y Microservicios, llamada eShopContainers que esta disponible en GitHub para ir siguiendolo (pues es un trabajo en construcción aún), miren nomas lo ambiciosa que es:
eShopOnContainers_Architecture_Diagram

Si, ambiciosa en cuanto a la diversidad de tecnologías a usar: Docker, Linux, .Net Core, Xamarin, etc pero lo mas importante a mi modo de ver es el libro que se esta construyendo, y que se puede descargar aquí.

He empezado a leerlo y me ha gustado mucho, se cubre con claridad que son los Microservicios, como se relacionan con Docker, los nuevos paradigmas a seguir, un concepto interesante llamado Data Sovereignty, como estructurar las entidades, lo cual hace caer en cuenta de la necesidad de ir entendiendo los conceptos de DDD, y lo mejor de todo, con un lenguaje claro y bien estructurado, lo dicho… ya estas tardando en descargar el libro!

Muchas gracias a Cesar de la Torre de Microsoft por este trabajo emprendido que nos ayudara mucho a los desarrolladores.

(Vídeo) Conociendo a los Build Agents

De vuelta a los contenidos y en esta ocasión (aprovechando la licencia de Camtasia) decidí probar con un video para explicar un concepto indispensable a la hora de decidir cual sera nuestra arquitectura de desarrollo y despliegue con TFS/VSTS: los Build Agents, que son, como han evolucionado, con que tipos contamos y cuales son las implicancias de elegir Agentes privados o Agentes hosteados, espero que sea de utilidad para entender este pilar de la arquitectura de TFS/VSTS

Enlaces de referencia:

Empezando bien el año: MVP

Pues si, este año empieza bien pues hoy recibí el correo que me informa que se me ha otorgado el reconocimiento Microsoft Most Valuable Professional (MVP) en la categoría Visual Studio and Development Technologies, esta designación me motiva mas para seguir este proceso de compartir conocimiento en lo que son las practicas ALM y DevOps, así que nos espera un año con un reto bastante exigente. Muchas gracias a todos los que me apoyaron en este proceso, tanto de Microsoft Perú como de las diversas Comunidades Microsoft.

mvp

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)