Autor: ecardenas

¿Una Imagen vale más?

Posted on by ecardenas

En esta ocasión cedemos el espacio a una amistad de la comunidad que prefiere permanecer en el anonimato, pero tiene algo valioso y crudo que contar.

La famosa frase que dice «Una imagen vale más que 1000 palabras» ¿Realmente calza en todos los entornos? Porque lo que percibo en mi mundo laboral, mi entorno el desarrollo de Software, Aplicación de Negocios, y Mejora de Procesos, etc. Realmente esta frase solo engaña.  L

Mi comentario, es que ahora lo que se ve más por los pasillos son lindos posits  de colores e imágenes bonitas de equipos que aparentan la mejor calidez y que nada malo pasa por ahí.

Hasta que se tienen resultados. Finish Reading: ¿Una Imagen vale más?

De valor, historias técnicas y mantenimiento

Posted on by ecardenas

A veces una reunión de la comunidad te genera un debate interno una revisión de tópicos que ya se habitan visto antes pero que conviene reflexionar y visitar de nuevo, así en la ultima reunión de Agile Perú Cynthia presento como tema principal si existían las historias técnicas, planteándose los siguientes conceptos clave: los componentes técnicos dependen o tienen que depender de un requerimiento de valor de negocio, siendo mayormente tareas y no deberían ser considerados como «historias» puesto que estas son una base para conversar, siendo clave el reflexionar valor de negocio que se le deja al cliente si al día de hoy se acaba el proyecto.

El debate posterior fue interesante, se comento que de haberlas no se debería llamarla «historias» sino «epicas» «enablers», que si lo que importa únicamente es el negocio, lo cual me ha derivado a unas reflexiones que quiero compartir con ustedes.

Ante todo, hay que precisar ¿a que llamamos historias técnicas? En mi experiencia creo que corresponde llamar así a las actividades técnicas (sorry por lo redundante) que no se pueden subordinar o mapear directamente a requerimientos de negocio, siendo así ¿deberíamos considerar como tal al código que implementa una funcionalidad o historia de usuario? para respondernos planteémonos el caso de que  por X razones debemos escribir un script para conectarnos a una BD externa a fin de lograr realizar una consulta para uso de nuestros usuarios, pues no… no es historia técnica a pesar de su complejidad ya que hay una vinculación directa con un historia de usuario, lo contrario pasa con actividades tales como refactorización, configuración de infraestructura, etc, procesos que por su naturaleza transversal No deberíamos forzarlos (como muchas veces se insiste) a que encajen como tareas hijas de una historia de usuario.

Siendo así ¿que tipos de historias técnicas hay? pues Alexander Menzinsky nos recuerda una muy razonable categorización (**):  Arquitectura, Infraestructura de Producto, Infraestructura del Equipo, Refactorización y Spikes (investigación).

Como pueden darse cuenta, mi posición es a favor de la «existencia» de las historias técnicas como la ha sido desde hace unos años, ya entonces insistía en su lugar debido a la necesidad de hacer visible el «como» se llega a la necesaria entrega de valor que se propugna desde la agilidad, los años transcurrido han reafirmado mis posturas visto que las tendencias que ya comentaba entonces respecto al descuido al componente técnico no han hecho sino acrecentarse, siendo que sin pelear por la visibilidad no se lograra el cambio. ¿Y por qué es importante esa visibilidad? pues, como me comentaba Omar «es como si las historias (tradicionales) se hubiesen hecho para mostrar el exterior y no el interior… » por lo que «hay una especie de vacío sobre donde poder ver dichos aspectos (técnicos) y que se valoren» ya que «las historias están hechas para conversar con el cliente y entenderse….pero la parte técnica, no la comprenderá mucho pero la valorara de la forma que pueda y en ese sentido la relegara hasta que pueda aprender sobre la importancia de esta en algún momento«, lo cual nos lleva a algo que sale a nuestras conversaciones de tanto en tanto, la importancia de explicar adecuadamente el rol estos componentes para que el Producto Owner acepte su inclusión en los sprints que vayan saliendo, y claro… ¿como se puede iniciar el dialogo sobre estos componentes si no están visibles? (*).

