#002 – Kubernetes For Humans Podcast with Wouter Ligtenberg (ING)

Wouter Ligtenberg
Platform Operations, ING

Listen to the Podcast

Episode Overview

In this episode of Kubernetes for Humans, host Itiel Shwartz talks with Wouter Ligtenberg, a platform engineer at ING calling in from Romania. Wouter shares the story of helping build an ING bank from scratch in the Philippines on Kubernetes six years ago, when almost no one inside the company knew the technology. The conversation moves through standardizing CI/CD pipelines across hundreds of teams, ING's internal namespace-as-a-service platform built by their Tiger Team, and the cultural shift toward platform engineering at large enterprises. Wouter also weighs in on Backstage, OpenTelemetry, the risks of vendor lock-in from all-in-one tools, and his effort to launch Kubernetes Community Days in Romania.

In this episode we discuss:

  • Building an ING bank from scratch on Kubernetes in the Philippines
  • Why standardizing pipelines and hard defaults beat letting every team improvise
  • ING's namespace-as-a-service platform and the Tiger Team's zero-trust networking
  • Drawing the abstraction line between platform teams and application developers
  • Launching Kubernetes Community Days Romania and the local cloud-native scene

Key Takeaways

1
When ING built a bank from scratch in the Philippines, betting on Kubernetes with no in-house expertise still shipped to production in nine months.
2
The biggest scaling lesson was forcing one standard pipeline across all teams. Individual pipelines per app destroy reliability and operability.
3
Platform teams should ship sensible defaults developers don't have to think about (anti-affinity, monitoring versions, deprecated function bans) and treat the platform as a real product with a real PO.
4
Be wary of vendors selling one tool that does everything. Prefer tooling that adheres to open standards like OpenTelemetry so you can swap pieces later.
5
Romania has a huge cloud-native engineering community that was missing a KCD; Wouter opened the GitHub issue and quickly found ten organizers, CNCF ambassadors, and local meetup leaders to help.

Itiel Shwartz: Hey everyone, happy to have you back to the Kubernetes for Humans podcast. Today with me on the call is Wouter Ligtenberg from ING. Wouter, please introduce yourself.

Wouter Ligtenberg: Sure. Hey, I’m Wouter. I’m calling from the Netherlands, though I’ve been living in Romania for the past four years. I work with Kubernetes, mainly building and deploying applications.

Itiel Shwartz: That sounds cool. As always, I’d love to hear a bit about your journey, both into computer science and Kubernetes in particular—why, what, how, and so on.

Wouter Ligtenberg: Sure. I started with Kubernetes about six years ago when it was still relatively new. I was working in the Philippines, building a bank from scratch. We decided to use Kubernetes, even though we didn’t know much about it at the time. There was almost no knowledge of Kubernetes within the company, but we knew we wanted to use it. That’s how we started, and we learned a lot, made mistakes, but eventually brought it live in nine months.

Itiel Shwartz: Wait, you were building a bank? I’ve never heard of that before. Can you share more about that, and why you chose Kubernetes? Back then, Kubernetes wasn’t necessarily the go-to for bank infrastructure.

Wouter Ligtenberg: It’s a good question. When we said we were building a bank, most people thought we were laying bricks. But we were actually writing the code for all the APIs, connecting various systems like user data and payments, and making everything work with our front-end applications. We chose Kubernetes because we wanted to be more scalable for the future. At the time, it was decided that Kubernetes would be the platform, and that’s how we started.

Itiel Shwartz: Did this platform exist back then, or did you have to build everything from scratch?

Wouter Ligtenberg: We started building it simultaneously as we were building the bank. The idea was to have a platform layer running all our Kubernetes namespaces and applications. The application teams built their apps within these containers.

Itiel Shwartz: That sounds challenging. Can you share a difficult obstacle you faced, and something that went well?

Wouter Ligtenberg: A major challenge was that not many banks were running on Kubernetes at that time. We had little experience with handling heavy loads and connecting to applications not running on Kubernetes. Our biggest learning was standardizing the pipeline. Initially, everyone had their own pipelines, but we eventually standardized everything, making it more reliable and scalable.

Itiel Shwartz: Standardization and hard defaults are essential when serving a large group of developers. How did the project turn out? Was it successful?

Wouter Ligtenberg: Yes, the project was successful. We eventually left the Philippines, but the more interesting part began after that when we started using Kubernetes across ING. It was a great learning experience for the company, and now Kubernetes is widely used at ING.

Itiel Shwartz: After that project, what other significant Kubernetes implementations have you been involved in?

Wouter Ligtenberg: The platform team, called the Tiger Team, did an amazing job ensuring the platform worked safely and reliably. They even presented at KubeCon about their zero trust networks. Currently, I’m working on making platforms more efficient within ING, focusing on things like site reliability engineering, risk management, and service creation.

Itiel Shwartz: For people who don’t know, platform engineering involves a lot of abstraction. How do you balance what the platform team handles versus what developers need to know?

