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

Deploy de contenedores a Heroku con GitLab

En mi opinión gran parte de la popularidad que alcanzó Heroku se debió a la facilidad con la que era posible desplegar una aplicación: git push. Básicamente teniendo el código fuente en un repositorio Git, solo basta con agregar un nuevo remote provisto por Heroku y hacer push al mismo. Cuando Heroku recibe el código fuente ejecuta un build-pack que básicamente “preparar el ambiente” para poder ejecutar el código recibido. Dependiendo del lenguaje ese build-pack puede instalar dependencias, compilar e incluso ejecutar migrations. Esta es seguramente la estrategia más utilizada al usar Heroku pero no es la única. Otra opción es ejecutar directamente un contenedor Docker. Esta opción trae un poco más de complejidad pero al mismo tiempo trae algunos beneficios interesantes.

La opción de utilizar un contenedor nos da más “libertad”/flexbilidad. Con el modelo de ejecución tradicional nuestra aplicación está restringida a lo establecido por el build-pack (aún cuando es posible crear build-packs, eso ya tiene otro costo), mientras que al correr un contenedor podemos poner lo que querramos dentro. Al mismo tiempo, al poder especificar el Dockerfile tenemos la posibilidad de ajustar ciertos aspectos del runtime. Finalmente, el correr un contenedor nos también la libertad de salir de Heroku a un costo más bajo.

En el contexto de MeMo2 @ Fiuba, utilizamos Heroku en modo “tradicional” durante el primer trabajo grupal pero para el segundo TP grupal tenemos la intención de utilizar un modelo basado en contenedores ya que queremos estudiar algunas de las implicancias de este modelo en términos de configuración management y deployment pipelines.

Explicada la motivación veamos entonces algunas cuestiones de implementación. En primer lugar debemos crear la imagen del contenedor que querramos ejecutar, para esto podemos delegar la creación de la imagen en Heroku o bien podemos crearla nosotros mismo y luego darsela a Heroku. Una vez que la imagen está construida y subida Heroku, basta una invocación a API rest para desplegarla (también es posible haciendo uso del heroku-cli). Al mismo tiempo, si es necesario ejecutar algún tipo de inicialización antes de levantar el contenedor Heroku nos da posibilidad de ejecutar un esa inicialización con otra imagen. Esto eso, debemos crear una imagen llamada “release”, subirla a Heroku y cada vez que disparemos un deploy Heroku, se ejecutar primero la imagen release para hacer las tareas de incialización y luego se pondrá a correr el contenedor de nuestra aplicación. Todo esto está explicado con bastante detalle la documentación oficial de Heroku.

Llevando todo esto a nuestro escenario de MeMo2, vamos construir nuestra imagen Docker como parte nuestro pipeline de GitLab y vamos a almacenarla en la propia registry de Gitlab. Luego en el paso de deploy haremos un push de la imagen a Heroku y dispararemos el deploy via la API Rest. A continuación comparto algunos snippets de código de nuestro pipeline que puede resultar útiles para quienes pretendan implementar una solución similar con Heroku y Gitlab.

El siguiente fragmento de código corresponde a job de GitLab que crea la imagen Docker y la publica en la registry de GitLab

package_job:
  stage: package
  image: docker:stable
  before_script:
    - echo -n $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY
  script:
    - VERSION=$(cat VERSION.txt)
    - docker build -f Dockerfile.prod -t $REGISTRY_URL/$APP_NAME:$VERSION .
    - docker tag $REGISTRY_URL/$APP_NAME:$VERSION $REGISTRY_URL/$APP_NAME:latest
    - docker push $REGISTRY_URL/$APP_NAME:$VERSION
    - docker push $REGISTRY_URL/$APP_NAME:latest

A continuación tenemos el fragmento de código correspondiente al job de deploy el cual descarga la imagen a desplegar de la registry de Gitlab y la sube Heroku. Finalmente invoca a script de deploy que interactua con la API Rest de Heroku.

deploy_dev_job:
  stage: deploy
  image: docker:stable
  before_script:
    - apk add curl
    - echo -n $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY
    - docker login -u _ -p $HEROKU_TOKEN registry.heroku.com
  script:
    - VERSION=$(cat VERSION.txt)
    - docker pull $REGISTRY_URL/$APP_NAME:$VERSION
    - docker tag $REGISTRY_URL/$APP_NAME:$VERSION registry.heroku.com/$HEROKU_APP/web
    - docker push registry.heroku.com/$HEROKU_APP/web
    - export IMAGE_ID=`docker inspect registry.heroku.com/$HEROKU_APP/web --format={{.Id}}`
    - ./scripts/deploy_app.sh

Finalmente este es el script que invoca a la API de Heroku (este script es algo que definitivamente puede mejorarse)

#!/bin/sh
set -x 

DATA='{ "updates": [ { "type": "web", "docker_image":"'
DATA="$DATA$IMAGE_ID"
DATA=$DATA'" } ] }'

curl -X PATCH https://api.heroku.com/apps/$HEROKU_APP/formation --header "Content-Type: application/json" --header "Accept: application/vnd.heroku+json; version=3.docker-releases" --header "Authorization: Bearer ${HEROKU_TOKEN}" --data "$DATA" --fail

