Comment by jdoss
3 months ago
This is a pretty decent write up. One thing that comes to mind is why would you write your own internal tooling for managing a rack when Netbox exists? Netbox is fantastic and I wish I had this back in the mid 2000s when I was managing 50+ racks.
we evaluated a lot of commercial and oss offerings before we decided do go build it ourselves - we still have a deploy of netbox somewhere. But our custom tool (Railyard) works so well because it integrates deeply into the our full software, hardware and orchestration stack. The problem with the OSS stuff is that it's almost too generic - you shape the problem to fit its data model vs. solve the problem. We're likely going to fold our tool into Railway itself eventually - want to go on-prem; button click hardware design, commission, deploy and devex. Sorta like what Oxide is doing, but approaching the problem from the opposite side.
Look at the issue list...that is why.
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
Note how they want to be "NetBox functions as the source of truth for your network infrastructure."
Your individual situation dictates what is important, but had netbox targeted being a central repository vs insisting on not allow other systems to be truthful for certain items it could be a different story.
We have learned that trying to centralize complexity and control doesn't work, heck we knew that almost immediately after the Clinger Cohen Act passed and even ITIL and TOGAF fully call this out now and I expect this to be targeted by consultants over the next few years.
You need a central constant way to find state, to remove any questions or doubt regarding where to find the authoritative information, but generally if you aspire to scale and grow or adapt to new changes you really need to avoid having some centralized, god-box, and prescriptive system like this.
Netbox is just 10,000 Django models with a theme on top. Not very rewarding software to use.
I like netbox, had it deployed for quite a while. It's performance was abysmal and I had to shape my world around how they wanted things.
This is the usual case of "We need X and Y does X", but ignoring that Y also does Z,M,Q and washes dishes and you really don't need those things.
Sometimes building what you need is the easiest solution, specially when what you need is CRUD infront of a DB...
It is not that difficult to build it into your app, if you're already storing information about hosts, networking etc. All you're really doing is expanding the scope, netbox is a fine starting point if you're willing to start there and build your systems around it, but if you've already got a system (or you need to do anything that doesn't fit netbox logic) you're probably better off just extending it.
In this case railway will need to care about a lot of extra information beyond just racks, IP addresses and physical servers.
correct; I think the first version of our tool sprung up in the space of a couple of weekends. It wasn't planned, my colleague Pierre who wrote it just had a lot of fun building it.
Were there any promising OSS alternatives to Netbox?
1 reply →
Netbox is crap unless you are trying to manage a small but very heterogeneous environment. For anything big, very homogeneous etc you really don't want it.
It feels more like an OSS tool for managing university campus scale infra, which is completely fine if that is the problem you have but for commercial scale infrastructure unfortunately there isn't a good OOTB DCIM option right now.
Even for campus scale (e.g. CERN), there are limited options, https://www.epj-conferences.org/articles/epjconf/pdf/2019/19...