(without introducing more risk)
Rate of Change,
Microservices and Platforms
Puppet
Gareth Rushgrove
A tale of devops coevolution
Slide 2
Slide 2 text
(without introducing more risk)
Gareth Rushgrove
@garethr
Slide 3
Slide 3 text
(without introducing more risk)
Gareth Rushgrove
Slide 4
Slide 4 text
(without introducing more risk)
So you want to
go faster?
Some starting assumptions
Slide 5
Slide 5 text
(without introducing more risk)
What if I told you
It’s possible to go faster and to
reduce risk at the same time?
Gareth Rushgrove
Slide 6
Slide 6 text
(without introducing more risk)
You don’t need to be Google or
Amazon or Facebook
Gareth Rushgrove
Slide 7
Slide 7 text
(without introducing more risk)
What do I need to do?
Gareth Rushgrove
Slide 8
Slide 8 text
(without introducing more risk)
- Devops and microservices
- The effect of communication
overhead
- The influence of teams on
software adoption
Gareth Rushgrove
Slide 9
Slide 9 text
(without introducing more risk)
We should adopt
devops!
The rush for closer collaboration
Slide 10
Slide 10 text
(without introducing more risk)
30x
Gareth Rushgrove
More frequent
deployments
Faster lead times
than their peers
200x
2015 State of DevOps Report
Slide 11
Slide 11 text
(without introducing more risk)
60x
Gareth Rushgrove
Change
success rate
Faster mean
time to recover
168x
2015 State of DevOps Report
Slide 12
Slide 12 text
(without introducing more risk)
Gareth Rushgrove
Regular Releases Reduce Risk
Slide 13
Slide 13 text
(without introducing more risk)
Siloed teams
Long cycle times
Poor visibility
Manual processes
Gareth Rushgrove
Cross-functional teams
Short cycle times
Fast feedback
Automated processes
Slide 14
Slide 14 text
(without introducing more risk)
Gareth Rushgrove
Slide 15
Slide 15 text
(without introducing more risk)
Gareth Rushgrove
devopstopologies.com
Slide 16
Slide 16 text
(without introducing more risk)
Gareth Rushgrove
From http://web.devopstopologies.com/ by Matthew Skelton
Dev Ops
Slide 17
Slide 17 text
(without introducing more risk)
Gareth Rushgrove
Dev Ops
From http://web.devopstopologies.com/ by Matthew Skelton
Slide 18
Slide 18 text
(without introducing more risk)
Gareth Rushgrove
Dev Ops
From http://web.devopstopologies.com/ by Matthew Skelton
Slide 19
Slide 19 text
(without introducing more risk)
Gareth Rushgrove
Dev Devops Ops
From http://web.devopstopologies.com/ by Matthew Skelton
Slide 20
Slide 20 text
(without introducing more risk)
Bringing operational
considerations into development
Gareth Rushgrove
Slide 21
Slide 21 text
(without introducing more risk)
Building empowered, cross-
functional teams
Gareth Rushgrove
Slide 22
Slide 22 text
(without introducing more risk)
We should adopt
microservices!
The rush to smaller services (and teams)
Slide 23
Slide 23 text
(without introducing more risk)
Gareth Rushgrove
Slide 24
Slide 24 text
(without introducing more risk)
Gareth Rushgrove
Slide 25
Slide 25 text
(without introducing more risk)
There are two essential strategies to
manage [growing software]: a team can
keep everything together (create a
monolith) or a team can divide a project
into smaller pieces (create microservices).
Gareth Rushgrove
https://blog.heroku.com/archives/2015/1/20/why_microservices_matter
Slide 26
Slide 26 text
(without introducing more risk)
Microservices are as much
about people as technology
Gareth Rushgrove
Slide 27
Slide 27 text
(without introducing more risk)
Paraphrasing
There are two essential strategies to
manage a growing team: keep everyone
together or divide into smaller sub-teams
Gareth Rushgrove
Gareth paraphrasing https://blog.heroku.com/archives/2015/1/20/why_microservices_matter
Slide 28
Slide 28 text
(without introducing more risk)
Gareth Rushgrove
Software
Slide 29
Slide 29 text
(without introducing more risk)
Gareth Rushgrove
Monolith
Slide 30
Slide 30 text
(without introducing more risk)
Gareth Rushgrove
Microservice
Slide 31
Slide 31 text
(without introducing more risk)
Gareth Rushgrove
Microservice
Slide 32
Slide 32 text
(without introducing more risk)
The resulting need for a platform
Gareth Rushgrove
Slide 33
Slide 33 text
(without introducing more risk)
Using standards to drive the
adoption of platforms
Gareth Rushgrove
Slide 34
Slide 34 text
(without introducing more risk)
Gareth Rushgrove
12factor.net
Slide 35
Slide 35 text
(without introducing more risk)
Gareth Rushgrove
Codebase
Dependencies
Config
Backing services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Slide 36
Slide 36 text
(without introducing more risk)
Or using platforms to drive the
adoption of standards?
Gareth Rushgrove
Slide 37
Slide 37 text
(without introducing more risk)
Problems with microservices
- Significant operations overhead
- Substantial ops skills required
- Duplication of effort
- Distributed system complexity
Gareth Rushgrove
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
Slide 38
Slide 38 text
(without introducing more risk)
How to address the
operational challenges?
Gareth Rushgrove
Slide 39
Slide 39 text
(without introducing more risk)
We should adopt
devops!
Déjà vu all over again
Slide 40
Slide 40 text
(without introducing more risk)
We’ve adopted devops, we’re
going faster, deploying once a
week rather than once a quarter
Gareth Rushgrove
Slide 41
Slide 41 text
(without introducing more risk)
We’ve adopted microservices, we
have 10x more services now
Gareth Rushgrove
Slide 42
Slide 42 text
(without introducing more risk)
Does that mean 100x more
change approval meetings?
Gareth Rushgrove
Slide 43
Slide 43 text
(without introducing more risk)
Communication
overhead
Bring the research
Slide 44
Slide 44 text
(without introducing more risk)
Gareth Rushgrove
Slide 45
Slide 45 text
(without introducing more risk)
Conway’s Law
Any organization that designs a system
(defined more broadly here than just
information systems) will inevitably
produce a design whose structure is a
copy of the organization's
communication structure
Gareth Rushgrove
Slide 46
Slide 46 text
(without introducing more risk)
Gareth Rushgrove
Slide 47
Slide 47 text
(without introducing more risk)
By organizing the stimulus
input simultaneously into several
dimensions and successively into a
sequence of chunks, we manage to
break (or at least stretch) this
informational bottleneck.
Gareth Rushgrove
The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information, 1956
Slide 48
Slide 48 text
(without introducing more risk)
Gareth Rushgrove
Slide 49
Slide 49 text
(without introducing more risk)
The need for coordination drives
the need for communication among
team members.
Gareth Rushgrove
Findings from Communication Overhead: The Hidden Cost of Team Cognition, 2004
Slide 50
Slide 50 text
(without introducing more risk)
Reduction in communication
overhead can be created in multiple
ways, such as by restructuring the
team to reduce the need for
coordination…
Gareth Rushgrove
Findings from Communication Overhead: The Hidden Cost of Team Cognition, 2004
Slide 51
Slide 51 text
(without introducing more risk)
Reduction in communication
overhead can be created in multiple
ways, such as by restructuring the
team to reduce the need for
coordination…
Gareth Rushgrove
Microservices?
Slide 52
Slide 52 text
(without introducing more risk)
…or by activities that increase mutual
awareness and shared mental models
among team members
Gareth Rushgrove
Findings from Communication Overhead: The Hidden Cost of Team Cognition, 2004
Slide 53
Slide 53 text
(without introducing more risk)
…or by activities that increase mutual
awareness and shared mental models
among team members
Gareth Rushgrove
Devops?
Slide 54
Slide 54 text
(without introducing more risk)
Adopting software
The changing vendor relationship
Slide 55
Slide 55 text
(without introducing more risk)
Software adoption is a factor of
your organisational structure
Gareth Rushgrove
Slide 56
Slide 56 text
(without introducing more risk)
Is your organisational structure
an influence on the software
you adopt?
Gareth Rushgrove
Slide 57
Slide 57 text
(without introducing more risk)
Melvin Conway
If you have four groups working
on a compiler, you’ll get a 4-pass
compiler
Gareth Rushgrove
Slide 58
Slide 58 text
(without introducing more risk)
Paraphrasing
If you have four separate
business units with their own
budgets you’ll have 4 contracts
with
Gareth Rushgrove
Slide 59
Slide 59 text
(without introducing more risk)
Gareth Rushgrove
Developers as the new kingmakers
Slide 60
Slide 60 text
(without introducing more risk)
Developer driven software
adoption
Gareth Rushgrove
Slide 61
Slide 61 text
(without introducing more risk)
Developer evangelism
Gareth Rushgrove
Slide 62
Slide 62 text
(without introducing more risk)
Change the software you use by
changing your organisation
Gareth Rushgrove
Slide 63
Slide 63 text
(without introducing more risk)
Change your organisation by
changing the software you use
Gareth Rushgrove
Slide 64
Slide 64 text
(without introducing more risk)
Staffing
And the influence on technology adoption
Slide 65
Slide 65 text
(without introducing more risk)
Gareth Rushgrove
Software is eating the world
Slide 66
Slide 66 text
(without introducing more risk)
Organisations increasingly
prioritising speed over efficiency
Gareth Rushgrove
Slide 67
Slide 67 text
(without introducing more risk)
Explosion of new languages
Go, Rust, Clojure, Scala, Elixir,
Elm, Swift, TypeScript…
Gareth Rushgrove
Slide 68
Slide 68 text
(without introducing more risk)
Explosion of new platforms
Cloud Foundry, Docker, Rancher,
DC/OS, Kubernetes, Apcera…
Gareth Rushgrove
Slide 69
Slide 69 text
(without introducing more risk)
Gareth Rushgrove
The Full Stack Developer
http://xkcd.com/435/
Slide 70
Slide 70 text
(without introducing more risk)
Driven by need for speed?
Pick the right tool for the job
Gareth Rushgrove
Slide 71
Slide 71 text
(without introducing more risk)
Driven by competitive market?
Hiring pressure for skilled
technologists wanting new toys
Gareth Rushgrove
Slide 72
Slide 72 text
(without introducing more risk)
More services, many small bets,
lower risk, less focus on one
strategic technology
Gareth Rushgrove
Slide 73
Slide 73 text
(without introducing more risk)
Cause or effect?
Gareth Rushgrove
Slide 74
Slide 74 text
(without introducing more risk)
Conclusions
Wrapping everything up with more science
Slide 75
Slide 75 text
(without introducing more risk)
Sociotechnical Systems suggests that all
human systems include both a "technical
system" and a "social system"
Gareth Rushgrove
https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
Slide 76
Slide 76 text
(without introducing more risk)
It is possible for the system to optimize on
the technology, giving priority to technical
solutions and compelling the social
system to adapt to it…
Gareth Rushgrove
https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
Slide 77
Slide 77 text
(without introducing more risk)
… or to optimize on the social system,
giving priority to existing social patterns
and procedures and compelling the
technology to fill in what gaps remain.
Gareth Rushgrove
https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
Slide 78
Slide 78 text
(without introducing more risk)
In practice, both solutions are generally
suboptimal in terms of outcomes.
Gareth Rushgrove
https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
Slide 79
Slide 79 text
(without introducing more risk)
Better outcomes are usually obtained by a
reciprocal process of joint optimization,
through which both the technical system
and the social system change to some
degree in response to each other
Gareth Rushgrove
https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
Slide 80
Slide 80 text
(without introducing more risk)
Devops, microservices and the quest
for platforms are interdependent
examples of coevolution
Gareth Rushgrove
Slide 81
Slide 81 text
(without introducing more risk)
Only by understanding this coevolution
can you successfully evolve your
organisation to take advantage
Gareth Rushgrove
Slide 82
Slide 82 text
(without introducing more risk)
Questions?
And thanks for listening