Unix Philosophy in Infrastructure

The Unix philosophy is to do one thing and do it well. This enabled the development of tool chaining with pipes, sending input to small tools and obtaining output that, at the end of the pipe, is a more useful representation or use of that data. Software for enterprises goes in the opposite direction to this approach, instead trying to handle all cases and add more features into a single tool to make it sellable to any customer. The suckless movement has arisen in opposition to enshittification of Linux software that has come about due to the widespread corporate usage of Linux stacks. Infrastructure and infrastructure tooling is another to that trend that needs to be called out.

Modern Internet infrastructure is complicated. It’s hard to pick up, hard to test for, and hard to get right. Integrated solutions from vendors, which may be open source, are dominant in the landscape because it can be natural to reach for an off the shelf tool to solve one’s problems. Some of the tools did come in with new capabilities, while other glued together common pieces in order to make cohesive environments to make sales or generate contributions. Kubernetes is an example of huge project that is infinitely configurable, with so many different distributions, implementations, and guidelines that an engineer can’t reasonably make an effective production deployment in a short order without being trained on the system. The orchestration layer becomes the operating system of the deployment at that point and needs to be treated as such, rather than just another tool that Unix/Linux engineers need to know. Powerful and clunky, esoteric and open, the system and others like it are for enterprises and as such are not suck-free. Infrastructure components existed before and are still being developed that can be joined and piped together in ways reminiscent of the Unix and suckless philosophy. Getting back to basics in order to suck less may be in order for infrastructure.

A infrastructure engineer who has had Kubernetes, Openshift, Proxmox, or any number of availability platforms dictated to them as the appropriate tool for any and all jobs may ask what other options exist for them. How would someone deploy a containerized web application on redundant compute nodes and update images without using a heavy, integrated monolith? Using tools like keepalived to pass an IP address between nodes, pacemaker to define services and control running process count, and package manager tools to package and update their applications on immutable filesystems. Concepts that get touted as core offerings from the big tools had to come from somewhere, and those distilled concepts are still available and ready to be pieced together exactly as needed. Not every organization needs to run like a FAANG (or modern equivalent) shop with exceptional redundancy, and not every engineer needs to strictly follow those tool selections. Having room for free associations of infra tooling will only allow for new, unexpected pairings that may suck far less.