About
I tend to write things down when the explanation becomes more useful than the fix itself.
This site grew out of debugging sessions, architecture decisions and the recurring realization that the interesting part usually starts after the diagram has been drawn.
I'm Nikolas, based in Dortmund. Most of my professional work revolves around cloud platforms, but this site is less about my job title and more about the things I find worth understanding properly.
I like systems that can be explained from the DNS record down to the workload — and abstractions that still leave enough information behind when something breaks.
Technical Biases
Infrastructure should be boring to operate.
DNS is part of the architecture.
Automation should preserve debuggability.
Failure paths belong in architecture diagrams.
Explicit configuration beats clever abstraction when production is broken.