The term ‘DevOps’ has been widely misunderstood because the different teams within any really substantial development project understand the work of the other teams so poorly. There will be several teams, including business analysts, technical architects (maybe), UX specialists, designers, testers, and developers. No development specialists, however, have until recently had the production environment firmly in mind when designing and developing their applications. Unfortunately, this causes problems for the team tasked with supporting the live application, especially as development teams move towards a culture of releasing applications ever more frequently.

The DevOps grassroots movement grew up from groups of operations people meeting to discuss the challenges of providing 24×7 support for business applications, subject to stringent SLAs, when those business applications, on the whole, lacked those qualities that allowed for uninterrupted service to meet those SLAs in production. The goal was to find ways to encourage developers to “think production” earlier in their development efforts. It aimed to promote the ideas, tools and automation that will allow developers to release software often, while retaining environmental stability, and the sanity of the Ops staff. The aim, in short, was to prevent nasty surprises and subsequent conflict as the time of software release approached.

It makes a lot of sense for Dev and Ops to cooperate in streamlining the application deployment process, but I don’t think DevOps means that these two separate skills should be merged into a multi-skilled development role. It is an unrealistic idea. Instead, surely, the devs work on their deployment processes so that they can deliver early and often, to a “production-like” environment. The Ops are able to ‘work upstream’ and identify the coming changes that might cause issues way before they are due to hit production. They can then advise on whole range of issues that will derail the whole process if discovered at the eleventh hour. More important, they can contribute to solving the more ‘cultural’ issues such as instrumentation, the types of performance, resilience, and scalability testing that minimizes production risks, and support-documentation that will help them support the application effectively when it goes live.

The DevOps movement has not had an easy growth, as the warring tribes of corporate IT departments have used it as a weapon to diminish the work of the others (e.g. NoOps), and development movements such as Agile have tried to claim the infant movement as their own. It has, at times, been portrayed as little more than a “group hug”, aimed at nurturing better relations and communications between the development and operations teams, so that delivering business applications becomes more like a smooth, cooperative production line than a game of ‘pass the hot potato’.

Surely it is more than this? I’d love to hear from anyone about the technical solutions and better processes that DevOps has delivered for them.