Aun es tiempo de DevOps… pero…

Hace unos meses comentaba sobre el interés creciente de las organizaciones sobre el concepto de DevOps y como estas debían enfocarse en la sinergia y colaboración a fin de mejorar la eficiencia de sus procesos de despliegue, lo cual implica todo un reto.

El problema es que en este tiempo he podido percibir que la percepción respecto a DevOps se ha quedado en la parte técnica del asunto, reduciendo DevOps a aplicar correctamente los scripts de despliegue, usar Docker y/o Infraestructura como Código, monitoreo, control de código fuente ahhh y si todo lo hacemos en la nube, mejor aun.

Y claro, así como en su momento surgio el boom de las certificaciones de los frameworks de proyectos, de liderazgo, de escalamiento, de cambio, era cuestión de tiempo que se implantaran por aquí los cursos y/o certificaciones de DevOps, con el sabor que se desee, contexto en el cual es difícil separar la paja del trigo.

En todo caso creo que debemos distinguir lo que propugna el enfoque DevOps: colaboración y sinergia en búsqueda de mejora de resultados, de una potencial implementación especifica en la cual ya pasamos directamente a las herramientas que se pueden utilizar, siendo que no hay recetas únicas sino el elegir adecuadamente el stack correcto según las necesidades y realidad de las aplicaciones y/o organización, por ejemplo… si uno “aprende DevOps” basandose en containers  ¿esos conceptos nos servirán para coordinar las mejoras para desplegar servicios Windows? (o viceversa).

Otro tanto viene con los procesos de reclutamiento de personal, la confusión es tal que como mencionaba Nico Paez se ve a “DevOps” como un perfil,  no como “mindset” (personalmente yo prefiero llamarlo “enfoque”) y como indique en mi sesión “En búsqueda del DevOps perdido” los reclutadores ven la palabra “DevOps” y te contactan preguntando por tecnologías que no están tu perfil; y por el otro lado pasa lo mismo, cuando me ha tocado entrevistar a postulantes por roles relacionados, al preguntar sobre el entendimiento respecto al enfoque DevOps no ha sido raro que lo primero que les vino a la mente fue … automatización!

Al final casi siempre termino regresando a la “definición” que en su momento hizo Carlos Peix respecto a como definir un “rol” para DevOps: “Para mí el nombre del rol debería ser “Facilitador de mentalidad DevOps”. Eso es lo que yo he hecho y hago en varios casos.

Sin duda, para cumplir ese rol, me viene muy bien saber de bash, de firewalls, de DMZs, de TCP/IP, de herramientas de automatización, lenguajes de programación, etc. También me viene bien haber sufrido mucho con el trabajo manual repetitivo, cometido errores y haber creado soluciones artesanalmente. Por último, también me ha sido útil desarrollar habilidades de facilitación de debate, procesos de diálogo y de discusión, de divergencia y de convergencia.” Y claro, el detalle es que en una certificación no te viene la experiencia de haber desplegado manualmente, el sufrir con organizaciones en las que el divorcio entre áreas sea tal que las ventanas para desplegar sean estrechas y escasas (¡alguien dijo silos?), ni el saber como son las cosas que uno quiere evitar para lograr la mejora.

En ese sentido, si uno va a estudiar herramientas para DevOps, pues genial, pero teniendo en cuenta que al final ese stack puede ser el valido en un contexto, pero que en otro corresponderá aplicar los criterios de colaboración y comunicación con tu equipo para entender el contexto y así poder definir correctamente el flujo y el stack necesario, pues son justamente esas capacidades de comunicación y de preguntar correctamente las que te permitirán adaptarte pronto a escenarios con herramientas que no hayas visto antes; y es que también de eso se trata el enfoque DevOps: no ser el super sabelotodo que domina tanto los stacks de desarrollo como de infraestructura sino de, con mucha humildad, poder plantear esquemas de colaboración y multicapacidad de los equipos.

Los retos de la agilidad en el Perú para el 2018

