Dutch Cloud Native Day 2025 – Field Notes from Utrecht

1. Why this event mattered

After a strong debut in Amsterdam last year, the Dutch Cloud Native Day (DCND) returned with a bigger venue, three parallel tracks and a single ambition – re‑energise the Benelux cloud‑native community. The 2025 edition delivered on that promise, pairing deep‑dive talks and practical workshops with a hallway track that felt more like a reunion than a conference.

2. First impressions – registration & vibe

The day kicked off inside Utrecht’s Jaarbeurs Supernova with fast check‑in queues, neon‑striped lights and a table-full of OSS stickers. Crew shirts, lanyards and friendly volunteers set the tone: contributor‑first, ego‑last.

The main stage during the lunch break, with the event logo on the screen.

3. Content highlights

4. Hallway track = real value

Between sessions the expo floor became an impromptu ideas market:

• Book exchanges – a stack of Kubernetes Recipes turned into the perfect ice‑breaker.

• Sponsor demos – Platinum booths (Exoscale, Mirantis, HCS Company) doubled‑down on internal developer platforms. Isovalent previewed new Tetragon features – fitting given the eBPF buzz.

• Career serendipity – impromptu chats on GPU tenancy, GitOps bootstrapping and SOC‑2 evidence automation translated into concrete follow‑ups.

The expo floor: Rabobank, Isovalent, HCS company and Exoscale booths.

The recording corner of De Nederlandse Kubernetes Podcast.

The closing slide thanked a long list of sponsors: Exoscale, Mirantis, HCS company, Isovalent, Rabobank, SUSE, Devoteam, eG Innovations, i-share, TrueFullstaq, Booking.com, ITQ, mogenius, Sysdig, Scaleway, Cyso, Leaseweb, fika.works, controlplane and more.

The sponsor thank-you slide at the end of the day.

Cortney Nickerson Reviews “Kubernetes Recipes” at Dutch Cloud Native Day 2025

Talks I photographed

A few slides from the main room give a more specific picture than the timetable above. The speakers’ names are not on these slides, so I leave them out.

A highly available PostgreSQL cluster on Kubernetes: three availability zones, one primary and two standbys, each on its own worker node with PGDATA and WAL volumes, behind a read-write and a read-only service.

“Was it worth the effort?” compared a ClusteredCron setup with KubeCron. For KubeCron the slide listed runtime and dependency isolation, support limited to the Kubernetes domain, applications that are infrastructure-agnostic and can be deployed on private or public cloud, and similar dev, integration and prod environments. For ClusteredCron it listed complicated support questions across several domains, apps tightly coupled to the platform and infrastructure, and only production plus a limited dev environment.

“Extending Kubernetes: Patterns, Operators, and Plugins” came up in the afternoon. This is the Apress book listing, as shown on a phone.

The slides above came from the afternoon sessions in the main room. I also recorded the audio of a few of them, so here is what the speakers said. Their names aren’t on any slide I photographed, so I describe them by role.

PostgreSQL on Kubernetes. The speaker, a maintainer of CloudNativePG, showed the topology on that slide and what it means in practice. Within one data centre, losing a worker node means a failover of a few seconds and, with synchronous replication, zero data loss. For disaster recovery you run a replica cluster in another region from a backup; because recovery relies on archived WAL files, which are archived when complete (16 MB by default) or every five minutes otherwise, the disaster-recovery data loss is capped at about five minutes. His design philosophy was a stream-aligned team that owns its database in the same namespace as the application, with a pipeline from local kind tests through CI, vulnerability scans and Postgres’s transactional DDL to continuous delivery. On the roadmap he described dynamic loading of extensions, using image volumes from Kubernetes 1.33 and a change landing in Postgres 18 that the project had asked for, so extensions no longer need to be baked into the base image. The project is also taking part in a Linux Foundation mentorship and aims at CNCF incubation. His closing advice was to join the community, start with an internal or external database-as-a-service, be open to bare metal and local storage for Postgres, and keep the cloud-neutral idea in mind.

Retiring a legacy cron platform. The “Was it worth the effort?” slide came from a migration story: collecting feedback from engineers, managers and architects, turning that feedback into a generic migration playbook and a list of exceptions, and then closing the legacy platform to new cron jobs as the first step before decommissioning.

Keynote: one decade into cloud native

The talk I enjoyed most was a keynote on the first ten years of cloud native and what the second decade will look like. The speaker is a maintainer of the Cilium project, which fits the Isovalent presence on the expo floor; his name isn’t on a slide I have, so I leave it out.

