In case you’re interested in the slides, here you go:
In a previous post, I was making a call for HomeOps, the application of DevOps principles to SOHO (small and home office) scenarios as well. I’ve listed a number of arguments. Here’s another one.
You have been practising sort of a DevOps approach at home already since the very beginning.
Or to be more precise: while you may not have been exercising the professional tools and methods we have to come to associate with a DevOps mindset, you will have nevertheless applied the gap-bridging mindset.
This claim includes three aspects:
- that it takes a Dev
- that it takes an Op
- that you’ve fulfilled both of these roles simultaneously
Let’s begin with the second point. Trivially what you’re doing at home is fulfilling the role of an Op. You might not have a dedicated monitoring system in place that sends you manager on your pager but you’ll actually have a much more advanced monitoring instance that will ring on your mobile the very moment your file service goes down: your family. (Or, if we consider the SO in SOHO, your colleagues.) If you’re reading this article, you’re likely to be the one in charge to get that file storage back up running. If not for them, then out of your own interest. If that’s not Ops, then what? Yes, you do not have the professional tools known from your employer, but as I set, I’m talking about the mindset.
And you’ve been a Dev. Still enjoying the traps of a distribution upgrade? I mentioned the example of Berkeley DB updates that required converting of on-disk databases, of course _after_ installing the new OS release. Ancient times, you say? Think about updating from Apache 2.2 to Apache 2.4.
These are examples that all require an intervention. Of course, in the event of n=1 servers, the ops guy in you might be tempted to do the necessary steps manually, in lieu of a “fire and forget” perspective. But then again, why would you have to do the same steps as thousands of other IT professionals? After all, the update pain is roughly the same. So why not let ONE of us, or more exactly the dev guy in one of us, do the work in a manner that can be reused by us all for collective advantage?
The last point is rather trivial, too. I don’t know if you’ve delegated IT responsibility to members of your family or your office, but in all SOHO scenarios I’ve met there is exactly one guy proficient enough to handle all IT business. And that guy does not exactly divide himself between the dev half and the op half. The dev in him does not meet his goals if the dev in him does not meet his ones. For the very reason that their goals are, in the end, pretty much identical.
Actually, when I matured from my a young boy’s perspective influenced by home computing to understanding the way business IT is structured, I’ve never really understood the divide between devs and ops that seems to dominate the corporate world. But then again, that must be due to someone who thought it would be benificial to divide responsibility.
I’m currently at the Linux Foundation’s LinuxCon Europe 2011 conference in Prague. I’ve been to the Collaboration Summit in San Francisco earlier this year, too, and I’m pleasantly surprised by the quality of the talks so far. This year’s talks seem to be a lot focussed on btrfs and ext4:
- Quo vadis Linux File Systems: An Operations Point of View on Ext4 and BtrFS
- The Ongoing Evolution of Ext4: New Features and Performance Enhancements
- Ext4 Improvements For Cloud Servers
- The Btrfs Filesystem: Status and New Features
These talks have actually all been quite good and not too superficial. Another topic I found rather often was High Availability:
- Staying Alive – Establish a Nearly Unbreakable IT Infrastructure by Fair Means
- Survey on HA Solutions on Linux
- Fencing and maintaining sanity while using High Availability Clusters
- Open Source Solutions for High Availability and Disaster Recovery
The talks in this area have not been quite as good, but still, seeing the topic itself represented was a good point. Further talks I liked include:
- Optimal Usage of SSDs Under Linux: Optimize Your I/O Subsystem (although most of its contents had already been published in a recent c’t article)
- What Goes into an Executable? Identifying a Binary’s Sources by Tracing Build Processes
- Introduction to Configuration Management with Puppet
- The Case AVM vs. Cybits: The GPL and Embedded Systems
- CTDB + Samba: Clustered CIFS Services Growing Up
In addition, the Prague location, although at first rainy and later cloudy, turned out to be quite a good choice. The conference hotel seems to be a nice location to me and dining is really cheap in the Czech republic: consider a warm meal and two beers for 8 Euros :-)
The very moment you start running a service of what kind ever, you will face yourself being exposed to the concepts and release cycles of the software underlying your service. In the case of Linux, among other issues this results in the question of what type of Linux distribution you deploy on your servers. The question is not whether it is Debian, Red Hat, Suse or Ubuntu — the question is: do you go the “enterprise” road or stay with community-backed products.