Príklady diagramov nasadenia

The diagram above is the one worth being able to draw from memory. A browser, a web server terminating TLS, an application server, a database. Three communication paths carrying the protocol and port, and three artifacts dropped onto the nodes that run them.

Two decisions in it are worth naming. First, the protocol labels are the reason the diagram is useful: HTTPS, HTTP/8080, TCP/5432 is the entire content of most security reviews, and a diagram without them is four boxes anybody could have guessed. Second, the artifacts are real filenames - orders.jar, not “application” - because a deployment diagram is about physical things, and a build produces files with names.

Containers make people hesitate, because a container is both a thing that runs and a thing that was built. UML already separates those: the running container is an execution environment, which is a node, and the image it started from is an artifact, which is deployed onto it.

Nothing about the shape of this diagram differs from the three-tier one, which is the point: the runtime changed and the notation did not. The load balancer is a «device» because it is infrastructure you do not deploy into. The ingress controller and the pod are «execution environment» because other things run inside them. The image tag orders:1.4.2is an artifact because a build produced it, and putting the version in the label is what makes the diagram answer “what is running in production right now”.

The managed database sits at the edge as a plain device. That is the honest drawing: you do not deploy artifacts onto a service somebody else operates, and pretending the schema is installed “onto RDS” is only true in the sense that it was applied there once.

The commonest reason anyone opens a deployment diagram is to find out what happens when one box dies. That question has a shape, and it is worth drawing explicitly rather than leaving it to a footnote.

Three application nodes behind one load balancer, all writing to a single primary. Drawn this way, the single point of failure is visible without anybody having to say it: the app tier fans out and the data tier does not. That is a sentence somebody will act on, and it took no extra notation to make.

When the count varies at runtime, replace the three nodes with one carrying a multiplicity - app-node [3..*] - rather than drawing an arbitrary number. A diagram that claims exactly three is false the first time the group scales, and a diagram known to be false stops being consulted.

Every deployment diagram that becomes useless does so the same way: somebody kept adding nodes. The discipline is deciding what the diagram is for before the second box goes down.

If you need the counterpart that shows the software rather than the machines, that is a component diagram. The two are usually drawn as a pair, and the deployment one is the shorter of them.