About Me

If you’re looking for someone who quietly follows outdated runbooks and never questions a design decision, you probably shouldn’t hire me.

Since 2009 I’ve built and secured infrastructure across Windows, Linux, cloud and identity. That can look scattered. It isn’t: the platform changes, the job doesn’t. Whether it’s a domain controller, a fleet of more than a thousand Linux servers or an AWS organization, I make it secure by default and put it in code. And if the tool I need doesn’t exist, I build it, these days mostly in Python and FastAPI.

How I got here

#

It started when I was a kid, with MS-DOS: editing AUTOEXEC.BAT and CONFIG.SYS, loading HIMEM.SYS just right to free up enough memory for the next game. I still remember those lines. I’ve wanted to know how things work underneath ever since.

Professionally, I started out in 2009 as a Microsoft engineer: Windows Server, Active Directory, Group Policy, Exchange and Citrix, plus the network and the service desk. Even then I automated what I could: new Windows machines were installed with MDT task sequences, not cloned from a Ghost image.

At an international engineering manufacturer I ran the server park for years, mostly on my own. I set up SCCM, managed Exchange, and did just about every migration it needed: Active Directory, file servers, and the disaster recovery environment. The biggest one: moving the Hyper-V clusters from Windows Server 2008 to 2012, network stack included. In most companies that’s a project for a team or an outside partner. There, it was me. That’s where I learned that identity is the backbone of every environment, and that a well-designed policy beats a hundred manual fixes.

Then the company centralized its IT. I wanted to keep being challenged, so I moved to a global data center provider, and into Linux, where automation became the whole job. I never looked back. I was building platforms before “cloud” was the default: machines that configured themselves from code with tools like cloud-init, when most teams still installed servers by hand and kept the steps in their heads.

Puppet was my first real automation platform, and the one that taught me to think in desired state. Later came Ansible, which I’ve used extensively ever since.

At that data center provider I managed more than a thousand servers with Puppet and Ansible, and helped deliver the infrastructure (IaaS) for the Dutch government: the platform underneath most of its online public services, from DigiD and MijnOverheid.nl to many more. Mail platforms, DNS, routing, firewalling, intrusion detection: almost all of it built on plain Linux services. Redundant ring networks, BGP, keepalived moving virtual IP addresses to a healthy node when one failed, firewalls and SNAT/DNAT in hand-written iptables rules, managed in Puppet manifests of course, Snort watching the traffic. No fancy appliances with a web GUI. When millions of citizens depend on it, you learn to understand every layer yourself.

Next, at cloud and hosting providers, I worked on critical infrastructure for large customers, including major insurers. There too we ran a fleet of more than a thousand servers on Puppet. I didn’t just write manifests; I also took Puppet itself through the major upgrades from version 4 to 7 across that fleet, the kind of job that breaks in a hundred small places before it works. I love that kind of complexity. I’ve touched and tuned almost every layer of those platforms, from the operating system to Galera, MariaDB and PostgreSQL clusters that simply weren’t allowed to go down.

I didn’t just keep those layers running, I designed and built the stacks themselves, end to end. A typical one: HAProxy or Nginx as the reverse proxy and load balancer at the front, then the web and application servers, then the backend. And when that backend is a three-node MariaDB Galera cluster, the database needs routing too: a proxy in between that knows which node takes the writes and pulls a failed node out of rotation before the application notices. Every hop is a place where traffic can get lost, so I made sure I understood each one.

Upgrades were part of that job too. After every major MariaDB upgrade I ran MySQLTuner against the cluster, because settings that were fine in one version can be deprecated or even harmful in the next. The query cache is the classic example: tuned for years, then something you turn off. And when a database did go down, I wanted evidence, not guesses: I wrote a script that captured what an RDS instance was doing just before it crashed, so a colleague could open the dump afterwards and see exactly what had happened.

There I also built a complete build street on Foreman, cloud-init and Puppet. A new VM went from request to fully configured, monitoring included, without anyone touching it. Zabbix picked up every new machine automatically, but only started alerting once someone ticked it as production. A server that isn’t live yet shouldn’t wake anyone up at night.

At a multinational in defense and aerospace I brought that automation to a more traditional environment: configuring Linux and Windows with Puppet and Ansible, automating ITSM processes around ServiceNow, and improving the CI/CD workflows of the development teams.

From there I went from Linux engineer to cloud engineer. When the cloud arrived, it felt less like a revolution and more like the rest of the world catching up. At a global, publicly listed enterprise, as a senior SRE and DevSecOps engineer on AWS, that looked like this:

