Ever Higher Levels of Abstraction - Building the Future With Chef
If you have been in the industry for a decade or more, you probably have a pretty good idea of what being a Unix sysadmin is all about. Load the OS? Check. Configure local user accounts? Check. Install packages, compile some from scratch? Double check. Unix has not changed all that much, so it would be easy to assume that the job you were doing ten years ago would be the same job that you can do for the foreseeable future. But, that is the trap of dinosaurs my friend, the weather has already changed, and the days of dealing with bare metal are already moving fast behind us.
My first servers were OpenBSD, back before you could get a downloaded disk image. I had a script that would download the latest release and build an ISO image for me. I loved, and still do, the simplicity in the BSD systems. You couldn’t get any closer to the metal; all you had was a kernel, a formatted disk, and a few gzipped tarballs to unzip at the root of the filesystem, and that was your OS. It would be very easy for me to take this basic understanding of how Unix-like systems worked and apply it today, but that would be a mistake. Like all things in computers, the tendency over time is to aspire to higher levels of abstraction. This is true in programming languages, which have progressed from assembly, to C, to Perl, and now, to languages like Ruby. When writing in a high level language like Ruby, it is unnecessary to worry about things like pointers and memory management. Instead, the developer simply thinks about the best way to solve the problem he sat down to solve when he started programming. Less syntax, less manual configuration, and further away from the metal.
If you consider the old OpenBSD days as analogous to programming in C, you can draw a parallel to systems administration today. Managing servers with Chef is like programming in Ruby. Chef abstracts away the hardware and the operating system, allowing systems administrators to operate at a higher level, concentrating on provisioning resources. Chef takes care of the details of how to spin up a new virtual machine, or ensure that all of the running machines share the same configuration. Managing servers with Chef is like programming in Ruby, in fact, Chef and it’s configuration files are Ruby. Today’s systems administrators not only need to understand the internal workings of the Linux kernel, what the chip speed of the latest Xeon processor is, and how to most efficiently divvy up precious disk space… today’s sysadmins need to be programmers as well.
Of course, a certain amount of programming has always been a part of being a sysadmin. Shell scripts, Perl, Python, and now Ruby have all had their place in the savvy sysadmin’s toolbox, but what is different with tools like Chef is how the sysadmin thinks of using the tools. Using Chef, a server is nothing more than an object to be manipulated, a resource to be used. Which, honestly, is how it should be.
Chef uses the analogy of cookbooks and recipes to provide a hierarchy of configuration scripts. The recipes are written in something Opscode (the developers of Chef) call “just enough Ruby”, which is meant to give a syntax for the recipes that is easy to read without sacrificing programatic flexibility. Diving into some of the existing cookbooks can be intimidating if you are new to Ruby, so it might be good to start from scratch and write something very basic on your own first. However, one of the other fundamentals of Chef is that you should be able to download and deploy one of their field tested recipes without needing to know exactly what it is doing, we just need to know that it gives the intended result. If you are old school, that last sentence might scare you a bit. It scares me, but how many people developing in Ruby know how their code is being executed by the CPU now? Adopting Chef is also a bit about moving on, and giving a bit of control over to the system.
It’s an exciting time to be in the technology field, there has never been a better time to learn and grow. Accepting change and moving into the future can be scary, it can be hard to accept, but, technology waits for no one, you either ride the wave, or be buried by it.