4 libros de Agile no tan conocidos pero excelentes

Continuando el aniversario de los 20 años del manifiesto ágil parece un buen momento para compartir algunas recomendaciones de libros.

El primero es la joya oculta de mi biblioteca: Planning Extreme Programming. Estoy seguro que mucha gente ni lo escuchó nombrar pero definitivamente vale una mirada aunque más no sea por sus autores: Kent Beck y Martin Fowler. A pesar de ser un libro de XP no es un libro de código, como su nombre lo indica es un libro de planificación que cubre también varias cuestiones de generales de gestión obviamente desde una perspectiva de XP. No es un libro reciente, es del año 2000, o sea que es previo a la publicación del manifiesto. Al igual que todos los libros la serie XP, el contenido está organizado en capítulos cortos, lo cual facilita la lectura.

Tengo dudas de incluir en este listado el libro The Art of Agile Development de Shore y Warden porque tengo la sesión que es un bastante conocido. Si bien no lo indica en el título, es un libro de XP. Fue publicado en 2007 y en estos días (marzo 2021) se está escribiendo en forma abierta la segunda edición la cual parece muy prometedora. El libro es excelente y es la referencia central de mi materia de Ingeniería de Software. Cubre muchísimas cuestiones que van desde mindset, pasando por temas de gestión y hasta cuestiones de código. Es en un libro de ingeniería de software al estilo XP.

Agile!: The Good, the Hype and the Ugly es un libro un tanto polémico para “los agilistas”. Lo conocí gracias a mi amigo @dfontde. El autor del libro es Bertrand Meyer, un referente en el mundo académico de la ingeniería de software. El libro es tal cual lo que indica su título: lo bueno, lo feo y lo popular de agile. Personalmente no comparto algunas de las apreciaciones del autor y justamente por eso lo recomiendo. Resulta interesante leerlo porque Meyer es un referente que lleva muchos años en esta disciplina y que en cierto modo muchos lo asociamos a métodos más tradicionales/pre-agile. Un aporte interesante del libro es que para parte del análisis que hace de agile toma las 10 prácticas ágiles que considera más relevantes/representativas de agile.

Otro libro de un autor reconocido es More Effective Agile, este libro aún lo estoy leyendo, pero lo que llevo leído me pareció excelente. Es un libro reciente, fue publicado a mediados de 2019. Su autor es Steve McConnell, un reconocido autor de libros de ingeniería de software entre los que se encuentran Code Complete, Rapid Development y Software Estimation: Demystifying the Black Art. Hay dos cuestiones que me llevaron a leer este libro. Por un lado, ya había leído mucho material de McConnell (además de sus libros también tiene publicados muchos artículo interesantes) y quería saber su visión de agile. Por otro lado, al ser un libro reciente, me resultaba interesante averiguar qué hay para decir de agile a casi 20 años del manifiesto cuando ya se han publicado cientos de libros de agile. La visión de agile que ofrece McConnell la sentí muy afín con mis propias ideas. En esa visión McConnell desmistifica y corrige algunas falsas creencias (y argumentos de venta) de Agile.

Seminario de Postgrado en Software Delivery (2º edición)

Desde hace un par de semanas que venimos preparando esta segunda edición que viene con algunos cambios. En primer lugar hemos ajustado la frecuencia de los encuentros, en esta ocasión serán cada 2 semanas. Por otro lado también cambiamos algunas cuestiones de la dinámica general como ser el hecho de que esperamos que los participantes comiencen su trabajo final ya desde el segundo encuentro para de esa forma poder hacer desarrollos de mayor grado de profundidad e impacto. Otro de los cambios es que esperamos contar con invitados especiales que vengan a compartir sus casos de aplicación de los temas que vemos en seminario. Las fechas de los encuentros de esta edición y los detalles del programa está disponibles aquí.

La semana próxima, el miércoles 17 de marzo, a las 9:30 hs hora argentina (GMT-3) haremos una charla de presentación del seminario donde apuntamos a contar brevemente sobre el contenido, la dinámica y también contestaremos dudas de los interesados. La participación en esta charla es gratuita pero requiere registración, simplemente hay que completar este formulario y les enviaremos el link de acceso.

Consultores DevOps: entre purismo, pragmatismo, ética profesional y complicidades

La semana pasada comencé a trabajar en la segunda etapa de una iniciativa “DevOps”. Luego de la reunión del kick-off un colega que está trabajando conmigo en este proyecto pero que no había participado de la primera etapa me consulta: “¿qué onda esto de armar pipelines de deployment de aplicaciones sin ningún tests automatizado?”

