Hello — I’m Jendrik. I work as a DevOps engineer with a systems-administration background and have about ten years of experience in cloud and on‑prem infrastructure, Infrastructure-as‑Code (IaC), and automation.
My focus areas include Azure, Kubernetes, Terraform, CI/CD pipelines, and improving the developer experience through pragmatic automation. In my posts I share practical recipes, tools, and approaches that help teams deliver more reliably and faster.
Technically, I enjoy working with .NET, PowerShell, Hugo, and common CI/CD tools; I’m always focused on repeatable deployments, clean builds, and pragmatic operational automation.
If you have topic suggestions or want to discuss collaboration, feel free to contact me via the project page or by e‑mail.
Every platform engineering conference talk in the last two years has had a Backstage slide. Glossy catalogue screenshot, a scaffolder demo that creates a repo in four clicks, a knowing nod about “developer experience”. What the slide never shows is the six months the team spent building plugins, the Postgres instance somebody now babysits, the TechDocs theme nobody asked for, and the 0.4 of an engineer permanently assigned to chasing Backstage’s two-week release cadence.
There is no shame in any of this. Backstage is a serious project and serious teams run it well. The shame is treating it as the default (the thing you reach for on day one) when most teams could ship 80% of the value with a tenth of the effort and a fraction of the running cost. Backstage is a platform for building platforms. Most teams need a platform, not a platform-platform.
This post is the Internal Developer Platform (IDP) I keep building when nobody is forcing me to use Backstage. It is small, opinionated, runs on Azure plumbing you already pay for, and ships value in the first quarter instead of the third year.
Running AKS at 1,000+ nodes exposes hard limits in etcd, networking, observability, and cost that never appear in vendor documentation. This article shares operational lessons from mega-cluster deployments: where the scaling cliffs are and how to plan around them before production outages force your hand.
Most organizations run Kubernetes across cloud and on-prem simultaneously. This article covers practical patterns for hybrid AKS: ExpressRoute and VPN connectivity, Azure Arc for unified management, consistent policy enforcement, DNS resolution, and identity federation without duplicating systems.
Your cluster will fail. The question is not if, but when, and whether you can recover before customers notice. Most organizations discover their backup strategy does not work during an actual outage, when recovery time matters most and manual heroics cannot save you.
If you run Azure Kubernetes Service (AKS) in production, you need a recovery plan that engineers can execute half asleep at 2 AM. We will go through what to back up, how Velero works in day-to-day operations, when Azure Backup for AKS is enough, and how to design realistic failover with measurable Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
The goal is simple: repeatable recovery procedures you have already tested, not a document that looks good in Confluence but fails during an incident.
Securing Azure Container Registry for AKS needs more than a single control. This guide walks through a production-ready sequence: vulnerability scanning, image signing, RBAC, private endpoints, policy enforcement, and geo-replication. You get practical Terraform, Kubernetes, and pipeline patterns, plus clear trade-offs for real-world operations.
