Other people's computers
Last month I gave a short talk at Bristol DevOps about Infrastructure as Code (IAC) with Terraform. Of the 50 or so people in the room, I think at least a few of them were already on their own IAC journey but they humoured me through my very basic examples, memes and bad jokes. However, lots of people seemed to be looking at me as I explained the necessary steps to set up your development environment, write, plan and apply infrastructure code, with an expression that can only be described as: “Why?”
If you’re new to Cloud infrastructure in general, it can look like quite a lot of effort. If you’re a traditional systems engineer then you’ll be familiar with building a server and lovingly crafting its operating system and configuration. This mindset doesn’t scale in the cloud however. I joke in the talk that the cloud is, as we all know, just other people’s computers, racked by people who are much better at cable management than us. But it’s also the elasticity we could never get in our own data-centres, scaling to thousands of CPUs or exabytes of data. And you just can’t set that up by hand.
Towards the end of my talk I bring out the unicorns and rainbows (slide 38 if you don’t believe me) to describe the dream of managing infrastructure in an auditable, repeatable and dependable way. Why are these 3 things important?
- Auditable — Could manually configured infrastructure pass an audit for ISO? Maybe if you enjoy writing endless docs. I don’t.
- Repeatable — So you clicked through 40–50 pages of AWS web UI and finally, your stack is built. Now do it again for staging. Now do it again for DR.
- Dependable — If you can’t audit and repeat the actions that built your infrastructure reliably, you can’t depend on them.
The whole philosophy of doing something “as code” is of course a software engineering approach to an operations function, which is the primary tenet of Site Reliability Engineering. This shouldn’t frighten you off though, because once you enter this wonderful world you suddenly get the benefits software developers have had for all these years — source code control, collaboration tools, automated testing and deployment, and more.
I enjoyed giving the talk but didn’t have the time (or the guts) to provide a live demo, so in lieu of that I’m going to expand on it with some tutorials in the coming weeks (Update: here’s the first one). In the meantime, you can view the slides here: