Ok. Here’s the deal. As the term “Web 2.0” makes its way into more and more glossy ads printed prominently in the largely irrelevant technical drivel outlets (er, magazines), more PHBs are going to want it. In many cases, this is probably a justified desire, given all that Web 2.0 encompasses. Some of those who have a clearer view of the technological landscape have commented recently that operations could well be *the* differentiating factor, the “value add”, that determines success or failure in Web-2.0-land.
I’ve seen very little, even from the usually outspoken developer community, to dispute these comments. Of course, I’m an operations person, and I think that most of the comments are spot on. They are also cautionary in their tone, which is also spot on, because operations is sort of a forgotten landscape in the technological ecosystem. It’s worthy of concern.
The only questions that seem to be going unasked, then, are “What do the
operations folks need, and what plans exist to meet these needs?”
Commentary has gotten us to the point of consensus. It’s time to get moving on
a plan of attack now. I haven’t a clue exactly where to start. For my part,
I’ve tried to clean up a lot of my code, and post any snippets that can be of
use to others on my website - http://www.linuxlaboratory.org. Unfortunately,
what’s there is hardly even a drop in the bucket.
(NOTE: if you have code you want to put there for operations folks, drop me a line)
In addition to working in operations, I’m also someone who loves discovering
and exploring new technologies (and old ones, too), and I love to write and
help others understand how things work, the context that different
technologies operate in, the patterns that exist in different technologies and
operating paradigms, and the like.
This, I’m told, is something that a vast majority of people working in
technology despise. Nobody likes to document things. Maybe part of it has to
do with r0ml’s ‘bozo’ theory: documenting things means somebody will read it,
and perhaps you’ll be found to be a bozo for one reason or another. Maybe part
of it is sheer laziness: nobody’s found a way to automate documentation for a
service deployment that I know of. Whatever reasons exist for operations
people tending to stay away from vi for anything other than config files or
code, I’d like to help fill the gap in whatever ways I can.
So here’s how this works:
I’ll ask you, the operations people at large, some questions. You will either
leave replies as comments to this post, or you can email them to
I’ll monitor the responses and email, and I’ll use any and all resources at my
disposal to come up with some directions that I and others can take to address
the needs of the operations community. If it means development work, we can
bring them into the conversation. If it means more documentation is necessary,
I’ll try to do my part there, and share the information I get with other
authors and experts whose documentation I can help develop if need be. My
hunch is that there’s plenty of things needed by operations people that a
whole team of smart people who have access to resources themselves haven’t
even thought of. That’s what makes this whole experiment interesting.
So, without further nonsense:
What is it that you need? Do you need tools? What kind of
tools? What tasks need automating for which there is no good tool? Why do you
think the current tools suck? What exactly sucks about them?
What things lack the requisite integration? What services are lacking in
features? What features do you want to see? How would these features help you
in your work?
What services don’t even exist yet in a form that you can use? Why can’t you
use what’s available now? Why does it suck?
What are you currently writing code to do yourself? What platforms are you
working with? What is the “holy grail” for your environment? Why aren’t you
What things have you left behind because they’ve failed to scale or perform?
What have you moved to? What decisions have you made that you’ve been forced
to revisit in light of new requirements? What’s the driving factor of the new
requirements? Is there a theme or patterns in the requirements you’re seeing
now as opposed to two or three years ago?
What tools have you been happy with? How can they be even better?
Basically, in a nutshell, “What’s causing you pain, why is it painful, how can
it be alleviated, and why do you think the right solution doesn’t exist
Be as specific as you can in your replies. Name names. Bring on the links. If
you think that application x is only useful to you if it can integrate with
service y, and it doesn’t, then say so, and also say anything else you can
think of that would make either app x or service y more useful.
If you work with software vendor foo and you need tool bar, but you can only
get it if you sign your life away, then SAY SO! Chances are, some of us who
work with nothing but open source solutions aren’t even aware that these
commercial proprietary tools exist, and if we were aware, we’d say “hey,
that’s cool, I need a free tool that does that”. If anyone has proven that
they have the power to make it so, it’s the open source community.
I look forward to your responses.