DevOps for Humans

1. DevOps for Humans
Stefano Picozzi
spicozzi@redhat.com
https://StefanoPicozzi.blog

2. Agenda
2
DevOps at the Behaviour and Technology Intersection
1. Start with Why
2. Rediscover your Mojo
3. Go to the Dojo

3. Burrhus Frederic Skinner
Frederick Irving Herzberg
Millard Fuller
Daniel Pink
David Rock
Aristotle
Simon Sinek
Jim Whitehurst
Mike Meyers
Gene Kim
Ivar Jacobson
Paul Keating
Bruce Tuckman
…
Featuring

4. Start with Why

5. THE OPEN ORGANIZATION
JIM WHITEHURST, RED HAT CEO
CONVENTIONAL ORGANIZATION
“TOP DOWN”
OPEN ORGANIZATION
“BOTTOM UP”
WHAT
HOW
WHY
WHAT
HOW
WHY
SETTING DIRECTION
GETTING THINGS DONE
MOTIVATING AND INSPIRING
COMMAND AND
CONTROL
CENTRAL
PLANNING
TITLE AND
RANK
HIERARCHY
PROMOTION
AND PAY
CATALYZING
INCLUSIVE
DECISION-MAKING
MERITOCRAC
Y
LET THE
SPARKS FLY
PURPOSE
AND PASSION
ENGAGEMENT

6. Open unlocks the world’s potential
6

7. OPEN SOURCE IS MORE THAN CODE. IT’S CULTURE.
OPEN SOURCE
CULTURE
Engaged communities
more rapidly adapt change
Transparency forces
honesty and authenticity
Open standards
preserve business agility
Shared problems
are solved faster
Walk fast, walk alone. Walk far, walk together.

8. Risk averse
Managing upwards
Gold plated requirements
Long phases
Succeed slowly
Consulting deliverables
Detailed documentation
Command and control
Time bounded project
Compliance
Control
High-touch
Waterfall
Reward centric
Managing outwards
Practical experimentation
Short sprints
Fail fast
Collaborative learning
Working software
Self organizing teams
Long lived product
Adherence
Autonomy
Self-service
Agile
Mind Reset

9. It is easier to act yourself into a new
way of thinking, than it is to think
yourself into a new way of acting
- Millard Fuller

10. 1. Concerned with value delivery
2. Professional empathy formed
via shared sensibilities
3. Automation as actionable
intervention
DevOps – The Talent Dividend

11. The Hard Problems In Software Delivery
operatedeployreleasetestbuildcodeplanwhy
Adapted from: http://www.continuousautomation.com/wp-content/uploads/2014/08/solution-s-curve.png
Lean
DevOps
Continuous Delivery
Continuous Integration
Agile Development
Collaboration
Value
Existential Value Delivery

12. Rediscover your Mojo

13. Topics
PEOPLE
PROCESS TECHNOLOGY
DEVOPS
SEMAT
MATURITY
MODEL
SCARF
MOTIVATION
CONTAINERS
AUTOMATION

14. W W S D
Technology

15. Nudge. Make the desirable choice easier. Reward adherence.
The ABCs of DevOps
Teaming
Feedback
Experimentation
Standardization
Automation
Self-Service
Increased velocity
Improved quality
Reduced waste
A B C
Negative
Positive
Reinforcement

16. VIRTUAL MACHINES AND CONTAINERS
Container Host
Container
Application
OS dependencies
Dev
IT Ops
Infrastructure
Virtual Machine
Application
OS dependencies
Operating System
IT Ops
(and Dev, sort of)
Infrastructure
Clear ownership boundary
between Dev and IT Ops
drives DevOps adoption
and fosters agility
Optimized for stability
Optimized for agility

17. Automation Technology Landscape
Automation Centricity
Infrastructure Application
LowHigh
Infrastructure as code
Containers as code
Container primitives
Enterprise Management
Operational Convenience Opportunistic Productivity
Operational Efficiency Organizational Innovation
Where should infrastructure automation end and application automation begin?
Whatistherightlevelofabstraction?
Separation of Concerns
Projects
Namespaces
Registry, ImageStreams
Multitenancy plugin
SDN
Quotas
Roles
Playbooks ...
Self-Service for All
Source to Image
Templates
Storage Classes
Console, CLI, REST
Pipelines
A/B, Canary,
Software Catalog
Log aggregation ...

18. Herzberg's OpenShift
SERVICE CATALOG
LANGUAGE RUNTIMES,
MIDDLEWARE, DATABASES ..
SELF-SERVICE
APPLICATION LIFECYCLE MANAGEMENT
(CI / CD)
BUILD AUTOMATION
DEPLOYMENT
AUTOMATION
CONTAINER
NETWORKING SECURITYSTORAGE REGISTRY
LOGS &
METRICS
CONTAINER ORCHESTRATION & CLUSTER MANAGEMENT
(KUBERNETES)
RED HAT ENTERPRISE LINUX
CONTAINER RUNTIME & PACKAGING
(DOCKER)
ATOMIC HOST
INFRASTRUCTURE AUTOMATION & COCKPIT
CONTAINER
CONTAINER
Motivators
Hygiene
Factors

