The Changing face of 'Dev' & 'Ops'

I was about to give the heading “Changing face of Ops” to this article but on deeper introspection, I asked the question why should the Poor Ops guy be singled out? Everyone in the current Tech world is expected to acquire new skills, more so the Developer. With the constant onslaught of new technologies and buzz words whether it is IOT (Internet of Things), BigData, Hadoop, AWS (Amazon Web Services), Azure, Kubernetes, Blockchain, Spark, Scala, Python, Machine Learning, AI (Artificial Intelligence), Data Science, it is indeed a challenge to catch up ! Training Centers are mushrooming, both classroom and online, and trying to cash in on this new found opportunity. One look at their name boards and one can easily figure out the current industry and job market trends. 

The Developer or the Software Programmer used to be happy just writing his code in Java or whatever language he or she was familiar with. He didn’t have to worry about what happens next after his module is checked-in and committed to the repository; the QA Engineer was there to test the code and the Ops guy was there to release it to Production. Overnight many established companies felt they could act like a startup and do away with QA and in some cases Ops also and let the Developer own the Software Development Life Cycle end to end. The intention was good, to be Agile and to also follow the principle - “You wrote it, So You own it (this piece of shit)! ” But unfortunately in the mayhem, the poor developer had no clue of what it took to deploy the code to production or how to ensure it met the Reliability,Availability and Serviceability standards. He had very little idea of the Operations world - DNS, NFS, Active Directory, Kerberos, IPtables, Load balancers were all greek to him and so was implementing HA (High Availability) or DR(Disaster Recovery). On top of that, God forbid, if there are no teams in other geographical regions to support his application, he used to get woken up in the middle of the night to join incident and outage calls. Instead of focusing on writing good code, his time was spent on incident management and customer management and answering his organizational leaders on why the application failed or took time to recover. He now has to worry about MTTD (Mean time to Detect) and MTTR(Mean time to Restore) which was primarily an Ops responsibility earlier.

Coming to the Operations guy, He always had an identity crisis - He was called by various names ; In the good old days he was a System Admin, then he became a System Engineer, Production Engineer, Service Engineer, App Ops Engineer, Devops and finally following Google’s direction to the industry, a SRE Engineer. The work more or less remained the same - He was responsible for all the Infrastructure pieces - right from procurement to the installation of Operating System, setting up the network and storage to the deployment of Application software and custom code. He also in most cases would setup the CICD (Continuous Integration/Continuous Delivery) pipeline for automated release deployment to the various environments. He would also take care of setting up monitoring, alerting and logging and also ensuring production environment is secure. Scalability, Capacity management and Performance of the application in production would be his primary focus.He would also take care of all the mundane hygiene tasks what we call sometimes as RTB(Run the Business) like patching and upgrading systems and software, backups and maintaining storage space through regular cleanup of files. He would also spend some time in writing small scripts and automation tools to make his life easier and less monotonous.

Suddenly Clouds loomed large over the horizon and poured water down his skills ! In the Virtualized Cloud world, his scope of work reduced drastically. With few clicks of the mouse, a service or even an entire website can be set up in no time. With Amazon Web Service(AWS), Microsoft Azure and Google Cloud Platform (GCP) breathing down the neck, the Ops guy definitely needs to reinvent himself. However he is not alone and the fact is that even the developers and DBAs have started feeling the heat. What took many hundreds of man hour efforts in conceptualizing to materializing a service in the past have now shrunk to negligible resource and time requirements thereby enabling companies to react fast to competition and allowing them to redeploy their personnel to key areas of need.

In the Container world, with the breaking of monoliths into micro services, it is even more daunting. One can scale up and scale down a service in a jiffy. The need to invest in expensive hardware or software tools is no longer there and now companies can focus on their main asset, Data, developing algorithms using AI and ML to enhance their business model.

What is the way out then for both the Developer and Operations guy ? What should he or she do in this circumstance?

The answers can be manifold. They could 

Be Receptive

It is best to accept the fact that the Tech Industry is moving at a lightning pace and gear up oneself for this change.

Have a Learning Mindset

If one has an open mindset and is willing to learn and adapt, he or she can evolve and will stay relevant. While one cannot be a master of all trades, a little shift will help. 

Build Amicable Partnership

While the Operations guy should still front end the application in production, the Developer should be an able partner and a joint owner. It takes a team to make a dream !

Acquire New skills

 Now with the time available at his disposal because of advancements in Cloud technology, the Operations guy should help himself by acquiring software development skills. The Developer should also drop his ego and adopt native Cloud Services wherever possible to provide faster turnaround time.

Operationalize Engineering

 Seize the advantage of cloud by spending less and less time in Operations and more and more time in Operational Engineering. This could mean a whole gamut of things like building tools for measuring Performance of the application to building frameworks for disruptive testing to using AI for anomaly detection.

We are lucky to see this pace of technological advancements in our time , so my advice to all the Tech folks out there is to have a fun ride learning and enjoy the moment !