DevOps origins

The Devops origins – A revolutionary Road

DevOps is a set of practices that brings together Development (Dev) and IT Operations (Ops). It is essentially a culture that comes from the fusion of management principles, traditional software development, infrastructure management processes and tools that increase an organization’s ability to deliver applications and services at an intense pace.
Getting all IT departments to work together is a concept that may seem obvious, like isn’t it what they should do? But the reality is more complex for a very simple reason: traditionally, Devs and Ops each operate in silos and have diametrically opposed roles and objectives. DevOps was created to reconcile these two opposing camps. To fully understand it, we must deconstruct this tragedy in 3 acts, leading to the Dev/Ops rupture.

Systemic issues

To understand the very notion of DevOps, we need to travel back in time. Traditionally, IT departments were organized on a functional basis, organizing teams according to their areas of expertise – database administrators, network administrators, server administrators, developers, and so on. Each in different groups, and to add to the difficulty, each with diametrically opposed goals…

Devs

Developers focus on meeting business needs for new features and functionality and getting them into production as quickly as possible.

Ops

IT operations have the mission to provide customers with a stable, reliable and secure IT service, and therefore strive to avoid implementing changes that could jeopardize production.

And here comes the drama

Here begins the classic drama, a 3-act structure.

The Set-Up

The scene started in Ops, busy maintaining applications and infrastructure to ensure that the organization continues to deliver value to their customers. The grind is to deal with issues due to application complexity, technical debt and daily hacks. Of course, the pledge is made to fix the problem later, when the workload eases…

The confrontation

Obviously, the most vulnerable artifacts, being the most subject to heavy and ever-urgent modifications, are also the ones that generally support the most critical projects or the most revenue-producing systems. And therein lies the tragedy. A bug, a system down, delays, a security problem. And while the Ops teams are busy solving the problem, a Product Manager or a CEO or a Business Manager comes up with a brilliant idea for a new feature that will surely solve all the pre-existing problems (no matter how difficult or technically challenging). Once again, the Devs enter the scene and have to come up with a quick solution to create this new feature, meet the technical challenges and sometimes take shortcuts to meet the deadlines. And the cycle goes on…

Resolution

No happy ending here, the cycle ends up leading to extended delivery cycles, less reliable deployment results, failures, greater resistance from Ops to any change, internal and external feedback processing slows down… Finally the whole company loses its competitivity and the IT teams who feel stuck in a system that predisposes to failure in which they feel powerless and unrecognized Ask any system administrator what they think about the joys of Friday night deployment, which forces all teams to work all weekend.

The Follow Up – Calms down

Over the past decade, technological progress and digital transformation have impacted all businesses. Digital transformation is driven by customer, partner and supplier interactions, which are increasingly moving towards digital. Nowadays, « every company is a tech company » and applications and infrastructure have become key strategic differentiators for companies. This means that the stakes and pressure facing IT teams are huge.
And here comes DevOps! The idea appeared for the first time in 2008 from the meeting of Andrew Shafer (software developer) and Patrick Debois (sysadmin) at a session that became famous at the Toronto Agile conference: Birds of Feathers. Gone are the days of “siloed” development and operations teams, often merged into a single team where engineers work together on the life cycle (build – test – release). Over the years, frameworks have also appeared that bring together the basic principles of DevOps: CALMS, The Three Ways, Accelerate.

To Sum Up

DevOps is in itself a culture shift: small teams working on small chunks of work from beginning to end while focusing on shared goals, which always take priority over individual or group goals. Technically speaking, the DevOps model aims to normalize and standardize development environments, automating processes (testing and automation) and eventually providing a wide range of self-service functionalities. From a human perspective, DevOps allows for frequent and rapid feedback between operations and development, identifying operational issues earlier, thus allowing for more efficient work without wasting time. Most importantly, DevOps provides teams with psychological safety, enabling innovation. DevOps requires a shift from a hero culture to a learning culture, and a culture of collaboration and transparency. The results of DevOps adoption are indisputable. Organizations that practice DevOps deploy their code thirty times more often, the time it takes to go from “validated code” to “successful production release” is eight thousand times faster.
The highest performing organizations have timelines measured in minutes or hours, while the lowest performers have timelines measured in weeks, months, or even quarters. Not only do organizations get more work done, they get much better results: when top-performing organizations deploy changes and code, they are twice as likely to complete them successfully (i.e., without causing production downtime or service degradation), and when the change fails and results in an incident, the time to resolve the incident is twelve times faster.
The biggest companies have understood this, such as Facebook, Google or Netflix…