19. "Software is eating the world"
Marc Andreesen, August 20, 2011
Virtual machines are eating bare metal
Containers are eating virtual machines
Kubernetes is eating containers
Kubernetes (Istio) will eat microservices
Kubernetes (PSA-P) will eat AI/ML
Red Hat's OpenShift is eating Kubernetes 

20. People
Self Interest

21. Motivation 3.0
AUTONOMY
PURPOSE
MASTERY
The urge to get
better at something
that matters.
The desire to do
something that has
meaning and is
important.
To be self-directed.
Control increases
compliance but
autonomy increases
engagement.

22. We Are All on a Spectrum
10x
Programmer
Citizen
Developer
Opinionated frameworks
Not invented here
Vendor babble ☺
Fast > Right
80/20 Simplicity
Self service
Bureaucracy
Corporate IT
Steering Committees
Enterprise
Architect
Consistency
Evaluations
Governance
Snowflakes
Rogue Behaviour
Exceptions
1x
Programmer
Aging
Hipster
Roll your own
Autonomy
Edge cases

23. Motivation 3.0 for DevOps
AUTONOMY
PURPOSE
MASTERY
Self-service
Automation
Service catalogs
Immediacy
Frictionless
Choice
Roles based access
Enable, get out of the way
Accessibility
From Novice to Expert
Multiple form factors
Scale invariance
Tooling range
Training and enablement
Open Innovation Labs
Community engagement
Collaboration
CI/CD integration
Image provenance
Stateful applications
Security and scalability
Logging
Telemetry
Middleware …

24. The SCARF Model for Collaboration
Away Toward
Threat Reward
Status
Certainty
Autonomy
Relatedness
Fairness
Perception of control over
environment. A sense of
choice dramatically
reduces stress.
Deciding whether others are
‘in’ or ‘out’ of a social group.
Empathy response is more
active within the tribe or with
friends.
Brain is a pattern matching
machine. More resources
are expended processing
novel situations.
Significant determinant of
health and longevity.
Challenge to status can
generate strong threat
response.
Equitable outcomes.
Sense of unfairness
triggers strong threat
response.

25. SCARF on DevOps
Away Toward
Threat Reward
Status
Certainty
Autonomy
Relatedness
Fairness
Small, long-lived, cross-skilled team
Embed Developers into Operations
Embed Operators into Development
A success exemplar
Shared decision making
Skills transfer to new model
Relevancy via enablement
Equity in remuneration
KPIs and MBO alignment
Career growth outside management
Measurement time horizons
Executive sponsorship
Leadership authenticity
Reinforcement of behaviours
Role transition clarity

26. Process

27. Imagine if you could easily assess
the state of an organization’s
software development project?
27

28. Software Engineering
Method and Theory

29. TheKernel
SEMAT
SoftwareEngineeringMethodandTheory

32. Programs of work be
they sprints,
workshops, healthcheck
change state.
The current state is
assessed, target end
state agreed to, and
then appropriate
intervention is designed
and applied.
Events such as
Discovery Workshops
advance Reqs and
Software System.
Red Hat's Open
Innovation Lab program
advances Team, Way
of Working and more.

33. DevOps Maturity Model

34. DevOps Maturity Model
1 (Initial) 2 3 (Improved) 4 5 (Optimizing)
Culture &
Organization
Teams organised based on
platform/technology.
Defined and documented
processes.
Low cooperation or power-
oriented.
⬤
Agile Adoption
One backlog per team.
Adopt agile methodologies.
Remove team boundaries.
Share the pain.
Modest cooperation or rule-oriented.
Scaled Agile Approach (SAFe or other)
Extended team collaboration.
Remove boundary dev/ops.
Common process for all changes.
Cross-team continuous improvement.
Teams responsible all the way to
production.
Cross functional teams.
High cooperation or performance-
oriented.
Test &
Verification
Automated unit tests on every
build.
Separate test environment.
⬤
Some automatic integration tests.
Code analysis.
Test coverage analysis.
Automatic component tests.
Full automatic integration tests.
Behaviour-driven development.
Full automatic acceptance tests.
Manual exploratory testing.
Automatic performance tests.
Automatic security tests.
Verify expected business value.
Defects found and fixed immediately
(roll forward).
Information &
Reporting
Baseline process metrics.
Manual reporting.
⬤
Measure the process.
Static code analysis.
Automatic reporting.
Automatic generation of release notes.
Pipeline traceability.
Reporting history.
Report trend analysis.
Real time graphs on deployment
pipeline metrics.
Dynamic self-service of information.
Customizable dashboards.
Build & Deploy Centralized version control.
Automated scripts for building
software.
Nightly builds.
No management of artifacts.
Manual deployment.
⬤
Continuous Integration
Polling or triggered builds (commit hook).
Fail builds if they do not compile and
pass unit tests.
Any build can be re-created from source
control.
Management of build artifacts.
Builds are not left broken.
Deployment Pipelines
Fail builds if more general quality is not
met.
Automated provisioning of
environments.
Automated deployments.
Standardized environment templates.
Standard deployment process for all
environments.
Team prioritises keeping codebase
deployable over doing new work.
Orchestrated deployments.
Blue/green deployments.
Zero touch continuous deployments.
Data Management Data migrations unversioned
and performed manually.
⬤
Automated and versioned changes to
datastores.
Changes to datastores automatically
performed as part of the deployment
process.
Automatic datastore changes and
rollbacks tested with every deployment.
Release Infrequent and unreliable
releases.
⬤
Painful infrequent but reliable releases.
⬤
Infrequent but fully automated and
reliable releases in any environment.
Frequent fully automated releases.
Deployment disconnected from release.
No rollbacks, always roll forward.
Team is roughly at this stage
already and is not targeting this
area for next phase.
Team is targeting these
activities as critical for next
phase.
Team is targeting these
activities as potential work for
next phase.
Cells without status indicate stages the
team has not achieved fully and are not
being focused on for the next phase.

