Comment on Become the Thousand Servers
grrgyle@slrpnk.net 5 days ago
That also means resisting the temptation to make ourselves indispensable. Being the person everyone has to call when something breaks can feel like a sign that we are contributing something important, but […] the goal should be to make ourselves increasingly unnecessary by making the knowledge we carry increasingly available to other people.
What a beautiful sentiment. Very well said.
To my chagrin, I’ve seen the “private sector” learning this lesson very well, with the practice of codifying configurations of machines and networks in “infrastructure as code” documents. Though these still require special training to decipher and apply, they make people (or workers) much easier to replace.
Although, I’m not sure I want reproduce the patterns I’ve learned from the corporate world, I’m curious if there’s merit to using some of this technology to make infrastructure more easily "spin-up-able. " Or maybe SH hardware will vary too much to make something like OpenTofu useful in a non-cloud setting.
fruitycoder@sh.itjust.works 4 days ago
I’m 100% biased towards this. It’s really cool to see a system get frankenstiened or frankenstein a system from code. It’s like getting to leap frog from all of their work without needing to ever explicitly knowing or working with each other.
The real deciding factor isn’t whether to automate or not but what is the expected technical skills of who expect to contribute or maintain it the future.
So I personally layer levels to it prefering the common automation where applicable. So tofu for infra and spin up. Ansible for OS config and network equipment. Kubernetes for everything else with a fallback to tofu for some apps that have no k8s API but a good tofu provider.
With that people can actually piecemeal what they want and where they want it if some underlying assumption changed (it’s no longer bare metal or aws, it’s Ubuntu or SuSE now, it’s RKE2 or it’s GKE now etc)
That said for bare metal I actually skip tofu and do a cloud native bare metal management service like TinkerBell or Metal3, and that’s really only if it’s worth it.
The other, when you see it work it’s beautiful, thing about the approach. GitOps. Watching what was a thousand shadow IT ops become PRs through automated testing and review is really magical. Coming from a IT back ground for life saving infrastructure the stress difference between the old hat way and this is really hard to understate.