Some tools such as Chef and Jenkins are used by engineers in ops to great effect. Rarely though, a technology brings a paradigm to the masses. Docker, like cloud virtualization is of this more rare breed.

1. Docker Enables
DevOps
Boyd E. Hemphill
@behemphi @stackengine

2. History
Started Austin
DevOps In 2012

3. History
Started Austin
DevOps In 2012
At Feedmagnet,
Chef saved my
bacon learned I
was “doing DevOps”
at Chef Conf

4. History
Started Austin DevOps
In 2012
At Feedmagnet, Chef
saved my bacon
learned I was “doing
DevOps” at Chef Conf
Our first host and
sponsor was
CopperEgg

5. History
Started Austin DevOps In
2012
At Feedmagnet, Chef saved
my bacon learned I was
“doing DevOps” at Chef Conf
Our first host and sponsor
was CopperEgg
After moving from a tools
focus to philosophy and
models have grown to 700
members

6. History
Started Austin DevOps In 2012
At Feedmagnet, Chef saved my
bacon learned I was “doing
DevOps” at Chef Conf
Our first host and sponsor was
CopperEgg
After moving from a tools
focus to philosophy and models
have grown to 700 members
Ended up at StackEngine when
the CopperEgg founders started
this venture

7. What is The
Goal of Your
Company?

8. What is The
Goal of Your
Company?
Make Money!

9. So … What is
DevOps?

10. Is DevOps a Process?

11. Is it an intersection of
overlapping concerns?

12. Is DevOps a Culture?

13. So … What is
DevOps?
DevOps is a
Philosophy

14. So … What is
DevOps?
DevOps is a
Philosophy
All of the previous
are models for
implementation

15. DevOps:
DevOps is the way
in which a
technology
organization
embeds itself in a
business to the
benefit of that
business.

16. Business Basics
Profit

17. First Principles
Profit
Business Value

18. Profit, Revenue &
Cost
Profit = Revenue -
Cost

19. Profit, Revenue &
Cost
Profit = Revenue -
Cost
Drive Cost to $0
and you are out of
business

20. Profit, Revenue &
Cost
Profit = Revenue -
Cost
Drive Cost to $0
and you are out of
business
Increasing Revenue
has no theoretical
cap

21. Tools vs.
Technology
Tools have their
greatest impact on
cost

22. Tools vs.
Technology
Tools have their
greatest impact on
cost
Tools are the result
of implementing a
DevOps model

23. Tools vs.
Technology
Tools have their
greatest impact on
cost
Tools are the result
of implementing a
DevOps model
Technology enables
revenue creation

24. Tools vs.
Technology
Tools have their greatest
impact on cost
Tools are the result of
implementing a DevOps
model
Technology enables
revenue creation
Technology enables the
creation of new DevOps
models.

25. Tools v. Tech
Virtualization
Configuration
Management
Continuous Integration
Continuous Delivery
Service Discovery
Containers
Vmware, AWS, Heroku
CFEngine, Puppet, Chef,
Ansible
Go, Hudson, Jenkins, Travis
Artifactory, Nexus,
Shippable
Zookeeper, etcd, consul
(no SaaS yet)
FreeBSD Jails, LXC, Docker

26. Ideally
We do ourselves a disservice by
naming technology with tools.

27. Ideally
We do ourselves a disservice by
naming technology with tools.
We should be talking about “solving
a config management problem,” not
“writing Chef code”

28. Realistically
Good tools enable a technology to
be consumed by mere mortals

29. Realistically
Good tools enable a technology to
be consumed by mere mortals
CFEngine has been around a long
time, but Puppet and Chef raised the
config management conversation

30. Realistically
Good tools enable a technology to be
consumed by mere mortals
CFEngine has been around a long time,
but Puppet and Chef raised the config
management conversation
VMware is world class virtualization, but
AWS brought virtualization to the masses.

