Powerful Network Configuration Management: Unimus | SourceForge Podcast, episode #79

By Community Team

Unimus by NetCore is a powerful Network Configuration Management (NCM) platform that simplifies automation, backup, and compliance for networks of any size. Built by network engineers, it’s vendor-agnostic, fast to deploy, and delivers secure, web-based control without complexity.

In this episode, we speak with Tomas Kirnak, the Founder and CEO of NetCore, about Unimus, a network automation and configuration management platform. The discussion covers the challenges of network management, the evolution of Unimus since its inception in 2016, and the importance of automation in modern network infrastructure. Tomas explains how Unimus simplifies network management for both small and large-scale operations, emphasizing its user-friendly approach that doesn’t require deep developer skills. The conversation also touches on the limitations of AI in network management and the importance of security and scalability in infrastructure management.

Watch the podcast here:

Listen to audio only here:


Learn more about Unimus.

Interested in appearing on the SourceForge Podcast? Contact us here.


Show Notes

Takeaways

  • Unimus does not require developers’ skill sets.
  • Network engineers can use their existing CLI knowledge.
  • The platform enables network management at scale.
  • No need to learn Python or Git for Unimus.
  • Unimus simplifies the application of network management.
  • Scalability is a key feature of Unimus.
  • Network engineers can focus on their core skills.
  • Unimus bridges the gap between knowledge and application.
  • The tool enhances efficiency in network configuration.
  • Unimus is designed for ease of use by network professionals.

Chapters

00:00 – The Role of Unimus in Network Management
05:00 – Founding of NetCore and Unimus
08:15 – Challenges in Network Automation
12:00 – The Evolution of Networking and Automation
15:45 – Core Features of Unimus
19:30 – Scaling Unimus for Different Business Sizes
23:00 – The Future of AI in Network Management
27:15 – Security and Integration with Existing Tools
31:00 – Success Stories and Real-World Applications
35:00 – Conclusion and Where to Learn More

Transcript

Beau Hamilton (00:00.75)
Hello everyone and welcome to the SourceForge Podcast. I’m your host, Beau Hamilton, senior editor and multimedia producer here at SourceForge, the world’s most visited software comparison site where B2B software buyers compare and find business software solutions. Okay, now if you’ve ever worked in IT, you might know just how messy network setups can be. There are hundreds of devices, you have constant updates, and I feel like there’s always something breaking when you least expect it. And so that is where Unimus comes in.

It helps teams really automate all of that behind the scenes network work. Things like backups, you have configuration changes, and it just works to keep everything in sync so businesses can stay secure and efficient without all of the manual heavy lifting that would be required. So joining me today to talk about the platform is Tomas Kirnak, Founder and CEO at NetCore, company behind Unimus.

He founded it back in 2016 with a simple goal in mind, and that’s just to make network management easier, faster, and more reliable for as many people as possible. And he’s used his background in networking, Linux, and virtualization, among other things, just to do that, to do just that, I shall say. And since then, the platform has grown into a really trusted tool used by IT teams all over the world. So we’re going to talk a lot about how it all started the trends shaping the future of network automation and how Thomas and his team are helping companies tackle the growing complexity of modern networks. So lots of cover. Tomas, welcome to the podcast. It’s great to have you here.

Tomas Kirnak (Unimus) (01:36.149)
Hi, and thank you. It’s great to be here.

Beau Hamilton (01:38.946)
So I want to start just at the very beginning. Maybe you can maybe introduce NetCore and Unimus for our listeners who might not be familiar. And maybe you can talk about and explain its mission in this space, the network automation configuration management space.

Tomas Kirnak (Unimus) (01:55.547)
Yeah, so as you mentioned at the start, we basically for almost 10 years now at this point have been developing Unimas as a network configuration management network automation system. It’s been quite a journey and yeah, the entire mission is that networking really being a niche area and quite a deep technical rabbit hole as well. And of course, as network scale that becomes even more challenging with the scale coming in basically for quite many years before Unimus. I’ve been in IT for like 20 years at this point.

So I’ve jumped through like Sysadmin and Linux management stuff to networking. Then I was a network architect, a social architect. basically Unimus became what I myself as a network engineer was missing at the time. So when I was doing network architecture and large-scale network operations, I found out that there was a hole in the toolset for network engineers where you didn’t have a multi-vendor system that could really both improve network operations, improve change management, but also do that configuration management and automation stuff around networking equipment.

