If you think of deployment diagrams at all, you might think of something like this:

Yep, most of the time, when you see examples of deployment diagrams, they feature very old technology. (e.g., The Sun Fire servers in the above diagram were around in the 2000-2010 period.)

These days, when IT architects draw their solutions, they are more likely to be cloud centric and look like this:

While this is an IBM Cloud example, all the major cloud service providers have reference architectures that look like this.

In my opinion, the second diagram is also a deployment diagram. It doesn't follow the UML format, but it is essentially showing where services and other technology are deployed and how they relate to each other.

What I want to argue for is that these new diagrams could take a few things from the old deployment diagrams. For example, in the new diagram, we see a number of services running in a Kubernetes cluster. If this was a traditional deployment diagram, it might show nesting of boxes that would be something like this:

Kubernetes cluster > Worker node > Pod

Or it could be even more specific, and state what version of Kubernetes is being used in the cluster, how many worker nodes there are, what is the capacity of the worker node, and what is the OS of the pod. You could also state within the pod what containers are running there.

To extend this approach further, the new diagram could show which application components the containers are manifestations of. It’s here where the deployment diagram provides value, for it’s here where you see the linkage between the application and the runtime environment. You could even have tag or other information. For example you could have one pod manifesting one version of application components and another pod manifesting a different version. That linkage from the software components being designed by the application architect and the cloud infrastructure being designed by the cloud architect can be very powerful.

What I sometimes see is the application architect will design the software independently of how it will be deployed. They will provide the cloud architect with needs the application has for specific services. From there, the cloud architect will work to build out the cloud infrastructure.

What I would prefer to see is the application and cloud architects working together to determine how the code should be deployed, and then working together to come up with the right deployment model. The properties of deployment diagrams are suited for making that collaboration and communication more effective.