La historia de mi equipo es muy reveladora. Empezamos como una prueba de concepto para modernizar parte del stack y mejorar la deployment frequency de algunos productos. De esto hace ya dos años, aunque el primero no fue nada fácil.

Payvision era una organización con diez años de .NET, SQL Server y Windows a sus espaldas; un stack bien sólido. La infraestructura —completamente on-premise— se administraba desde nuestra sede en Amsterdam. Nuestro margen de maniobra estaba muy limitado y las herramientas de las que disponíamos no resultaron efectivas fuera del mundo Microsoft.

La estrategia no contemplaba adoptar Kubernetes a puñetazos; sin embargo, estos fueron los cimientos de Atlas, la plataforma que operamos hoy en día. Virtualizamos sobre VMware, y Red Hat Enterprise Linux es el sistema operativo donde corren los contenedores que orquestamos a través de varios clusters de Kubernetes. Administramos nuestro propio registro de imágenes con Harbor y mantenemos varios clusters de Elasticsearch. Los agentes de entrega continua y algún que otro producto de seguridad cuelgan también de nuestro backlog.

Trabajar con un stack «manejable» es sin duda alguna la lección más valiosa que hemos aprendido. Nos movemos en un entorno donde la novedad golpea con una frecuencia casi diaria; sin embargo, nos gustaría ser early adopters de muchos proyectos que entran en la CNCF. La experiencia nos obligó a concretar un budget de innovación.

Para materializar este nuevo balance revisamos una cláusula de nuestro contrato: la que destina el 10 % de nuestro tiempo a formación. Tradicionalmente hemos podido dedicar este tiempo a jugar con nuevas tecnologías, preparar charlas o contribuir a proyectos open source. Nuestra propuesta para los viernes de proyectos se puede entender como una iteración sobre esta cláusula:

  • Todos los viernes. Se trata de un esfuerzo significativo para cualquier organización, ya que requiere casi un 20 % del tiempo del equipo.
  • Propuestas concretas. La motivación, los objetivos y el scope de cada proyecto quedan recogidos en un repositorio gestionado por el equipo. Los resultados y las conclusiones de cada proyecto también forman parte de este repositorio.
  • Aprobación del equipo. El visto bueno necesario para empezar a trabajar en un proyecto se otorga por unanimidad y ningún agente externo al equipo interviene en la toma de decisiones.
  • Solo para proyectos. Este plan se concibe con un enfoque pragmático y no contempla cursos de formación ni certificaciones.
  • Completamente opcional. Como estas condiciones no aparecen en nuestro contrato, cada miembro del equipo es libre de adherirse o no a ellas. No se trata de una imposición.

Me atrevería a definir esta iniciativa como una solución de compromiso. De lunes a jueves se trabaja por y para el backlog: boring stack y eficacia a corto plazo. Los viernes, en cambio, quedan blindados para invertir en soluciones que nos permitan mejorar como equipo y ampliar horizontes.

Dios me libre de recomendar abiertamente este modelo, ya que todavía no disponemos de métricas que respalden su eficacia. Hoy me limito a compartirlo con el mundo, libre de toda responsabilidad.