Yeah, basically it was born out of my own need for a tool like this. yeah, luckily after almost 10 years, it’s now being used by network operation teams and network administrators all around.

Beau Hamilton (03:39.234)
Well, that’s fascinating. love like hearing how you, take your background and your, your, your skillsets and expertise and combine it into a product and just finding, you know, obviously like you’re saying, kind of a gap in the market or like an area you think you could do a better job at and, and, and do some serious fixing. I’m curious, like, so when you started back in 2016, I like automation then is, I feel like quite a bit different than it is now with a lot of these AI automations and kind of new technology coming down the pipeline. Was the company, was the platform, would it be almost unrecognizable nowadays with some of the improvements you’ve made or how has it shifted over the last decade or so?

Tomas Kirnak (Unimus) (04:26.662)
Actually, that’s quite interesting because networking is quite unique in that there is very little evolution or you could say very little new tool sets introduced into networking. As an example, usually say, in the networking field, we’ve been, as a network operator, a network administrator, IPv6 has been trying to get adopted into the networking world for 20 years now, and it’s still not there.

So networking is like roads. It’s what brings all of your traffic around. It’s what brings you to the cloud. And you can have as much redundancy in your servers and clusters and everything else. But when the networking goes down, all that upper level or upper layer redundancy really disappears because you don’t have the roads that carry the traffic around.

Why I’m saying is that the networking area in general is quite archaic and you commonly find folks using tools from literally 90s still today because it’s such a critical area and change is really slow, adoption of new technologies is really slow. And actually, same applies to AI. I personally, okay, maybe I am over exaggerating a little bit, but I don’t think I know a single engineer that uses AI to in production to automate networks, simply because AI makes mistakes. That’s reality, right? You have hallucinations are a common thing. And then you try to apply an unreliable technology to a high risk environment, right? Networking, as I mentioned, when you bring down the network, you bring down everything. It’s a very different mindset that you have to adopt with reliability being such a high requirement. So to answer your questions directly, Unibiz has changed a lot in the 10 years, but I would not say it has been like completely changed how it approaches automation and change management and stuff like that because of the specific requirements of this industry.

Beau Hamilton (06:30.35)
Gotcha. No, that makes sense. I mean, you look at, yeah, you look at like, hospital networks or something, and they’re they’re using old storage drives from way back in the day, they like basically you have a lot of networking components that you almost don’t want to touch because you feel like it’ll break. Right. And so I feel like you need to constantly just like, it’s harder for companies to spend the money and invest where they need to. But I think it also comes back to that road analogy where like, you do have hot holes and you have eventually like there’s the road is going to break down and stop functioning and allowing people to get to where they need to be or companies to do the things they want to do. So you need to obviously have a pretty robust solution or platform in place that allows you to fix the things that need to be fixed and update accordingly.

Tomas Kirnak (Unimus) (07:29.022)
Yeah, absolutely. You still need maintenance and of course you still need to build out capacity. Again, with the roads, good analogy is, know, once the highway is full, it’s full and if you need more traffic, you need to find ways around it. So absolutely, infrastructure still evolves. It’s the same, you know, if you look at maybe 15 years ago compared to today, just what you have with 5G networks and mobile data coverage and transfer speeds, same with home internet transfer speeds. So yeah, absolutely. All the infrastructure needs to keep up and needs to evolve.

But at the same time, it’s always a balancing act between resiliency, redundancy, and risk management of stuff breaking and taking out the AWS outage just yesterday. And in that case, it was DNS, but still, there’s been plenty of outages of entire cloud ecosystems because of routing protocol BGP misconfigurations. So yeah, it’s a, you have to have kind of a different mindset when you deal with the underlying infrastructure that basically carries all of the data around the world.

Beau Hamilton (08:34.092)
Now, I want to talk about some of the core features of your platform. Can you share what defines Unimus in terms of its products and services, and which industries may be a benefit the most from using it?

Tomas Kirnak (Unimus) (08:50.598)
Sure. Like I mentioned, in perhaps a single sentence, Unimas is a configuration management and network automation system, which is quite wide and vague. In particular, if you want to go a bit deeper into it, Unimas basically, for network administrators, for infrastructure architects, it offers five basic features or functions, which probably the simplest one is just configuration backup, which is very simple, stuff breaks, you want to have a backup. As with data, the same goes for configuration of your infrastructure itself, Be that networking, be that servers, be that anything else. The device itself does nothing unless it’s configured, right? And with that, of course, comes change management and change detection and change notification, which if you have a bigger infrastructure team and maybe you are in the quality assurance for that, then you absolutely want to know or even if you are a senior administrator and you have a bunch of juniors under you, you absolutely want to know when, what and how changes in the infrastructure.