35. Go to the Dojo

36. OPEN INNOVATION LABS
OPEN SOURCING OUR DNA TO ACCELERATE APPLICATION DEVELOPMENT
MISSION
VISION
To accelerate the delivery of our customer’s innovative ideas, and create
infectious enthusiasm for building applications the Red Hat Way, by leveraging
community-powered innovation to deliver an outstanding labs experience.
To empower our customers to deliver the most innovative software
success stories of the 21st century.

37. 37
BUILD SOFTWARE THE RED HAT WAY
IN OPEN INNOVATION LABS
EXPERIMENT
Rapidly build prototypes,
do DevOps, and be agile.
IMMERSE YOUR TEAM
Work side-by-side with experts
in a residency-style engagement.
CATALYZE INNOVATION
Bring modern application
development back to your team.

38. OUR PROCESS
PRE-WORK "RESIDENCY" RETROSPECTIVE
Discovery session Agile, Lean, DevOps Backlog and roadmap
PUSH-BUTTON
INFRASTRUCTURE
DEMO DAY
CONTINUOUS LEARNING

39. Story
Slicing
Priority
Sliders
Screen
Flow
Event
Storming
DOMAIN-DRIVEN DESIGN
OUR METHODS

40. PUSH BUTTON CONTAINER DEPLOYMENT PIPELINE

41. 41
DISRUPTION
RAPIDLY CO-CREATE AN INNOVATIVE
OR DISRUPTIVE PRODUCT

42. 42
TRANSFORMATION
CREATE THE CATALYST TO CHANGE
THE CARGO SHIP’S COURSE

43. 43
THE ROAD TRIP
EXPERIENCE STATE-OF-THE-ART
APPLICATION DEVELOPMENT AND DEVOPS

44. CONFIDENTIAL - FOR INTERNAL USE ONLY
DISCOVERY SESSION
AGENDA
RESULTS
In a 1-day no cost session, the client and
Red Hatter work together to scope Labs
and make Red Hat sticky.
• Understand business priorities and IT landscape
• Identify future state objectives
• Define value hypothesis
• Define minimum viable product to build in Lab
• Well-documented consulting proposal + SOW
• Clear understanding of objectives
• Established credibility and thought leadership
INTERAT
E
ENABLE
44
CREATING THE SPACE
TO INNOVATE
“By creating a shared space for
testing and developing new open source
solutions, I hope that [the Innovation Lab]
will spur a culture of innovation within
state government and lead the nation
in using technology to bring the
government closer to the people.”
Lt. Gov. Gavin Newsom, 2016
RAYMOND YEE
School of Athens
https://www.flickr.com/search/?license=4%2C5%2C6%2C9%2C10&ad-
vanced=1&text=the%20school%20of%20athens
Original image: https://en.wikipedia.org/wiki/File:Sanzio_01.jpg

45. 45
TAKING A NEW APPROACH
TRADITIONAL I.T. VERSUS OPEN INNOVATION
TRADITIONAL OPEN INNOVATION LABS
Maybe
Probably not
Slow
Months to years
Very high
Team of teams
DANGER
Yes, infectiously
Definitely
Fast
1-3 months
None
Small team
Low
CULTURE OF INNOVATION
AGILITY
SPEED TO VALUE
DEV LIFE CYCLE
INFRASTRUCTURE COST
PEOPLE NEEDED
RISK

46. 46

47. Insights and Summary
Culture as an advantage is defensible. All
others are transient or can be neutralised.
Technology intervention as nudge
towards desirable behaviours. Behaviour
in the aggregate then forms patterns
observed as culture.
Start with small empowered team with
Executive blessing. Success becomes
exemplar that triggers viral enablement.

48. DO TRY THIS AT HOME
https://www.openshift.org/minishift/
https://www.openshift.com/promotions/for-developers.html
https://www.openshift.com/promotions/devops-with-openshift.html
https://www.openshift.com/promotions/kubernetes.html
https://www.openshift.com/promotions/docker-security.html
https://stefanopicozzi.blog/2016/06/21/openshift/

49. The Beginning
Stefano Picozzi
spicozzi@redhat.com
https://StefanoPicozzi.blog