The world of technology and development moves at a tremendously fast speed. The computer industry in its different applied areas has not been consolidated for more than 50 years, almost two generations. The world has evolved thanks to technology. It has gradually permeated society so much that it’s hard to think about how we could have lived without it many years ago. The simple fact that you are reading this post in front of your screen is a reflection of this. Thanks, Internet!

Having a personal computer or cell phone is a reflection of that. Do you remember your first computer? Do you remember your first cell phone? How was it? Do you remember how long ago you had it? In most cases, it hasn’t been more than 15 years from our first computer or cell phone to the one we have now. If we compare these devices and how much they’ve improved in just 15 years, the difference in technology is abysmal.

I use this reference as context for what follows. There are companies today that have based all their success on the internet and cell phones. Companies like Uber, Amazon, Facebook, Google share the same competitive strengths.

As a key pillar, tech developments must meet certain characteristics so that these companies can remain in the market. The two that I consider the most important are:

• Speed: The time it takes to make a new functionality or innovation to your product, from the time you are developing it until it is available to end-users.
• Stability: Once you have released the new functionality or innovation, the reliability that users have to be able to use it without failures and its availability.

What would have happened if Uber had revolutionized transportation but the platform was unstable, would it have succeeded?

If we take into account these two characteristics today, the efficiency and reliability of a company can be measured in everything from the legal aspects to the adoption of its end-users.

Throughout software development history, a very high percentage of development projects (in fact, most of them) did not reach the finish line. Projects took years to come to light, and when they did, often the project requirements did not match up, and if they did, these were outdated. After two years of development, the conditions and requirements were no longer the same.

As a result of this, Agile software development methodologies were born. If that sounds exaggerated, what I mean is yes, it really was a spectacular paradigm shift of how to do things in software development.

In short, what came to change these methodologies was:

• Focus do, do, do! Versus spending time planning.
• Not having such a rigid framework for the requirements
• Assume that development priorities could change
• Short development periods (maximum 4 weeks) and many iterations
• The result of each iteration must be a stable and usable product for end-users
• Priorities and new functionalities should be based on the experience of the users when using the product, that is, the feedback and the next steps are always based on the experience of using the product you are creating and this is where the Minimum Viable Product or MVP is born

This new paradigm of doing things helped to provide competitiveness to companies that had a technological product as one of its core pillars. This is the question I asked myself… Did having a framework where the speed of development was faster, make companies consider basing their competitive edge on tech products or did basing their competitive edge on tech products create agile frameworks? In my opinion, it was both.

Based on this new framework, certain roles were enforced to fulfill certain tasks. On one hand, the developers (Devs) who are in charge of making the new functionalities and throwing all the code lines necessary to fulfill these objectives; many new tools, languages, ​​and frameworks were created to meet the new demand for software products. On the other hand, the role of QA was born, the one in charge of testing the functionalities that the Devs created; new tools, methodologies, and frameworks were also created for this new role. And last but not least, the role of operations (Ops), the ones in charge of managing all of the infrastructures in which to deploy software products, was specialized. This role is commonly known as SysAdmin, and like the other roles, it became specialized and created new tools to fulfill its role.

For a long time, these roles formed the structure of a development team; Devs, QA Testers, and SysAdmins. Each specialized in their work, without necessarily knowing the work of the others. In this structure, the flow for deploying a new functionality was:

1. Developers created or maintained software product functionality
2. The QA testers did the job of testing the new changes and giving a verdict
3. The SysAdmins were in charge of deploying the new functionality on their infrastructure.

This seems like a good flow, and it was, but speed and stability were compromised due to a phenomenon that occurred between these roles. Throw over the wall!

This phenomenon was named after the action of throwing something on the wall, forgetting and delegating responsibility to the person on the other side of it. That is, the Devs created the new functionality and threw and delegated the responsibility to the next role without having any communication of the requirements that their partners needed to be able to prove this. In many cases, they threw the responsibility of returning to the Dev, in other cases they threw this responsibility over to the next wall, to the SysAdmins, and the action could be repeated, throwing the responsibility from wall to wall, directly affecting the efficiency and agility.

These practices also affected the coordination that should exist between these teams. Pointing the finger was a common practice when something went wrong, and the endless review boards did not help to improve this. Ego, hostility, misunderstandings; all the necessary ingredients for the failure of any project and, not to mention, bad equipment. Software products were delayed at best and ended up being very expensive at worst.

This environment was ripe for a revolution. And it happened.

The term DevOps is born from taking part of two words:

• Dev = Developers
• Ops = Operations (Sysadmin)

Yes, that easy and practical. But what is DevOps?

Let’s answer this with another question: What is not DevOps?

DevOps is not:

• A career
• A degree or job
• A product
• The cloud
• A series of tools
• An industry standard

DevOps is:

• A culture
• A philosophy for working
• A series of good practices

There is no DevOps charge, rather there are people who practice DevOps. It is not a series of tools, rather DevOps creates tools. But the tools don’t carry out DevOps; DevOps creates the standards and not the other way around. DevOps makes use of the Cloud, but is not necessarily the Cloud. Make sense? Stay with me!

This movement was born in 2009 thanks to people who were aware of these problems and the burdens they caused. Patrick Debois and Andrew Shafer initiated this movement, a movement that grows more every year and specializes more. The growing number of DevOpsDays events held worldwide each year are proof.

But how did this movement help mitigate these practices?

If we put it in perspective, this problem occurred because the objectives of each role were opposites itself. While the goal of the Developers was speed, the goal of the Sysadmin was stability. While some wanted to make the largest possible number of features available to end-users, the others had to guarantee product availability and stability. Changes are the main cause of system errors, so here is the dilemma.

With DevOps, new ways arise to ensure the speed of creating new features and making them available to end-users, while still maintaining product stability. With practices such as TDD, continuous integration, continuous deployments, and monitoring among others, DevOps turned out to be the next step to improving the industry.

There’s no such thing as perfection. There are still errors but in reality, there are fewer and fewer, with a faster response time. There is more control over each release and this gives a competitive advantage to companies and products.