Announcing Infrahub 1.0!!
We had a chance to catch up with Solution Architect Wim Van Deun about his journey in network automation. In this conversation, Wim opens up about his early “ad hoc” scripting days, how he stumbled into data challenges, and why a flexible, version-controlled source of truth—like our platform Infrahub—would have been a game-changer in his past roles. Plus check out a bonus video where Wim shares about his first experience leading a strategic network automation initiative at a major enterprise.
Question: You’ve mentioned before that you started with automation long before it had that label. Can you walk us through your early steps?
Wim: Early on, I was the go-to person whenever there was a networking puzzle no one else wanted to deal with. I’d write Perl scripts—really rough stuff—to log in to devices, check for weird metrics, and figure out if we’d hit specific issues. Honestly, I didn’t think of it as “automation;” I just knew scripting was faster than doing everything by hand. For example, we once had a Cisco firewall module that didn’t expose certain metrics. My script would hop in via SSH, run a command, and compare the output. If it saw a specific counter jump, we knew something was up. These mini-projects solved problems our monitoring tools couldn’t handle. That’s how I ended up learning that scripts could really streamline day-to-day tasks.
Question: So how did you go from those quick Perl scripts to more serious automation?
Wim: The real turning point was at a large organization in the healthcare space. They had a huge network, and my boss recognized we were burning too many hours and dollars doing everything manually. Since I was already known as the “script guy,” I got the nod to build a more formal automation strategy. That’s when I realized just how chaotic our data was. We had no centralized inventory, no clear ownership, and every device move or team change seemed to introduce new glitches. I learned pretty quickly that if you want to automate at scale, you have to tackle data management first.
Question: You’ve told me before that data management was your biggest hurdle. Can you explain why?
Wim: Picture an environment with thousands of devices, all at different sites, each with its own specs. If you don’t know exactly which devices exist or how they connect, you’re in for a world of frustration. We tried using spreadsheets, but that quickly became a nightmare—multiple versions, random naming conventions, fields missing. Eventually, we adopted tools like NetBox or later Nautobot, and that helped a bit. But we kept running into restrictions with how the data was modeled. We’d have to create plugins or store critical info in random “tags,” which felt like a hack. Plus, if we wanted a new relationship—like connecting a device to a custom design spec—that usually required more tinkering than it should.
Question: Let’s talk about Infrahub. In your view, what’s the big difference between that and other source-of-truth platforms?
Wim: Two things stand out: schema flexibility and built-in version control. Take the schema part. With some tools, you’re forced to fit your network data into a model that might not match your reality. Maybe you’ve got specific relationships—like “these branches share a unique WAN design” or “this device needs these custom attributes”—but the tool doesn’t support it, so you do a ton of workarounds. Infrahub flips that and says, “Model your data however you want.” That means I can adapt the schema to my actual environment, instead of bending my environment to fit a cookie-cutter approach.
And version control? That’s huge. We often needed to plan a “future state” for a network refresh while keeping production data intact. Doing that with older platforms meant awkward duplication or separate staging instances that never stayed in sync. Infrahub’s branching system lets me spin up a separate version, test it, and merge it back when everything’s good. No guesswork. No accidental overwrites.
Question: Sounds like version control is especially helpful for big projects, like hardware rollouts. Did you face that sort of challenge often?
Wim: Absolutely. Enterprise networks can’t just stop for a day while you swap out old hardware for new. You might have 200 sites that need a refreshed design, but you still have to maintain daily operations. With a branching approach, you can create a “future” environment of your site, plan out all your changes (like new VLANs, IP addresses, and device details), then merge it in one go. It’s essentially the same workflow developers use for code, only now you’re doing it with network configurations and inventory data. Before, we’d basically keep a second spreadsheet and pray no one messed with the original. Infrahub’s approach is drastically more reliable.
Question: Any final words of wisdom for folks trying to decide if they should invest in better automation and a centralized data platform?
Wim: The best advice I can give is: don’t overlook the data problem. Automation is only as good as the data that drives it. If you’re dealing with incomplete, out-of-date, or scattered info, you’ll spend more time fixing scripts than enjoying the benefits. Before you build fancy workflows, nail down a solid source of truth. And look for a platform with flexibility in how you store information and the ability to version-control big changes. That’s a massive boost to productivity and reliability.
Conclusion
That’s a wrap on this Q&A. Wim’s experiences paint a clear picture: network automation works best when you have a solid handle on your data and the right platform to accommodate changes. Infrahub provides that flexibility and branching capability, allowing teams to stay agile and confident in their automations. If you’re grappling with similar data and version-control headaches, learn more about how Infrahub can help you build a successful infrastructure automation journey at your organization. Check out our Github, visit our always-on-demo, or request a demo at opsmill.com.
![65a656b0aa32b71080018ef5_logoOpsmill[1]](https://www.opsmill.com/wp-content/uploads/2024/07/65a656b0aa32b71080018ef5_logoOpsmill1.svg "65a656b0aa32b71080018ef5_logoOpsmill[1]")