And so it brings that kind of, you could say, developer mindset into change management. And yeah, absolutely, you can see this, you can see your versioned change history of the entire infrastructure. DevOps driven approach, or sometimes it’s called DevOps or net DevOps, a bunch of, you know, a bunch of names for this, but it brings these concepts into infrastructure management. And then there’s auditing, there is compliance of configuration against security standards. And then of course there is the automation part of like I mentioned, how do I update, you know, hundreds switches during my maintenance window on the weekend when nobody’s using the network.

Beau Hamilton (10:38.998)
Okay, so there’s, yeah, there’s, have a lot of the five kind of main pillars, I guess, features that define the platform, I would say. And I think the ones that stand out just are kind of the making everything as simple as possible from a UI standpoint, displaying as much useful information as possible, but then also being able to, to like have it scale as your needs grow. Right. So how can you talk maybe a little bit about how it works with, you know, SMBs, small to medium sized businesses. And then if it’s able to scale and work with enterprises as well.

Tomas Kirnak (Unimus) (11:13.534)
Yeah, so actually that’s one of the big focuses or other philosophy is that you shouldn’t be an enterprise. You shouldn’t be a national telco or a carrier just to be able to have these kinds of network or infrastructure tool sets available to you. And you shouldn’t need a team of 20 engineers just to be able to maintain a tool set like this. So from the start, we actually built Unimas with the philosophy of, yeah, it should just work. It should be approachable. The barrier of entry to the product should be as low as possible. so, absolutely. Even if you are an SMB, maybe with 20 or 50 network devices in your infrastructure, it should be a tool that is usable and applicable to you. And it absolutely is. And absolutely, as a scale, it’s very different. like auditing infrastructure, it’s very different than you have to audit 20 devices versus 100 versus 1,000.

Right. And so that scale challenge absolutely comes in at a certain level of infrastructure management. yeah, so Unimas as well, we have customers which are literally, like I mentioned, managing from home labs of maybe five switches and the router and an access point to SMBs, to educational institutions, to universities, through massive corporations or even nationwide telcos. So yeah, it’s made to be useful at small scale, but also scale into the extremely large scales of networking.

Beau Hamilton (12:48.172)
Now I was listening to one of your speeches that you had recorded and published on YouTube and you got into a lot of the technical components of the platform, which I thought was really interesting and above my pay grade, above my expertise. But I do want to see if you can maybe help maybe talk about what makes your platform work in practice. Maybe you can paint a visual picture for us.

Because you have a bunch of different tools. mean, have like mass configuration, push-pull, have various backup and change management tools. You can search network-wide searching capabilities. Can you talk about just how these features actually prove the way organizations really manage their networks?

Tomas Kirnak (Unimus) (13:36.671)
So usually you could think about it if we talk about adoption or how do you roll this out into the organization. Maybe we could talk about day one use cases, day two use cases, and then maybe month one use cases. And so we usually find that a lot of the day one use cases, or at least what customers immediately implement, is that configuration backup and, of course, the change management, change detection, change notification. Because that’s quite simple and basically you can literally have Unimas doing that in half an hour. Like, and I could talk a lot about, like I mentioned, our philosophy is that it should be very simple to adopt this into the network. So, yeah, Unimas is built from the ground up to synchronize inventory, for example, from monitoring systems and the CMDB.

So like configuration databases and stuff like that. So adoption into the network is usually very fast and that comes with that lessening of the barrier of entry. So even though this is quite a technical product, it can be rolled out easily and fast. And so I get that day one adoption usually is, yeah, now we have backups and we have change management, change detection, change notifications, right? And so usually once you get that into the infrastructure, then those day two use cases start becoming like, okay, how do I audit this infrastructure at scale? How do I find out if all my security is correct? Like if my firewalls are enabled where they should be, ACLs, access control lists, are how they should be. Are they consistent across the entire infrastructure? Are all of my VPNs secured with the right combination of encryption? These consistency checks, these audits that you can do into network. And we usually find that that’s a very good day-to use case of the product. Start doing these large scale checks. Start finding out errors and inconsistencies in the configuration of the infrastructure.