Wouter Ligtenberg: Developers should always understand what’s underneath, even if they don’t need to know all the details. Platform teams take away the cognitive load and handle the heavy lifting. For example, we set defaults like anti-affinity, which aren’t included by default in Kubernetes. We enforce these standards to make things more reliable without burdening developers with too many details.

Itiel Shwartz: How do you handle the tension between platform teams and developers who want to build their own solutions? How do you know you’re doing a good job?

Wouter Ligtenberg: It’s crucial to have an open dialogue with developers. Even though developers are required to use the tools we maintain, we still need to think about their needs. We gather feedback through various channels and from experts within the company. Listening to the field and staying informed about industry best practices is essential for making informed decisions about what to implement next.

Itiel Shwartz: Do you see any big changes or trends in Kubernetes at ING over the past couple of years?

Wouter Ligtenberg: One of the major changes is the shift towards a platform-oriented approach. With Kubernetes becoming more widespread, there’s a lot of tool development happening around it. Companies are now providing tools that were previously built in-house. However, I’m cautious about tools that try to do everything; they can create dependencies on a single vendor. It’s important to use tools that adhere to industry standards, like OpenTelemetry.

Itiel Shwartz: Are there any tools you’re particularly excited about?

Wouter Ligtenberg: OpenTelemetry is quite interesting, especially as companies compete to be the best in the market. I think this competition will help mature Kubernetes even further.

Itiel Shwartz: What about tools like Backstage? Are you using it at ING?

Wouter Ligtenberg: Backstage is an interesting development. It fills a niche for internal portals, particularly in corporations with a lot of internal tooling or APIs. It’s a good product, though I’m cautious about the lack of competition in some areas, as it can slow down innovation.

Itiel Shwartz: Looking to the future, what trends or changes do you see emerging in Kubernetes or the broader tech industry?

Wouter Ligtenberg: It’s difficult to predict exactly where Kubernetes will go, but I expect continued development around Kubernetes tools. As Kubernetes becomes the default approach, I think we’ll see a few offerings emerge as market leaders, making it easier to use Kubernetes in conjunction with everything around it.

Itiel Shwartz: What do you think about the rise of eBPF and its applications in Kubernetes?

Wouter Ligtenberg: I’m not too familiar with eBPF, but I understand it’s used for things like network policies in a standardized way within Kubernetes. It’s definitely an area to watch, especially for large clusters where default configurations might not be sufficient.

Itiel Shwartz: How about stateful applications in Kubernetes? Are you running databases on Kubernetes?

Wouter Ligtenberg: We try to keep everything as stateless as possible. The applications I work on are stateless, which makes standardization and scalability easier. We still run some stateful applications on virtual machines, especially those requiring specific performance characteristics.

Itiel Shwartz: One last question: I know you’re also a mountain climber. Do you see any parallels between DevOps and mountain climbing?

Wouter Ligtenberg: Definitely. Both require perseverance. With mountain climbing, sometimes you have to push through to reach the peak. The same goes for Kubernetes; sometimes you’re debugging without an end in sight, and it’s important not to give up. Kubernetes requires knowledge and experience, which you gain over time. It’s easy to get started, but making it production-grade and maintaining it securely and reliably is much more challenging.

Itiel Shwartz: Kubernetes makes everything look easy at first, but the complexity underneath can be overwhelming if you don’t understand it. It’s like how things seem simple until you dig deeper.

Wouter Ligtenberg: Exactly. The same goes for platform teams. If you’re using a tool maintained by a platform team, you don’t need to know everything going on underneath, but someone does.

Itiel Shwartz: Trust is key in both cases. Well, I think we’re all set. It was a pleasure having you, and I hope to talk again soon—maybe at the next KubeCon.

Wouter Ligtenberg: Thank you for having me.

Itiel Shwartz: Thank you. Bye-bye.

Voiceover: Kubernetes for Humans

Wouter Ligtenberg is particularly passionate about CICD and everything that involves automation in the tech industry. In the past years, he worked in different countries on projects that involve automating Kubernetes workloads while at the same time speeding up and standardizing the landscape in ING. In his free time, you can occasionally find him on a split-board touring the Romanian mountains

Itiel Shwartz is CTO and co-founder of Komodor, a company building the next-gen Kubernetes management platform for Engineers.

Worked at eBay, Forter, and Rookout as the first developer.

Backend & Infra developer turned ‘DevOps’, an avid public speaker who loves talking about infrastructure, Kubernetes, Python observability, and the evolution of R&D culture. He is also the host of the Kubernetes for Humans Podcast. 

This is an AI generated transcript of the conversation

About the Guest

Wouter Ligtenberg
Platform Operations, ING
Wouter Ligtenberg is particularly passionate about CICD and everything that involves automation in the tech industry. In the past years, he worked in different countries on projects that involve automating Kubernetes workloads while at the same time speeding up and standardizing the landscape in ING. In his free time, you can occasionally find him on a split-board touring the Romanian mountains.