DevOps and SRE

DevOps: An Overview

Samir Tata, PhD

samir@horizon-university.tn
DevOps
Introduction
 Dev and Ops - Problems

Dev Ops

The Drivers Business Needs Non-Functional Requirements

Inclined to Change? Yes No

Quick Changes Mean … New Features Additional Risks

Frequency of Change As Often as Possible Never if Possible

 Dev and Ops - Problems
In the traditional Delivery model, teams have conflicting priorities and mindsets, resulting in a lot of friction and increased lead time.
 DevOps
DevOps is a set of practices, tools, and a cultural philosophy that automate and
integrate the processes between software development and IT Ops teams.
 Why DevOps ?
Reducing the time to market without impacting the quality or the value of the software application that is being delivered.
DevOps
Values and Principles
 DevOps - Values
• Culture
• Substantial communication improvement can result when there is a mutual
understanding of others and their goals and responsibilities
• Automation
• Automation can save time, effort, and money, just like culture, it truly
focuses on people and processes and not just tools
• Measurement
• Measure key metrics across the organization
• Sharing
• Spreading knowledge helps to tighten feedback loops and enables the
organization to continuously improve.
 DevOps - Principales
• The principles of flow

• The principles of feedback

• The principles of continuous improvement

 DevOps - The principles of flow
• The principles of flow
The principles of flow are about having the work flowing from left to right on the value stream, in the
fastest way possible, from the conception of the feature to the deployment in production.

• Actions
• Small Batches
• Limit WIP (Work in Progress)
• Give focus and
• Not fall into the multitasking and prioritization traps
• Give Visibility
 DevOps - The principles of flow
• The principles of flow :
• Small Batches + Limit WIP + Visibility
• Small Batches
• Differences between the two process flows for Folding — Inserting — Sealing —
Stamping 5 brochures.
 DevOps - The principles of flow
• The principles of flow
• Small Batches + Limit WIP + Visibility
• Limit WIP (Work in Progress)
• Give focus and
• Not fall into the multitasking and prioritization traps
• Give Visibility
 DevOps - The principles of feedback
• The principles of feedback
• key to the opportunity to quickly identify and address problems while they
are small and easier to fix, preventing it from too late discovery when fixing
can be costly and take a longer time.
• Actions
• Test frequently, identify problems and fix them
• Learn from previous mistakes
• Control close to the source : peer review instead of manager approval
• Blameless
DevOps - The principles of continuous improvement
• The principles of continuous improvement
• Feedback to improve the process and implement changes
• Actions
• Enable safety
• Generalize improvement : share learnings to replicate success
• Change the organizational culture if it does not embrace change
• Pathological : People hold information for political reasons and often distort it to make
them look better. Problems are hidden.
• Bureaucratic: Driven by lot of processes and controls, highly siloed with low flow of
information between departments. Failures are punished for not following processes.
• Generative: People seek and share information with a common goal for the
organization to achieve its goals.
DevOps - People / Process / Tools
DevOps - People over Process over Tools
Not
the
oth
er w
ay a
rou
nd!

- Communicate the “why” - Document how people - Automate your process

- Assign ownership work
- Ensure people are - Who will do what
trained on processes and when, etc.
tools
 DevOps
DevOps Lifecycle and Tools
DevOps Lifecycle
 The DevOps
Lifecycle and
Tools

DevOps teams should adopt agile practices to

improve speed and quality. Agile is an iterative
approach to project management and software
development that helps teams break work into
smaller pieces to deliver incremental value.
The DevOps
Lifecycle and
Tools

Code involves software design and the creation of

software code. Sample tools include GitHub, GitLab,
Bitbucket, or Stash.
 The DevOps
Lifecycle and
Tools

Build involves the management of software builds and

versions, and use of automated tools to help compile and
package code for future release to production. Sample
tools include Docker, Ansible, Puppet, Chef, Gradle, Maven,
or JFrog Artifactory.
The DevOps
Lifecycle and
Tools

This phase involves continuous testing (manual or

automated) to ensure optimal code quality. Sample
tools include JUnit, Codeception, TestNG, or
BlazeMeter.
 The DevOps
Lifecycle and
Tools

CI/CD allows teams to release quality products

frequently and predictably, from source code
repository to production with automated workflows.
Teams can merge code changes frequently, deploy
feature flags, and incorporate end-to-end testing.
The DevOps
Lifecycle and
Tools

This phase can include tools that help manage,

