DevOps – My 20 cents


Before going in DevOps details – let’s think how business requirements are delivered these days. While many organizations have understood the importance of delivering features in multiple small sprints instead of doing them in one big monolithic waterfall block – practically every organization is practicing some version of “agile” methodology (XP, CanBan and so on). Which means teams get requirements in the form of user stories that traverse to production from Development team to Test team and Ops team in the end. Nothing wrong with this methodology really, it works ok sprint after sprint. But with the fast paced world we live in, what if the critical business requirements just pour in at a brisk pace which need to be deployed to production immediately. Probably the version of Agile we use might not scale.

We know and exercise “Continuous Integration” which means any piece of code that is being checked in has to be rock solid and is tested automatically every time. Now – organizations (especially the ones who use some sort of virtualized environments to deploy their services/apps) have gone a little ahead and have implemented what is known as “Continuous Delivery”. This means every check-in is not only run against the tests suite on build server, but gets deployed to staging and production as well. Many organizations, do multiple deployments to production on any particular day. This becomes possible when everything your team is doing is very well automated, planned scripted and all your engineering departments collaborate with each other.

E.g. Facebook does multiple deployments/day. The way they have implemented is any feature that Development team commits is tested rigorously against automated test cases locally and staging before getting exposed to the production. Obviously the feature is not enabled to the entire audience directly. Using traffic routing in load balancer partial traffic is routed to the new feature which yields performance numbers and user feedback. Once confident – the feature is made available globally to all users. This concept is known as testing in production which is the topic for my next post. This is obviously done using precise planning, scripting and automation.

What is DevOps?

DevOps – in my mind is the way continuous delivery/deployment is achieved by making Development and Operations/IT folks talk with each other, collaborate with each other and last but not the least trust each other. The way test engineers collaborate with Dev teams and start writing test cases from Day 1; with the amount of deployments that are happening to cloud these days, time has come to invite Ops team in the design reviews and get them working from Day 1.

The applications/services getting deployed to cloud differ from the traditional deployments in many ways. Logging/monitoring, SCOM packs or alerting, security, scalability and availability – are buzz words with cloud deployments. E.g. For logging and monitoring, Dev team cannot afford to say that it’s Ops headache and for me it’s a low priority task. Logging and monitoring has to be baked into the code from Day1.  Your services and apps need to be secure from Day1, because once your feature is checked in, it might be deployed to production straight away. DevOps practice – essentially tears the walls down between Dev and Ops teams. Both teams work collaboratively on planning, preparing environments, configuring security, writing the SCOM packs etc. To implement DevOps – everything including integration tests, BVTs, Smoke Tests, environments, configuration and deployments need to be scripted and automated.

Delivery methodologies that are used by organizations traditionally with classic setup of separate teams for Devs, Test and Ops did not have deep cross-teams integration. DevOps promotes a suite of common processes, methods and tools for communication and collaboration between teams. DevOps – really is a collaborative work relationship between development team and operations team.


Traditionally, Devs target set of goals like architecture/implementation, while Ops team worry about availability and stability. It is designed that way keeping separation of concerns in mind. With DevOps – both these teams do not have 2 separate goals. While Dev team need to care about the availability of the service in production, Ops team need to care about how security has been implemented. Like I said before, it’s about tearing the walls down, if not – at least making holes in walls, while marching towards a common set of goals. In fact, many organizations have started hiring developers with some sort of IT/Ops background. Looking at the Cloud computing burst, that day is not too far when there would not be two separate departments for engineering and IT.

To conclude, I am trying to define DevOps again! In my mind, it’s a relationship that increases the overall delivery efficiency and reduces the production risk associated with frequent releases.