Categoría: DevOps

¡Añade aislamiento a tus despliegues con Environments!

Posted on by ecardenas

Regresando, en plena cuarentena, a las arenas del CI/CD para hablar algo que curiosamente ayuda a lograr cierto aislamiento a tus recursos en la nube al momento de desplegar: Los Environments en Azure Pipelines, así que vamos a ello.

Repasemos un poco, cuando hemos tenido pipelines usando Designer Mode, hemos definido el despliegue (en este ejemplo hacia un Web App) mas o menos así:

Y en el caso de Multi-stage pipelines, el paso de despliegue se define así:

Si nos fijamos en ambos casos, veremos que corresponde al Pipeline definir el recurso “destino” donde haremos nuestro despliegue:Subscripción, Grupo de Recursos y Recurso (en este caso una WebApp), o sea que toda la responsabilidad recae sobre el pipeline y quienes tienen acceso a desarrollar sobre el.

Si, es cierto que podemos establecer una cierta seguridad si, cuando enlazamos nuestro Team Project contra los recursos de Azure, lo hacemos contra Grupos de Recursos acotados y no contra toda una Subscripción, algo de eso lo vimos anteriormente, pero lo que vamos a ver proporciona una abstracción adicional y funcionalidades que nos ayudaran al seguimiento de nuestros procesos de despliegue. Finish Reading: ¡Añade aislamiento a tus despliegues con Environments!

¿YAML Pipelines? Si, ¡fácil! (2)

Posted on by ecardenas

Si, la evolución de Azure Pipelines hacia el mundo YAML sigue su marcha, lo cual quedo determinado con el lanzamiento de los multi-stage pipelines en el pasado Build, lo cual es un avance pues permite incorporar al modo YAML las capacidades de despliegue que ya hemos conocido desde hace buen tiempo, pero mientras este camino continua ¿como logramos que el usuario final se sienta confortable trabajando con YAML? pues la verdad sea dicha, a muchos de nosotros el trabajar a puro texto no nos hace sentir cómodos; así que (como ya vimos anteriormente) a la capacidad de agregar snipets de texto, desde el editor de tareas, hacia nuestro editor de texto, ahora se ha incorporado una ayuda que apenas Tom la menciono me encanto inmediatamente, así que vamos a ello.

Repasemos, si nosotros usamos la capacidad de agregar porciones de texto luego de parametrizar una tarea, nos vemos en la siguiente situación ¿qué hacemos si luego resulta que queremos editar la tarea y sus parámetros?, si es solo cambiar un parámetro de texto (una ruta por ejemplo) no hay mucho problema, pero si queremos cambiar mas de un parámetro dentro de una lista de opciones la cosa cambia un poco, así que lo que hasta hace poco hacía era pegar una nueva tarea con los parámetros actualizados y según correspondía reemplazaba o toda la tarea o solo la sección afectada, y a seguir adelante.

Pues bien ahora en los últimos sprint del producto se ha liberado la capacidad de editar una tarea ya existente en nuestro pipeline, para lo cual debemos fijarnos en las letritas que dicen “settings” sobre una sección de tipo task en nuestro YAML:

En este caso he elegido una tarea que me vino con la extensión para soportar Terraform (¡Si! ahora tenemos una extensión oficial para incluir despliegue de recursos cloud usando Terraform), hago clic sobre las letritas de settings y….

Listo, ya podemos editar totalmente la tarea y actualizar los parametros que hagan falta.

Espero que esto les sea de utilidad para ir avanzando en la creación de mas pipelines YAML, a estar atentos en las novedades que vendran saliendo en cuanto a los multi-stage pipelines.

Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Posted on by ecardenas

Por aquí ya hemos hablado una vez y otra sobre como gestionar los datos sensibles (como las cadenas de conexión) de nuestras aplicaciones, porque, claro, nadie debería de poner los datos de producción en el código fuente que grabamos en nuestro repo, ¿verdad?

Anteriormente las opciones pasaban por efectuar mezclas/transformaciones de tal manera que en tiempo de compilación se generara un archivo final con los datos sensibles correspondientes a cada entorno, lo cual si bien nos daba simplificación para colocar la clave correcta en el paquete y entorno correcto, nos obligaba a seguir versionando las cadenas de conexión en el código fuente (por no mencionar que había que compilar mas de una vez); la otra opción pasaba por gestionar dentro del entorno de destino (en nuestros ejemplos: WebApps) sobrescribiendo de esta manera los valores que vinieran desde el código fuente.

