Yes – Aperations, not apparitions as Google tried to correct me when I checked to see if the term had been used previously although this blog post may be a bit spooky to some (had to thrown in the seasonal tie – sorry). I’ve been mulling this concept for awhile and the thinking begins along the following line – we all know the story about applications getting more and more complex due to the growing number of interdependencies as well as the increasing degree of loose coupling and dynamic binding found in newer application architectures. Yet we persist with an organizational alignment that in my mind doesn’t act to counter these attributes, i.e., the familiar pattern of development (and application support), test (and staging) and then of course, operations.
Years ago when I covered application management and saw the rise of J2EE-based applications, I was initially surprised that my client inquiries for tools and best practices with regards to Java management were coming from development and application support teams. It was déjà vu all over again with SOA. Today, of course, we have REST, EDA (Event-driven Architecture), CoDA (Context Delivery Architecture) and other application paradigms that just seem to add fuel to the proverbial management challenge fire. And why were application developers calling and not traditional IT operations? Well, the latter weren’t sufficiently skilled in terms of support at the time, and this can still be true today – especially for these emerging application types.
So the thought is this … quit fighting natural selection. Developers (or application owners) know more about the application than others within IT so they should be the rightful management owners as well. I’m not talking about traditional level 3 style activity, but ALL management. I know the argument against this which is that an expensive resource like a developer should focus on their core competency and only be engaged with problems at the last possible moment, but I ask you the reader, how successful has this posture been? We throw applications over the wall to operations and somehow we hope that those less knowledgeable about the architecture will sometime in the future be able to management it effectively. This is not a criticism of IT operations capabilities because they are already extremely busy having to deal with substantial infrastructure change in the form of virtualization, cloud computing, etc.
And speaking of cloud computing, for some cloud and Internet services providers this wouldn’t seem so unusual as some already require heavy instrumentation of their applications and operate under the mantra of “you built it, you manage it (see On Designing and Deploying Internet-Scale Services).” They (as does Gartner) believe also that most operations-related issues have their origin in pre-production (note: the research paper by James Hamilton has many other valuable lessons in it that I’ll return to periodically). For me, the question isn’t so much should application development assume management ownership, but “how low should they go?” The recent acquisition of SpringSource by VMware I think will further blur the line between infrastructure and applications adding even more impetus to a re-evaluation of how we’re currently structured within IT. So, let the debate begin.
7 responses so far ↓
1 Lew Cirne // Oct 26, 2009 at 1:12 pm
Amen, Cameron!
I think you are totally dead on. If the team that built the application has to support it, it’s amazing how much care and thought goes into making that application successful in production. When management is “somebody else’s problem”, then manageability predictably becomes a lower priority – which hurts the business.
Early on at New Relic when I hired my VP Engineering, I decided to give him ownership and responsibility for production management and support, and it has resulted in a big win for us. Our app collects and writes 70 Billion rows of data a month (up from 40 Billion just 5 months ago). This kind of growth and scale must be managed with precision. As you can imagine we eat our own dogfood and use our app management tool to manage itself, but more importantly, we’ve structured the team organizationally so that development has responsibility for the success of the app in production. We are very happy with the results.
2 Cameron Haight // Oct 27, 2009 at 12:27 am
Many thanks for the feedback, Lew. It’s great to see this concept working in real life – not just in the minds of an analyst! Thanks again for taking the time to comment.
3 Javier Soltero // Oct 29, 2009 at 11:55 am
Completely agree, Cameron. Building manageable apps and having management tooling that can at least provide common context for ops and developers will definitely help.
One thing though, perhaps you should add another P and make it App-erations.
4 Cameron Haight // Oct 29, 2009 at 1:50 pm
Thanks Javier. I thought of App-erations as well … but initially elected to go with the single “p” since it mapped more closely to Op-erations. But point made – I may need to go back! Thanks …
5 George F. Black // Nov 3, 2009 at 3:45 pm
Cameron, your points are well taken. Lew, you make a great point on accountability.
I would counter, however, that application developers find operations to be drudgery, and I wonder if they could ever truly settle down into the humdrum 8 to 5 of daily operations (or 24×7x365). Perhaps there is a compromise that would look like this:
Application Management in full charge of implementation planning, execution, training and operation management for the first 12 months (or some time frame). This couples the accountability that Lew describes with the acknowledgement that sooner or later the work is going to become routine and bore the hell out of application developer types. Yes, and I mean even management types.
Could there be something here. Perhaps Aperations is the glue between development and operations?
6 Cameron Haight // Nov 6, 2009 at 4:00 pm
George – thanks for your post. I think what you suggest is in fact often the traditional approach (it certainly was in the Java world). Still, it didn’t solve the problem. The way you do less operational drudgery is by putting more thought into how the application will be managed during design and development. The better the documentation, instrumentation and run-books (automation) the less time application development (and operations) will spend dealing with production stage problems.
7 uberVU - social comments // Nov 20, 2009 at 4:00 pm
Social comments and analytics for this post…
This post was mentioned on Twitter by sweetlew: Awesome Gartner article on the future of managing apps. http://bit.ly/4MJm9…
Leave a Comment