¿Qué onda? Riesgoso. Lo hablé con el cliente y fui muy explícito:

“Por este camino más que DevOps vamos a hacer DevOoooops!”.

Habiendo hecho la advertencia del caso y siendo conscientes que el término DevOps queda grande para lo que estamos haciendo, mantuve mi ética profesional. Dejé mi purismo de lado y me convertí en complice de la situación con el único objeto de lograr una mejora en el proceso de software delivery. Concretamente lo que estamos haciendo es automatizar el proceso de build y deployment.

Previo a nuestra intervención varios proyectos generaban sus binarios en la máquina de un developer y luego los hacían llegar al área encargada de deployments via un sistema de tickets. Algunos otros equipos tenían un Jenkins, pero solo para compilación. Los encargados del deployment ejecutaban entonces varias tareas manual para desplegar el binario pedido en el ambiente especificado. En este este contexto estamos buscando que:

  • Todo el código esté almacenado en la herramienta oficial de versionado de la organización (GitLab)
  • Todos los binarios se generen en un servidor (GitLab-CI) sin depender de la máquina de ningún developer
  • Los binarios generados sean subidos automáticamente a un repositorio de binarios (Nexus)
  • El proceso de deployment comience descargando el binario a desplegar desde el repositorio de binario y a continuación ejecute un script parametrizado de forma de utilizar el mismo script para despliegue a todo ambiente.
  • El proceso de deployment sea ejecutado por una herramienta de CI/CD (GitLab-CI)

¿Esto es hacer DevOps? Esto solo no lo es. Sin duda una estrategia DevOps debería incluir versionado y automatización, pero también muchas otras cuestiones como colaboración entre negocio-desarrollo-operaciones, entrega frecuente, manejo de infraestructura como código, integración continua y pruebas automatizadas (como bien observaba mi colega).

Personalmente suelo hacer mucho hincapié en todas esta cuestiones y las aplico en todos los proyectos en los que trabajo como team member. Sin embargo, cuando hago trabajo de consultoría, no está en mí decidir qué prácticas aplicar. Claro que sugiero (con mucho énfasis en general) pero la priorización y decisión está en manos del cliente. Lo que suele ocurrir es que dentro de todo el set de prácticas DevOps, una de las que ofrece mayor visibilidad y retorno temprano de inversión es la automatización de deployments. Entonces se suele comenzar automatizando los deployments de una aplicación y a continuación surge el dilema, ¿avanzamos en ancho o en profundidad?. O sea: ¿seguimos trabajando sobre esa aplicación para agregarle pruebas automatizadas (y demás prácticas)? o ¿nos movemos al equipo de al lado para seguir automatizando deployments? En general mis clientes suelen optar por lo segundo, avanzar en ancho y dejar en manos del cada equipo el avance en profundidad (pero esto no siempre ocurre). Obviamente que esto no es lo mismo en todos los clientes, esta descripción corresponde a una organización muy grande con cientos de equipos de equipos de desarrollo y varios cientos de aplicaciones.

En fin, esta es la vida del “consultor responsable”, bailar el fino equilibro entre purismo y pragmatismo honrando siempre la ética profesional.

El impedimento de “ser especial”

Creo que la mejor forma de explicar mi punto es con un ejemplo concreto. La cuestión es más o menos así:

  1. Me contacta una persona de una organización para mejorar algún aspecto de su proceso de software delivery.
  2. Agendamos una charla.
  3. Hablamos un rato, primero escucho, pregunto algo y sigo escuchando.
  4. Luego le cuento a mi interlocutor algunas cuestiones de mi forma de trabajo.
  5. Preguntas, respuestas, escucho, pregunto, respondo y finalmente acordamos (a pedido mio) coordinar una reunión con la gente que está en “la trinchera”
  6. En esa reunión con “la gente de la trinchera” yo intento validar la situación problemática descripta inicialmente por quien me contactó. Para ello escucho y pregunto. A medida que voy confirmando la situación voy haciendo alguna pregunta/sugerencia del tipo “¿Y ante eso probaron XYZ?” siendo XYZ típicamente una práctica ampliamente difundida.
  7. Es en ese punto donde aparecen respuestas del tipo “XYZ no funciona aquí porque este es un contexto especial”

Ahí está, el primer impedimento para el cambio y la mejora. Gente que tiende a creer que es especial, que tiene problemas que nadie más tiene, que su problema es único y nadie más en el mundo lo tuvo.