Pues si, se acaba el año y aunque no soy muy fan de estas revisiones y mirada hacia adelante que rodean estas fiestas, creo que en esta ocasión corresponde hacerlo a fin de reflexionar por donde estamos yendo como comunidad agilista, así que tratare de repasar lo que he visto en base a las interacciones en diversos entornos y encuentros… vamos a ello.

  • Interés creciente, ya ser ágil no esta siendo una curiosidad, sino una tendencia cada vez mas visible lo que ha hecho que las personas estén buscando cursos, las empresas buscando Scrum Masters y coaches..
  • Mucha conversación acerca de implementar/adoptar/etc la agilidad en grandes organizaciones, lo cual ha derivado en atención hacia los frameworks de escalamiento
  • La búsqueda externa de la piedra filosofal o como dice mi amigo Uzi “las empresas quieren un coach mágico y divertido” en lugar de promover el crecimiento interno
  • DevOps se ha vuelto la palabra de moda, debido a un legitimo interés en automatizar los despliegues, pero olvidando el factor cultural y de colaboración que involucra
  • Ganas por retomar la excelencia técnica como pilar de la agilidad
  • Mas dudas sobre los problemas en el día a día que sobre como implementar por primera vez
  • Profesionales que antes veían la agilidad como otra opción mas (equiparándola a cascada a veces) empiezan a preguntarse sobre ella
  • Grandes organizaciones están haciendo sus experimentos de innovación basándose en la agilidad y volviéndose referentes en el camino

Entonces, puede que Perú este llegando un poco tarde a la fiesta del crecimiento (si nos comparamos con nuestros amigos de Colombia, por ejemplo), por lo que toca plantearnos como comunidad como podemos contribuir hacia los cambios propuestos de la agilidad de la mejor manera, así que planteo unas ideas sueltas.

  • Tener siempre en mente que no hay recetas únicas, a algunos les puede ir mejor arrancando con Kanban a otros con Scrum o algún hibrido, pero debemos estar atentos a que lo que funciono en una organización u equipo puede no funcionar en otra, asíi que lo que toca es ir generando los contextos para que vaya surgiendo y recordar que “You can do better than the Spotify Model”.
  • Estar alertas con las implementaciones top-down impuestas que no involucren a los equipos y tomar todo con pinzas a pesar de la popularidad del framework propuesto, pues esta no es indicativo de calidad sino que puede ser resultado de búsqueda de algo que mantenga lo existente sin procurar realmente el cambio necesario.
  • Enfatizar la necesidad de una base técnica solida como pilar de la agilidad, se nos ha recordado mucho a los desarrolladores acerca del desarrollo de las habilidades blandas, pero por otro lado poco se hace para recordar a los Scrum Masters y coaches sobre la importancia del entendimiento del rol que juegan las decisiones técnicas en la buena marcha de un proceso de desarrollo de software, ya que como decía Hernan Wilkinson en el pasado Agiles 2017 “si solo hacemos Scrum y no mejoramos en la parte técnica vamos a seguir haciendo la misma porquería pero vamos a estar todos más felices“.
  • Estar alertas ante los vendedores de humo, y discernir entre quienes solo venden horas de consultoría y certificaciones, pero no se aplican el cuento a si mismos y quienes si efectivamente se involucran en lograr mejores resultados.
  • Recordar que DevOps va mas allá de automatizar y entregar de manera continua, que involucra mucho lo que es colaboración y cierto cambio cultural, a estar atentos cuando alguien empiece a hablar de DevOps vinculándolo a nube o a procesos de despliegue y no se mencione sobre la necesidad de colaboración dentro y entre los equipos. Personalmente siempre he creído que los profesionales de la tecnología vivimos permanentemente en un contexto de “Todos somos genios. Pero si juzgas a un pez por su habilidad de trepar árboles, vivirá toda su vida pensando que es un inútil” ya que se nos ha enfatizado en las mediciones basadas en nuestras habilidades blandas y hasta cierto punto en una extroversión que no tenemos, lo cual impide la valoración adecuada de muchos de nosotros; pero, dicho esto, creo firmemente que en el apoyo a enfoques DevOps se requiere tratar de tener el pie en ambos lados.
  • Ser más proactivos para entender y apoyar los contextos complicados, muchas de las reflexiones y propuestas que se vienen dando últimamente parten del marco supuesto en que toda la organización esta involucrada en una transformación técnica y cultural, pero poco se habla por ejemplo de como lograr hacer la transición hacia la agilidad (y mejorar el desempeño) en equipos que mantienen (y lo seguirán haciendo por un tiempo) aplicaciones legadas pues la respuesta no puede ser simplemente que se limpiara esa tecnología (ahí nos olvidamos del factor humano) sino procurar la forma de que estos equipos sumen al resultado final, o como trabajar lo más ágil posible con equipos en los cuales la permanencia de sus miembros está supeditada a contratos de tres o seis meses (renovables o no), o como ayudar a esa pequeña consultora que depende de entregar un presupuesto cerrado para un potencial contrato del cual depende su continuidad, ya que es muy fácil y cómodo desde una posición consolidada que se debe optar por otro tipo de clientes.
  • Evitar caer en el cargo-cult, si en un pasado se vio el dejar la línea técnica para irse a gestión (y llegar a ser Project Manager o similar) como una mejora de carrera profesional, ahora corremos el riesgo de caer en una variante de lo mismo al dar mucho énfasis en cómo ser o efectuar el rol de coaches y su importancia (o considerar que un Agile Coach es un Scrum Master junior), olvidándonos que lo realmente importa es el cambio y evolución de todos los integrantes de un equipo u organización.
  • Estar seguros de si lo que se está efectuando es efectivamente innovación o no.
  • Empezar a pasar de un enfoque basado en proyectos (y por ende en costos fijos) a uno basado en equipos que van construyendo productos que generan valor a la organización, esto tomara mas tiempo, pero es algo que debemos tener siempre presente.

