DevOps for absolute beginners (2022 edition)

Ahmed Misbah - October 2022
DevOps for absolute beginners
2022 edition

This session is for software professionals
(as individuals) and not companies
and yes this is Uncle Bob :D

DevOps for absolute beginners (2022 edition)
Agenda
• About the speaker

• The Past

• The Present

• The Future

Agenda
➡ About the speaker

• The Past

• The Present

• The Future

About the speaker
Role and previous talks
• Chief Software Engineer and Architect

• Speaker at:

‣ Delta Technopreneurs

‣ DevOpsDays Cairo

‣ AMECSE

‣ Orange DevTest Days

‣ GDG

‣ JDC

About the speaker
Topics of interest
• DevOps

• Agile and Lean

• Cloud-Native Apps and beyond

• Software Architecture

• Java

• FOSS

• Arti
fi
cial Intelligence and ML

About the speaker
Experience
• 9 years at Orange Innovation Egypt

• Delivered two award winning innovative
solutions

• Worked at two startups

• Helped many others!

• Winner of Dell Hacktrick 2022 UI/UX track

• MSc. degree in ML and many other
professional certi
fi
cations
Nile University
J;.lll ~l:J.. Qtertifirate
(3/'~
This is to certify that
Ahmed Mahmoud Amir Misbah
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Has successfully completed the program of study
and fulfilled the requirements for
BigData & Data Science Diploma
for the period from October 2015 to July 2016
...f:.!.l...~'!!~~!.tf....El..#.!(!.~.1..
INF Program Director
~~.__QI II
C.a.::::a..;r:q;;; AU J M
IW fl ,
: ~t '-M4'
October 2016 ·
····························••-
•··············
Date

Agenda

➡ The Past

• The Present

• The Future

The Past
Timeline to DevOps
1970
Waterfall
Dr. Winston W. Royce Proceedings of IEEE WESCON, August 1970

The Past
Timeline to DevOps
Problems with waterfall:

• Silos and hando
ff
s

• Upfront everything

• Customer sees product too late
Speci
fi
cations Implementation Validation
Delivery
Customer after n months or years

The Past
Timeline to DevOps
1970
Waterfall
1975
Iterative and
Incremental
Development (IID)
IEEE Trans. Software Eng., Dec. 1975
V. Basili J. Turner

The Past
Timeline to DevOps
Challenges in IID:

• Mini waterfalls!

• Business and Developer collaboration

• Quality

• Feedback

The Past
Timeline to DevOps
1970
Waterfall
1975
Iterative and
Incremental
Development (IID)
2001
Agile Manifesto

The Past
Timeline to DevOps
Challenges in Agile SWD:

• Dev and Ops!

IBM (2022)
“Information technology operations - more commonly referred to
as IT operations, or ITOps - is the process of implementing,
managing, delivering and supporting IT services to meet the
business needs of internal and external users.”

Kate Brusk - TechTarget (2022)
“IT operations include administrative processes with support for
hardware and software. Important roles of the IT operations team
include tech management, quality assurance, infrastructure
management and confirmation that finished products meet all the
customer's needs and expectations.”

The Past
Timeline to DevOps
1970
Waterfall
1975
Iterative and
Incremental
Development (IID)
2001
Agile Manifesto
2008
Patrick Debois and
Andrew Shafer
meet
Patrick Debois
Andrew C. Shafer

The Past
Timeline to DevOps
1970
Waterfall
1975
Iterative and
Incremental
Development (IID)
2001
Agile Manifesto
2008
Patrick Debois and
Andrew Shafer
meet
2009
Dev and Ops coined

First #DevOpsDays
Velocity 09 - John Allspaw and Paul Hammond DevOpsDay in Belgium

The Past
Timeline to DevOps
1970
Waterfall
1975
Iterative and
Incremental
Development (IID)
2001
Agile Manifesto
2008
Patrick Debois and
Andrew Shafer
meet
2009
Dev and Ops coined

First #DevOpsDays
2010
“Continuous Delivery”
book published

Agenda

• The Past

➡ The Present

• The Future

Wikipedia (2017)
“DevOps is a culture, movement or practice that emphasizes the
collaboration and communication of both Software Developers and
other Information-Technology professionals while automating the
process of software delivery and infrastructure changes.”

Mindset
CALMS Model
• Culture: DevOps isn’t simply a process, or a di
ff
erent approach to
development, it’s a culture change. A major part of a DevOps culture is
collaboration and embracing failure.

• Automation: Automation helps eliminate repetitive manual work, yields
repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for
teams who don’t have them in place already. What better reason for business,
developers, testers, and operators to work together than building systems to
bene
fi
t everyone?

Mindset
CALMS Model
• Lean: DevOps is about maximizing customer value, minimizing/eliminating
waste, and continuous improvement.

• Measurement: It’s hard to prove your continuous improvement e
ff
orts
actually improve anything without data!

• Sharing: Breaking silos and embracing a culture of sharing information by
better communication, transparency and availability.

Mindset
Shift-left mindset
• Shift-left is the practice of moving
testing, quality, and performance
evaluation early in the software
development lifecycle.

• This concept has become increasingly
important as teams face pressure to
deliver software faster and more
frequently with higher quality.

• Shift-left speeds up development
e
ffi
ciency and reduces costs by
detecting and addressing software
defects earlier in the development
cycle before they get to production.

Practices
DevOps pipeline
• DevOps Pipeline represents all the stages and technical practices your code needs to
go through until it reaches production.

Practices
5Cs of DevOps
5Cs of DevOps are a set of practices in
software development that are of
repeatable nature and can be automated
to increase quality and productivity.

Practices
Continuous Integration (CI)
• In software engineering, Continuous Integration (CI) is
the practice of merging all developers' working copies
to a shared mainline several times a day.

• Grady Booch
fi
rst proposed the term CI in his 1991
method, although he did not advocate integrating
several times a day.

Practices
Continuous Integration (CI)
Extreme programming (XP) adopted the concept of CI and did advocate
integrating more than once per day – perhaps as many as tens of times per day

Practices
Continuous Delivery (CD)
• Continuous Delivery (CD) is a software engineering approach in which teams produce
software in short cycles, ensuring that the software can be reliably released at any
time.
• It aims at building, testing, and releasing software with greater speed and frequency.
The approach helps reduce the cost, time, and risk of delivering changes by allowing
for more incremental updates to applications in production.

• A straightforward and repeatable deployment process is important for continuous
delivery.

• CD contrasts with Continuous Deployment, a similar approach in which software is
also produced in short cycles but through automated deployments rather than manual
ones.

Practices
Continuous Deployment (CD)
• Continuous Deployment (CD) is a software engineering approach in which
software functionalities are delivered frequently through
automated deployments.

• CD contrasts with continuous delivery, a similar approach in which software
functionalities are also frequently delivered and deemed to be potentially
capable of being deployed but are actually not deployed.

Practices
CI/CD
• In software engineering, CI/CD is the combined practices of continuous
integration and either continuous delivery or continuous deployment

• CI/CD bridges the gaps between development and operation activities and
teams by enforcing automation in building, testing and deployment of
applications

• The CI/CD practice, or CI/CD pipeline, forms the backbone of modern-day
DevOps operations

Practices
Deployment Strategies
A Deployment Strategy is a way to change or upgrade an application. The aim is
to make the change without downtime in a way that the user barely notices the
improvements.

Practices
Feature Toggling
• Feature Toggles (aka. Feature Flags) are a powerful
technique, allowing teams to modify system behavior
without changing code.

• There are 4 types of feature toggles:

1. Release Toggles (trunk-based dev. with CD)

2. Experiment Toggles (multivariate or A/B testing)

3. Ops Toggles

4. Permissioning Toggles (e.g., premium vs. regular
customers)

Practices
Continuous Testing
The process of executing automated tests and comparing actual outcomes with
predicted outcomes.
Can now be automated

Practices
Continuous Monitoring
• Continuous monitoring in DevOps is the process of identifying threats to the
security and compliance rules of a software development cycle and
architecture.

• Continuous monitoring informs all relevant teams about the errors
encountered during the production period.

• Once detected, these
fl
aws are then looked into by the people concerned.

• DevOps tools for continuous monitoring include Prometheus, Datadog, and
Nagios.

Practices
Types of Continuous Monitoring:

• Technical:

‣ CPU, Memory, and Disk storage utilization

‣ Component availability

‣ Network tra
ffi
c

‣ Log aggregation (e.g., using ELK, Datadog, etc.)

‣ Application (e.g., using NewRelic, Crashlytics, etc.)

• Business:

‣ Aka. User behavior monitoring via # of visits, # of active users, # of clicks (e.g., using Google Analytics)

Practices
5Cs of DevOps
Continuous Integration
Continuous Delivery, Deployment and Testing

Practices
Metrics
• Mean Time To Production: How long does it take for any newly committed source
code to reach production?

• Deployment Frequency: How often are releases deployed into production?

• Average Lead Time: How long does it take for a new feature to be developed, built,
tested, and deployed into production?

• Deployment Speed: How much time does it take to deploy a new release into
production?

• Production Failure Rate: How often do failures occur in production?

• Mean Time To Recover (MTTR): How long does it take to recover from a failure?

Technologies
DevOps Toolchain
• DevOps Toolchain represents all the tools required to automate each stage and
technical practice your code needs to go through until it reaches production in the
DevOps Pipeline.

Technologies
DevOps Periodic Table

Technologies
Essential and Trending Technologies
• Containers

• Container Orchestration

• Cloud

• Microservices

• Service Mesh

• GitOps

• Serverless

• Infrastructure as Code (IaC)

• Infrastructure Testing and Chaos Engineering

Technologies
Containers
Containers are a form of operating system virtualization. A single container might be
used to run anything from a small microservice or software process to a larger
application. Inside a container are all the necessary executables, binary code, libraries,
and con
fi
guration
fi
les.

Technologies
Container Orchestration
Container orchestration is the automation of much of the operational e
ff
ort required to run containerized workloads
and services. This includes a wide range of things software teams need to manage a container’s lifecycle,
including:

• Provisioning

• Deployment

• Availability

• Scaling (up and down)

• Networking

• Load balancing

• Security

• Health monitoring

• and more

Technologies
Infrastructure as Code
Infrastructure as Code (IaC) is the process
of managing and provisioning
computer data centers through machine-
readable de
fi
nition
fi
les, rather than physical
hardware con
fi
guration or interactive
con
fi
guration tools.

Technologies
Infrastructure Testing and Chaos Engineering
• How do you make sure you have provisioned the right infrastructure?

• Does it meet de
fi
ned your service-level requirements?

• Don’t assume, test!

• Here are a few practices that can help you:

‣ Automated Infrastructure Tests: InSpec, RSpec, and Serverspec
are tools to develop automated compliance test suites.

‣ Chaos engineering: is the discipline of experimenting on a software
system in production in order to build con
fi
dence in the system's
capability to withstand turbulent and unexpected conditions.

‣Performance tests
‣Security/Penetration Testing

Technologies
Service Mesh
• A Service Mesh is a dedicated infrastructure
/ communication layer for facilitating
service-to-service communications
between services or microservices, using
a proxy (often as a sidecar).

• Having such a dedicated communication
layer can provide a number of bene
fi
ts,
such as:

‣ Providing observability into
communications,

‣ Providing secure connections,

‣ Tra
ffi
c management

Technologies
What about Web Development?
• Build: npm, Gulp, Grunt, etc. on any CI server.

• Test: Jasmine, Chai, Mocha, Jest, Nightwatch, Selenium, Robot
Framework, Katalon, Cypress, ESLint, headless browsers, etc.

• Release: Webpack.

• Deploy: Using any CD capable server.

Technologies
What about Mobile Development?
• Build: Gradle, Fastlane, MS App Center, etc.

• Test: Appium, Robot Framework, Katalon, jUnit, Robolectric, Mockito,
Espresso, Mobile cloud farms, Mac VMs on AWS, STF, etc.

• Release: MS App Center.

• Deploy: MS App Center, Google Play, App Store, etc.

Agenda

• The Past

• The Present

➡ The Future

The Future
Study Track for DevOps
Scan for my study track

The Future
Job Roles
• Old roles still count!

• Site Reliability Engineer (SRE)

• Platform Engineer

• Cloud Engineer

• DevOps Engineer
Old roles (Business, Dev and Test) New roles (SRE, etc.)

The Future
What’s next?
• BizDevOps (DevOps 2.0)

• DevSecOps

• NoOps

• MLOps

• Everything as Code

• Continuous Everything

• eBPF for Service Mesh

• No / low code platforms

Future of DevOps
BizDevOps
• BizDevOps (aka. DevOps 2.0) is an approach to software
development that encourages developers, operations sta
ff
and business teams to work together so the organization
can develop software more quickly, be more responsive to
user demand and ultimately maximize revenue.

• One of the technologies driving the BizDevOps movement
is real-time analytics.

• Using application performance monitoring tools (technical
perspective), as well as analytics tools (business
perspective), companies are now able to get data about
application performance and end-user behavior instantly
and quantify how well it supports the business’ KPIs.

Future of DevOps
DevSecOps
DevSecOps (short for development, security, and operations) is a development
practice that integrates security initiatives at every stage of the software
development lifecycle to deliver robust and secure applications.

Future of DevOps
NoOps
NoOps (no operations) is the concept
that an IT environment can become so
automated and abstracted from the
underlying infrastructure that there is
no need for a dedicated team to
manage software in-house.

Future of DevOps
MLOps
MLOps (a compound of “machine learning” and “operations”), is a practice for
collaboration and communication between data scientists and operations
professionals to help manage production ML (or deep learning) lifecycle.

Future of DevOps
eBPF
• eBPF is a revolutionary technology with origins in the Linux kernel that can run
sandboxed programs in an operating system kernel. It is used to safely and e
ffi
ciently
extend the capabilities of the kernel without requiring to change kernel source code or
load kernel modules.

• eBPF promises to solve a major pain point in service mesh — the lack of performance
when there are many
fi
nely grained microservices.

Book a free call to arrange a workshop
• DevOps Maturity Assessment workshop

• DevOps for Enterprises workshop

• Microservice Architecture workshop

• Serverless Architectures workshop

• CI/CD workshop

• Hands-on DevOps mentorship
Scan to book a free call

DevOps for absolute beginners (2022 edition)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie DevOps for absolute beginners (2022 edition)

Ähnlich wie DevOps for absolute beginners (2022 edition) (20)

Mehr von Ahmed Misbah

Mehr von Ahmed Misbah (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

DevOps for absolute beginners (2022 edition)