coordinate, schedule, and automate product releases
into production. Sample tools include Puppet, Chef,
Ansible, Jenkins, Kubernetes, OpenShift, OpenStack,
Docker, or Jira.
 The DevOps
Lifecycle and
Tools

Manage the end-to-end delivery of IT services to

customers. This includes the practices involved in
reconfiguration (scale up and down), maintenance,
fleet refresh of all IT infrastructure that supports an
organization’s services.
The DevOps
Lifecycle and
Tools

Monitor and Alert

Quickly identify and resolve issues that impact product
uptime, speed, and functionality. Automatically notify
your team of changes, high-risk actions, or failures, so
you can keep services on.
The DevOps
Lifecycle and
Tools

Continuous feedback
DevOps teams should evaluate each release and
generate reports to improve future releases. By
gathering continuous feedback, teams can improve
their processes and incorporate customer feedback to
improve the next release.
Continuous Everything
Continuous Integration
• Continuous integration aligns with the Code and Build phases
• The practice of regularly
• Merging a developer’s code into the centralised codebase
• Integrating developer’s changes back into the shared codebase
• Conducting automated testing to ensure that no regressions have been
introduced.
 Continuous Delivery
• Continuous Delivery is an extension of Continuous Integration which
automates the process of delivery a new build into environments.
• Goal
• Perform automated testing on each new build to verify builds that are ready for
release into production, and fail those which are not.
• Manage the automatic provisioning and configuration of deployment
environments, as well as testing of these environments for stability, performance
and security compliance.
• Deploy a new release into production when approved and manually triggered by
the organisation.
• Continuous Delivery allows organisations to manually trigger the release of
new builds as regularly as they choose.
Continuous Deployment
• In a Continuous Deployment model, each build which passes all of
the checks and balances of the pipeline are automatically deployed
into production.
Continuous Feedback
• The whole point of DevOps is to release new features and fixes as
quickly as possible so that the organisation can get feedback from
customers, stakeholders and analytics as quickly as possible to make
better decisions when designing the next set of changes. The whole
point is to achieve a strong Continuous Feedback loop to develop a
better product.
• Continuous Feedback ties the ends of the loop together, feeding
back data and analytics from the Operate and Monitor phases back
into the Plan phase to do it all over again.
DevOps
DevOps in Public Clouds
DevOps Tools at Azure
DevOps Tools at AWS
DevOps Tools at GCP
DevOps
Dev in DevOps
Agile Methods on Dev Teamv Opp
alu osi
es te t
an o D
d p ev
rin Op
cip s
les
 Op
va pos
lue ite
s a to
Agile Methods on Dev Team nd De
pri vO
nc ps
ipl
Business Dev QA and Ops es

Water Scrum Fall

Jez Humble, https://youtu.be/L1w2_AY82WY
Dave West, http://sdtimes.com/analyst-watch-water-scrum-fall-is-the-reality-of-agile/
Agile Dev With DevOps : People, Processes and Tools
• People
• Heavy collaboration between all stakeholders (including Ops)
• Constantly available open communication channels:
• Dev and Ops together in all project decision meeting
• Virtually or physical but sharing common collaboration environment
• Chat/e-mail/Wiki services available to all team members

• Processes :
• Establish a process to enable people to succeed using the tools to develop and
operate software
• Faster deployment , frequent quality release

• Tools
• Automated environment creation and provisioning
• Automated infrastructure testing
• Parity between Development, QA, Staging,
• and Production environments
 Achieve Agile Principles with DevOps Techniques
Agile Principle DevOps Technique
1. Highest priority is satisfy the customer through early and
Continuous Delivery & Deployment
continuous delivery of software
2. Welcome changing requirements, even late in
Continuous Integration &Feedback
development
3. Deliver working software frequently, from a couple of
Continuous Integration, Deployment & Feedback
weeks to a couple of months
4. Business people and developers must work together daily
Integrated Development Environment
throughout the project
5. Build projects around motivated individuals. Provide
Infrastructure as a Code
environment and support they need
6. The most efficient and effective method of conveying
information to and within a development team is Communication and collaboration
face-to-face conversation
 Achieve Agile Principles with DevOps Techniques
Agile Principle DevOps Technique
7. Working software is the primary measure of progress Continuous Integration & Deployment

8. Agile processes promote sustainable development. The