Retos y alertas que hay que tener en mente para seguir en el camino emprendido… a estar en ello en este 2018 que esta por empezar.

 

 

“Nuestro sistema no es compatible con DevOps”

Esto del enfoque DevOps y el que sepan de que uno es promotor de ello trae escenarios bien peculiares que me motivan a reflexiones que quiero compartir con ustedes….

Hace unas semanas conversaba con unos amigos y hacíamos referencia a que en el proyecto de uno de ellos los pases a producción terminaban en la madrugada, y la respuesta fue “es que nuestro sistema no es compatible con DevOps”, bueno… directamente solo le pude decir que DevOps no es solo eso, pero me derivo a pensar en la malinterpretación de mi amigo, las implicancias que esto trae y claro… caminos de solución.

Lo primero, como ya hemos conversado anteriormente, DevOps es un enfoque que procura la sinergia y colaboración entre las (usualmente divididas) áreas de Desarrollo e Infraestructura de cara a mejorar los flujos de entrega de valor a los usuarios finales, empero las ideas que se suelen asociar al concepto son las de Integración y Entrega Continua, Automatización, Infraestructura como Código, y ya en casos extremos con los ejemplos ultra difundidos (pero interesantes) de las empresas tecnológicas que sacan varias versiones de sus aplicaciones a producción… diariamente, y claro si al final uno termina pensando en DevOps=Despliegues superautomatizados, el corolario es creer (como mi amigo) que aplicar DevOps es imposible por culpa de las aplicaciones con las que se esta trabajando, olvidándonos de lo mas importante en DevOps: sinergia y colaboración, que como veremos es el punto de partida en la búsqueda de mejoras.

Regresando al caso que nos ocupa, pensemos en lo que involucra un despliegue de una aplicación corporativa de mediana a grande: compilación, parada del sistema actual, actualización de base de datos, ejecución de scripts en sistemas asociados, despliegue de compilados, validación progresiva de que los cambios están funcionando, etc… si, pasos complejos que deben realizarse con cuidado y que son la razón por la cual la fiesta dura hasta el amanecer con desayuno incluido; en ese contexto se puede pensar que para acelerar los despliegues se requieren cambios muy grandes, instalación (y adquisición) del software adecuado, capacitación de los equipos, consultores, y zas! pasamos al escenario de pensar en los recursos (financieros) para la implementación de una iniciativa DevOps que ponga en marcha lo necesario (*), siendo que aun con restricciones se pueden dar los pasos de Mejora Continua en los procesos de despliegue.