Cierro con algunos comentarios:

  • Estos fragmentos de código requieren del uso de un API token de Heroku que debe ser configurado en las variables del ambiente del pipeline.
  • Ambos jobs del Gitlab asumen la existencia del un archivo VERSION.txt que contiene el tag correspondiente a la imagen docker que construye/publica/despliega. Típicamente ese archivo se genera en el build y se lo propaga por el pipeline o bien está en el repositorio de código fuente.
  • Estos fragmentos son ejemplos que pueden ser mejorados y/o ajustados para contextos más específicos. De hecho es muy posible que en los próximos días les aplique algunos ajustes.

Infra definida para el TP2 de MeMo2 @ fiuba

Después de varias averiguaciones y algunas pruebas de concepto ya tenemos bastante encaminado el diseño del pipeline e infraestructura del TP2. El sistema a construir consta de dos aplicaciones/artefactos: un bot de telegram y una web-api.

El bot de telegram lo vamos a correr en kubernetes, más precisamente en el servicio de Kubernetes de Azure utilizando la opción Azure for Students ofrecida por Microsoft, la cual incluye 100 dólares de crédito y no requiere de tarjeta de crédito.

Las web-api la vamos a correr en Heroku pero en lugar de usar el modelo de runtime tradicional de Heroku, vamos a correr la aplicación en un contenedor. Esto es: en lugar de hacer push del código fuente directo a Heroku, lo que hacemos es construir una imagen Docker y luego indicar a Heroku que corra un contenedor basado en esa imagen.

Si bien, en términos de infraestructura a bajo nivel, el bot y la api van a correr en distintos runtimes, a nivel proceso ambas aplicaciones correran como un contenedor Docker. Al mismo tiempo el proceso de build y deploy va a ser el mismo para ambas aplicaciones, ofreciendo al equipo de desarrollo una experiencia de trabajo uniforme. En un escenario real es poco probable utilizar una estrategia de este estilo, porque tener dos plataformas de runtime implica un mayor costo operacional pero en nuestro contexto creemos que puede resultar interesante para mostrar explícitamente a los estudiantes como, a partir de ciertas técnicas, es posible lograr un buen nivel abstracción de la infraestructura.

El pipeline de CI/CD lo implementaremos con GitLab utilizando la suscripción Gold que GitLab ofrece para contextos educativos.

Un detalle que me parece relevante mencionar es que, si bien vamos a utilizar productos/servicios de determinados vendors, tenemos la intención de mantener la menor dependencia posible con caraterísticas específicas/propietarias de cada vendor.

En siguientes artículos explicaré como será el modelo de ambientes y pipelines que armaremos tomando esta infraestructura de base.

Nuevos cursos, nueva modalidad

Desde hace varios años vengo dictando cursos más a allá de mis materias en la universidad. Si bien las temáticas de mis cursos es compartida con los temas que suelo dictar en mis materias, los cursos implican un desafío distinto que amerita una dinámica distinta.

Una materia tiene usualmente (en Argentina) una duración de 16 semanas, lo cual permite “cocinar a fuego lento”, un mismo tema puede verse varias veces, con distintos abordajes, dando al estudiante tiempo y material complementario para digerirlo durante la materia.

Mis cursos han sido típicamente “one-shot”, uno o dos días, consecutivos, varias horas de corrido con duraciones totales variando entre 4 y 16 horas de clase. Sin embargo, para ayudar en el entendimiento de los temas, todos mis cursos tienen una parte práctica importante y es por ello que prefiero utilizar el término “taller” más que “curso”.

Creo que esta modalidad on-shot va bien para cursos/talleres introductorios, donde los participantes vienen a tener un primer acercamiento al tema y se llevan una lista de cuestiones para investigar/profundizar. El tema es justamente que esa investigación/profundización queda en manos del participante y completamente fuera del alcance curso. Para los casos en los que la inversión la hace el propio participante, el retorno de la inversión de haber participado del curso queda a criterio del participante. Pero para los casos en los que la inversión la hace una organización, las expectativas de retorno de la inversión son distintas. Usualmente la organización espera algún impacto positivo en el desempeño de la gente que participa del curso, lo cual me parece completamente razonable.

En 2019 hice un par de experimentos de cursos de “larga” duración, varios encuentros cortos (~90 minutos) a lo largo de varias semanas, con tareas para hacer “fuera del aula”. En aquel momento fueron un conjunto de talleres sobre Docker y Kubernetes y anduvieron muy bien. Esta misma dinámica utilizamos en el Seminario de Software Delivery y también tuvimos buenos resultados. Pero en el caso del seminario fuimos un paso más allá y en el trabajo final les propusimos a los alumnos que trabajen sobre una problemática de su organización. Con esta estrategia estoy diseñando mis nuevos cursos: 100% remoto, varias semanas, con un encuentro semanal de ~90 minutos, con trabajo e interacciones entre encuentros y con actividades de aplicación en el contexto/proyecto/organización de cada participante.

El primer curso que voy a ofrecer aún no tiene título pero tengo la intención de utilizar el stack de herramientas con el que estuve trabajando gran parte de 2020: netCore, Gitlab y Docker/Kubernetes. El foco del curso será Continuous Delivery. En los próximo días estaré publicando más información al respecto.