/dev/oops

fiddyspence's blog

The Simple Things

I’ve had a week where I’ve been thinking, professionally at least, about expressing system configurations in terms of code.  The code is used at a high level to describe what the state of bits of an infrastructure should be.  There’s all sorts of other stuff going behind the scenes to actually make that code turn into reality, on but at the most basic level it’s been a game of describing what reality should look like in an abstracted way.

One of the tricks to doing this effectively is to make those configurations as dynamic as possible.  The code should  consume data from one or more sources, make decisions on that data and output sets of configurations accordingly.  As a technique, this isn’t that new - IT is built around the idea that depending on what you input, the output gets modified and different things happen accordingly.

The data that is consumed by, and fuck it we’ll call a spade a shovel and talk about a configuration management system, might come from various places.

You might have static data that turn into very specific bits of config - think database connection strings that consume passwords, or website vhost entries that have various different attributes.  The data you consume might be dynamic - something is happening over there in a smoke and mirrors kind of way, and lo your configuration management system consumes some data and decides that you need to magically deploy another widget because the widget farm is approaching some capacity trigger that means you need more widgets, dammit.  The data you have, it’s complexity and how you use it to drive your infrastructure will depend on what you’re doing.

One of the fundamentals of data is that if it’s bullshit, it’s going to be hard to use.  Bullshit data will cause you to spend a lot of time working out what the data is (think about a 2 year old banging that square peg into the triangular shaped hole) and then what to do with it.  If you’re going to use data to drive your configuration, don’t fuck you-of-the-future up by trying to be cute or clever with the data.  Classifiying systems by hostname is a common trick to consuming data whilst making decisions on what configurations to deploy to a particular node.  Having a robust, meaningful but flexible hostname convention that is both machine and human consumable starts to look really important - the days of naming systems after Star Wars characters, Tube stations or car models are steadily vanishing into the distance.

The moral of this story is that a hostname convention where:

- The first three characters are the TLA of some football league (to denote production or development)
- The next n characters (where n is a number you first thought of, subsequently wiped your arse with and then composted it for n divided by some fish moments) are the names of your first several pet hamsters
- The next characters is a single hex number (that corresponds to something that was never quite clear)
- The final 2 are numeric characters (that mean this server is number xx)

Is going to be difficult to code against (to say the least) and are going to consume a lot of brain power to remember what the fuck bpl(barclays premier league)flashthethird(we had several hamsters as kids which met variously sticky ends)A69 actually does.

In case you were wondering about what else I’ve been thinking about, non-professionally as it were,  I’ll give you the conclusion and save on the reasoning - Pizza on 2 days in a row is a bad thing.