And so that’s usually day two. Day three is usually, now that I have all of these consistency checks and I found a bunch of my issues in my network, because that’s like reality. None of us are perfect. Network engineers are also not perfect. So we make mistakes as well, right? There’s misconfigurations, there’s inconsistencies, there’s oftentimes security, you know, a router that was configured 10 years ago is still routing traffic somewhere, but is that secure? And so you start finding this through the auditing tools, and then you can start creating compliance checks for all of this. So like automate the checking of those consistency of the configuration, security of the configuration and stuff like that. And that also, if you are in a bigger organization, is really nice with reporting to your management. we adopted this new tool. It found all of these issues and we’ve automated compliance checking and we now are aware of all of that. And that goes into cybersecurity as well.

Beau Hamilton (16:26.284)
Now, the more you, the bigger the network you have and the more you have to audit, obviously, I imagine it’s going to take a little bit more time to set up and get up and running. But I’m just curious, like, so you mentioned the day one, day two, day three kind of steps. How long does it typically take a company to get up and running? I mean, is it literally just a few days?

Tomas Kirnak (Unimus) (16:45.554)
So that depends, of course, on the size of the infrastructure and on how much time you want to put into all of this, right? How deep do you want to go? But yeah, literally, I would say the time to implement everything that I’ve mentioned up until now is in days. Like a good network engineer that understands their network, that know what they are doing, they can have all of this done in, I would say, including the compliance part in days.

What is a little bit more complicated, you could say, is the next part of it. And now we are talking about the next weeks of your time. And then comes the network automation. So how now that I have identified, for example, that my firewall address lists or ACLs are inconsistent around the network, because people go, IP addresses change, new branch offices are added or removed.

Network is a living, breathing thing which adjusts business requirements and to the needs and the scaling up and scaling down and the changes of the business itself. So yeah, there is a bunch of legacy stuff and I now have compliant checks which will tell me what is correct and what needs to be fixed. But then comes the question of how do I fix potentially tens or hundreds or sometimes even thousands of not consistently incorrectly configured devices? And then that is when you get into the network automation use case. And that is a more complex one because as maybe it’s the same as in like automating of other infrastructure parts like servers and services and stuff like that. When you adopt solutions like Puppet or Chef or Ansible, or there’s many of those as well for your infrastructure, you probably know that that’s not a project you take on lightly. It takes time. It takes a lot of time.

And so it’s a little bit, I would say, less time intensive. We are not talking about months of implementation time with Unimas. We are probably talking about weeks of implementation time. And again, it goes into how deep down that automation rabbit hole do you want to go. But if we are talking about, for example, I just want to fix ACLs across 100 firewalls around my infrastructure, then yeah, that may be a matter of days to get into that. But that’s just a single automation that fixes a single problem. Now, if you want to roll out consistent templated configuration across hundreds of devices, then yeah, that’s probably another week of getting there. so the point is that it’s still much better than doing it some completely self-written homemade way.

Beau Hamilton (19:38.094)
All right. So some of the automations you have built into your platform, I mean, they can help remedy a various, like a handful of different issues, but it’s not necessarily a one size fits all, right? You have to of fine tune the automation for the specific problem. Is that kind of in the most general sense?

Tomas Kirnak (Unimus) (19:57.95)
So how Unimus Automation works, it’s basically an open automation framework, an automation platform where you as a network or infrastructure engineer are able to create these automations that you need to solve the issues or deploy configurations at scale into the network. So it’s not really something that is pre-built. It doesn’t take away control from the engineering team.

On the opposite side of the spectrum, gives them the tooling to extend their existing knowledge and their existing ability to influence network at scale, if that makes sense.

Beau Hamilton (20:31.306)
Okay. Yeah, no, it does. it brings you back to my kind of the earlier question about, you know, maybe where this is all headed, right? Because when I think of automation in today’s space with a lot of these software tools and platforms, it’s like everyone’s talking about, you know, AI and agentic AI and how you’re able to have these agents kind of configure networks for the user on their behalf. And I think a lot of it is just a fancy new term for kind of the same old capabilities that have been present in the past. But at the same time, I also know that, like you were saying, a lot of these networks are kind of archaic. They’re not necessarily like, you’re not even thinking about AI and how to automate it with some of these AI tools we’re seeing and hearing so much about nowadays. Can you maybe just talk about some of these trends that are coming down the pipeline that you might be curious about adopting? Or if you think that there’s just no relevance for including in your platform.

Tomas Kirnak (Unimus) (21:34.942)
So there is, and by the way, yeah, this is a lot, or there is a lot of discussion in the networking space about this. We go to a lot of conferences as well as like specifically network automation communities and conferences to talk about these topics. And so there is actually multiple problems or issues into like adoption of fully AI driven infrastructure management. And first of all is that risk management aspect to it.