Bueno amigos, tengo una noticia, no sois tan especiales

“Es que nadie tiene que lidiar con el incompetente de mi jefe” y tal vez sea cierto, pero seguramente hay gente que tuvo que lidiar con jefes mucho más incompetentes. Y lo superaron.

No pretendo herir los sentimiento de nadie, tal vez seas especial, pero eso no implica que tu problema no tenga solución o que tu situación no tenga chances de mejora o ninguna de las prácticas/técnicas ampliamente probadas no puedan intentarse en tu contexto.

Un patrón que encuentro en estos casos es que “la gente especial” muchas veces ni siquiera hace el intento. No se preocupan en estudiar seriamente el problema y sus posibles soluciones. Se quedan en “su caso especial”. Caso típico “este contexto es muy especial no podemos estimar” ¿y cuántos libros/artículos leyeron sobre estimación? ¿cuántas técnicas probaron? La respuesta suele que nunca leyeron nada, o que tal vez leyeron algo en una materia en la universidad pero ni siquiera recuerdan lo que fue.

No está mal pensar que somos especiales (pues tal vez lo seamos), pero por favor que eso no sea un excusa para evitar el esfuerzo de intentar mejorar.

Para cerrar les comparto un breve fragmento de la película Los Increibles: “Decir que todo el mundo es especial es otra forma de decir que nadie lo es” 🙂

(adelantar hasta 1:57)

De Gitlab a Azure Kubernetes Service

IMPORTANTE: escribo este post principalmente como una nota personal para futura referencia. El procedimiento que describo aquí es el que seguimos para hacer el setup de la infraestructura que utilizamos para el trabajo final de memo2@fiuba. En este contexto de cara a no tener dependencia fuerte con ningún proveedor hemos decidido armar nuestra infraestructura sin hacer uso de ninguna característica particular de las herramientas de ningún vendor. Es por eso que este procedimiento podría utilizarse con mínimos cambios para conectar con cualquier otro proveedor de Kubernetes y al mismo tiempo también podrían utilizarse con otra herramienta de CI/CD que no sea GitLab. En este caso estamos utilizando las suscripciones educativas tanto de Azure como de GitLab.

Creación de cluster

Al crear el cluster simplemente elegimos el tamaño de nodo, en nuestro caso B2S y especificamos 2 nodos. Adicionalmente debemos especificar un grupo para los recursos que se crearán como parte del cluster, en nuestro caso pusimos “memo2” y obviamente necesitamos un nombre para cluster, en nuestro caso “cluster-memo2-prod”. Finalmente desactivamos la funcionalidad de monitoreo porque está fuera del scope de nuestra suscripción. Esto representa un costo mensual aproximado de ~ us$ 73, lo cual está bien ya que la suscripción nos ofrece 100 dólares de crédito y nosotros solo necesitamos el cluster 1 mes.

Una vez creado el cluster, el siguiente paso es descargar la configuración de conexión para kubectl (el cliente kubernetes). Para esto es necesario en primera instancia utilizar el azure-cli. La opción obvia es instalar el azure-cli, pero también está la opción de usar un “cloud shell” de azure que nos abre un shell en la ventana del navegador y que tiene el azure-cli instalado. Una vez que tenemos el azure-cli a mano (ya sea instalado en nuestra máquina o usando el cloud shell) debemos ejecutar los siguientes dos comandos:

az account set --subscription <subscription id>
az aks get-credentials --resource-group <resource group> --name <cluster name>

El segundo comando “instala” la configuración para conectarnos al cluster, lo cual significa que tenemos un archivo en ~/.kube/config con todos los parametros de configuración de conexión. Ejecutando “kubectl version” deberíamos ver la versión de nuestro kubectl y la versión de kubernetes que corre el cluster.

Con esto ya estamos en condiciones de conectar nuestro GitLab con el cluster creado.

Conexión Gitlab > Kubernetes

El primer paso, es crear una cuenta de servicio para que gitlab se conecte al cluster. Esto lo hacemos con este manifiesto.

Una vez creada la cuenta de servicio necesitamos obtener su token para lo cual ejecutamos los siguientes comandos:

# primero creamos la cuenta de servicio
kubectl apply -f gitlab-service-account.yaml

# luego buscamos entre los secrets el correspondiente a la cuenta creada
kubectl get secrets

# finalmente hacemos un describe del secret para poder obtener su token
kubectl describe secret <nombre del secret>