31. Realistically
Good tools enable a technology to be consumed by
mere mortals
CFEngine has been around a long time, but Puppet
and Chef raised the config management conversation
VMware is world class virtualization, but AWS brought
virtualization to the masses.
Twitter, Facebook, Google, Pantheon have all be using
containers for some years. Docker brings containers
to conversations to all phases of the SDLC

32. Docker - Opportunity
& Consequence
Density
Factoring
Build and Test
System Architecture

33. Density

34. Density - Defined
The amount of idle
compute on a host
tends to zero

35. Density - Benefits

36. Density - Benefits
Reduces VM
consumption thus
reducing cost

37. Density - Benefits
Reduces VM
consumption thus
reducing cost
Reduces power
consumption in a
physical setting

38. Density - Concerns

39. Density - Concerns
Fewer VMs in fewer
physical locations

40. Density - Concerns
Fewer VMs in fewer
physical locations
Location of VMs or
Hardware critically
important

41. Density - Concerns
Fewer VMs in fewer
physical locations
Location of VMs or
Hardware critically
important
Spare capacity on
hosts not there to
save you during
usage spikes

42. Density - Concerns
Fewer VMs in fewer physical
locations
Location of VMs or
Hardware critically
important
Spare capacity on hosts not
there to save you during
usage spikes
YACL - Yet another
complexity layer: containers
on vms on hardware

43. Density - Concerns
Fewer VMs in fewer physical
locations
Location of VMs or Hardware
critically important
Spare capacity on hosts not
there to save you during
usage spikes
YACL - Yet another
complexity layer: containers
on vms on hardware
Container Sprawl

44. Density - Business

45. Density - Business
Reduces VM
consumption thus
reducing cost

46. Density - Business
Reduces VM
consumption thus
reducing cost
Helpful by not
enough to merit the
difficulty of a
migration

47. Density - Adoption

48. Density - Adoption
Purely a production concern

49. Density - Adoption
Purely a production concern
Discussed a great deal, but
implementation implications too
large

50. Density - Adoption
Purely a production concern
Discussed a great deal, but
implementation implications too
large
Revolution, not evolution

51. Density - Adoption
Purely a production concern
Discussed a great deal, but
implementation implications too
large
Revolution, not evolution
Tools just not there yet

52. Density - Tools

53. Density
Tools Gap
Scheduling that is
location aware -
bin packing
problem

54. Density
Tools Gap
Scheduling that is
location aware -
bin packing
problem

55. Density
Tools Gap
Scheduling that is
location aware - bin
packing problem
Inventory
management
images
containers
hosts

56. Density
Tools Available
StackEngine
Tutum
Fleet
Dies
Control Center
Docker
Red Hat
Google
AWS
…

57. Factoring
Distributed Applications

58. Factoring -
Defined
Reduce your
production
topology to a
single machine

59. Factoring -
Defined
Reduce your
production
topology to a
single machine
Works great for
many applications

60. Factoring -
Defined
Reduce your
production
topology to a
single machine
Works great for
many applications
Vagrant is a killer
tool

61. Factoring -
Benefits

62. Factoring -
Benefits
Vagrant multi-machine
is resource
hungry. Run a
single VM with
multiple containers

63. Factoring -
Benefits
Vagrant multi-machine
is resource
hungry. Run a
single VM with
multiple containers
Developer, not Ops,
driven

64. Factoring -
Benefits
Vagrant multi-machine
is resource hungry. Run
a single VM with
multiple containers
Developer, not Ops,
driven
Developers need not
learn config
management, only
Dockerfile

65. Factoring -
Concerns

66. Factoring -
Concerns
Impedence: How do
Build, QA and Ops
teams become
aware of config
change

67. Factoring -
Concerns
Impedence: How do
Build, QA and Ops
teams become
aware of config
change
Does Dockerfile
have enough power

68. Factoring -
Concerns
Impedence: How do
Build, QA and Ops
teams become aware
of config change
Does Dockerfile have
enough power
Is it necessary, or
just cool? (sharding)

69. Factoring -
Business

70. Factoring -
Business
Unclear

