Aseptic vs Docker Compose
Casi todo el mundo empieza aquí, y con razón: un docker-compose.yml y una
orden levantan Kafka, Redis y Postgres sin discusión. La pregunta no es si Compose
sirve —sirve—, sino qué pasa cuando lo que hay dentro del compose deja de ser
infraestructura y empiezan a ser tus servicios, los que tocas cada día.
En una frase
Docker Compose declara un conjunto de contenedores y su red en un fichero YAML, y los levanta juntos. Todo lo que corre, corre en contenedor; todo lo que se comunica, lo hace por el nombre del servicio dentro de esa red.
Aseptic usa Docker para la infraestructura común y arranca tus servicios como procesos de tu máquina, resolviendo cada dependencia a un servicio local, a tu entorno compartido en la nube o a un mock, y reescribiendo las URLs entre ellos al levantar.
La tabla
| Docker Compose | Aseptic | |
|---|---|---|
| Levanta la infraestructura común | Sí, es lo que mejor hace | Sí — con Docker, por debajo |
| Tus servicios | En contenedor, con su imagen | Nativos por defecto; en contenedor si quieres |
| Ver un cambio de código | Reconstruir la imagen y recrear el contenedor | El hot reload del propio framework |
| Depurador enganchado | Se puede, cableando puertos y opciones | Es un proceso local: como siempre |
| A dónde llama cada servicio | Al nombre del servicio en la red del compose | Por dependencia: local, nube o mock |
| Levantar solo una parte del sistema | up de unos cuantos; el resto, a mano | El escenario define qué entra, y el resto se resuelve solo |
| Configuración | Un YAML, normalmente dentro de un repo | Escenarios fuera de los repos; manifiestos autodetectados |
| Colisiones de puertos | Las resuelves tú | Remapeo automático |
| Sirve también en CI | Sí | No — es una herramienta de escritorio |
| Licencia | Código abierto | Gratis para uso personal, de pago para uso comercial |
Quédate con Docker Compose si…
- Tu sistema son dos o tres servicios estables y no los tocas a diario. Un compose y una orden es difícil de superar, y no instalas nada nuevo.
- Necesitas lo mismo en tu máquina y en CI. Aseptic es de escritorio; Compose corre en los dos sitios con el mismo fichero.
- Los servicios que levantas son de otros y solo tienen que estar arriba: si nunca los editas, que corran en contenedor es exactamente lo que quieres.
- Quieres una herramienta de código abierto, sin licencia que revisar.
Quédate con Aseptic si…
- El servicio que estás tocando lo quieres nativo —con recarga en caliente y el depurador enganchado— y los otros levantados y quietos. Eso es una mezcla que un compose no distingue: dentro, todo es un contenedor.
- Quieres levantar tres de los doce y que los otros nueve salgan a tu entorno de la nube o a un mock, decidiéndolo por dependencia y no por entorno.
- Estás cansado de cambiar una URL en el
application.ymlde un repositorio que no es tuyo y acordarte de no commitearla. - Quieres que el entorno se comparta como un fichero y no como un documento de cuarenta pasos que nadie actualiza.
Dónde se queda corto Aseptic
No corre en CI. Es una aplicación de escritorio con su CLI, pensada para el bucle de trabajo de una persona. Si lo que buscas es levantar dependencias dentro de un job de integración continua, Compose —o Testcontainers— es la respuesta, y Aseptic no compite ahí.
Tampoco es código abierto, y Compose lleva años siendo el estándar de facto: está en la máquina de todo el mundo, hay respuestas para cualquier problema y no hay que convencer a nadie de instalarlo.
Y si tu sistema es pequeño, Aseptic es maquinaria de más. La ventaja aparece cuando hay suficientes servicios como para que decidir a dónde llama cada uno sea un trabajo en sí mismo.
Lo que suele acabar pasando
Que conviven, porque no compiten en la misma capa. El compose se queda con lo que Compose hace bien —la infraestructura común—, y de hecho Aseptic lo usa tal cual: le apuntas al fichero que ya tienes. Lo que sale del compose son tus servicios, que es donde el ciclo de construir una imagen por cada línea que cambias se nota.
Si estás comparando también Tilt, Skaffold o un Kubernetes local, la página de alternativas a Docker Compose las pone una al lado de otra, y la comparativa amplia cubre los tres enfoques generales. Si lo que te ronda es si Testcontainers ya te resuelve esto, está la comparación con Testcontainers.
Preguntas frecuentes
¿Aseptic sustituye a Docker Compose?
No, lo usa. Aseptic levanta la infraestructura común (Kafka, Redis, PostgreSQL) con Docker, igual que harías tú. Lo que cambia es qué pasa con tus servicios: en vez de construir una imagen de cada uno en cada cambio, los arranca como procesos de tu máquina —o en contenedor, si lo prefieres— y les reescribe las URLs al levantar.
¿Puedo seguir usando mi docker-compose.yml?
Sí. Aseptic apunta al fichero compose que ya tienes para la infraestructura; no hay que reescribirlo ni migrarlo a otro formato.
¿Qué gana Docker Compose sobre Aseptic?
Es estándar, es código abierto y lo ejecuta cualquiera sin instalar nada más: si tu sistema es pequeño y estable, un compose y una orden es difícil de superar. También es la única de las dos que funciona igual en tu CI que en tu portátil.
¿Y si solo quiero levantar dos de mis doce servicios?
Ese es justo el caso en el que compose se queda corto: los otros diez o los levantas también, o editas a mano las URLs de los dos que sí quieres. En Aseptic decides por dependencia si resolverla al servicio local, a tu entorno en la nube o a un mock, y se aplica al arrancar sin tocar tus repositorios.
¿Necesito Docker para usar Aseptic?
Sí, para la infraestructura común. Aseptic gestiona esos contenedores por ti, con remapeo automático de puertos cuando colisionan.