At the moment, you would be crazy to attempt something like this. And why? Because if you think about the current generation of AIs, LLMs, back-propagating deep learning algorithms, really what it comes down to is, and there is still research ongoing into this, but it’s the age-old question of is AI actually creative or is it just learning from the stuff that it sees and it only understands what is in its learning set, if that makes sense. And there is a, I don’t want to get too deep into the AI discussions. But the problem becomes that every single network is unique because it in a certain way mirrors the real world. Why? Because always in the network there is latency, which depends on geographical location, cabling, and how the physical layout of the infrastructure is done. That all depends on the real world. So almost every single network is quite unique in some way.

And the data sets for training AIs are not like, know, of course you can train an LLM on Reddit, which has like, you know, millions and millions of lines of text, which makes sense in like a conversational topic. But if there really aren’t millions and millions of networks and network configurations available publicly for AIs to be able to be trained on them sufficiently enough. And at the same time, basically what infrastructure and network is, there is a few parts to it. There is the topology, and then there is the configuration, and then there is the intent of the network engineer or of the business or whoever is building the network. To be able to understand the network, your configuration is your intent inside of a topology, if that makes sense, and the AI will have to understand all of this. First of all, AI doesn’t have the data because there is just no way to here AI, here is my network, here is my topology, and here is my configuration, all of it. And the context window becomes so large on all of these configurations and the topological data. then you will have to also explain the intent behind this network. And the point becomes that AI gets lost and just is not able to generate and apply the configuration in a, you could say safe enough way where anybody who’s a risk assessment or a quality assurance engineer for a large infrastructure, they’re like, yeah, let’s do that. Like there is so much risk, especially with the AWS outage, again, as an example, there’s hundreds of millions in damages because of a misconfiguration in AWS. And so imagine that, again, if you are a hospital, imagine you include agentic AI in your infrastructure management and suddenly your network goes down for half an hour, and like, okay, but are you willing to adopt that at the risk that that brings in, you know, when it fails?

Beau Hamilton (25:03.82)
Yeah, you’re after triage patients and you’re, feel like you’re playing whack-a-mole with all these different issues that pop up because of this solution that’s supposed to be, you know, help, help the grasses greener type of thing. Right. You’re supposed to, it’s supposed to fix all your problems. Yeah.

Tomas Kirnak (Unimus) (25:15.739)
Yeah, so where is the currently the actual valid use cases in AR is on the other side of the spectrum, on the analysis. Like, OK, AI, look at my network, and do you think it’s OK? And many times, it will tell you it’s OK, but are you sure it’s really OK? Does that mean I can go to a security audit and do a penetration test to really think it’s OK? So it’s a really complicated. That is very much being discussed at the moment in infrastructure management conferences and stuff like that. But currently, really, again, I do not know of anybody that would be, you could say, crazy enough to let agents manage their infrastructure because of those super high stakes that it brings to run an infrastructure.

Beau Hamilton (25:59.534)
That makes sense. Really interesting take there. I didn’t really think about that with this, with this particular area. Cause you think that AI is, mean, everyone’s talking about how it’s just going to impact every single industry. And I think that, I mean, safe to say like, maybe it will make its way to that word automation at some point, but like the near future, it sounds like that’s a no.

Tomas Kirnak (Unimus) (26:22.567)
So not in the near future. for example, even with Unimas, we support over 400 different network device types across 200 vendors. Some of these vendors, their documentation is not even available publicly. So how is AI going to learn how to configure and manage that equipment if you have to have an NDA just to receive the documentation for that network device, right?

And again, some of these devices, we have customers who literally manage devices from like physical hardware from the 90s, because it’s so niche that there is no newer stuff even exists, right? And that’s production networks, which you would be surprised how critical they are. It’s just critical infrastructure is an area onto itself which requires very specific approach. And AI being very generalized doesn’t have yet at least that super deep technical knowledge where, again, you can be sure that it does things well. And especially in other scale with hundreds of vendors, with every single vendor, every single device type having different syntax, different configuration, different purpose, different intent, and all of the stuff that I mentioned around. I do not know if at some point AI will be able to autonomously run infrastructure itself. Maybe in 10 years. It’s very hard to predict what will happen in 10 years. Like 10 years ago, AI was not even on anybody’s mind, right? So it’s very hard currently to predict what will happen in 10 years, but at least in the foreseeable future, I do not think like autonomous AI agent driven infrastructure is something that is realistic.

