Kubenet, Schemas, k8s and More: Exploring the Evolution of Network Automation with Wim Hendrickx of Nokia
When Wim Hendrickx from Nokia started building containerlab, he was solving a simple problem: testing network configurations required too many manual steps. That personal project has since become one of the most popular tools in network automation. In a recent Network Automation Heroes podcast, Hendrickx shared how his journey from containerlab through kubenet to schema-driven automation is reshaping how we can think about network infrastructure management.
The containerlab Origin Story
containerlab started as a solution to a recurring problem while Hendrickx was working on Nokia’s SR Linux network operating system. The existing Python-based tools required editing too many files for each new topology.
“I was a little bit hung up with it. So I said, okay, there must be a better way of doing it,” Hendrickx said. His guiding philosophy was clear: “We need to build as low as possible so everybody can consume things. Everything should be able to run on your laptop locally, on a machine, not too much horsepower.”
Although Hendrickx began the project, he credits Roman Dodin for taking it to the next level: “It became what it is because of Roman, not because of me. Roman has done a fantastic job.”
Learning from Kubernetes Without Copying It
containerlab’s success led Hendrickx to explore how Kubernetes principles could transform network automation through kubenet.
“Kubernetes basically gives a lot of capabilities that I felt we also need in the networking space. You have this event-driven automation, you get a trigger of a drift or something else, and you do an action based on that.”
But he soon realized the networking community wasn’t ready for the full complexity of Kubernetes-style controllers written in Go. “This is way too complicated and not easy to understand,” Hendrickx admitted.
That sparked a new focus: “What I’m doing these days is trying to see what are the gaps or holes in the Kubernetes ecosystem? What do we have in the network automation system and how can we blend those two worlds together?”
The Schema-First Revolution
The breakthrough came with a schema-first approach: instead of forcing engineers to code in specific languages, let them describe intent declaratively and generate everything else.
“Making the tool decide how you have to do it is already broken,” Hendrickx argued. This approach lets users define models in Python, Go, YAML, or JSON, and automatically generate SDKs, APIs, UIs, and CLIs.
“The majority in our ecosystem is Python. But if you go outside of networking, you see a lot of Go,” he noted. “We should build a tool where the language doesn’t really matter.”
Decoupling Relationships for Flexibility
Another innovation in Hendrickx’s approach is how object relationships are handled. Traditional systems hard-code parent-child links into schemas, limiting reuse.
“By not mapping that attribute in the schema itself, but as a loosely binding of the relationship, you can actually build way more flexible APIs,” he explained. This effectively creates a graph-like system without requiring a graph database, offering flexibility for evolving network architectures.
WebAssembly as the Next Frontier
Looking ahead, Hendrickx sees WebAssembly as a pivotal tech, not for web interfaces, but as a lightweight, secure way to run automation code in any language.
“WebAssembly as a mechanism is a powerful way to build automation in any language of choice,” he explained. With file sizes in kilobytes and startup times in milliseconds, WebAssembly enables function-as-a-service approaches for network automation.
Collaboration Over Competition
One theme surfaced repeatedly: successful network automation requires collaboration between tools. This is aligned with our big tent philosophy as we think about the broader ecosystem of tools.
“There is no such thing as one tool that rules it all,” Hendrickx emphasized. “It’s basically a collection of items.”
Borrowing from Kubernetes’ strengths, he envisions systems where multiple automation engines can operate on the same API objects. The goal is to make “the server’s role to assist the client as much as possible,” offloading complexity from automation developers.
Looking Ahead
The journey from containerlab to schema-driven automation represents more than technical evolution; it marks a fundamental shift in how we approach networking. By prioritizing simplicity, flexibility, and collaboration, Hendrickx and the community are creating a future where network automation isn’t just for specialists writing complex code. Instead, it becomes accessible to anyone who can describe what they want their network to do.
As networks form the foundation for AI workloads, cloud platforms, and digital transformation, this democratization of automation couldn’t come at a better time.
Watch the full episode below:
