DevOps Foundations and Concepts

In this post, we will cover the foundations, concepts and practices that are essential for anyone who works in a DevOps environment.

We will cover the following:

• Culture – The culture of collaboration between Dev and Ops
• Practices – The practices which support the goals of DevOps culture
• Tools – The tools that help implement DevOps practices
• Cloud – The close relationship between DevOps and the cloud

What is DevOps

DevOps = Dev (Development) + Ops (Operations)

This definition from Wikipedia is a good starting point:

“DevOps is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops)… DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.”

DevOps Is

• DevOps is first a Culture of collaboration between developers and operations people
• This culture has given rise to a set of Practices
• DevOps is a way of working
• DevOps is a movement, by practitioners, for practitioners

DevOps Is Not

• DevOps is NOT a set of tools, but Tools are essential to success in DevOps
• DevOps is NOT a standard
• DevOps is NOT a product
• DevOps is NOT a job title

DevOps Culture

DevOps culture is about collaboration between Dev and Ops. Traditionally, the two worked separately and had different and opposing goals.

Under the DevOps culture, Dev and Ops work together and share the same goal. That is devs care about stability as well as speed, and ops care about speed as well as stability.

The traditional roles of developers and operational engineers become blurred under DevOps.

Instead of “throwing code over the wall,” dev and ops work together to create and use tools and processes that support both speed and stability.

With DevOps:

• Dev and Ops are playing on the same team

• Dev and Ops share the same goals

  • Fast time-to-market (TTM)
  • Few production failures
  • Immediate recovery from failures

Traditional Silos

What was wrong with the traditional silos?

Under the traditional silos:

• Devs write some code
• “Throw it over the wall” to QA
• Code bounces back and forth between Dev and QA as QA discovers problems and Devs fix them
• Finally, it is ready for production

• QA/Dev “throws the code over the wall” to Operations
• If there’s a problem, Ops throws it back over the wall to Dev
• Each group’s domain is a “black box” to the other groups
• Ops would say: “Our systems are fine; it’s your code!”
• Dev would say: “But the code works on my machine!”

This way of working leads to a lot of finger pointing - Ops being a black box, Devs don’t really trust them And Ops don’t really trust Devs.

Dev and Ops have different priorities - Ops views Devs as breaking stability and Devs see ops as an obstacle to delivering their code.

Even if they WANT to work together - Dev is measured by delivering features, which means deploying changes and Ops is measured by uptime, but changes are bad for stability.

Downsides of Traditional Silos

• “Black boxes” lead to finger pointing
• Lengthy process means slow time-to-market
• Lack of automation means things like builds and deployments are inconsistent
• It takes a long time to identify and fix problems

Merging Dev and Ops (DevOps)

How does DevOps fix traditional silos problems?

Under the DevOps model:

• Devs write code
• Code commit triggers automated build, integration, and tests
• QA can get their hands on it almost immediately
• Once it is ready, kick off an automated deployment to production

• Since everything is automated, it is much easier to deploy while keeping things stable
• Deployments can occur much more frequently, getting features into the hands of customers faster
• If latest deployment breaks something in production, automated monitoring notifies the team immediately
• The team does a rollback by deploying the previous working version, fixing the problem quickly
• An hour later, the dev team is able to deploy a fixed version of the new code

Dev and Ops worked together to to prioritize both speed of delivery and stability.

Automation led to consistency - Building, testing, and deploying happened the same way every time, much more quickly and more often

Good monitoring, plus the swift deployment process, ensured problems could be fixed even before users noticed them. Even though a code change caused a problem, users experienced little or no downtime.

Benefits of DevOps

• Tech teams tend to be happier doing DevOps than being under traditional silos
• More time innovating and less time putting out fires
• Devs and Ops both share the same goal which is speed of delivery and stable system.
• DevOps way of working gives customers the features they want quickly and reliably.