Beau Hamilton (28:00.268)
Hmm. Wow. I totally didn’t expect that answer. I was going to expect you to say, you know, it’s in the feature roadmap. You’re planning on rolling out some AI features in some way, or form. But I think all the points you mentioned make a lot of sense. Super interesting there. Thanks for sharing. I want to kind of get off the AI topic now and pivot a little bit just to kind of go back to some of the pain points that you see companies face, right? I’m curious, like maybe you can share some of the challenges that you see companies face when implementing a network automation solution and maybe how you can help alleviate some of that pain.

Tomas Kirnak (Unimus) (28:46.493)
So probably especially with network automation, the biggest pain is that a lot of the automation tooling that exists right now is aimed at developers, even like the name DevOps, developer operations. again, if we go into the specifics of networking, being a competent network engineer takes years and years and years. Probably say that if you want to be like a resident network architect, that’s 10 to 15 years of a career that you have to have because of so many protocols, so many use cases, so many devices. You have people which all their life, they just specialize on wireless networking, right? Because that area is so huge in itself. And especially if you go into bigger organizations, yeah, you have teams which is on layer two team, which just manages switching and stuff like that. You have a routing team which manages routing teams, very large organizations have a single team that manages BGP, like global routing tables and peering. What I am trying to say, or where I am getting with this, is that network engineers do not usually want to be developers, and they do not have the skill sets of developers. And at the same time, you will find that developers are not network engineers, and very often, most developers do not know networking.

Yeah, the question is whether they should. That’s an entirely another discussion. And I mean, that goes both ways, whether network engineers should know more development and whether developers should know more networking. But the point is that that’s just not the reality we live in. Network engineers, if you know, barely know any development, like a philosophy or any development workflows, could say most network engineers do not even know what Git is and I think that’s okay. I think it is not a realistic expectation for a network engineer to at the same time be a software developer.

And that is where we come to your question, like what is the biggest, you could say, barrier of entry into automation for organizations is that most of the tooling that exists, it is aimed at developers and it is aimed at the user of that platform or that library or that framework to be a developer, which network engineers, again, as I mentioned, are not, and so that is where we see the most issues that even large organizations, like if they want to establish a network automation team, it will usually be like one to two people out of the 20 of their network engineers. And like imagine basically now have two specializations and two jobs you have to specialize in. You have to be both a developer and a network engineer. And so especially with elements like other realization was that, there needs to be an alternative. There has to be a better or a different way, right? So with Unimas, the network automation that we do does not require you to be a developer. It does not require you to learn Python, Ying, Yang, Jinja, even Git. You do not need that skill set.

As a network engineer, you already know the command line, the CLI, and you already have all of the necessary knowledge to manage and configure the network. What you are missing is to be able to apply that at scale. So Unimas gives you that. It gives you the ability to do that network management and configuration at scale without needing to adopt developer skill sets. And again, we could talk about pros and cons of that approach because Unimas, is not a infrastructure as code platform, but that’s on purpose. So it is not a fully infrastructure as code driven networking product. Rather, what we try to do is we try to lessen that barrier of entry into network automation. And it’s like that golden rule of 80-20 or 70-30. Like, Unimus can do 70% of the network automation use cases you would ever want for 30% of the effort or of the time. And so we try to be very transparent with that. We are, as I mentioned, not infrastructure as code, but at the same time, you could absolutely route Unimus within the network and in a week be automating deployments rather than taking a mandlong Python course and I mentioned yin-yang, Jinja and all of that.

Beau Hamilton (33:08.034)
Yeah, and barely scratching the surface. Yeah. Yeah, no, that’s huge. mean, that’s no understatement to say that you can tackle and handle a lot of the developer components for handling network automation. That’s great. Because I mean, my mind goes to a science major. Like if you’re studying physics or a chemical engineer versus a structural engineer, and there’s all these different niches and specializations where you need to, I mean, there’s so much knowledge to learn. can’t realistically expect you to also be a geologist and know everything about, you know, the structure of like how the earth works as well as the structural components necessary for building a bridge.

And you kind of have to seek help, get a bigger, broader team with some other people that have that specialization, that knowledge, or in this case, use, like in the software world, use a platform that helps kind of tackle some of those issues and those gaps in the knowledge to bring the barrier entry down. That’s really interesting. I think you did a great job explaining that. Kind of digging in a little deeper to that question, I’m curious, what kind of barriers do you see that still kind of keep organizations from jumping into the automation side of things? Like, you, is there anything that like comes up that like really stands out?

