Wednesday, January 9, 2013

DevOps - really a rebranding stunt?

Many  a times.. rather, mostly we adopt a principle where development happens in isolation from operations delivery.Which means team that builds an application is separate from the team which maintains them in getting that up-and-running.

Why is that!!

Might be we have separate concerns?

It might be a cultural difference as well - or the background that they come from. Whatever might be the reason it matters to business people because  they want their  product to be delivered as rapidly as possible. Hence it is thought that ,by fusing application development with operations into an integrated process run by a joined-up team, we can shorten  the delivery timescales to fit into the same, agile, 2-3-weeks sprint cycle in which development happens. YES! the ask is for one single team of Dev,QA & App Ops professional and motive behind is definitely praiseworthy.

I think collaboration is easier in startups but large organizations  needs it more..

Enough!!  NO superhero SA's - lets focus on 'one team'  = 'one goal !! Devops is not a job title - its just a culture, it's just a directional things and not yet a road-map..

Problem was and is always in the translation. Mangers to team members(Vision Vs Priority),   Parents to child (Safety Vs Freedom) , Mentor to disciple( Creativity Vs. stupidity)... and so on. Do we see a translation issue here in IT Apps vs Ops as well?   YES!!    DevOPS breaking traditional IT silos and speak their own language aligning to agile culture with a multidisciplinary skill set - as they  are (also)comfortable with infrastructure and configuration, but happy to roll up their sleeves, write tests, code, debug, and ship features.

In a way - Devops being professional -Fosters collaboration - increases trust - generates respect - STOP being an asshole..  (Yeah for 'them' we are 'assholes' - that's why I said separate tribes!!)

You  can NOT  change the culture - but can changes behaviors(and that becomes culture) - why we do it the way we do it.. most stories are on technology or tools -  Ah! comeon.. we need more on process levels rather... - Operations as a Service(I know SaaS, so can it be OaaS ?)

I reiterate and I stick onto it.. Operations is NO fun.  On top of it - we have separate concerns.. and furthermore I am being advised to treat  my tools as cattle's AND treat  peoples(customers)  as pets.
If you belong to operations domain you will understand that any process OR methodology that  do not have a "NO formal authority" is a joke! It is just this morning that I  had a discussion with one AppOPS engineer . He just need  'reboot' privilege. I had my Q clear - "why would you need to reboot you UNIX box so often". And there was actually NO answer. Come on dude.. I studied 5+ yrs of rigorous CSc and spent 10+ yrs matching those theorem to realities...  and I can sense this difference as I had the opportunity to spend my 60% of my career in the Application domain. 

O morons..Go n' set-up a remote PXE boot server/ Plan VLAN's in a DC, analyze the kernel dumps, analyze TCP/IP performance issues/ troubleshoot routes, write scripts(that "I" suggest), write iRules, and yet you advice to reduce just couple of clicks on your Ticket Portal even if it takes less than 60 secs.  

So - if your application team is planing for a separate  DevOps team to form you might have a bigger problem..

Because I 'know' I really don't worry about it too much. Not really being 'overconfident' - but it  is NOT being easy , if I really understand this chain and try to contribute here  (NOT necessarily with the flower power though..).

Just to wrap up - 'DevOps' is gaining momentum and yet it in it's infancy. BUT probably would need  horizontal minds to breaks the barriers.

And for those who are planing to hire 'devops' - please be aware that - there are already peoples in the current existence who has been already doing this kind of tasks every day.. and considering those engineers in Ops (App-Ops) I would really term it as a re-branding stunt which will be of-course evolving ('the branding!!')  all the more going forward..and who knows ..even this will be an obsolete post :-)


No comments:

Post a Comment

Why Database CI/CD?

Making the Database Part of Your Continuous Delivery Pipeline The database, unlike other software components and code or compiled co...