Todos los equipos tienen ese diagrama de arquitectura. Era precioso el día que alguien lo hizo, y estaba mal una semana después. Un servicio se movió, apareció una caché, se añadió una cola, y nadie quiso abrir la herramienta de dibujo y volver a mover cajas.
Así que el diagrama se pudre en silencio, y los nuevos ingenieros aprenden el sistema leyendo YAML. La buena noticia: ese mismo YAML basta de sobra para dibujarte la imagen. LetDraw lee tu archivo de Compose o de Kubernetes y organiza la arquitectura, de modo que el diagrama sale de la fuente de verdad en lugar de alejarse de ella.
Visualizar Docker Compose en diez segundos
Abre el diálogo Generar desde código, pega tu archivo y obtendrás un diagrama ya organizado con formas reales y editables. Sin arrastrar cajas ni conectar flechas a mano. Aquí tienes un archivo de Compose que casi todo el mundo reconocerá:
services: web: image: nginx depends_on: [api] api: image: app:latest depends_on: [db, redis] db: image: postgres:16 redis: image: redis:7
Pégalo y LetDraw lo convierte en esto:
La base de datos se convirtió en un cilindro, la caché recibió su propio icono y las aristas de depends_on se transformaron en flechas que rodean tus cajas en lugar de atravesarlas. Es un diagrama, no una captura de pantalla de una configuración.
Qué está haciendo realmente
El diálogo hace tres cosas que merece la pena destacar:
- Detecta el formato automáticamente. No eliges "Compose" o "Kubernetes" en un menú. Pégalo y LetDraw reconoce qué es.
- Agrupa las piezas relacionadas. Los manifiestos de Kubernetes se agrupan para que el diseño refleje tus namespaces, no una sopa plana de nodos.
- Coloca los iconos correctos. Los servicios, las bases de datos y las colas reciben iconos de producto reconocibles, así que el diagrama se entiende de un vistazo.
Ahora el diagrama sale de la fuente de verdad, así que es correcto por construcción, no por disciplina.
No es solo Compose
El mismo diálogo acepta muchos más formatos, y de eso se trata. Si describe infraestructura o un sistema, probablemente lo dibuja:
- Manifiestos de Kubernetes, agrupados por namespace
- Terraform y Helm para infraestructura y releases
- Graphviz DOT, SQL DDL, una especificación OpenAPI o incluso un git log
- Mermaid y D2, si ya guardas diagramas como código
Después hazlo tuyo
El diseño automático te lleva al 90 por ciento del camino, y el último 10 por ciento es donde está el valor. Como el resultado son formas reales, puedes:
- Mover un poco una caja, añadir una nota o resaltar la ruta arriesgada
- Agrupar las partes que pertenecen a un equipo o a un contexto acotado
- Exportar a PNG, SVG o PDF para un documento, o copiar directamente al portapapeles
- Convertir el dibujo de nuevo en Mermaid o D2 cuando quieras volver al código
Y si quieres que esa imagen viva en tu documentación, pega un fragmento de incrustación en un README o una wiki y seguirá siendo una vista en vivo de solo lectura. Se acabó el PNG desactualizado que alguien tiene que acordarse de volver a exportar.
Por qué importa esto en DevOps
Los diagramas de arquitectura deberían ser un modelo mental compartido. En cuanto se quedan por detrás de la realidad, se convierten en una trampa: enseñan lo equivocado a quienes llegan nuevos y dan una falsa confianza a quienes revisan. Generarlos a partir de los archivos que ya mantienes cierra esa brecha. El diagrama es barato de hacer, así que es barato mantenerlo al día, y un diagrama al día es el único que vale la pena tener.
Pega tu docker-compose.yml y mira cómo tu stack se dibuja solo. Tarda más o menos lo mismo que leer esta frase.