You just started working for an organization and your manager has asked you to implement the DevOps approach with all the relevant tools. But what is DevOps?
The main advantages of DevOps are:
speeding up deployment of applications.
reducing time to market.
But what is it, really? And why is it so important to reduce this so-called “time to market”?
In this chapter, you'll discover the history of DevOps, why it's often associated with agility in an organization, and why it’s considered by some to be the holy grail of deployment. We’ll also present several examples to demonstrate how organizations that implemented DevOps in their daily processes have benefited from it.
Where Did DevOps Come From?
At that time, IT application Dev and Ops were in separate “silos” within most organizations, with each team taking responsibility for their own tasks. This created what’s known as the wall of confusion. This wall appears due to the two separate teams' conflicting objectives.
The Development team’s main objective is to develop the application by adding new features or fixing bugs as quickly as possible and at low cost, which can sometimes affect quality when done under pressure due to project constraints.
The Ops team’s objective is to ensure that the application is operating correctly, while guaranteeing application stability and quality—which often means sacrificing time and money when deploying a new version.
In addition, these objectives often have an effect on end-of-year bonuses for the different teams. Development teams are rewarded for the number of bug fixes and features delivered in each new version, while Ops teams are rewarded based on the number of critical production issues and the application's overall availability throughout the year.
These practices enable applications to be developed, tested, and deployed in a quicker and more reliable way.
There are many advantages to adopting DevOps:
increased trust between teams
accelerated delivery and deployment
faster ticket resolution
more effective management of unplanned tasks
Etsy’s DevOps transformation
Etsy is an online marketplace specializing in individual creations and vintage products, and it implemented the DevOps approach a few years after starting out.
Since its launch in 2005 it had been operating like a traditional organization, with developers and operations in separate teams. This resulted in:
employees working late.
overly complex deployments.
systems malfunctioning as it failed to cope with business growth.
To give you an idea, deployments would take around 4 hours and took place twice a week. In 2008, Etsy began to question this approach, comparing themselves to other companies such as Flickr who were already deploying up to ten times a day!
So, in 2009, they began to shift towards the DevOps methodology, breaking down the silos that prevented them from collaborating effectively and introducing continuous integration and deployment pipelines with lots of automation. These methods were implemented through small, gradual, but continuous changes.
The results speak for themselves. Etsy now deploys over 50 times a day, and, because each development is properly tested before being deployed, the changes are more robust. Consequently, this helped the company to grow.
The Impact of DevOps at Contoso
Another example comes from my own experience working at a large company. To preserve their anonymity, we’ll call them Contoso. At the time, I had the role of DevOps Coach, helping employees transition to the DevOps way of working. This meant helping them to:
speed up their deployments using continuous integration pipelines.
improve code quality.
set up measurement processes (system monitoring).
create environments on demand.
With my help, the team managed to deploy changes to their legacy system (i.e. a system over 10 years old) every 15 days, where previously this happened every 4 months. In addition, the process for requesting environments was made much more efficient using Infrastructure-as-Code tools, which we’ll look at in the next chapter.
Instead of waiting several weeks for a test environment to be made available, staff could create an environment in just a few minutes, deploy their code, run the testing, and check the results immediately.
Another consequence of implementing Infrastructure-as-Code is the option of multiplying environments while reducing associated costs. In fact, if you were paying for one dedicated environment for one month, it would be difficult to provide stable environments (ones that are available for testing) for many people. However, with Infrastructure-as-Code, you can create as many environments as you have tests to run, but only for the duration of the test. This represents a cost saving—despite the sheer number of environments involved!
Let's Recap!
So, now you understand where DevOps came from and its purpose. DevOps is essentially a reaction to the wall of confusion and a lack of understanding and communication between Dev and Ops teams. Because these teams have different objectives and practices, working together can be difficult.
In the next chapter, we’re going to break this methodology down and examine how it tackles the problem of the wall of confusion.
