infra-bootstrap-tools VS c4-notation

I have started to documents my infra for small projects here if you are interested: https://github.com/xNok/infra-bootstrap-tools

In this article, I will give you a tour of Terraform Cloud and the necessary explanations to get started. This piece is part of a series I created on How to create infrastructure for a small self-hosted project. You can find all the code here: https://github.com/xNok/infra-bootstrap-tools, but this article does not how much prior requirements if it is not being a little bit familiar with Terraform.

I want to remind you that the goal of this tutorial series is to document what I consider the bare minimum for a small self-hosted side project. I invite you to visit my repository for more information: https://github.com/xNok/infra-bootstrap-tools. At this point, we are doing the groundwork of setting up a server to host the application we will deploy later as docker containers.

With a small project spread across several articles, I want to show you what I consider the minimum requirement for a small self-hosted project. I invite you to check my Github repository for other articles and more details about the whole project.

What you are describing sounds a lot like C4: https://c4model.com/

The C4 model [0] provides a mostly sensible structure and techniques for representing pure software systems across different abstraction levels.

For systems involving software and hardware, or other complex interfacing (both technology and bureaucracy) this starts to delve into the universe of systems engineering. There's a decent assembly of knowledge on that in the SEBoK [1].

As another commenter has already called out too, one of the most valuable sources of information is also _why_ a system is in its current form and _how_ that's changed over time. ADR's [2] really do a good job at nailing this for just about any scale.

[0]: https://c4model.com

[1]: https://sebokwiki.org

[2]: https://adr.github.io

There a various standards for documenting software architecture, like arc42 or C4. While useful and somewhat well-known (there is certainly a correlation here), here architecture documentation can be further simplified, particularly due to the self-similarity of project and component. Following is a small template, that can also serve as a project's and component's README:

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong.

The 'what does this box do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'.

I highly suggest folks take a look at the C4 Model: https://c4model.com/

We often use abstractions in software engineering to communicate complex architectures and software systems. In this article, we’ll discuss how abstractions are inherently hierarchical and how the C4 model provides a nested structure for defining your software architecture. We’ll then cover how IcePanel allows you to create interactive and zoomable diagrams for your audience to zoom in and out of different levels of technical detail.

You probably want https://c4model.com/ which explains what a C4 architecture diagram is. (See the first footnote in the article.)

I looked at the book OP is talking about and it seems to be advocating 'C4' (https://c4model.com/). IMO this is the same kind of block diagrams we end up creating organically. I dunno that I'd call this 'modern' or anything special, it's just what everyone already does. I've done hundreds of these and not once has anyone ever mentioned 'C4' or anything being 'modern'. Shrug