←back to thread

309 points dban | 1 comments | | HN request time: 0.254s | source
Show context
jdoss ◴[] No.42744258[source]
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.

https://github.com/netbox-community/netbox

replies(4): >>42744318 #>>42744734 #>>42745234 #>>42745416 #
1. nyrikki ◴[] No.42745234[source]
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.