Sponsors, developers and users should be able to Continuous Integration, Delivery, Deployment & Feedback
maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good
Collaboration and Continuous Integration
design enhances agility
10. Simplicity—the art of maximizing the amount of work not Integrated Automated Development Environment
done—is essential Continuous integration
11. The best architectures, requirements, and designs emerge
Communication, collaboration and sharing
from self-organizing teams
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior Monitoring and measurement
accordingly.
Agile Dev vs. DevOps

Without DevOps With DevOps

DevOps
Ops in DevOps
 Organisational Model of Software
Development (COBIT)
● Delivery (Dev) will be responsible for building features
● Operations (IT Ops) will be responsible for running applications

Delivery will have multiple development teams. ● Database, Network, and Server teams to administer resources,
● Service Transition team to check operational readiness prior to launch,
● one or more Production Support teams to respond to live incidents.
Organisational Models of Software Development in DevOps
• You Build It Ops Run It → Opposite to DevOps values and principles
• You Build It You Run It
• You Build It Ops Sometimes Run It
• You Build It SRE Run It
 You Build It Ops Runs It Op
va pos
lue ite
s a to
nd De
pri vO
nc ps
ipl
es

Operations teams will be responsible for all Run activities, including deployments and production support for all applications
 Op
po
sit
e
an to D
You Build It Ops Runs It d p ev
rin Op
cip s v
les alu
You Build It Ops Run It usually involves multi-level production support e s
- The Service Desk will receive customer requests,

- Operations Bridge will monitor dashboards and

receive alerts.

- Both L1 teams will be trained to resolve simple

technology issues, and to escalate more
complicated tickets to L2.

- Application Operations will respond to incidents

that require technology specialisation, and when
necessary will escalate to an L3 Delivery team to
contribute their expertise to an incident.
 You Build It You Run It

Delivery team will be responsible for its Run activities, including deployments and production support.
 You Build It You Runs It
You Build It You Run It consists of single-level swarming support, with developers on-call

- Service Desk is an L1 team that receives customer

requests and will resolve simple technology issues
wherever possible. Service Desk should escalate
tickets for particular website pages or user journeys
into the incident management system, which would be
linked to applications.

- A development team in Delivery is also L1, and they

will monitor dashboards, receive alerts, and respond to
incidents.
 You Build It Ops Sometimes Runs It
You Build It Ops Sometimes Run It refers to a mix of You Build It You Run It and You Build It Ops Run It.
- A minority of applications are supported by
Delivery teams, whereas the majority are
supported by a Monitoring team in Operations.
This can be accomplished by splitting
applications into higher and lower availability
targets.

- Higher availability applications are supported by

their L1 Delivery/Dev teams.

- Lower availability applications are supported by

the L1 Monitoring/Ops team

- When necessary, the Monitoring team will

escalate to L2 Delivery team members on best
endeavours.
 You Build It SRE Run It
• SRE is a software engineering approach to IT operations.
• Will be developed later in this course

• An SRE on-call team has strict entry and exit criteria for services. The process is:
• A development team does You Build It You Run It by default.
• If user traffic becomes substantial, the development team requests SRE on-call assistance.
Their service must pass a readiness review.
• If the review is successful, the development team shares the on-call rotation with SREs.
• If user traffic becomes critical, the development team hands over the on-call rotation to a
team of SREs.
 You Build It SRE Run It
• An SRE on-call team has strict entry and exit criteria for services. The process is:
• …
• The SRE team automates operational tasks to improve service availability, latency, and
performance. They monitor the service, and respond to any incidents.
• If the service is inside its error budget, the development team can launch new features
without involving the SRE team.
• If the service is outside its error budget, the development team cannot launch new
features until the SRE team is satisfied all errors are resolved.
• If the service is consistently outside its error budget, the SRE team hands the on-call rota
back to the development team. The service reverts to You Build It You Run It.
 You Build It SRE Runs It
You Build It SRE Run It involves multi-level production support

- Service Desk handles incoming customer requests.

They can link a ticket in the incident management
system to a specific web page or user journey, which
reassigns the ticket to the correct on-call team.

- Delivery teams doing You Build It You Run It are L1

on-call for their own services.

- The SRE on-call team is L1 on-call for critical services,

and when necessary they can escalate issues to the
L2 Delivery teams building those services.
DevOps
DevOps and Beyond
 DevSecOps
Practice of integrating security into DevOps Pipeline
BizDevOps
NetDevOps
EXPAND YOUR HORIZON

WWW.HORIZON-TECH.TN
HORIZON SCHOOL OF DIGITAL TECHNOLOGIES