Docker: por qué «en mi ordenador funciona» dejó de ser una excusa

Hasta mediados del siglo pasado, cargar un barco de mercancía significaba descargar caja a caja, saco a saco, cada uno de una forma distinta, con cuadrillas enteras de estibadores tardando días en un solo puerto. Todo cambió cuando alguien tuvo una idea que hoy parece obvia: meter la carga en cajas metálicas de un tamaño fijo, iguales entre sí, que cupieran igual en un barco, en un tren o en un camión sin que nadie tuviera que tocar lo que había dentro. El contenedor no cambió lo que se transportaba. Cambió que el barco, la grúa y el camión dejaran de necesitar saber qué había dentro para poder moverlo.

El software tuvo el mismo problema durante décadas, y lo resolvió con la misma idea.

#El problema que existía antes

Un equipo de desarrollo construye un programa en su propio ordenador. Ahí funciona perfectamente. Cuando llega el momento de ponerlo en marcha en el servidor real, donde de verdad lo va a usar el negocio, algo falla que en el ordenador del desarrollador nunca falló. Casi siempre es lo mismo: una versión distinta de alguna pieza de la que ese programa depende —una librería, un lenguaje, una configuración del sistema— que en un sitio está y en el otro no está, o está pero con un número de versión distinto.

De ahí sale la frase que da título a este artículo, repetida en incontables reuniones técnicas durante años: «pues en mi ordenador funciona». No es que quien lo dice esté mintiendo. Es que su ordenador y el servidor real son dos entornos distintos que solo se parecen en apariencia, y esa diferencia invisible es la que decide si algo funciona o se rompe.

El coste de este problema no era anecdótico. Poner en marcha un sistema nuevo en un servidor podía llevar días enteros de ajustes manuales, probando versión tras versión hasta que todo encajara, y cada vez que había que repetir ese proceso —en un servidor nuevo, en el ordenador de un desarrollador que se incorporaba, en un proveedor distinto— había que volver a pasar por lo mismo desde cero.

Un caso muy repetido, antes de que este problema tuviera solución: un equipo prepara una demostración importante, todo funciona sin fallos durante los ensayos en los portátiles del equipo, y el día de la presentación, al montar el sistema en un ordenador distinto para enseñarlo, algo se rompe por una diferencia mínima de configuración que nadie había anticipado. El fallo no tenía nada que ver con el trabajo del equipo ni con la calidad del producto; tenía que ver con la máquina en la que se estaba abriendo, y eso, para quien está delante viendo fallar la demostración, es indistinguible de un producto mal hecho.

#Qué resuelve empaquetar la aplicación con todo lo que necesita

Docker resuelve ese problema con la misma lógica que el contenedor marítimo: en vez de mover el programa solo y confiar en que el sitio de destino tenga todo lo que ese programa necesita, se empaqueta el programa junto con todo lo que necesita para funcionar —la versión exacta de cada pieza, la configuración exacta— en una unidad cerrada que se comporta igual en cualquier sitio donde se abra. Da igual si esa unidad viaja al ordenador de un desarrollador, a un servidor propio o al de un proveedor de nube distinto: lo que hay dentro no cambia, y lo que hay fuera no necesita saber qué hay dentro para poder moverlo.

Eso es, en esencia, un contenedor de software: una caja cerrada con la aplicación y todo su entorno dentro, que se ejecuta igual sin importar la máquina que la reciba.

#Por qué le importa a un negocio, no solo a quien programa

Esto podría sonar a detalle interno de un equipo técnico, pero tiene tres consecuencias que sí se notan fuera de ese equipo.

Los despliegues dejan de ser una lotería. Poner en marcha una versión nueva del sistema —una función añadida, una corrección, una mejora— pasa de ser un proceso con riesgo real de que algo se rompa por una diferencia de entorno, a ser un proceso repetible que se comporta igual cada vez que se hace. Menos sorpresas la noche en la que se publica un cambio importante.

Montar un entorno nuevo pasa de días a minutos. Incorporar a alguien nuevo al equipo, levantar una copia del sistema para hacer pruebas, o preparar un servidor adicional para absorber más tráfico dejan de requerir una lista de instrucciones manuales que alguien tiene que seguir a mano, paso a paso, cruzando los dedos. La caja ya viene lista; solo hace falta abrirla donde toque.

Cambiar de proveedor deja de ser un proyecto en sí mismo. Si el sistema entero está empaquetado de forma que se comporta igual en cualquier máquina, moverlo de un proveedor de nube a otro, o de la nube a un servidor propio, es mucho más parecido a trasladar una caja que a reconstruir el sistema desde cero en un sitio nuevo. Eso reduce, de forma muy concreta, la dependencia de un proveedor único.

Hay una cuarta consecuencia, menos vistosa que las tres anteriores pero igual de real: un sistema empaquetado así es mucho más fácil de duplicar. Un negocio que necesita un entorno idéntico al de producción para probar cambios sin riesgo —algo que casi todo negocio serio debería tener y que muchos posponen porque montarlo a mano cuesta demasiado— puede levantar esa copia en minutos, con la garantía de que se comporta exactamente igual que el sistema real. Antes de que existiera esta forma de empaquetar, mantener un entorno de pruebas fiel al real era, en sí mismo, un trabajo casi tan grande como mantener el sistema real.

#Lo que Docker no resuelve

Alrededor de esta tecnología se ha acumulado bastante humo, y conviene desinflarlo con la misma claridad con la que se explican sus ventajas.

Empaquetar una aplicación en contenedores no la hace, por sí sola, más rápida. El programa de dentro sigue siendo el mismo programa, con el mismo código, con la misma eficiencia o ineficiencia que tenía antes de empaquetarlo. Tampoco la hace, por sí sola, más segura: sigue siendo tan vulnerable como lo era su código, aunque viaje mejor envuelta. Lo que Docker mejora es la consistencia entre entornos y la velocidad de puesta en marcha, no el rendimiento ni la seguridad de lo que va dentro de la caja.

Y hay algo más que rara vez se cuenta en la reunión de venta: esta forma de trabajar añade una capa nueva que alguien del equipo técnico tiene que saber levantar, mantener y actualizar. No es una tecnología que se instala y desaparece del mapa de responsabilidades; es una pieza más de la que alguien tiene que responder, con su propio aprendizaje y su propio mantenimiento.

#Cuántos pasos manuales hay entre un cambio y tus clientes

Merece la pena hacer esta pregunta directamente a quien mantiene tu sistema: «cuando publicáis una versión nueva, ¿qué pasos concretos hay que seguir, y cuántos de ellos son manuales?». Una respuesta que suena a lista de instrucciones que una sola persona conoce de memoria —«hay que entrar por aquí, copiar esto, reiniciar aquello, y si algo falla se avisa a fulano»— es la señal de que el despliegue de tu sistema depende de la memoria y la disponibilidad de una persona concreta, no de un proceso repetible. Esa dependencia no se nota casi nunca, hasta el día en que esa persona no está disponible y hace falta publicar un cambio urgente de todos modos.

Dos preguntas más completan el cuadro. «Si mañana cambiamos de proveedor de servidores, ¿cuánto tardaríamos en tener el sistema funcionando en el nuevo?» pone un número concreto encima de la mesa, en vez de dejarlo como una suposición optimista. Y «¿alguien fuera de nuestro equipo actual sabría poner esto en marcha si hiciera falta?» revela si ese conocimiento está repartido y documentado, o si vive únicamente en la cabeza de una persona que un día puede no estar disponible.