When it comes to IT infrastructure and server management, there is an easy way to do things, and a hard way to do things. The fact is that most of the tasks involved in deploying and configuring servers–especially virtual servers–are routine and repeatable, which makes them ripe for automation.
There is another benefit, though, to automated server configuration. A platform like Chef can help ensure a stable, dependable configuration, and makes the task of troubleshooting and resolving issues with servers a more trivial exercise that doesn’t need to impact operations.
I wrote about this topic for DevOps.com:
Deploying, managing, and maintaining servers can be tedious. Deploying, managing, and maintaining thousands, or tens of thousands of server instances is overwhelming—bordering on impossible—without the right tools. Thankfully, the right tools exist.
The Pain of Doing Things the Hard Way
I know I am dating myself, but when I was an IT admin for a dot.com startup, I had to deploy servers the old-fashioned way. UPS would show up with a box from Dell. I’d unpack it, and mount it on the rack in the datacenter. Then, I’d begin the process of configuring the operating system, and installing the application software. Each server was essentially a full-day project, and we seemed to constantly be adding new servers, so my full-time role was basically “racking and stacking” for a while.
Adam Jacob was experiencing similar obstacles when he developed chef. Working as an IT infrastructure consultant, Jacob was frustrated by the configuration tools that were available, and the lack of a simple, repeatable process. Rather than starting from scratch and reinventing the wheel for each client, he developed Chef to enable IT admins to create modular, reusable “recipes” that automate the process.
Server management doesn’t end with deployment and initial configuration, though. You also have to maintain the servers, and resolve issues that might occur. When an issue arises, it could mean hours of troubleshooting to identify the root cause, and another few hours to work out and implement a resolution.
I used to get into philosophical debates with management and other IT personnel because it was my opinion that we should just skip the troubleshooting and rebuild the server from scratch. My theory was that it might be nice to know what caused the problem, but from an operational perspective I knew I could rebuild the server and restore normal operations in a couple hours. Troubleshooting, on the other hand, was an unknown—both in terms of whether or not it would even be successful, as well as how long it would take…
Check out the full article at DevOps.com: Simplify and expedite server management