“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.

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…