What’s on our mind: Infrastructure as code

On my mind today are the skeuomorphic terms we use to conceptualise functions performed by computer systems, and how they are not always helpful. At Open Fifth, we host and manage applications running on servers. “Server” conjures in the mind “a box in a rack with fans and cables”, which can tempt us to behave as though we are custodians of many different, highly important, physically whirring machines; connected by cables, protected by firewall appliances, powered on and off with a switch at the wall. New ones must be configured and plugged in when new applications need to run, old ones must be unplugged and decommissioned when an application no longer needs to run.

The groaning pile of APIs and virtualisation layers and hidden composability protocols we now operate on make these terms much less useful, however. I’m trying now to think in terms of functions, rather than virtual instances of familiar hardware devices. The creation of a cloud VM (virtual machine) is much more akin to a malloc() and a pthread_create() in C, than the plugging in of a new computer in a cupboard. DNS records are pointers, Ansible plays are constructors, VM templates are classes. This allows us to apply concepts like scope, inheritance, polling/interrupts, encapsulation, idempotence and mutability to the digital infrastructure we manage.

It may be that this distinction is only meaningful inside my own head, but I aim to have these parallels better inform our systems design strategy, and keep more libraries working more reliably more of the time.