Dado que ni nuestro repositorio ni nuestra herramienta de integración/despliegue deberían contener datos sensibles, usaremos un servicio de nube que nos da la seguridad necesaria para gestionar nuestras credenciales, el Azure KeyVault, el cual nos permite almacenar de manera segura y granular ya sea certificados digitales como data sensible, pudiendo restringir quienes pueden acceder a que datos y a que no (aplicando Control de acceso basado en roles: RBAC). Un mecanismo usual de accesos a estos recursos sensibles es programar dentro de nuestra aplicación un código que lea los valores en tiempo de ejecución (procurando no releer el valor a cada uso, sino hacerlo una única vez), en este caso usaremos un enfoque distinto que consistirá en leer los valores almacenados en KeyVault durante nuestro pipeline de despliegue, alterando secciones del archivo appsettings.json (porque nuestro ejemplo se basara en .Net Core) que se alojara en nuestra Web App destino (aunque también funciona perfectamente en un despliegue sobre IIS).

Así que estos serán los pasos que seguiremos:

  • Crear un KeyVault
  • Crear un “Secret” dentro de nuestro KeyVault, ahí sera donde almacenaremos una cadena de conexión a la base de datos
  • Identificar el “Principal” mediante el cual nuestro Team Project se conecta a Azure
  • Dar los permisos sobre nuestro KeyVault a dicho principal
  • Identificar en nuestra aplicación las secciones a modificar en tiempo de ejecución
  • Enlazar nuestro TeamProject contra el KeyVault, fijando el scope respectivo
  • Configurar el reemplazo de valores en el appsettings.json
  • Validar que nuestros cambios han sido desplegados en el entorno destino

Para esta demo asumiremos que tendremos tanto un pipeline de Build como de Release, de una aplicación en ASP.Net Core, en nuestro ejemplo usare la aplicación de ejemplo del libro de EF Core in Action (excelente libro que tuve el honor de revisar) cuyo código fuente se puede descargar aquí, y claro, como es usual el despliegue lo haremos contra una Azure Web App.

Para el primer paso seguiremos las instrucciones dadas en la primera parte de este articulo, en mi caso he usado estos nombres: RG_DevmoVault01 para el Resource Group y ErnestoDemoKeyVault para el KeyVault, como en este caso la creación la hemos hecho vía linea de comandos verificaremos que podemos revisar este recurso en el Portal de Azure, así:

Finish Reading: Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

En el Microsoft Ignite 2018!!

Posted on by ecardenas

Estas semanas han sido muy intensas para mi pues tuve la ocasión de participar en el Microsof Ignite, que se realizo en Orlando el pasado Septiembre, y si, era la primera vez que iba a un evento de estas dimensiones, pero la emoción era mayor pues participaba como speaker al haber sido aprobada mi ponencia DevOps is about people, beyond automation, reto grande, ya que si bien es un tema que me es familiar significaba mi primera vez como orador en ingles, por lo que me pase un buen tiempo ensayando todos los días para estar a la altura del evento.

Domingo 23, MVP Preday donde nos dieron los ultimos tips para la presentación.

Ya en el evento en si, arrancamos con el Keynote de Satya Nadella, y tuve la suerte de poder ver de cerca la presentación.
Y antes de mi charla aproveche para visitar el stand de libros donde hojee dos de los libros que tuve la suerte de revisar para Manning

Y llego el momento, lunes 24 en el Expo Theater 6, tocaba presentar el material, felizmente todo salio bien ante mas de 100 asistentes.

Aquí con la gran Jessica Deen, de la League!!

Ya en los siguientes días, trate de aprovechar el evento con calma, pero primero atendí a una entrevista con el equipo de Microsoft Latam!!.

Ultimo día, mis pasos se dirigían con cierta pena al OCCC, pero contento por todo lo aprendido.

Con la promesa de regresar!!
Gracias OCCC y hasta la próxima!!!

Comparto mi sesión, esperando sus comentarios sobre estas visión de DevOps.

Presentando Azure DevOps

Posted on by ecardenas

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Posted on by ecardenas

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

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.

 

 

“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