The Fear of DevOps. For Dev, QA and Ops.

fear-shadowsDevOps suddenly seems to be a great buzzword that is gradually taking over organizational mindsets thinking of achieving agility in how IT gets delivered, consumed and again delivered based on consumption-based behavioral feedback. But then, there are consumers of DevOps who have different ideas of what means DevOps; to what extent people, process and technology needs to be re-organized to achieve a state of DevOps – and this is good enough to not only confuse themselves, but also keep the IT organization (or vendor) who talks to that consumer’s business organization (or in-house IT) enough confused on the expectations. Again, coming down to the people who comprise the IT team – typically, the developer [Dev], quality assurance [QA] and Operations [Ops] – they have enough evidence of being confused and afraid, even more; more so, as their traditional roles and responsibilities start getting broken up. So let us see what this fear is all about, and how such fear can be broken in this new scheme of things. And then enters the enterprise architects of either organization, who either tries to drive the show or try his/her best to implement DevOps into how IT is to be done. This causes more confusion when the architect tries to get these seemingly heterogeneous roles work as one-IT team.

I am a developer. I am so afraid of moving away from deep coding (thereby, forgetting my language), and scripts are now perceived as code! Moreover, why should I participate in testing after all?
Till now, what meant development was all about functional coding – so knowledge in typical languages such as java, VB.NET, C++, C#, Scala, etc. were of essence. Enter DevOps. While the depth of your functional coding knowledge still has room to grow deep, you start getting (and hence, appreciating) the spread of IT when you indulge in coding for the entire IT space – more specifically, test coding and infrastructure coding in addition. Hence, the expectation is to move up the value chain where you see entire IT as code. Two things – (a) While scripts may also be perceived as code, it is a path towards higher complexities where the barrier between scripts and code become blurred, (b) While functional code development is already getting automated, though this is in nascent stage as of industry adoption today, a state of NoDev is poised to be realized in future whereby, the typical developer will have either of two options – cease to be a developer and lose the job, or grow up in the value chain with respect to realizing IT as code.

I am a tester. I am so afraid that DevOps in automating everything and I don’t have my cubicle to peacefully sit and test! My nice excel sheets with repeatable test frameworks are now taken over by the machine.
That is the very nature of DevOps – to break the walls between Dev and Ops. And what happens when this comes in? Traditional QA becomes redundant and gets embedded as part of the entire automation. So, manual testing goes away (at least partially to start with) and testing becomes the job of the machine; whenever code gets pushed on to the test environment, it gets automatically tested for quick and real-time feedback to Dev team on what didn’t work. So what does a tester do now? The tester again has two options – cease to be a typical tester and lose the job, or grow up in the value chain whereby the QA guy (that’s you!) is perceived as someone who creates the overarching automation test framework (read, test code) that will drive functional and non-functional development. For functional, collaboration with developers would definitely be needed; and for non-functional, collaboration needs to be done with the operations guys.

I am the Ops – infrastructure guy. Till now I was having so much knowledge on how to configure servers, workstations and environments. And suddenly there are new tools I have to learn which will eventually eat up my job!
The most important essence of DevOps is to bring in Ops automation; and more so, starting with infrastructure automation. Hence, what does the infrastructure guy do? Surprise, surprise – It is indeed creating the code that automates infrastructure and environment provisioning! And yes, this is niche when it comes down to actual DevOps implementation today given that while everyone seems to be doing Agile based Dev (and functional QA), Agile based Ops [Infra] is something that customers look forward to from a capability perspective. So tools such as Puppet, Vagrant, etc. suddenly become so important. And that makes you to move up the value chain whereby you sit on a single machine, either in office or at a beach in Florida, and keep provisioning any piece of IT infrastructure across the world on-demand – options include virtual machines, cloud, or even bare metal ! Also note that the world is going towards a NoOps state whereby you create this automation, sit back and enjoy monitoring whatever you have created – being the God of infra things!
Further, for the infrastructure guy, two greater things spin off – (a) release & deployment automation, and (b) continuous monitoring. So what are these? (Oops, you have to again learn something new; hope you are not afraid?)
(a) Release & deployment automation is whatever it takes to eliminate the Ops nightmare whenever a developer pushes code for release to any environment, and even to production (which is then called deployment or deployment-ready). And this is basically done again through … yes, you guessed it right – automation!
(b) Continuous monitoring – Given that DevOps is all about making entire IT seamless and agile, both in pre-production and in production, it entails monitoring of applications, data and infrastructure (including networks) on a continuous basis to detect any disaster, provide real-time feedback for action to the Ops team at large (including yourself) and provision feedback-based automated self healing mechanisms. Ooooh, too much to digest!

I am the Ops – Service Management guy. What will I do if tickets get resolved automatically?
Again, given that DevOps spans across the entire IT cycle, it would definitely mean that the world is slowly moving towards self healing systems. So a move higher up in this value chain would be to know how to create the service management automation framework where a ticket from tools such as ServiceNow or BMC Remedy may get auto approved based on a rule engine, resolved subject to a certain level of maturity with little or no manual intervention, and scripts automatically run to get everything up to the desired state in production that neutralizes the time taken to handle the disaster.

And a few more fears, rather myths, that needs to be demystified

1. DevOps will not work or is so irrelevant with our scheme of things – we do not need agility in driving our IT
Then think – what is the harm of being ready for the future, just in case business starts demanding agility in delivering IT; in case there is a end customer behavior suddenly getting too dynamic? Or, the country undergoing an economic turmoil and regulatory changes suddenly pace up? Or say, a new business model gets spun off to create new business opportunities needing agility for the very systems which woke up once in year? Or better still, the business undergoes a hostile takeover or a merger, and thus two large disparate IT landscapes found a need to talk to each other?

2. There is no point in doing DevOps because the customer’s non-IT business supply chain is too slow
Firstly, DevOps in not a concept purely for IT to adopt. It is more of a philosophy, and then a practice, that can be easily adopted across industries. Read the book ‘The Phoenix Project’ by Gene Kim, available on Books 24×7, to appreciate how manufacturing has parallels in DevOps – and also note that companies such as GE have increasingly adopted it across their non-IT processes. Also, just think of the agile readiness again – what happens when suddenly one day you have a non-IT vendor pushing changes to their supply chain systems every other day, having adopted DevOps?

3. I am quite comfortable in pursuing work with (and keep learning) the rich proven technology which is also niche in the market. So no need to get myself fitted on to this new world of DevOps.
Note that DevOps is not new, and is gradually becoming mainstream (Gartner says this, not me … just in case). And also, DevOps is evolving; some already say that DevOps is dead, giving way to stuff like NoDev and NoOps, and adopting AI to do IT. So if you still garner the fear in you, better think of (a) getting voluntary retirement after a few years, (b) open a grocery store, or (c) get into academics to teach ‘how to: belly dance in 3 days’.

….. Oh yes; in case you are still right, expect me knocking on your doors after a few years for a job back to good ol’ IT 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s