Infrastructure diagrams as code

Creating a diagram of your infrastructure is quite a tedious job. I noticed that when, for example, someone new wants to understand our architecture, I tend to grab a marker and draw it on a whiteboard. That works well, but it keeps all that information that we have at our disposal inside of our heads. Next time someone asks, I’d just draw it all over again, maybe missing some interesting parts.
To actually get all of the benefits of having these kind of diagrams available at all times, you want to keep them up to date. When you need a third party tool to do this, that makes the effort of updating them way higher than it needs to be.
That’s why I built a very small Javascript library that allows you to generate diagrams with code. The goal is to specify your infrastructure in a way that reads naturally. If you want to check it out, go ahead an go to the Github repository.

How it works

Let’s just dive straight into an example of how the library works. Imagine we want to plot an infrastructure containing a load balancer, some webservers behind that load balancer and some databases from which the webservers read. We want to generate the following diagram:

This is how we would set that up:
const { diagram, dac: { Client, Elb, Ec2Cluster, RdsCluster } } = window;

const client = new Client();
const loadbalancer = new Elb();
const webserver = new Ec2Cluster();
const databases = new RdsCluster();



We first specify a list of things that make up our infrastructure. Then we specify how those things communicate with each other. In the end we render the diagram.
Other options we have for specifying the relationship between nodes are sendsDataTo() and exchangesDataWith(). The library offers an extensive list of (for now mostly AWS) infrastructure components that you can use. They will all get a nice icon and for some there’s also a cluster variation available.


Specifying your infrastructure diagrams as code has several advantages.
Because it’s code, it can be quite verbose about what you’re doing and why. That’s good, because that allows you to capture the intent of relationships in your diagram. If that’s not enough, you can even add comments to make things super clear.
It’s easy to add this to your version control. And you can actually see what changed as well, and even why it changed if you add a good commit message. With special file formats that are often used by diagramming tools, this would be hard.
It’s easy to keep up to date without any tooling required. Anyone with a text editor can update your docs. Now there’s really no excuse anymore to not update technical documentation.


To me this approach seems very useful, as it lowers a barrier that I find quite high with the current tooling available. There are clearly big upsides to being able to create a digital version of a diagram in the same time that you would draw it.
If you want to try it out, check out the Github repository.
How do you document your infrastructure? What do you think of this approach? I’m very interested to know your thoughts! Also, if you know of any tools or libraries that do something similar, please let me know!