This is a bit of back story on why I am sitting here in San Francisco at my first day of PuppetConf pre-conference training, Fundamentals for System Administrators.
You see, I took enough programming as an undergraduate to gain a healthy respect for developers and to know that I am not one. Although I took some C++, Java and a tiny bit of machine language, at some point I realized it was not necessarily my calling. In my career as an IT Pro I gravitated toward the SysAdmin and Operations side of the house. I was content to run the servers, hardware infrastructure and interact with the off the shelf software or custom apps without needing to go much further than looping through the occasional bat script, if-else and for-each that I kept in my script kitty bag of tricks. I got along well with that level of skills for nearly 15 years working for various customer organizations. Then in late 2011 I was presented with an opportunity to join a tech startup that writes software for the hypervisor storage stack. Part of the reason I decided to make the leap from being a customer to working for a partner organization was precisely because of the team of strong developers I now work alongside. Our team is lean, agile, fluid… whatever moniker you want to assign to how the work gets done, the point is things move at a quick pace and there are constantly multiple projects moving in parallel. A portion of my duties involve rapidly provisioning, configuring and managing multiple environments for everything from TestDev, QA, UAT, customer and partner POCs and of course production. With this many moving pieces, reacting to a request is already too late. I have to be proactive. Wading into this role, it quickly became evident that the ‘traditional SysAdmin’ way of working; click, click, next, next, finish was not going to be enough to keep up with my responsibilities in this environment
So there I was, painfully aware of the fact that I need to be able to make my hosts, vms, apps, infrastructure and the like come together faster and more reliably…. The question was, where to start? Realizing the potential learning opportunity I was presented with I began to take stock of what I needed to bone up on and what resources I had available to me. I needed to know how best to invest my time and energy. I knew I was not going to somehow become a developer overnight, or even in a few months. Besides, it would take me years to get where my teammates already were. They are valuable resources, especially when it comes to the coding of our infrastructure automation. I bring the operations know how of which levers to pull and buttons to push, they help me with how to coordinate the quick systematization of the otherwise labor intensive execution of repetitive tasks.
I’ll admit that working along side senior programmers can be a bit intimidating. Still, I think it’s important to realize that this relationship should actually be very complimentary. While certainly many developers are incredibly skilled, there are a great number of tasks that an infrastructure managing ‘IT guy’ does in operations that a developer may not have much experience doing. It’s important for either party not to be afraid to admit to a colleague when you don’t (yet) possess a particular skill or need their help to step through an area where they only have surface level understanding.
For myself, some of the areas I’ve been able to strengthen my skills include improving my comfort level using the commandline. Coming from a mostly Windows background, I will admit to being a bit apprehensive at first, because again, I’m not a developer… That has changed somewhat and while previously I was mostly content to remain comfortably perched atop my GUI, armed with my mouse and only a few good ole keyboard shortcuts, I now feel comfortable spending a solid portion of my time ‘shelled in’ to multiple systems at a time, monitoring, deploying and modifying systems physical and virtual, from the command line. Now, I’ll say I’m still no bash hash slash wack bang splat spittin’ CLI Wizard… but I feel I can comfortably and efficiently navigate around a file system, interact with apps, utilities and system services enough to get my job done. Piping or passing along parameters are not an insurmountable challenge. Where I do lean on my developer is with structuring my code to be robust and with regular expressions. I had the ‘hello world’ down pat and I’d seen some awk & sed used in scripts that I might have copied and pasted somewhere without really understanding how they worked. So, PowerShell has been a great transitional tool for me and the assistance of my more wizardly colleagues, I was able to take a few scripts and cobble them together into functions.
Now, taking this another step further, we have this build system, that pulls code from sourcecontrol, does the compiling, runs some continuous integration tests and spits out a bundle with some binaries ready to be picked up and deployed…. and hey, that’s exactly why my little scripts were doing. So, we took my scripts, added some error handling, parameterized them and told the buildbot about them so it could call them every time a build was completed. This allowed for push button deployment of our app from code into an existing environment. What we’ve created can look up the latest build, check to see if it’s already running in and environment and if it isn’t, go ahead and provision it along with initiate some elementary interactions between the environment and our software. Now this is still not completely fleshed out and there are a number of enhancements that I’d like to make and have captured on Trello cards.
That is the reason I am here at PuppetConf pre-conference training. To dive headlong into learning and using Puppet to perform more advanced operations to achieve desired configuration state using the simple yet powerful declarative management tool.
So, my first takeaway for you, whether you’re a SysAdmin, operations type, or a hardcore code warrior, don’t be afraid to reach out to your brethren. We can accomplish a lot more when we work together and pull from each other’s strengths.
Keep an eye on this space as I’ll be posting updates on my take as I progress through this 3 day adventure in Puppet.
Here’s to Day -1 of Puppet Fundamentals for System Administrators.