Hay un tipo concreto de diagrama cloud que incomoda a los revisores sin que sepan muy bien por qué. Todo es un rectángulo gris. El balanceador de carga, la cola, el almacenamiento de objetos y la base de datos gestionada se ven idénticos, y solo se distinguen por las palabras escritas dentro. Técnicamente es correcto. Pero nadie puede leerlo por encima, y un diagrama que tienes que leer palabra por palabra apenas es más rápido que el párrafo al que sustituyó.
Los buenos diagramas cloud parecen no costar esfuerzo porque se apoyan en un lenguaje visual compartido. Un ingeniero que ha trabajado con la plataforma reconoce la forma de un servicio de cómputo, de un almacenamiento de objetos o de una cola gestionada antes de leer una sola etiqueta. Cuando tu diagrama usa la iconografía propia del proveedor, conecta directamente con esa memoria compartida y el dibujo se puede leer de un vistazo. Esa es toda la diferencia entre un diagrama en el que la gente confía y uno que obliga a entrecerrar los ojos.
Los iconos aportan significado, no decoración
Es tentador tratar los iconos como un retoque que se añade al final. No lo son; son la forma en que un diagrama cloud codifica el tipo. En cuanto una caja lleva el icono de almacenamiento de objetos, el lector conoce su durabilidad, su patrón de acceso y su modelo de costes sin que tengas que escribir nada. Un icono de base de datos gestionada dice "esto lo opera otro" de una forma que un rectángulo simple nunca podrá. Quita los iconos y habrás tirado una capa de información, por eso el diagrama todo gris se siente tan plano.
Usa los iconos reales de AWS, Azure y GCP
LetDraw incluye bibliotecas de iconos de estilo oficial para las tres grandes nubes (AWS, Azure y GCP), así que no tienes que aproximar un servicio de cómputo con un glifo de servidor genérico. Abre la biblioteca de formas, elige tu proveedor y suelta los servicios reales en el lienzo: el balanceador de carga que se parece al balanceador de ese proveedor, la cola que se parece a su cola. Un diagrama hecho con el conjunto correcto se lee bien para cualquiera que trabaje con esa plataforma, que suele ser justo el público del diagrama.
Mezclar proveedores también está bien, y es honesto cuando tu sistema realmente abarca varios. Los iconos hacen evidente la frontera (esta mitad está en una nube, esa mitad en otra) en lugar de esconder una realidad multicloud detrás de cajas grises uniformes.
El icono correcto le dice al lector qué es una caja antes de que lea una sola palabra. Ese es todo el trabajo de un diagrama cloud.
Empieza por la infraestructura que ya declaraste
No tienes que colocar cada servicio a mano. Si tu infraestructura vive en Terraform o en una declaración similar, ese archivo ya enumera los recursos y cómo se conectan. Pégalo en Generar desde código y LetDraw distribuye los componentes por ti; después estampa los iconos correctos del proveedor sobre las cajas para que el borrador generado se lea como una arquitectura real y no como un grafo de dependencias.
resource "aws_lb" "web" { # → load balancer icon } resource "aws_ecs_service" "api" { # → compute icon } resource "aws_db_instance" "main" { # → managed DB icon } resource "aws_s3_bucket" "assets" { # → object-store icon }
Mantenlo legible a medida que crece
Los diagramas cloud reales se llenan rápido, y lo que los arruina son las flechas trazadas en línea recta a través de lo que haya en medio. Deja que el lienzo enrute los conectores alrededor de tus servicios, agrupa cada capa o región en un contenedor, y el dibujo seguirá siendo legible con treinta cajas igual que con cinco. Cuando lo necesites como código (para un documento, una wiki, un pull request), expórtalo a Mermaid o D2 y haz commit junto al Terraform que describe.
Un buen diagrama cloud no es más bonito que uno malo; es más rápido de leer. Usa los iconos reales, genera el primer borrador a partir de tu infraestructura y dales a tus revisores un dibujo que reconozcan a primera vista.