Winter’s almost over, at least over here on the West Coast. Naturally, we decided to venture out to Montréal last month so we could get one last taste of winter. We were a sponsor at Confoo, one of the biggest local dev conferences. We had an amazing time meeting developers and architects, handing out custom t-shirts, and IcePanel Pokémon cards.

In this issue, we share a useful guide that often comes up in our conversations. How do you model Kubernetes with the C4 model? It’s simpler than many think. We also released a new (our fifth) design deep dive on a metrics and alerting system. Last but not least, Luca’s new architecture podcast is out, featuring an insightful episode with Jacqui Read.

Let’s dive in! 🏊

Kubernetes (K8s) is the de-facto standard technology for orchestrating containerised applications at scale. However, visualising it only as a K8s cluster diagram doesn’t express its architecture in a format accessible to all stakeholders.

Thinking about architecture with the C4 model works great as a technology-independent abstraction. However, software architectures are often visualised as cloud-specific diagrams like AWS/Azure/GCP diagrams or as Kubernetes cluster views. These diagrams are often static and contain all implementation details in a single view. Details like networking, service meshes, and ingress/egress traffic get in the way when trying to understand the high-level components of the architecture, like core business services or datastores. For organisations running on K8s with little-to-no architectural documentation, there’s a modelling problem.

So, how does translating a Kubernetes cluster into the C4 model work?

For starters, the cluster becomes a single Context layer. In this view, the emphasis is on what the system does and who interacts with it (actors and external systems). At a high level, we draw the third-party APIs the cluster depends on and the users who interact with the system (e.g., admins and customers).

A K8s namespace is a logical grouping of resources within a cluster. It is a useful mechanism for isolating groups of resources together, but not modelled as a first-class element in the C4 model. For C4, it is a visual dotted-line boundary on the Container diagram. It could also be represented as a Group.

A K8s deployment defines how an application runs and scales. It specifies the number of instances to run, resource limits, and other metadata. In the C4 model, the Container diagram highlights a set of deployable/runnable units that power the system. Each unit is a K8s deployment. Pods are runtime instances that wrap one or more running containers (not to be confused with Container diagrams!). They do not belong to the C4 model since this is already abstracted by the deployment resource. Code inside the pod belongs to the Component diagram, where you show internal structure like REST handlers, API clients, and domain logic.

A K8s service is a networking mechanism that lets one workload talk to another. In C4, that’s just an arrow between two Containers with a protocol label. Other resources like Ingress rules, ConfigMaps, or Secrets are operational details that don’t need their own boxes on a Container diagram.

Another deep dive fresh off the press. Learn how to design a metrics and alerting system for infra observability and maintenance health. In this example, we’re using 2 popular technologies, Prometheus and Grafana.

We’re honoured to be sponsoring Luca’s new podcast, Dear Architects. Luca has spent months thinking and planning a new podcast focusing on untold architectural stories. Episode 1 just dropped with Jacqui Read, author of Communication Patterns.

Luca and Jacqui explore why most architectural problems aren’t technical but are rooted in communication failures. Jacqui highlights key dangers of waterfall thinking in AI-driven development and the need for even better communication when working with LLMs.

We had a blast in Montréal, exploring the city, freezing our butts off (we weren’t quite prepared for -20 🥶 ), and connecting with the technical community We didn’t quite anticipate the fervour for our Pokémon cards, but it turns out people still love to collect cool things.

What did we take away from our conversations? Automation (code → diagrams, infra → model) is still a hot topic, as well as integrations with existing tooling (ServiceNow, Terraform, observability).

We also demo’d our new model viewer, which will be coming out soon. This is one of our first steps toward killing diagrams ⚔ . Slowly, then suddenly.

We’ll be back soon, most likely during warmer times! 🌞

Stay chill,