71. Factoring -
Business
Unclear
Could speed up
development, but is
only a local optima

72. Factoring -
Adoption

73. Factoring -
Adoption
By far the most common adoption
path

74. Factoring -
Adoption
By far the most common adoption
path
Typically seen in shops where
Vagrant perceived as complex

75. Factoring -
Adoption
By far the most common adoption
path
Typically seen in shops where
Vagrant perceived as complex
Often gains traction in Build/QA

76. Factoring - Tools

77. Factoring -
Tools Gap
Application
modeling
simplification

78. Factoring -
Tools Gap
Application
modeling
simplification
Workflow
management

79. Factoring -
Tools Available
Boot2Docker
Fig
Vagrant Docker

80. Build and Test
Grids

81. Build and Test
Grids - Defined
Testing a number
of language
versions and
environments in
parallel

82. Build and Test
Grids - Defined
Testing a number
of language
versions and
environments in
parallel
Very important to
installed software

83. Build and Test
Grids - Defined
Testing a number of
language versions and
environments in parallel
Very important to
installed software
Example Testing on
Centos 6.5, Ubuntu
14.04 and CoreOs, with
the last three stable
Docker releases

84. Build and Test
Grids - Benefits

85. Build and Test
Grids - Benefits
Containers come up
fast making for
shorter builds

86. Build and Test
Grids - Benefits
Containers come up
fast making for
shorter builds
Multiple containers
on a build agent
improves density

87. Build and Test
Grids - Benefits
Containers come up
fast making for shorter
builds
Multiple containers on
a build agent improves
density
Makes it possible to test
many more
permutations of system
environments

88. Build and Test
Grids - Benefits
Containers come up fast
making for shorter builds
Multiple containers on a
build agent improves
density
Makes it possible to test
many more permutations
of system environments
Potential for more build
parallelism

89. Build and Test
Grids - Concerns

90. Build and Test
Grids - Concerns
Is a container
based test
environment close
enough to
production

91. Build and Test
Grids - Concerns
Is a container based
test environment
close enough to
production
Impedance: how
does the container
get from build or
test environment to
production

92. Build and Test
Grids - Business

93. Build and Test
Grids - Business
Increased grid
density reduces
costs

94. Build and Test
Grids - Business
Increased grid
density reduces
costs
Reducing build
times increase
innovation

95. Build and Test
Grids - Business
Increased grid
density reduces costs
Reducing build times
increase innovation
Reducing build times
increase
development velocity

96. Build and Test
Grids - Business
Increased grid density
reduces costs
Reducing build times
increase innovation
Reducing build times
increase development
velocity
Increase test speed keeps
QA from becoming a
bottleneck to increase
development velocity

97. Build and Test
Grids - Business

98. Build and Test Grids -
Business
A Unique Perspective
Development
Velocity is Revenue

99. Build and Test Grids -
Business
A Unique Perspective
Development
Velocity is Revenue
Laundry Ops

100. Build and Test Grids -
Business
A Unique Perspective
Development
Velocity is Revenue
Laundry Ops
Now we talking
disruption

101. Build and Test
Grids - Adoption

102. Build and Test
Grids - Adoption
Next most common adoption path

103. Build and Test
Grids - Adoption
Next most common adoption path
See as an efficient way to bring up
many copies of a test environment
efficiently

104. Build and Test
Grids - Adoption
Next most common adoption path
See as an efficient way to bring up
many copies of a test environment
efficiently
Surprisingly few producing a
container from the build system

105. Build and Test
Grids - Adoption
Next most common adoption path
See as an efficient way to bring up
many copies of a test environment
efficiently
Surprisingly few producing a container
from the build system
The final mile

106. Build and Test
Grids - Adoption
Next most common adoption path
See as an efficient way to bring up many
copies of a test environment efficiently
Surprisingly few producing a container from
the build system
The final mile
Production adoption creating impedance

107. Build and Test
Grids - Tools

108. Build and Test
Grid - Tools Gap
Build systems not
container aware