Ya con todo esto podemos proceder la configuración del cluster en GitLab

En el formulario de configuración del cluster completamos los campos de la siguiente forma:

  • Kubernetes cluster name: el nombre con el cual queremos identificar el cluster, en mi caso “cluster-memo-prod”
  • Environment scope: el ambiente que este cluster representará, en mi caso será “prod”. Este ambiente luego será referenciado dentro del pipeline de CI/CD
  • API URL: la sacamos de la configuración de kubectl, es el campus server. Lo podemos obtener haciendo “cat ~/.kube/config | grep server“
  • CA Certificate: también lo obtenemos de la configuración de kubectl haciendo “cat ~/.kube/config | grep certificate-authority-data“. Pero, adicionalmente hay que desencodearlo, entonces podemos poner el valor en una variable y ejecutar: “echo $CERT | base64 -d“
  • Service token: aquí utilizamos el token de la cuenta de servicio que creamos previamente
  • RBAC-enabled cluster, GitLab-managed cluster, Namespace per environment: en el caso de MeMo2 no hacemos uso de ninguna de estas funcionalidades con los cual dejamos las 3 opciones como unchecked
  • Project namespace prefix (optional, unique): esto tampoco lo utilizamos con lo cual no dejamos en blanco

Algunas reflexiones a 20 años del manifiesto ágil

En estos días se están cumpliendo 20 años de la publicación del manifiesto ágil. Mucha agua ha corrido bajo el puente.

Agile se volvió mainstream (¿hacia ~2010?).

Alguna gente llegó, probó y se fue (¿los menos?).

Otra gente llegó, se enamoró y ahora abraza árboles (¿demasiados?).

Están también los fundamentalistas, que incorporaron Agile a su vida y evangelizan con Agile a todo el que se cruza (¿coaches?).

Están también los pragmáticos no fundamentalista que ven los métodos ágiles como una herramienta útil para ciertos contextos pero que no dudan en dejar Agile de lado si ven un enfoque que calza mejor para el contexto (¿yo?)

Obviamente también hay gente que aún no llegó (¿llegarán algún día?).

Como dirían algunos amigos, también están los “vende humo” (como en todo negocio ¿no?)

Siempre que hay una moda, están los contra, en este caso los “anti-agile” que, en gran medida debido a los abrazadores de árboles y a los vende humo, creen que Agile es puro cuento y militan en su contra.

Sin duda podríamos seguir enumerando posiciones respecto a Agile, pero creo que con esto basta para exponer la situación.

El término “agile” a mi entender ha perdido un poco de significado, ha sido utilizado para referirse a cosas muy distintas, basta ver algunas conversaciones de twitter para confirmarlo.

Uno lee el manifiesto y en los primero años de los 2000, hablar de Agile es prácticamente XP, equipos chicos, autogestionados, que construyen software con excelencia técnica, tal como sugiere el manifiesto. Hacía el 2010 la situación cambia y Scrum toma el lugar de mayor popularidad. Nos inundan los post-its. Empezamos a ver equipos agile que no construyen software con excelencia técnica (Flaccid Scrum). Tiempo después aparecen los enfoques de escalamiento y todo el “Agile Industrial Complex” y los equipos casi que dejan de ser autogestionados y cierta burocracia renace. Esto da origen a un movimiento “revolucionario” de vuelta a las raíces y los enfoques de Modern Agile y Heart of Agile empiezan a cobrar relevancia en contraposición a las propuestas de escalamiento como SAFe.

En fin, realmente hay discusiones y usos de Agile que son de lo más diverso. Pero hay un hecho innegable: agile ha tenido un importante impacto en IT tanto a nivel industrial como académico. Y a mi parece ese impacto ha sido muy positivo.

Justamente con motivo de estos 20 años de Agile, estas semanas se han organizado diversos eventos relacionados a Agile. En mi caso estaré participando este viernes 12 de febrero en un conversatorio con formato fishbowl sobre DevOps. Este evento es organizado por la gente de RunRoom. La participación es gratuita pero requiere registración aquí.

Cucumber modo dual

Cucumber es la “herramienta insignia” de BDD. Permite escribir ejemplos (pruebas) ejecutables utilizando Gherkin, una sintaxis amistosa para gente no técnica.

