My dog is brilliant. He’s a ginger and white collie cross mongrel rescue thing, and he’s such a good boy. Every morning, he hears the alarm and before I have chance to snooze it, and he comes to get me up. From the moment I wake up and have a cool wet nose nudged up against my face, we hang out. He comes to the office on work days, but he also loves Netflix and chill with me and our family on days off. His name is Nigel, and now you know a bit about him, I bet you kinda care about this dog you’ve never met. And that’s exactly the reason you shouldn’t give your cloud servers names. And if you do, pick a better one than Nigel!
Bart, Lisa and Homer
In times gone by, and certainly when I got into my career in IT, we knew all our servers by name. Sometimes they might be things like CITY-FILE02 and CITY-APP01, but often they’d be things like Bart, Lisa and Homer. We would give them little personalities. I remember one mischievous little domain controller we named Garfield because the cheeky little scamp didn’t like Mondays.
Then along came virtualisation, and all of a sudden lots of servers were running inside one big noisy server, instead of us being able to tend to individual boxes. Our attachment to our pet servers grew strained. But we knew our old friends were still in there somewhere, and we still loved them.
Cattle, Not Pets
But now our servers are in the cloud. And we probably rebuilt them to when we did our cloud migration too, so they’re not the same server they were 10 years ago. My emotional connection to the finance line-of-business server just isn’t what it used to be. It’s not you BC-FIN-PRD01, it’s me.
Okay, enough of my silly flim flam, but I’m talking like this to make a point – that talking like this is silly. Our servers are nothing more than 0’s and 1’s these days. We don’t need to monitor their devices, check their temperature nor adjust the humidity of their special room. If BC_FIN-PRD01 disappeared right this minute, I would not care. Servers are more like cattle than pets now.
I’m not saying that no server is important. All servers are important to some process somewhere, otherwise they wouldn’t exist at all. What I’m saying is that a particular instance of a given server isn’t important, since we can simply recreate it within seconds using modern tools.
How To Make The Change
Lots of us have looked after temperamental servers before. Ones where a consultant had to come in to install it and get it working the way it should. Woe betide anyone who alters the configuration! And look, those servers might just stay that way until the application is replaced. We can keep images of it, have red-hot controls for patching and rollbacks, and monitor it like crazy. Let’s make the best of a bad job.
But wherever we can, servers ought to be disposable, and the best way to achieve that is with scripts. A build script is a set of commands which can be run automatically to install and configure a given application on a brand new server, given a fresh installation of a base operating system. A build script always performs the same actions, in the same order, and with the same results. So if a server disappears, nobody cares, because we just provision a new server, and run the build script.
The Future
Containers! Well, actually containers are totally a thing now, and they’re awesome, but they take another mental leap. You should definitely go and read about them here though!
Once we have build scripts, and we’re used to redeploying critical applications onto new server platforms, the leap to containerisation is easier. However a lot of clients we work with are already struggling to get to grips with new concepts in the cloud. One thing at a time. If you need help with getting to grips with this, get in touch!