Reitero: colaboración y a lo cual debemos sumarle el compartir información, así que para el despliegue mencionado correspondería reunir a los involucrados en el proceso de las diversas áreas y basarnos en la técnica de Los cinco ¿Por qué? a fin de entender plenamente el flujo de despliegue, así que especulando mucho la cosa quedaría así:

  • “¿Por qué el pase a producción de XYZ tarda de 3 a 5 horas?”
  • “Es que necesitamos antes actualizar el subsistema conceptual VW y las bases de datos golosinarias OP” “El sistema de actualización estratosferico GH tarda media hora”
  • “¿Por qué el sistema GH tarda media hora?”
  • ….
  • “¿Por que los módulos florales DE no se actualizan como los módulos hidráulicos JK?”

Bueno, cada sistema es un mundo propio, pero el punto de este análisis es procurar que las áreas involucradas tengan un conocimiento cabal de lo que involucra cada etapa del despliegue, incluyendo las que no están bajo su directa visibilidad o responsabilidad, pues es lo que nos pasa como tecnologos nos enfocamos mucho en nuestra área y solemos pensar en el resto de los sistemas e infraestructura con los que interactuamos como si fueran una caja negra (**) lo cual limita nuestra capacidad de sugerir mejoras en el proceso de forma integral.

Como consecuencia de este análisis se pueden identificar de manera colaborativa los puntos de mejora que se pueden acelerar (ya sea mediante scripts o automatizaciones parciales), coordinaciones a simplificar, reducción de redundancias en el proceso, y establecer una prioridad de acciones de mejora a realizar de cara a los sucesivos pases a fin de reducir los tiempos, que si, no hemos logrado aun establecer los hermosos pipelines en los que con un clic logramos desplegar todo el repositorio de código fuente en los entornos, pero por lo menos ya se han dado los pasos para que cuando llegue el momento sea mas simple el orquestar todos los pasos apoyándonos en una herramienta de automatización de despliegues como VSTS/TFS o similares, pero en el camino habremos iniciado el proceso de reducir los tiempos de despliegue, mejorar su calidad y logrando incrementar la autoconfianza del equipo en su labor, pues quienes hemos tenido que hacer pases a mano sabemos la tensión extrema que hay hasta que no se esta seguro de que los cambios “ya están corriendo en producción”. Y.. ¿saben? aun cuando no se llegue a la super automatización, este proceso de colaboración también es DevOps.

Ahora que si me dicen que va a ser muy difícil (y no hablo de temas de disponibilidad de horarios) poner a los diversos involucrados frente a una misma pizarra y mas difícil aun que compartan su información, pues…. el problema es muchísimo mas serio que unos despliegues lentos, y toca trabajar bastante desde el punto de vista cultural, por lo que cualquier estrategia llamada “Iniciativa DevOps” o similar basada unicamente en la automatización y gestión del ciclo de releases/entregas solo estará automatizando ineficiencias de una raíz muy profunda.

Entonces podemos ver que si bien mejorar nuestros flujos de entrega de valor implican un esfuerzo y cursos de acción priorizados, es posible lograr mejoras importantes aun sin llegar (de momento) a la total automatización, la cosa es partir desde el principio, en mejorar la colaboración y el flujo de información entre las áreas involucradas.

(*) Lo cual no esta mal si dicha iniciativa no se queda solo en la automatización pura y dura sino que también (y sobre todo) es capaz de lograr los cambios culturales asociados al enfoque DevOps.

(**) Siempre comento lo productivas que fueron unas reuniones que el equipo de desarrollo tuvo con el jefe de infraestructura en un proyecto en el que participe, gracias a dicha reunión pudimos entender cabalmente cual era el trafico de paquetes entre las sedes de la organización, eso nos ayudo a hacer cambios en la configuración de la aplicación así como a sugerir ajustes en el sistema DNS y de ruteo de la red.

Las perspectivas PaaS Linux sobre Azure

Si hace unos años me hubieran dicho que estaría comentando sobre lo que menciona el titulo, me hubiera puesto a reír, pero el contexto tecnológico cambia de manera constante y este es el escenario en que los desarrolladores debemos tener claras nuestras opciones a la hora de considerar Linux como plataforma.

De mas esta comentar sobre las oportunidades que nos ofrece .Net Core para poder llegar a escenarios en los que tradicionalmente Windows estaba vedado, pero también debemos tener en cuenta las perspectivas de poder integrarnos y trabajar con otros stacks, así que si… Linux nos va a rodear bastante a los que trabajamos con .Net.

Ahora bien,  trabajar con Máquinas Virtuales Linux siempre ha sido posible desde que los proveedores de cloud empezaron a ofrecer IaaS, pero si uno basa su estrategia cloud en depender de máquinas virtuales que básicamente replican la arquitectura que se tenía on premise, no se está sacando partido de las potencialidades de la nube (optimización de costos y escalamiento) ni  tampoco se esta asumiendo un enfoque pragmático frente a los retos (o limitaciones) inherentes a la nube, como pueden ser los niveles de servicio asegurados por el proveedor (SAL), lidiar con las latencias, etc, esto y la necesidad de brindar a nuestros equipos de desarrollo con plataformas que aceleren su productividad nos deben obligar a mirar la nube más allá del IaaS.

Es con esta mirada que debemos analizar la propuesta PaaS que nos da Azure en el entorno Linux; recordemos que tradicionalmente si queríamos implementar una Web App lo que estábamos provisionando “por detrás” era una MV Windows con un IIS especialmente configurado para permitir las ventajas como slots, escalamiento, kudu, etc… lo cual nos va bien para aplicaciones .Net pero por ejemplo no nos permite correr aplicaciones Ruby, aparte de que existen escenarios en que se requiere cierta librería PHP que ¡oh sorpresa! tiene una fuerte dependencia con el sistema operativo Linux, así que era natural que Microsoft Azure venga a ofrecer una solución de Web Apps basada en Linux como una opción para los desarrolladores, misma que en este momento esta en versión de prueba.
top-level-create
Finish Reading: Las perspectivas PaaS Linux sobre Azure

Las expectativas sobre DevOps

El pasado 7 de Abril tuve la oportunidad de exponer en el Scrum Day Perú mi presentación  “En búsqueda del DevOps perdido”, esta presentación es una evolución dos años después de mi charla “El reto del DevOps ágil”, pues trato de explicar como el concepto se ha ido distorsionando desde lo que originalmente era, un enfoque de búsqueda de sinergias entre los equipos en el proceso de generación de valor para la organización, en un afán por automatizar y que una persona se haga cargo de ello (de ahí la aparición de ofertas de empleo para el “rol” de DevOps).

Y parte de este problema lo pude notar en el auditorio, pues por lo que pude conversar, parte del publico esperaba una charla mas técnica, orientada a solucionar problemas de implementación y/o de elección de herramienta, lo cual me hizo reafirmarme en cuanto a la importancia de esta reflexión, en lo fácil que estamos cayendo en algunos de estos antipatrones sobre el enfoque DevOps:

  • DevOps es un rol, pues no… es un enfoque sinergico que busca la entrega continua de valor
  • DevOps es un rol que debería ser ocupado preferentemente por IT Pros/sysadmin, siendo que los roles de apoyo a este enfoque pueden provenir de cualquiera de ambos equipos, en tanto se cuenten con las habilidades blandas que faciliten la comunicación y sinergia
  • DevOps es básicamente automatizar, en realidad automatizar es el resultado de las decisiones sucesivas que se toman para optimizar el ciclo de construcción y entrega de aplicaciones
  • Tratar de asociar ciertas herramientas o plataformas a lo que es DevOps

Y claro, si se parte de esas premisas, el riesgo de terminar decepcionado es muy alto, así pues, nos toca seguir revisitando los orígenes del enfoque y seguir en la búsqueda de la mejora continua de nuestros procesos, y de eso nos cuenta un poco Jersson.

Espero sus opiniones, y de momento los dejo con la presentación mencionada.

(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:

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.

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…