Una de las particularidades de Cucumber es que provee una muy buena experiencia para el desarrollador pues tiene la capacidad de instanciar dentro del mismo proceso la ejecución de la pruebas y la aplicación a probar incluso cuando la aplicación bajo prueba es una aplicación web[*]. Esto tiene algunas implicancias interesantes como ser:

  1. Las pruebas corren mucho más rápido (comparado a si corrieran pruebas y aplicación en procesos separados) lo cual se traduce un feedback más rápido para el desarrollador
  2. Es posible desde las pruebas acceder el estado interno de la aplicación simplificando las tareas de setup (Given/Arrange) y verificación (Then/Assert) de las pruebas

Es importante tener presente que estas dos cualidades pueden traer también algunas complicaciones (pruebas inconsistentes, resultados incorrectos, etc) sino no se toman ciertas precauciones al momento de automatización de las pruebas.

Resulta interesante tener presente que si escribimos nuestras pruebas con cierta precaución en el uso de 2 (o sea: si evitamos acceder el estado interno de la aplicación por fuera de su interface pública) podemos entonces utilizar el mismo set de pruebas para probar la aplicación ya instalada en un ambiente de prueba.

Tenemos entonces dos usos posibles de Cucumber: 

  1. Como herramienta del programador, utilizándola en su máquina local para guiar su desarrollo y obtener feedback instantáneo de la ejecución de los ejemplos acordados con el usuario
  2. Como herramienta para ejecutar las pruebas de aceptación y regresión en un ambiente de prueba, siendo estas pruebas las mismas que el programador utilizo para guiar su desarrollo

Si bien en este caso estoy hablando de Cucumber (ruby) estas cuestiones que menciono también aplican a otros frameworks/tecnologías.

Mientras termino de escribir estas línea me doy cuenta que para entender mejor este tema puede resultar muy conveniente ver algo de código, por ello en los próximos días estaré publicando un video mostrando ejemplos de código.

[*] esto en parte tiene que ver con capacidades de Cucumber pero también con las abstracciones y capacidades de otras herramientas del stack de Ruby como Rack.

Dos estrategias para la adopción de DevOps

Partiendo de la premisa que DevOps viene a intentar mejorar el flujo de software delivery, reduciendo las fricciones entre desarrollo y operaciones, intentando incluso derribar los silos, me he encontrado con distintas estrategias de implementación. De forma muy simplificada he logrado identificar dos patrones recurrentes cuando una organización adopta una estrategia DevOps. A falta de creatividad en este artículo las denominaré “Desarrollo Empoderado” y “Operaciones Serviciales“.

Desarrollo Empoderado

Esta estrategia implica empoderar a los equipos de desarrollo para tomar responsabilidad sobre todo el proceso de delivery. Esto tiene dos implicancias fuertes. Por un lado el equipo de desarrollo incorpora más responsabilidades y habilidades, se involucra con la infraestructura, el pipeline de delivery, etc. Por el otro el equipo de operaciones “suelta” un poquito, comparte más con los equipos de desarrollo a partir de involucrarse en el día a día del proyecto, etc. Incluso en algunos casos una persona de operaciones se suma como un team member más al equipo de desarrollo.

Operaciones Serviciales

En esta estrategia operaciones sigue manteniendo cierta distancia con desarrollo pero a partir de un fuerte trabajo de automatización facilita el día a día del equipo de desarrollo proveyendo una experiencia que podríamos denominar “operaciones como servicio”. En estos casos la visión de operaciones es: “que desarrollo se concentre en las user stories y hagamosle la vida lo más simple posible y que con un par de clicks puedan tener acceso los recursos que necesiten“. Esto requiere obviamente, incorporar habilidades, herramientas y sobre todo proactividad, colaboración y vocación de servicio.

En cierto modo estas dos estrategias, descriptas aquí de forma muy simplificada, pueden ubicarse en dos extremos de un continuo de estrategias que incorporan elementos de cada una.

Personalmente, trabajando en desarrollo, me siento mucho más cómodo con la estrategia Desarrollo Empoderado, pero soy consciente que puede no ser así para todos los desarrolladores y también que en algunas organizaciones puede ser más conveniente una estrategia del estilo Operaciones Serviciales.

Plan 2021: en busca de la nueva normalidad y de proyectos .NetCore

Como todos los años, a comienzos de 2020 hice mi plan de alto nivel para todo el año. Luego llegó la pandemia y ese plan sufrió algunos cambios mayores. Ahora, comenzando 2021, aún no termino de armar mi plan anual. Mentalmente estoy intentando ver este año, no como un año excepcional, sino como un año de “nueva normalidad”.