109. Build and Test
Grid - Tools Gap
Build systems not
container aware
Build systems do
not produce docker
images

110. Build and Test
Grid - Tools Gap
Build systems not
container aware
Build systems do
not produce docker
images
Build systems do
not treat images as
artifacts

111. Build and Test
Grid - Tools Gap
Build systems not
container aware
Build systems do not
produce docker images
Build systems do not
treat images as artifacts
Deployment systems are
still, as a whole,
immature

112. Build and Test
Grid - Tools Gap
Build systems not
container aware
Build systems do not
produce docker images
Build systems do not treat
images as artifacts
Deployment systems are
still, as a whole, immature
Private repos very
immature

113. Build and Test Grids
- Tools Available
Jenkins - plugin
Bamboo
Docker Repository
Quay.io

114. System Architecture

115. System Architecture
- Defined
Overloaded term

116. System Architecture
- Defined
Overloaded term
Is concerned with
how the various
services of a
software system
interact

117. System Architecture
- Defined
Overloaded term
Is concerned with
how the various
services of a
software system
interact
Network, Data flow,
request path, job
management

118. System Architecture
- Benefits

119. System Architecture
- Benefits
A separation of
concerns leads to a
“code to the
interface” paradigm

120. System Architecture
- Benefits
A separation of
concerns leads to a
“code to the
interface” paradigm
Micro teams’ micro-services
can move
at their own pace

121. System Architecture
- Benefits
A separation of
concerns leads to a
“code to the interface”
paradigm
Micro teams’ micro-services
can move at
their own pace
Only coordination
between teams is on
breaking changes.

122. System Architecture
- Concerns

123. System Architecture
- Concerns
Very few coders
out there who get it

124. System Architecture
- Concerns
Very few coders
out there who get it
Very few models
for mere mortals to
reason from

125. System Architecture
- Business

126. System Architecture
- Business
Extraordinary
increase in
Development Team
velocity

127. System Architecture
- Business
Extraordinary
increase in
Development Team
velocity
True competitive
advantage

128. System Architecture
- Business
Extraordinary
increase in
Development Team
velocity
True competitive
advantage
Because of difficult in
adoption, advantage
will be lasting

129. System Architecture
- Adoption

130. System Architecture
- Adoption
Micro service architecture is very
rare in the wild (unicorns)

131. System Architecture
- Adoption
Micro service architecture is very
rare in the wild (unicorns)
Investment to move existing
applications is high risk

132. System Architecture
- Adoption
Micro service architecture is very
rare in the wild (unicorns)
Investment to move existing
applications is high risk
Most shops are not mature/agile
enough to realize the benefit

133. System Architecture
- Tools

134. System Architecture
- Tools Gap
Meaningful
materials on micro
service
architectures

135. System Architecture
- Tools Gap
Meaningful
materials on micro
service
architectures
Meaningful
materials on async
systems

136. System Architecture
- Tools Available
12factor.net
?

137. Deployment

138. Deployment -
Defined
Docker Deployment
promises A/B
deployment

139. Deployment -
Defined
Docker Deployment
promises A/B
deployment
Promises rolling
release and
rollback

140. Deployment -
Benefits

141. Deployment -
Benefits
Easier to reason
about deployment
operations

142. Deployment -
Benefits
Easier to reason
about deployment
operations
Configuration is
not a concern,
handled by
development team

143. Deployment -
Concerns

144. Deployment -
Concerns
Any discussion of
rollback that
involves a data
store is still hand
waving

145. Deployment -
Concerns
Any discussion of
rollback that
involves a data
store is still hand
waving
Complexity:
Different services
need to be deployed
in different ways

146. Deployment -
Concerns
Any discussion of rollback
that involves a data store
is still hand waving
Complexity: Different
services need to be
deployed in different ways
A/B deployment makes a
number of assumptions
about application
architecture

147. Deployment -
Concerns
Any discussion of rollback
that involves a data store
is still hand waving
Complexity: Different
services need to be
deployed in different ways
A/B deployment makes a
number of assumptions
about application
architecture
No tools for the job

