A New Addition to the InfoQ Family: The Operations Community
[Editor's note, April 7th 2010 - this has now been updated to reflect the launch of the Operations Q]
A seventh community has now joined the current six existing communities on InfoQ.com. When one looks at our existing queues, one sees a definitive pattern - we currently focus upon application development and architecture (.NET, Ruby, Java, SOA, Architecture) and also discuss Agile techniques, primarily in the context of application development. However, what happens to that software once it's been developed? Is 1.0 the end of the project, just like reaching the end of a video game, and choosing a new one to play?
I'm going to go out on a limb with this one and say "no". What happens after that point is that the software goes into production, where it usually becomes the primary responsibility of an Operations team. The Operations team will monitor the application, troubleshoot issues with it, and generally ensure that things are flowing smoothly with the application. I admit that this is a very generalized view, but that is because an in-depth analysis of the intricacies of Operations, how to best handle the interactions between Development and Operations (including DevOps), and the myriad of options that one has for operating an application would make a more detailed discussion span volumes of books. It's also a topic of great general interest (or should be), because every single website or web application in existence is being operated in some manner, no matter what language it has been implemented in. Operational choices have been made, whether it's on a server running inside of somebody's closet, hosted in a third-party environment somewhere, or a behemoth which spans several data centres around the world.
Speaking from my own personal experience, one of the best pieces of writing which crystallized in my mind the importance of Operations was Release It! by Michael Nygard, whom I actually had a chance to speak with around the book. It is actually also Michael who, in an interview I did with him at QCon London 2009, provided me with concrete justification for selling the idea of an Operations community within InfoQ itself:
It seems that the operation of an application is often considered a secondary concern to the development of an application. Why do you think that is?
Because mostly we ask developers about it. If you talk to CIOs and IT managers, they'll happily tell you that more of their budget goes to operations than to development.
What will the Operations community cover, you ask? A wide variety of things. We've actually been publishing some content over the last several months in preparation for the launch of the Operations Q, and they've covered topics such as:
- MySpace replacing standard HDDs with SSDs in a bunch of their servers, and the pros and cons of SSDs versus HDDs right now
- The exhaustion of IPv4 addresses and what's likely to happen given the slow pace of the transition to IPv6
- The Puppet and FAI management automation suites which can be used to install, automate and manage many Linux/Unix machines easily
- Amazon RDS, a relational database in the cloud, and what the tradeoffs are for cloud-based RDMBS hosting/storage
- Scout, a Ruby-based server and application monitoring service
In a more general sense, the Operations community is intended to discuss the wide variety of things that are of importance to the operating, maintenance and management of an application - network architecture, database management, hardware, the benefits and challenges of the cloud, monitoring and management of applications, options for pushing software to production and rolling back failed releases, and many other things of interest to Operations teams around the world.
The official launch of the Operations community has now taken place, and as of April 7th 2010 it is a top-level community on InfoQ. We'll have interviews with a variety of people and presentations from a few different conferences as is the InfoQ custom, but we're also interested to hear from you the reader what topics you find of most interest, and what things you would like to see more of. And, if you have an interest in writing for InfoQ about Operations, either regularly or via one-off articles now and then, we definitely want to hear from you - given that this is a new community, we're actively searching for new writers. And, as always, we're interested to hear any feedback you have, via any one (or even several!) of our feedback channels:
- Twitter via @InfoQ
- Email via email@example.com
- Google Groups via the InfoQ group
- LinkedIn via the InfoQ group
- Commenting on news posts
Chief Editor, InfoQ.com
Developers vs Operations
The popular belief seem to be that Operations' only task is to block each and every update of each and every possible piece of technology. This is turn 'requires' developers to trick Operations in various ways and install their updates anyway, for instance by hiding them inside application updates. A similar thing is true for the popularity of web services among developers. It's not that these are inherently better or easier to work with than other communication stacks, but they allow to penetrate the firewall transparently that Operations has spent so much time on to block each and every port.
Operations Community, yeah!
For starters, one particular area where I've spent a lot of thought and our organization has spent a lot of energy is in support tickets and trouble tickets.
Consider me an interested writer.
Flux Job Scheduler
Re: Operations Community, yeah!
Fantastic, that's great to hear! Can you please send me an email at firstname.lastname@example.org so that we can chat further about becoming an InfoQ newswriter?
Chief Editor, InfoQ.com
Ops vs Developers
My experience in the past has been that at least in some scenarios, Developers and Operations are either not really allowed to talk to each other - developers are not allowed to know actual IP addresses of the production machines because it may be a security risk, so they virtually develop the software, burn it on CD and slip it below the door to operations.
So I think one of the goals of this community should be to get the two parties together to get a better mutual understanding on what developers need to know about actual production infrastructure. And on the other hand to give operations the knowledge to request better support for their tooling (monitoring hooks within applications).
This may even go a step further to include biz people, so that operation support systems may deliver biz data - after the biz app has been instrumented by developers.