Re:Ask HN: How do you document and keep tabs on your infrast...
by sedachv on Friday March 09, 2018 @01:03AM
(#16550054)
There is an even better alternative. You can put infrastructure information into the same version control repository where your infrastructure code lives, and you can even keep all the benefits of spreadsheets by using plain text format spreadsheets like Org-mode tables.
This means you do not have two sources of truth to maintain (what is in the RDBMS, and how that relates to what is in the infrastructure code repository), the RDBMS system does not have to reinvent versioning, you can see exactly how your infrastructure evolves, you can do atomic changes to both the infrastructure code and the infrastructure information that the code relies on (obviously you need a modern version control system for this), and the infrastructure code can access the infrastructure information in a much more straightforward (and much easier to test) way.
Re:Ask HN: How do you document and keep tabs on your infrast...
by dmannorreys on Friday March 09, 2018 @03:32PM
(#16554736)
This would become very exhausting if working with very large infrastructures. 80 000 virtual and physical servers? Have fun keeping that data consistent, up to date and available with Org-mode and version control.
I'm not saying your example is wrong, but "there is an even better alternative" doesn't always apply. For smaller scales, sure.
Re:Ask HN: How do you document and keep tabs on your infrast...
by sedachv on Saturday March 10, 2018 @01:40AM
(#16557425)
VMs need to be kept track of in whatever system you use for provisioning (AWS, OpenStack), otherwise you now have three sources of truth: what the configuration says should be running, what the DCIM thinks is running, and what is actually running.
Re:Ask HN: How do you document and keep tabs on your infrast...
by vinceguidry on Thursday March 08, 2018 @08:16AM
(#16544107)
Just use Google Docs.
So you have exactly those sorts of problems that RDBMS are designed to solve. Therefore it makes sense to move to a DCIM system using an RDBMS under the hood, that allows for concurrent edits, and also can be accessed by automation (cronjobs, CI, etc.) via some sort of API (or direct DB read access).