I've previously explained the background and motivation of The Little Network That Could, but I realised that there are some implicit values that permeate my choices which would be worth making explicit. Here are a few which come to mind:
K.I.S.S.
Espousing the Keep It Simple, Stupid principle is well-enough established in IT circles that I don't feel the need to justify my selection of it as a core design principle, but I will note a couple of things:
- One of my main goals in network design is security, and complexity is the enemy of security.
- My time and my intellectual capacity are very limited, and building complexity directly impacts the abundance of the former and the energy required for the latter. Perhaps no better defence of the K.I.S.S. principle has been made in recent years than this gem from Richard Turton:
TL;DR: I'm an idiot, you're an idiot, and here's how to idiot well.
Pragmatism
This is somewhat of an extension of the previous point, in that I value simplicity in a solution over feature-completeness, elegance, or trendiness, but it is also a value in itself: I have to live with my design choices, so they have to work. Once I have something working, I usually stop there and move on to the next thing on my ever-growing to do list. My code is littered with FIXME comments, and I'm fine with that. Very occasionally something might work inelegantly enough for me to come back to it and put some time into making it better, but that's the exception rather than the rule.
Of Pets and Cattle
In my current day job I work on helping customers covert their applications into container- and serverless-friendly microservices. We try to work within the Agile Manifesto's principles as best we can, and usually this involves automating everything. This means we strongly eschew "pets", as they are typically termed - servers or containers or functions which are unique snowflakes, maintained by hand - in favour of "cattle", which are maintained via automation and easily able to be replaced with another unit at short notice.
When it comes to TLNTC the requirements are different, so the pets vs. cattle balance comes down in a slightly different location. I still prefer automating things, and I probably use more automation code now in TLNTC than I ever have before, but my services are still essentially one-instance - I only have one mail server, one public DNS server, one outside firewall, etc.
Because I don't replace them frequently it doesn't worry me that I might have to spend a few hours getting a new VM to the state at which it's a true replacement for its predecessor. Sometimes this involves trying out a new technology for the first time, or upgrading to a new major version of a software package which has a lot of new features and a few breaking changes, so often I'll roll these by hand the first time, and automate later when the need arises.
Again this value has some overlap with its predecessor: I automate to a point which is pragmatic for the problem at hand, but I don't feel the need to be ideologically (or aesthetically!) driven to have only cattle and to herd them using Declarative GitOps Continuous Delivery for Kubernetes.
Free Software, by which I mean: copyleft
This post is getting a little longer than I would like for a tech nibble, so I'll just mention that, despite the idea being more than 30 years old and the movement's founder being shown to be a terrible person, there's nothing more important for making it possible for humans to continue to thrive in the "software is eating the world" era than Free Software. So my default assumption is that everything on my network should be Free Software.
I no longer support the Free Software Foundation because of its founder's behaviour, but I remain ever committed to the principles he described. I remain hopeful that copyleft ideals will be stewarded more faithfully by the Software Freedom Conservancy.