148. Deployment -
Business

149. Deployment -
Business
Decreases
deployment
friction

150. Deployment -
Business
Decreases
deployment
friction
Features get to
production faster
and more reliably

151. Deployment -
Business
Decreases
deployment friction
Features get to
production faster
and more reliably
Significant, lasting
competitive
advantage

152. Deployment -
Adoption

153. Deployment -
Adoption
Shops adopting CoreOS must adopt
this some level of A/B deployment

154. Deployment -
Adoption
Shops adopting CoreOS must adopt
this some level of A/B deployment
Lack of tools is impeding adoption

155. Deployment - Tools

156. Deployment - Tools
Gap
A production ready
container image
has no place to go

157. Deployment - Tools
Gap
A production ready
container image
has no place to go
Version aware
scheduling - I have
a new version of x,
how do I deploy it
based on policy y?

158. Deployment - Tools
Available
None yet
Working on it
StackEngine
Tutum
Fleet
Dies
Red Hat
Google
AWS

159. Food For Thought

160. Nourishment
Black box production
instrumentation - Care only about
the container (tools don’t exist)

161. Nourishment
Black box production
instrumentation - Care only about
the container (tools don’t exist)
A/B Testing for Marketing

162. Nourishment
Black box production
instrumentation - Care only about
the container (tools don’t exist)
A/B Testing for Marketing
On Demand infrastructure
(Pantheon)

163. Closing Thoughts

164. Closing Thoughts -
Business

165. Business
Developer adoption of Docker is
only valuable as a first step. There is
not enough benefit from it alone to
justify the effort, it must inform
system architecture and production
operations (over time)

166. Business
Developer adoption of Docker is only
valuable as a first step. There is not
enough benefit from it alone to justify the
effort, it must inform system architecture
and production operations (over time)
Docker’s system architecture ramifications
have the potential to provide a significant
and lasting competitive advantage

167. Business
Developer adoption of Docker is only valuable as a first
step. There is not enough benefit from it alone to justify
the effort, it must inform system architecture and
production operations (over time)
Docker’s system architecture ramifications have the
potential to provide a significant and lasting
competitive advantage
Unlike most ops driven improvements derived from
applying DevOps thinking, this must be developer driven
since its greatest benefit is derived from system
architecture

168. Business
Developer adoption of Docker is only valuable as a first
step. There is not enough benefit from it alone to justify the
effort, it must inform system architecture and production
operations (over time)
Docker’s system architecture ramifications have the potential
to provide a significant and lasting competitive advantage
Unlike most ops driven improvements derived from applying
DevOps thinking, this must be developer driven since its
greatest benefit is derived from system architecture
The deployment model for Docker is promising, but still
only done by unicorns (e.g. Netflix)

169. Closing Thoughts -
DevOps

170. DevOps
DevOps thought leaders are
responsible for the holistic impact
of technology decisions at the
business level!

171. DevOps
DevOps thought leaders are responsible
for the holistic impact of technology
decisions at the business level!
DevOps thought leaders should be
working with peers and collaborators
in their company to determine if they
can derive the proposed business
benefits

172. DevOps
DevOps thought leaders are responsible for the
holistic impact of technology decisions at the
business level!
DevOps thought leaders should be working with
peers and collaborators in their company to
determine if they can derive the proposed business
benefits
Models must be developed that provide sensible
direction for implementation (evolution not
revolution)

173. DevOps
DevOps thought leaders are responsible for the holistic
impact of technology decisions at the business level!
DevOps thought leaders should be working with peers
and collaborators in their company to determine if
they can derive the proposed business benefits
Models must be developed that provide sensible
direction for implementation (evolution not
revolution)
Tools are not there yet. Companies are showing up with
the mission to address this, but it is very early days.

174. Should you be
Considering
Docker
Adoption?

175. Thank You for Your Time and
Comments.
Boyd Hemphill
@behemphi
@stackengine