• Landing zone from code. A new AWS landing zone built with CDK, Python, StackSets and AWS Organizations.
• Identity first. An IAM matrix designed on least privilege, and IAM Identity Center single sign-on through SAML with Entra ID, with access driven by RBAC groups.
• Authorization that scales. A proof of concept with a Lambda authorizer for API Gateway, so one Cognito identity pool could serve every API instead of hitting the limit of ten pools.
• Security and cost as one problem. An event-driven Lambda that sets log retention per account or OU. It’s good hygiene, and it stopped paying for logs nobody needed.
• Notifications as a platform service. A microservice that routed AWS events automatically to the right Microsoft Teams channel, with the same clear formatting for every team.
• Quality in the pipeline. CI/CD with CodeArtifact, SonarQube for code quality and Sonatype for vulnerability scanning across languages, plus the process for triaging and fixing what they find.
• Linux in the cloud too. EC2 fleets, NTP clusters and ETL servers configured and patched with Ansible.

I was also the team’s Scrum Master: running the ceremonies, clearing blockers and keeping the work flowing.

Today I’ve come full circle, back to identity, but with everything I’ve learned since. Ten years after I left Windows, I picked Active Directory back up to migrate an environment to Windows Server 2025, and it felt like I’d never left. Fundamentals don’t expire. Now, at a global enterprise in the energy industry, I work on Identity Governance & Administration (IGA), and I build FastAPI services that let platform teams automate against our IGA solution. Identity becomes something they can call from their pipelines, not a ticket they wait on.

It’s the same idea as always, at a bigger scale: if it isn’t in a repository, it doesn’t exist. I’ve lived that from SVN to GitLab, GitHub and CodeCommit, with pipelines in Jenkins and everything that came after.

That’s still how I work today, whether it’s an enterprise landing zone or my own server, where I even let an AI agent work on it without giving it the keys to the kingdom.

Under the hood

#

I like to know what’s actually happening underneath. I’ve run FortiGates, but what really interests me is the layer below: how conntrack tracks a connection, what SNAT and DNAT do to a packet on its way through, how the ARP table gets filled and refreshed, why keepalived sends a gratuitous ARP when a virtual IP moves, and why a stale entry can make traffic vanish while every dashboard looks green.

That curiosity goes for most of IT, especially the services everything else quietly depends on: DNS (resolvers, forwarders, CoreDNS), NTP, mail, load balancing, databases. Ask me what happens when you type a domain name, and I’ll happily walk you from the root servers to the TLD to the authoritative nameserver and its records, in plain words.

I’ve gone deep in each layer I’ve worked in: network, Linux, Windows and identity, databases, cloud. That’s why I see quickly how they fit together, and where a problem actually lives when every team says it isn’t theirs. I’m at my best next to specialists: I can follow them into their area, and I make sure the pieces fit and the whole team understands how.

Not everyone believes one person can cover that much ground, and that’s fine. I’ve been turned down for identity roles because I hadn’t built Conditional Access policies yet. It’s often seen as the hard part of identity. With my background, it’s the familiar part. A Conditional Access policy is a firewall rule for identity: who is asking, from which device and location, for which app, and then allow, block or require MFA. Report-only mode is what I did with every new iptables rule: log first, enforce later. Under a new tool there’s usually something I’ve already run, so I rarely start from zero.

The easiest way to find out is to give me something to automate: a firewall, a landing zone, an identity workflow. I honestly don’t mind what it is.

Career at a glance

#

Certifications

#

• Cloud: AWS Certified Solutions Architect – Associate (2020), AWS Certified Cloud Practitioner (2019)
• Linux: LPIC-2 (2017), LPIC-1 (2016)
• Kubernetes: Certified Kubernetes Administrator course (2025)
• Microsoft: MCITP Server Administrator on Windows Server 2008 (2013) and 2012 (2015), Windows 7 Configuring 70-680 (2011)
• Network: CCNA 1, 2 and 3 (2004–2006)

Why you might not want me on your team

#

❌ I don’t accept “we’ve always done it this way.”
❌ I automate repetitive work.
❌ I think in security even when no one asked.

So if you want to secure identities and break bad habits, hop on the boat or the train with me. 🚤🚆

Let’s talk

#

Working on identity, automation or a platform that needs to be secure by default? Reach out on LinkedIn. I’m always up for a conversation about hard problems.

And if I don’t reply right away, I’m probably out for a run.