Dicho esto queda pendiente sobre como se deben visibilizar y nombrar, y reitero que no debe forzarse su subordinación a una historia de negocio, sino asumir su rol transversal en la generación de valor con calidad y su impacto en la capacidad del equipo, ahora… que no te guste el nombre de «historias técnicas» es otra cosa (a mi si, aunque si no te gusta usa otra opción, pero siempre hay que recordar que la nomenclatura tiene impacto en como entendemos las cosas), pero no por eso hay que retirar su lugar visible dentro de los flujos de un equipo, muy por el contrario toca potenciarlo como muestra Henrik Kniberg:

Dicho esto, toca tener un necesario balance para evitar que por mor de la excelencia técnica nos encontremos atrapados en ciclos de refactorización sin generación de valor como ironiza Angel Medinilla:

 

Así que toca seguir dando vueltas y recalcar la importancia de la visibilidad de los componentes técnicos dentro de nuestros backlogs y sprints, como parte importante de la calidad del software y el valor que entregamos.

Y ya que hablamos de valor, no puedo dejar de mencionar una conversación en la que se hablaba de como pasar de los ciclos de desarrollo y entrega a la etapa en que un software es mantenido, en ese momento se comenzó de hablar de «equipos de mantenimiento» y de «equipos que generan valor», lo cual me hizo un ruido instantáneo por lo que tuve que manifestar mi postura respecto a que ese lenguaje involucraba que los equipos de mantenimiento NO generaban valor, siendo que consideraba que hay valor en el sostenimiento de las operaciones del negocio, y que encima agravaba las barreras dentro de la organización, generando naturales recelos que no hacen sino bloquear los objetivos de la organización, es que las palabras cuentan, y mucho.

(*) Mas allá del caso obvio de los aspectos de Infraestructura de Producto, como puede ser la instalación y configuración de un servidor, escenarios sobre los cuales también he escuchado defensas de colocarlos como subordinados a una historia técnica.

(**) Gracias a Guino por apuntar que quien planteo esta categorización fue Robert Galen.

¡Mudanza en MySQL

Posted on by ecardenas

Tal vez algunos recuerden pero hace un tiempo migre este blog de Blogger a un servicio WordPress alojado en Azure, ha sido un buen tiempo desde la migración pero lo que no comente plenamente en su momento es que para poder funcionar WordPress requiere contar con una base de datos MySQL, siendo que al momento de la migración Azure no proveía un servicio manejado de MySQL por defecto se nos ofrecía una base de datos gratuita proveída por ClearDB, lo cual nos hace tener que administrar ese servicio en «otro lado».

El caso es que entre las muchas novedades lanzadas por Microsoft en el Build del año pasado estaba el lanzamiento de una versión manejada (o sea que no tenemos que instalar un servidor Linux) de MySQL, por lo cual una de las cosas que pasaba por mi cabeza era migrar de ClearDB a Azure Database for MySQL, pero por una razón u otra siempre lo postergaba (aun cuando ya había creado una instancia en la misma zona geográfica y Resource Group que este blog!)

Y como suele suceder a veces es un hecho externo el que te hace pasar a la acción y en este caso fue la decisión de ClearDB de descontinuar los servicios gratuitos que estaba ofreciendo, dando como opción hacer un upgrade dentro de sus nuevos planes, pero como supondrán decidí hacer lo contrario y hacer pleno uso de mi BD en Azure, para lo cual seguí las instrucciones detalladas de este excelente post, con un salvedad que paso a contar:

El autor da las instrucciones para que una vez que, vía MySQL Workbench, nos hemos conectado a la BD destino y origen invoquemos un Wizard que efectúe la migración por nosotros y así lo intente, pero por alguna razón el efectuar pruebas consume el numero de conexiones que se pueden hacer hacia ClearDB, por lo que decidí jugar con otra opción: usar el backup que te ofrece ClearDB y tratar de restaurar en Azure, para lo cual entre a la consola web de ClearDB y exporte el ultimo backup disponible.

Una vez descargado el .zip exportado lo que tuve que hacer fue:

  1. Desempaquetar el archivo .sql que esta dentro del .zip (¡Si toda la base de datos esta en un archivo SQL!)
  2. En mi BD de Azure crear un schema con exactamente el mismo nombre existente en la instancia de ClearDB (para mas seguridad pueden copiar el comando de creación desde la BD origen)
  3. Seleccionar nuestra nueva bd/schema y ejecutar el SQL en cuestión.

