Qué construimos con él
Los contenedores son cómo se empaqueta todo lo que escribimos. Un servicio de backend, un trabajo programado, un entorno de compilación: cada uno es una imagen con sus dependencias fijadas dentro, así que «en mi máquina funciona» deja de ser una categoría de bug.
El beneficio práctico aparece cuando alguien nuevo se incorpora a un proyecto. En lugar de un documento de instalación con seis meses de retraso, hay un archivo de compose: un comando levanta el servicio, su base de datos y sus dependencias en las versiones que el proyecto usa de verdad.
Dónde lo hemos usado
Todo nuestro trabajo de backend está contenerizado, incluidos los servicios detrás de los proyectos de nuestro portfolio. Este sitio también se construye y se despliega como imagen de contenedor.
Cuándo lo recomendamos
Para cualquier servicio que vaya a desplegarse en un sitio distinto de la máquina donde se escribió, es decir, todos. El coste es un Dockerfile; el retorno es una build reproducible y una historia de despliegue que no depende del estado del servidor.
Donde discutiríamos es en contenerizar un flujo de desarrollo local que ya es simple. Si un proyecto es un único binario sin dependencias, un contenedor alrededor del ciclo de desarrollo añade fricción sin añadir mucho. Publica la imagen; no necesariamente desarrolles dentro de ella.
En producción esas imágenes corren sobre Kubernetes.
