GitOps, autoservicio y cero tickets: así se construye una plataforma interna
Dos ingenieros explican en KubeCon cómo pasaron de una plataforma que dependía de tickets manuales a otra declarativa, con soporte abierto y usuarios reconocidos.
Marcy Paramonova y Stéphane Cusin lo tienen claro: una plataforma interna no es infraestructura, es un sistema de colaboración por el que circula mucha comunicación. Los dos lo defendieron en su charla Building Cloud Native Culture in a Bank, en la KubeCon & CloudNativeCon Europe, y lo detallaron después en una entrevista. La tesis de fondo es que la cultura sigue a la estructura: si quieres una forma de trabajar concreta, diseñas el sistema que la produce en lugar de esperar a que aparezca sola.
El punto de partida era el clásico. El equipo de plataforma atiende a los equipos de producto, que a su vez dependen de él, y todos tienen que avanzar hacia el mismo sitio. Si cada acción requiere un ticket, una intervención manual o la ayuda directa de un ingeniero de plataforma, lo que se construye sin querer es una cultura de dependencia: los equipos esperan en vez de aprender a operar por su cuenta.
Autoservicio sin tickets
El principio que fijaron desde el primer día es que ninguna capacidad de la plataforma dependa de intervención manual. En lugar de abrir un ticket y esperar a que alguien haga el cambio, los equipos interactúan con la plataforma mediante configuración declarativa y flujos automatizados. Habilitar una capacidad es un cambio de configuración en Git que aplica el proceso de GitOps. El resultado es autoservicio con trazabilidad completa: saben qué capacidades se adoptan, cuáles han dejado de usarse y a qué usuarios afecta un cambio. Eso les ha permitido retirar funcionalidades muertas y migrar equipos con cierta tranquilidad.
En el plano humano montaron dos rituales. Uno es un "Genius Bar" dos veces por semana, dos horas por sesión: se va sin ticket y sin esperar a que alguien tenga hueco en la agenda, y sirve tanto para resolver un fallo como para entender cómo encaja un componente. El otro son premios para los super usuarios, desarrolladores que contribuyen activamente a mejorar la plataforma. Según Paramonova, ese feedback fue a veces duro de escuchar, pero ayudó a construir algo mejor. Y añade una consecuencia práctica: con estándares abiertos, las habilidades son transferibles y no hay que reaprender desde cero.
Ciclo de vida de cada capacidad
Cusin insiste en que las decisiones de plataforma tienen que ser visibles. Las capacidades se entregan como artefactos versionados, patrones de despliegue reutilizables e interfaces documentadas, no como acuerdos privados entre equipos. Cada funcionalidad tiene además un ciclo de vida declarado: quién la usa, cómo y si sigue aportando valor. Esa visibilidad permite evolucionar la plataforma a propósito en lugar de acumular complejidad.
La frase que resume su enfoque es que la cultura sigue a la estructura. "Si tu equipo se queja de que le interrumpen todo el tiempo, no culpes al otro equipo. Pregúntate si has definido una estructura para que la gente se ponga en contacto contigo", dice Cusin. Paramonova lo formula de otro modo: no se puede imponer una cultura por decreto, pero sí diseñar estructuras que hagan naturales ciertos comportamientos.
Para quien opera una plataforma interna, el interés está en que casi todo lo que cuentan es verificable en el día a día: GitOps como mecanismo único de cambio, artefactos versionados y un plan de retirada por capacidad. Lo que no hay son cifras de adopción ni detalles de implementación, y el caso es un solo banco. Tampoco hay atajos: son ritmos acumulados, no una herramienta que se instala.
