Adiós, Docker: Por Qué Volví a lo Básico para mi Desarrollo Local

Seamos directos: durante mucho tiempo, fui un evangelista de Docker para todo. La promesa de un entorno de desarrollo idéntico a producción era demasiado buena para ignorarla. `docker-compose up` y a programar. ¿Qué podía salir mal?

Bueno, con el tiempo, empecé a notar las grietas. Pequeñas fricciones que, sumadas, estaban saboteando mi productividad y mi estado de 'flow'. Y un día, decidí apagarlo todo y volver a lo básico. Fue una de las mejores decisiones que he tomado para mi flujo de trabajo.

La Fricción Inesperada de Docker en Local

Docker es una herramienta increíble para despliegues, CI/CD y orquestación en producción. Pero para el bucle de `código -> guardar -> ver cambio` en mi máquina local, se convirtió en un estorbo. Mis razones se resumen en tres puntos:

1. Rendimiento y Recursos: Especialmente en macOS, el rendimiento del sistema de archivos es un dolor de cabeza. La sincronización de volúmenes, sobre todo con proyectos de Node.js y su `node_modules`, era lenta. El 'hot reloading' tardaba segundos que se sentían como minutos. Además, Docker Desktop no es precisamente ligero; consumía una cantidad considerable de RAM y CPU, haciendo que mi portátil sonara como una turbina.

2. Complejidad Accidental: Un `Dockerfile`, un `docker-compose.yml`, redes, volúmenes, contextos de build... La pila de configuración crecía. Cuando algo fallaba, no era un problema de mi código, sino un problema de Docker. Pasaba más tiempo depurando la configuración del contenedor que mi propia aplicación. El famoso `docker exec -it <container_id> /bin/sh` se convirtió en un ritual tedioso.

3. La Abstracción como Obstáculo: El contenedor se sentía como una caja negra. Sí, se supone que debe serlo, pero en desarrollo local, quiero la menor cantidad de capas posible entre mi código y su ejecución. Quería que mi depurador se conectara sin trucos, que mis herramientas de base de datos vieran el servicio sin mapeos de puertos complejos y que todo, simplemente, funcionara de forma nativa.

Mi 'Nuevo' Stack: La Simplicidad es Rey

Decidí eliminar la capa de Docker *para el código de mi aplicación*. Ojo, no para los servicios. Mi configuración actual es un híbrido pragmático:

* El Runtime en el Host: Para gestionar las versiones de los lenguajes, uso herramientas específicas que son brillantes en su simplicidad. `nvm` para Node.js, `pyenv` para Python, `rbenv` para Ruby. Son ligeros, rápidos y me permiten cambiar de versión con un solo comando en la terminal. Cero sobrecarga.

    # Cambiar a la versión de Node.js del proyecto
    nvm use
    

* Servicios (Bases de Datos, Caches): Aquí es donde la cosa se pone interesante. En lugar de un `docker-compose` con Postgres y Redis, simplemente los instalo en mi máquina local a través de Homebrew (en macOS).

    brew install postgresql
    brew services start postgresql
    

Es absurdamente rápido, el servicio está siempre disponible y mis herramientas de GUI se conectan al instante. Para proyectos que necesitan un aislamiento más estricto o servicios más exóticos, herramientas como OrbStack son una alternativa increíblemente rápida y ligera a Docker Desktop para correr contenedores de servicios, pero mi aplicación principal sigue corriendo nativa.

* Variables de Entorno: El clásico fichero `.env` con una librería como `dotenv` sigue siendo el estándar de oro. Simple, efectivo y funciona en cualquier entorno.

El resultado es un bucle de desarrollo casi instantáneo. Guardo un fichero y el cambio se refleja al momento. Mi portátil está silencioso. Y cuando algo falla, el error está en mi código, no en una capa de virtualización.

Pero, ¿Cuándo SÍ Usar Docker?

No soy un anti-Docker. Sigo creyendo que es la herramienta correcta en muchos contextos:

* Producción y CI/CD: Indiscutible. La portabilidad y consistencia que ofrece para los despliegues no tiene rival. * Proyectos con Microservicios Complejos: Si tienes 10 microservicios en 5 lenguajes diferentes, `docker-compose` puede ser la forma más cuerda de levantar todo el entorno. * Onboarding: Darle a un nuevo desarrollador un solo comando (`docker-compose up`) para tener todo funcionando es una gran ventaja. Aunque argumento que también le oculta cómo funciona realmente el stack.

Mi punto es este: no adoptes una herramienta por dogma. Analiza tu flujo de trabajo principal. Para mí, como desarrollador que pasa el 80% de su tiempo en el bucle de edición y depuración de una sola aplicación, eliminar Docker de *ese* bucle me devolvió velocidad y agilidad.

Optimiza para la velocidad del 'inner loop'. Si una herramienta te frena, por muy estándar que sea, atrévete a cuestionarla.