Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Your single source of truth for everything regarding Komodor’s Platform.
Keep up with all the latest feature releases and product updates.
Leverage Komodor’s public APIs in your internal development workflows.
Get answers to any Komodor-related questions, report bugs, and submit feature requests.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
[Music]
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.
Please note: This transcript was generated using automatic transcription software. While we strive for accuracy, there may be slight discrepancies between the text and the audio. For the most precise understanding, we recommend listening to the podcast episode
Share:
Podcasts
and start using Komodor in seconds!