Looking back. He started with his first KubeCon, in Copenhagen, where he thought Kubernetes was a Greek island until he had to set up a cluster: about eight hours on a Windows laptop with Kubernetes 1.8. The two things he took from that conference were the evolution from racked servers through virtualisation and the early cloud to cloud native, and a Simon Wardley keynote with Wardley Maps. He re-read the 2017 map with hindsight: serverless was expected to become a commodity, which he thought looked funny now, while the real shift was new practices (declarative APIs, loosely coupled microservices) replacing ITIL-era practice.

The problem: centralised control. His claim was that we moved from centralised control to centralised control. The story he used came from Trip.com’s talk at KubeCon China in 2023. At the scale of hundreds of clusters, when an API server falls over, the Cilium agents on every node call back to it, crash and restart, and the load ends up on etcd. Dropped calls cause more calls, bigger pipelines, higher infrastructure costs and more latency, and because Kubernetes is eventually consistent, the system loses touch with the real state. His summary: the bureaucracy grows to feed the bureaucracy.

The answer: distributed intelligence, close to the data. He walked through three areas where decisions can move into the kernel with eBPF.

• Networking. Cilium’s sidecarless service mesh takes the data off the socket and redirects it, avoiding repeated trips through the Linux network stack that a sidecar needs. He pointed to Cloudflare doing DDoS mitigation with eBPF and XDP at the network card, and said this let them automate the handling of a 3.8 terabit-per-second attack. He also cited Seznam, a Czech company that replaced an IPVS load balancer with a Cilium eBPF one and thought it had broken something because CPU dropped so much.
• Observability. Rather than shipping everything to a central store and filtering later, filter in the kernel. Tetragon, another sub-project, showed in his benchmarks lower CPU overhead when you choose at the source what to export. Hubble, for network observability, was credited by users with diagnosing in about three seconds what used to take two engineers two days.
• Security. Instead of sending an event to an agent, then a SIEM, then a human, you can block an access (for example to a password file) directly in the kernel, where the context is. Exporting too many events can also starve the system of resources, so filter first and look for the needle, not the haystack.

Predictions. Redoing Wardley’s map for 2015 and for today, he placed cloud as nearly a commodity, Kubernetes moving from product towards commodity, and Cilium and eBPF moving from custom-built to standard. He said cloud native may be becoming “the new legacy”, and that the second decade will be about putting intelligence into the infrastructure, analysing at the source and acting instantly, with eBPF as the mechanism. He asked us to remember the predictions in ten years so we can laugh at them.

My take: this matches what I see with platform teams. The cost of observability and the blast radius of a control-plane outage are both symptoms of pulling too much data to one place. He is a Cilium maintainer, so the examples lean towards Cilium and Isovalent products, but the principle (decide at the source, filter before you ship) holds with any tool.

5. Emerging themes & strategic takeaways

6. Personal highlights

1. Live demos that worked. Tetragon traces lighting up, real‑time.
2. Tangible next‑steps. Three separate hallway chats already booked in my calendar.
3. Joy of print. The selfie‑wall of engineers holding Kubernetes Recipes says physical books still spark delight.

7. Gratitude & next steps

Huge thanks to the all‑volunteer DCND crew and the sponsors who kept the espresso flowing.

The announcement for the next edition was on the tables: Cloud Native Community Days Amsterdam 2026, 21st and 22nd May, at cloudnative.amsterdam.

Flyer and stickers for Cloud Native Community Days Amsterdam 2026.

Call to action

• Join the #dutch‑cloud‑native Slack and upcoming meet‑ups.
• Experiment with one new eBPF tool before Q4.
• Share your own lessons – blog, OSS PR or lightning talk. The community grows when we contribute back.

See you in Utrecht next year – until then, keep shipping, automating, and stay human.

Got feedback or want to co‑present a talk in 2026? Ping me on LinkedIn.

Related Articles

• Dutch Cloud Native at ASML: Kubewarden, Argo CD, GitOps (the community group’s meetup in September 2025)
• Dutch Cloud Native & AI: Spegel and Dash0 Meetups 2025
• openEuler: The Enterprise Linux Distribution You Have Not Heard Of — And Why It Matters
• Speaking at Conferences: From Ansible Berlin to FOSDEM and KubeCon
• FOSDEM 2026: Open Source, RISC-V & Community Energy in…