Ejemplos de diagramas de despliegue

El diagrama de arriba es el que merece la pena saber dibujar de memoria. Un navegador, un servidor web que termina el TLS, un servidor de aplicaciones, una base de datos. Tres rutas de comunicación que llevan el protocolo y el puerto, y tres artefactos colocados sobre los nodos que los ejecutan.

Dos decisiones suyas merecen nombrarse. Primera, las etiquetas de protocolo son la razón de que el diagrama sea útil: HTTPS, HTTP/8080, TCP/5432 es todo el contenido de la mayoría de las revisiones de seguridad, y un diagrama sin ellas son cuatro cajas que cualquiera podría haber adivinado. Segunda, los artefactos son nombres de fichero reales - orders.jar, no «aplicación» - porque un diagrama de despliegue va de cosas físicas, y una construcción produce ficheros con nombre.

Los contenedores hacen dudar a la gente, porque un contenedor es a la vez algo que se ejecuta y algo que se construyó. UML ya separa las dos cosas: el contenedor en ejecución es un entorno de ejecución, que es un nodo, y la imagen de la que arrancó es un artefacto, que se despliega sobre él.

Nada en la forma de este diagrama se diferencia del de tres capas, y de eso se trata: ha cambiado el entorno de ejecución y la notación no. El balanceador es un «device» porque es infraestructura en la que no despliegas. El controlador de ingress y el pod son «execution environment» porque dentro de ellos corren otras cosas. La etiqueta de imagen orders:1.4.2es un artefacto porque la produjo una construcción, y poner la versión en la etiqueta es lo que hace que el diagrama responda a «qué está corriendo en producción ahora mismo».

La base de datos gestionada se sitúa en el borde como un dispositivo simple. Ese es el dibujo honesto: no despliegas artefactos sobre un servicio que opera otro, y fingir que el esquema está instalado «en RDS» solo es cierto en el sentido de que allí se aplicó una vez.

La razón más común por la que alguien abre un diagrama de despliegue es averiguar qué pasa cuando muere una caja. Esa pregunta tiene una forma, y merece dibujarse explícitamente en vez de dejarla a una nota al pie.

Tres nodos de aplicación tras un balanceador, todos escribiendo en una única primaria. Dibujado así, el punto único de fallo se ve sin que nadie tenga que decirlo: la capa de aplicación se abre en abanico y la de datos no. Esa es una frase sobre la que alguien actuará, y no ha costado notación adicional.

Cuando el número varía en ejecución, sustituye los tres nodos por uno que lleve una multiplicidad - app-node [3..*] - en vez de dibujar una cantidad arbitraria. Un diagrama que afirma exactamente tres es falso la primera vez que el grupo escala, y un diagrama que se sabe falso deja de consultarse.

Todo diagrama de despliegue que se vuelve inútil lo hace de la misma manera: alguien siguió añadiendo nodos. La disciplina está en decidir para qué es el diagrama antes de que caiga la segunda caja.

Si necesitas la contraparte que muestra el software en vez de las máquinas, eso es un diagrama de componentes. Los dos suelen dibujarse en pareja, y el de despliegue es el más corto.