Tomas Kirnak (Unimus) (34:38.321)
Yeah, mostly it’s just time and people, right? Many times it is hard to find good network engineers and many times, and this goes into like, how do you drive adoption of automation into a company, right? Management will oftentimes prefer to like, you know, put out fires rather than prevent them. And I think that’s just a reality of the IT world. Everybody who’s at a senior position in any IT company probably knows the workload is always more than the available time that you have. And that goes same for your team size. You always need resources, you always need people, you always need more skill sets, you always need to learn more, new technologies come in. So yeah, time and resource are usually the main constraints into adoption of large-scale automation and, of course, management approval and building that you could say a spirit or that mindset of, know, we should be automating stuff. And yeah, that’s why I always talk about like the barrier of entry. Like the barrier of entry needs to be lessened for those issues to not be so high and for you to be able to start adopting automated management of infrastructure.

Beau Hamilton (35:55.064)
Well, and for the barrier of entry to be so accessible for more people, I feel like you have to have a lot of integrations and you have to be compatible with a lot of the tools out there. How does Unimas integrate with some of the other tools and systems that companies already rely on?

Tomas Kirnak (Unimus) (36:14.352)
Yeah, so for us, it’s exactly understanding our users, understanding what other tools they use and building that native or those native integrations into the product. And we have a lot of those. like we have actually put time to build, for example, direct integrations into like, I think at this point, eight different monitoring solutions and platforms. We have built native integrations into like CMDB, which is, you know, configuration databases. We have built direct integrations into DCIM, which is Data Center Inventory Management Systems like Netbox, which are quite popular in larger scale infrastructures. And so having all of that out of box, like this is what we get paid for, right? We get paid for to be developers and to develop this software. So absolutely. We have a lot of these integrations ready and functional out of box. It’s the same that I mentioned that we out of box support more than 400 network device types across 200 vendors.

Because again, as a network engineer, you shouldn’t have to know how to write a driver to talk to a particular equipment. You shouldn’t have to do that. And so, yeah, we absolutely put a lot of time into making sure those integrations exist and everything works out of box.

Beau Hamilton (37:29.474)
That’s great. Yeah. Flexibility is huge. And yeah, when you have ID teams that already have an ecosystem of tools they trust, I they don’t want to have to necessarily go learn a whole new system and they want things to work plug and play as well as possible. Do you have any success stories that really come to mind where you saw like a lot of big, maybe clients of yours saw big improvements after adopting Unimus and using it as their main platform?

Tomas Kirnak (Unimus) (38:11.706)
Yeah, we have quite a few big organizations which basically. So maybe I can mention that our biggest deployment is 110,000 routers managed from a single Unimus server, which is a, as you can imagine, a large-scale infrastructure provider, which before that, they had team of literally seven people managing 110,000 routers. And so you can imagine what state that infrastructure was in because there is no way you can manage that with seven people. And so, yeah, this is exactly why they adopted Unimas at large scale to automate, of course, like security and configuration deployments, firmware upgrades for security updates and stuff like that. And that entire project was, I think the entire project was about three months, but that’s almost fully automated management of 110,000 devices.

There’s many, many times we have heard that just, as I mentioned, the simplest feature of just configuration backup has saved people’s networks so many times. Especially, I think it was like three or four years ago, the hurricanes that came through Florida with the whole infrastructure rebuilt in Florida, a lot of our customers, they’re very happy with the UMS because just rebuilding the entire infrastructure after a hurricane, can imagine. So first of all, you don’t want to build that from scratch.

And second of all, you need to build it up as fast as possible and that’s when the automation part of it comes in. So yeah, there’s quite a few stories.

Beau Hamilton (39:46.828)
Yeah, I can imagine. Well, no, just that 110,000 routers and automation of that project, that’s pretty impressive. Wow. Yeah, that just paints, it really visualizes and it of drives home a lot of what you’re saying is just the scalability and how you’re able to work with smaller teams, but also scale to accommodate. I mean, is there a limit with how many maybe routers in the size you’re able to work with?

