Artisan Server Crafting - A Dying Approach

Artisan server crafting is how many system administrators once approached the work of provisioning and caring for servers. Hardware would arrive on site. Engineers would unpack the new servers and marvel at their new toys; the latest in telescoping rail systems, collapsible cable management arms, and wicked cool blue LEDs. The servers would be lovingly racked and cabled, then something odd would happen. When reaching for the Brother P-Touch label maker, work would grind to a halt; “What are we going to name these servers?” someone would ask. A series of (sometimes heated) conversations ensued while potential host names were debated...

“This one's going to be an SMTP relay so we should name it Cliff.”

“No! That wouldn't be in line with our convention of naming all servers after wizards.”

Eventually, agreement would be reached and the servers could finally be assigned names. This critical step allowed the rest of the work to begin; OS installation, configuration, networking setup, etc... Depending on the nature of the server's intended use, special care would be given to choosing the size of file systems, exactly which services would or wouldn't be installed. Favorite tools would be downloaded and installed. User accounts would be created and the administrators would copy in their preferred local environment variables. Overall, great care would be exercised over each step of the server's creation.

Finally, the servers would be put into service and they would continue to be anthropomorphized over time...

“Oh no! Greyhawk is down to 10hp! We need to delete some old logs to free up space.”

“Gandalf is alive! We saved him from the brink of death after replacing his failing power supply.”

“Hey everybody, Merlin has been up for 500 days in a row! How should we celebrate?”

Servers would be cared for, patched, monitored, and generally looked after by loving administrators. The servers would develop their own personalities, quirks, and other endearing (or maddening) qualities. Eventually, everyone on the team would memorize the little quirks of each server and be able to care for each host for years to come.

Eventually, a few things happened. Distributed applications designed for horizontal scalability helped drive explosive server growth. Business needs drove increasing demand for faster and faster provisioning. Budget constraints limited the server-to-admin ratio. Increased turnover exposed the undocumented state of many environments. Imagine the situation facing a typical administrator: “Welcome aboard! We need 30 new web servers deployed this weekend.” Followed by; “And we need to change the NTP settings on 200 application servers in the next two days.” Followed by; “Bob just turned in his two week notice, so try to schedule some knowledge transfer sessions before he leaves.”

At the same time; server hardware became increasingly commoditized and less expensive. Server virtualization became more widely accessible and less expensive. Provisioning tools became more sophisticated and less expensive. Right when the administrators needed it most, solutions were becoming available. Infrastructure automation became a real possibility! Actually, infrastructure automation became a real necessity!

Unfortunately, some shops still aren't getting it. They cling to hand-crafted artisan ways of the past. They blame the poor planning of project teams that don't provide enough time for server provisioning. They bemoan the budget constraints that keep them from hiring enough people to manage the hundreds or thousands of servers they're responsible for operating. What these shops need to consider is abandoning their server friends and embracing the notion of disposable nodes.

Now, what am I going to use for the SSID of my wireless LAN? Hmmm, let me think about that for a while... :-)