Software-as-Service as a disruptive trend and how it affects the traditional, ISVs and IT moving to the Cloud. Considerations in the transition to the new model and expertise on SaaS Service Operations - STORM™ and DevOps
Monday, January 27, 2014
Bring Ops back into DevOps
“Ownership is yet another of the endless forms of arrogance engaged in by the lower self.”
― Bryant McGill
Two items caught my attention in the past week.
One was an invitation for a DevOps event in Tel Aviv. Lots of flair, keynote speakers, demos, you name it. On the bottom, underlined, it was written “registration for developers only”.
What? Really?
A few days later I saw a recruitment ad for Director of Operations for an upcoming SaaS company, in Silicon Valley, no less. “… the Director of Operations will report to the VP of Engineering”.
I even read an article (don’t remember where – I should have bookmarked it) that DevOps is great since it returns control over production to Engineering, like in “the good old days”.
It felt like a trip in a time machine that landed me in the early 2000s.
Looking up DevOps in a Google search, it is all about configuration automation for Release Management, scripting languages as Ruby, courses for developers and such. No wonder Engineering feels so much at home.
When I took my first job as VP Service Operations in a SaaS company, I had to wrestle Production out of the hands of Engineering. I had to change the passwords to the production servers and wean the developers off the habit of changing the environment when they had a ‘safe and quick’ fix. They went home to their families in the evening. They were not on the 24x7 call list.
It took some time for the VP Engineering to come to terms with the new reality; imagine having to report to him while doing the job.
And yes, we used configuration automation scripts even back then, but they lacked the aura of ‘DevOps’. It was all about discipline, Change Management, Asset Management and careful planning, as covered in my previous post.
Chef, Puppet, Docker and the other mechanics are great tools, but they should enhance DevOps, not replace it. The first principle of DevOps is a culture of collaboration / cooperation / communication. Making the Ops team feel like an outsider is not going to help.
At the end of the day, Ops is left with task of keeping the light on, responding to outages 24x7, and taking the rap for service degradation.
So, just as SaaS is more about the Service than the Software, so is DevOps about the Operations more than Development.
Let the cowboys do what cowboys do best, and bring the ranchers back into the farm.
Subscribe to:
Posts (Atom)