Esta nueva normalidad implica nuevos hábitos, nuevas situaciones, nuevas formas de proceder, algunas de las cuales ya conocemos y hemos incorporado, como el lavado de frecuente de manos. Pero al mismo tiempo hay algunas cuestiones de esta nueva normalidad que aún no hemos descubierto (¿cómo es un casamiento en esta nueva normalidad?) y eso representa una oportunidad (casi obligada) de experimentar.

En cuestiones laborales creo que ya he encontrado varias de las dinámicas de la nueva normalidad, pero en cuestiones personales aún sigo buscando la vuelta a varias situaciones y algunas de esas cuestiones impactan en cuestiones laborales.

En este contexto, mi plan 2021 en lo referente a cuestiones laborales tiene varias intenciones pero muy pocas certezas.

A nivel docencia, más allá de mis materias de ingeniería de software en UBA y UNTREF, durante el primer cuatrimestre estaré dictando la segunda edición del Seminario de Software Delivery. Esto está confirmado.

A nivel investigación, tengo la intención de hacer la tesis para completar mis estudios de maestría, pero aún no estoy seguro que pueda tener el tiempo necesario para hacerlo.

A nivel industria tengo ganas de trabajar con .netCore (ya que es con C# donde tengo mi mayor expertise) o python (que he usado principalmente para scripting pero que tengo ganas de aprender más), pero esto es un tema medio azaroso pues depende de lo que me pidan los clientes. Por otro lado, al margen de la tecnología, me gustaría trabajar en una empresa de desarrollo de producto, o sea, una empresa que deba manejar varias versiones de su producto (ya sea porque cada cliente tenga potencialmente una versión distinta o porque a cada cliente se le ofrezcan distinto conjuntos de funcionalidades). Me interesa este tipo de contextos porque creo que plantea una serie de desafíos técnicos y de coordinación a nivel negocio-desarrollo en los que me parece me podría divertir bastante. Si alguien sabe de contextos así donde yo pueda aportar (con dedicación parcial), no duden en contactarme ;-).
Al margen de mi gustos, por el momento, los proyectos que tengo agendados están más relacionados a cuestiones de consultoría en temas de DevOps.

Kubernetes: logs y sidecar containers

Al trabajar con Kubernetes es posible acceder a los logs de nuestras aplicaciones/contenedores utilizando la herramienta kubectl. Para la etapa de desarrollo (por ejemplo cuando estamos trabajando con Minikube) esto puede estar bien, pero para un ambiente de test/producción esta solución se queda corta por múltiples motivos. Principalmente no resulta seguro ni cómodo andar conectandose con kubectl a un cluster productivo. Una solución bastante habitual para esta problemática es utilizar alguna solución de agregación de logs. Estas soluciones consisten básicamente en concentrar todos los mensajes de log en un almacenamiento centralizado y explotarlo con alguna de visualización. Para concentrar los mensajes de logs se suele hacer lo siguiente: junto con el contenedor de nuestra aplicación desplegamos desplegamos en el mismo pod un contenedor sidecar. Este contenedor sidecar colecta los mensaje de logs generados por nuestra aplicación y los envía un concentrador. El siguiente gráfico muestra un esquema de esta solución

Existen varias herramientas para implementar esta estrategia. En el contexto de la arquitectura de referencia que estamos armando para el trabajo práctico final de MeMo2@fiuba vamos a utilizar la propuesta de Sumologic. Para esto utilizamos un container de Sumologic, desplegado como sidecar, que recolecta los logs de nuestra aplicación y los envía a Sumologic que almacena los mensajes, los procesa y los pone disponibles via una interface web.

El siguiente fragmento de código muestra un posible descriptor de deployment para implementar esta solución.

De acuerdo a esta configuración, tenemos los dos contenedores compartiendo un volumen (logs-data). El bot (la aplicación en cuestión) escribe los mensajes de log en ese volumen de donde son leídos por el colector de Sumologic. Adicionalmente el colector de Sumologic tiene un segundo volumen (config-data) de donde lee su configuración. Al mismo tiempo ambos contenedores reciben como variables de ambiente algunos secrets (el telegram token, la key de sumologic, etc) y demás parámetros de configuración (el log level por ejemplo).

Nota 1: el uso de sidecar containers es un patrón muy popular que se utiliza para algunas otras cuestiones más allá de la recolección de logs.
Nota 2: por cuestiones de foco hay fragmentos de código del deployment que fueron removidos para dejar solamente el código relevante para este artículo