Tomas Kirnak (Unimus) (40:17.32)
So maybe important thing to mention here is that Unimas is on-prem software. It’s not cloud, which is another quite unique thing because if you think about it, Unimas manages networking. Networking is what brings you to the cloud. So if your management platform lives in the cloud and it manages what brings you to the cloud, and then your connection to the cloud goes down, you lose your management of what is supposed to manage that connection. So it’s a cyclic dependency, which is another unique thing that actually, and other customers are very happy because of this. in our industry, nobody wants this to be running in the cloud because then you lose control over your local infrastructure. And so why this is relevant to your question is that there is absolutely a limit because you don’t have the endless compute resources that the cloud offers because it’s not really a valid use case.

But yeah, I would say up to probably 150 devices in a single infrastructure we can manage from a single server that is using multiple pollers. So we can do about 20,000 devices per poller. So it’s like a multi-layer architecture. You have your server, have a database, have your pollers. So there is some load balancing and load splitting across the polling layer. But yeah, I would say up to 150,000 devices from a single server with multiple pollers is what we currently can guarantee the software scales up to.

Beau Hamilton (41:41.664)
OK. Hey, that’s still a pretty high bar. That’s true, I suppose. Yeah. Well, no, it’s good to note that you’re on-premises as opposed to the cloud, because like you’re saying, the scalability there. But then you also have the AWS outage and some of the surrounding issues associated with that. And security would even talk about really the security aspects. Yeah.

Tomas Kirnak (Unimus) (41:45.66)
It depends, if you are Google that’s not much, you know, security is like, yeah, as you can probably imagine from our discussion, like this is this system literally controls the network, right? So if you were to gain access to the system, would be gaining access over management of all of the networking. So absolutely, this is very close to what you would call our SCADA system, right? Systems that manage like your power plants and like water treatments facilities. It’s, you know, it’s SCADA is the general like family of these softwares. And in MS, it’s not scale up per se, it’s very close to that family of systems where absolutely security is a very large concern or a very large design requirement when you are designing and implementing the software.

So again, having it on-prem and even so many of our customers run this totally air-gapped cut off from the internet, cut off from any external networking, simply because if you are in a, like, yeah, if you are a electricity company or, again, a water treatment facility, all of these systems are today interconnected, connected to the network, managed sensors, polling, IoT stuff, like, and there needs to be a network which provides connectivity to all of that. And so absolutely, you want to take security seriously and air-gap that from the rest of the internet and the world just so nobody can get in there. And again, other software works this way and we have customers in these areas that manage their infrastructure. So yeah, it’s a very niche and very different way to look at the world.

Beau Hamilton (43:42.666)
It is, yeah. It’s really, you’ve given me a lot of different things to visualize and think about. And I think just in general, you know, it’s one thing to talk about like network automation in theory, but just seeing and hearing about some of the measurable gains just shows what’s possible. just, it helps me as a visual person, visual learner to help kind of visualize the kind of state of affairs with this industry and what you guys are doing. So I really appreciate that.

We’re coming down to our last couple of questions I have for you. And I just want to see if you could maybe help sum up some of the things you talked about. If someone maybe were to ask you, you know, what Unimus does in just maybe like one or a few sentences or so, what would you say? Like, how would you describe the company? Or maybe just some of the things you talked about.

Tomas Kirnak (Unimus) (44:33.552)
Yeah, we try to make configuration management, network automation, and modern infrastructure management workflows available to a wide of a set of infrastructure engineers, network engineers, and people managing infrastructure as possible.

Beau Hamilton (44:51.31)
Perfect, simple, clear, straight to the point. Where can listeners go to learn more about Unibus and maybe get in touch with you and your team?

Tomas Kirnak (Unimus) (44:59.152)
Yeah, unimus.net, it’s our main starting point. If you are more interested in a bunch of technical stuff, we do have actually a blog, which is very technical. It’s written by network engineers for network engineers. So if you are interested in some kind of what areas we tackle and what we talk about and deal with daily, there’s of course other forums. There is a decent size community active on other forums and quite a other ways of course they are across all of the your usual socials and yeah.

Beau Hamilton (45:33.454)
Perfect. All right, unimus.net. Check out the blog for technical information. Really appreciate all the insights you share with us. think listeners got a lot out of this and I’m excited to see how it turned out. yeah, so that’s Tomas Kirnak, Founder and CEO of NetCore and Unimus. Thanks again. I really appreciate your time.

Tomas Kirnak (Unimus) (45:54.35)
Hey, thank you for your time as well. Thanks for everybody listening.

Beau Hamilton (45:57.838)
Of course. Thank you all for listening to the SourceForge Podcast. I’m your host, Beau Hamilton. Make sure to subscribe to stay up to date with all of our upcoming B2B software related podcasts. I will talk to you in the next one.