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.