Luego toca proseguir con las instrucciones del post respecto a la configuración de seguridad y conexión en nuestra Azure Web App de WordPress, pero adicionalmente es necesario editar el archivo wp-config.php de nuestro site, a fin de que todos los parámetros estén actualizados completamente, y claro luego de eso verificar que funcione adecuadamente, lo cual como pueden ver, va perfectamente.

Asi que … ¡gracias ClearDB, hola Azure Database for MySQL!

Aun es tiempo de DevOps… pero…

Posted on by ecardenas

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

Posted on by ecardenas

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.

 

 

Pongamos una Wiki en nuestros Team Projects

Posted on by ecardenas

Bueno, esto podría sonar no tan novedoso si tenemos en cuenta que desde hace buen tiempo las plataformas de tipo Wiki se han popularizado como una forma practica de compartir información entre organizaciones y/o proyectos, pero curiosamente esto era una asignatura pendiente en VSTS, lo cual no deja de ser curioso puesto que hace rato TFS (la versión On Premise) cuenta con dicha herramienta «out of the box» (bueno, si instalas los módulos vinculados a Sharepoint), pero en todo caso esta es una buena noticia, desde hoy podemos agregar una Wiki a nuestros Team Projects.

Y empezar a trabajar con la Wiki, es sencillo, solo tenemos que loguearnos como administradores de nuestra instancia de VSTS y veremos la opción disponible en la barra de herramientas, hacemos clic ahí y solo habrá que seguir las instrucciones:

Y bueno, luego a editar, para lo cual habrá que seguir las guías de marcado correspondientes:

Es todo para empezar, ya se vienen nuevas características como buscador transversal dentro de los diversos proyectos, filtrado, mejoras en el marcado, etc.

Seguiremos informando 😉

El camino de la agilidad personal…

Posted on by ecardenas

Hace unas semanas durante un «after» luego de una de las reuniones de Agile Perú, surgió la cuestión de que la agilidad cada uno la vive de manera personal … diferente y si, conforme dimos nuestras opiniones vimos que cada uno lo veía bajo un angulo distinto, pero igual de valido; así hubo quien dijo que lo que le gustaba de la agilidad era el poder experimentar, alguien mas comentaba que era el cambio lo mas importante, otro punto de vista era que la agilidad era el poder eliminar desperdicio, también se menciono que lo que atraía de la agilidad era el poder motivar a las personas y equipos, en mi caso personal comentaba que para mi el ser ágil era el poder entregar valor (*) …

Nótese el detalle… distintas aristas, distintos enfoques, todos complementarios, pero en ningún caso hicimos mención a temas de «gestión de proyectos» ni entregar el alcance antes, no… hablábamos de como la agilidad como filosofía (por decirlo de alguna forma) había influenciado nuestras vidas, y que esto era un camino constante… lo cual me hizo traer a colación algo que había comentado hace unas semanas «Si crees que lo de agilismo va esencialmente de gestión, es que tu camino recién ha empezado…», la conversación de esa noche me lo reafirmó, así que … sigamos en el camino, o inicialo si es que recién estas viendo de que trata esto, no te arrepentirás.

(*) ¿Será por eso que me atrajo el enfoque DevOps?

Relanzamiento de www.agile-peru.net

Posted on by ecardenas

Para nadie es un secreto que desde que regrese a Perú he estado involucrado en Agile Perú, primero como asistente y luego como parte de su organización, en este lapso hemos tenido nuestras altas y sus bajas, sacando adelante los Agile Open Lima que tanto impulso Lennon, y sobre todo, nuestro recordado y fatigado Ágiles 2013, y en los ultimos años nuestras clasicas reuniones mensuales.

Pero a todo esto, había algo que habiamos pasado por alto, y era nuestra pagina web, que si, que nuestra lista de correo y nuestro Facebook están muy activos, pero si que hace falta un medio propio para poder ir registrando nuestras actividades, facilitar contenido a la comunidad, etc… es asi que desde el 12 de mayo nuestra web esta online nuevamente, en nuevo host WordPress, donde de momento iremos publicando nuestras actividades (como nuestro reciente Agile Open Lima VIII) asi como la discusión de los planes futuros de nuestra comunidad.

Como buenos agilistas hemos empezado con una versión básica que de momento nos permite ir posteando, pero que esperamos vaya creciendo para incorporar secciones y diseño funcional para nuestro publico, en eso estamos, paso a paso….

«Nuestro sistema no es compatible con DevOps»

Posted on by ecardenas

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

Posted on by ecardenas

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