The document discusses the philosophy and implementation of DevOps, emphasizing the role of technology and tools like Docker in transforming business operations and development processes. It highlights the benefits of adopting container technologies, addressing concerns about efficiency, density, and the challenges in existing build and deployment systems. The author argues for a developer-driven approach to leveraging Docker's advantages for competitive edge and encourages collaboration among technology leaders to realize potential business benefits.

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

2. Let’s Get
Acquainted

3. Background

4. Background
Oracle Developer,
MySQL DBA, PHP
Developer, System
Architect, DevOps
Director (snickering
encouraged),
Evangelist

5. Background
Oracle Developer,
MySQL DBA, PHP
Developer, System
Architect, DevOps
Director (snickering
encouraged)
Started Austin
DevOps In 2012

6. Background
Oracle Developer, MySQL
DBA, PHP Developer,
System Architect, DevOps
Director (snickering
encouraged)
Started Austin DevOps
In 2012
Co-Organizer of DevOps
Days Austin

7. Background
Oracle Developer, MySQL
DBA, PHP Developer, System
Architect, DevOps Director
(snickering encouraged)
Started Austin DevOps In
2012
Co-Organizer of DevOps
Days Austin
Became involved in
Docker Austin in August.

8. Background
Oracle Developer, MySQL DBA,
PHP Developer, System
Architect, DevOps Director
(snickering encouraged)
Started Austin DevOps In 2012
Co-Organizer of DevOps Days
Austin
Became involved in Docker
Austin in August.
Launching the First Ever
Container Days in Austin -
http://bit.ly/1CBppRV

9. Pespective

10. What is The
Goal of Your
Company?

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

12. So … What is
DevOps?

13. Is DevOps a Process?

14. Is DevOps an intersection of
overlapping concerns?

15. Is it what Gene Kim says?

16. Is DevOps a Culture?

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

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

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

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

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

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

23. Tools vs.
Technology
Tools are the result
of implementing a
DevOps model
Technology enables
revenue creation

24. Tools vs.
Technology
Tools are the result
of implementing a
DevOps model
Technology enables
revenue creation
Technology enables
the creation of new
DevOps models.

25. Tech v. Tools
Virtualization
Configuration Mgmt
Continuous
Integration
Continuous Delivery
Service Discovery
Containers
Vmware, AWS, Heroku
CFEngine, Puppet, Chef,
Go, Jenkins, Travis
CircleCI
Artifactory, Nexus
Zookeeper, etcd, consul
LXC, Docker, Rocket

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. Examples

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

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

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. Slice
host made it affordable. AWS brought it to
the masses.

32. 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. Slice host made
it affordable. AWS brought it to the masses.
Twitter, Facebook, Google, Pantheon have all be using
containers for some years. Docker brings containers
to all phases of the SDLC

33. Docker -
A Technology

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

35. Density

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

37. Density - Benefits

38. Density - Benefits
Reduces VM
consumption thus
reducing cost

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

40. Density - Concerns

41. Density - Concerns
Spare capacity on
hosts not there to
save you during
usage spikes

42. Density - Concerns
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
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
Doesn’t impact
revenue.

47. Density - Business
Reduces VM
consumption thus
reducing cost
Doesn’t address
revenue.
Probably not
compelling

48. Density - Adoption

49. Density - Adoption
Purely a production concern

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

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

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

53. Density - Tools

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

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

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

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

58. Factoring
Distributed Applications

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

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

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

62. Factoring -
Benefits

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

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

65. 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 the
Dockerfile

66. Factoring -
Concerns

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

68. Factoring -
Concerns
Impedence: How do
Build, QA and Ops
teams become
aware of config
change
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 -
Business
Unclear
Could speed up
development, but is
only a local optima
Vast majority of
apps factor to a
single machine

73. Factoring -
Business
Unclear
Could speed up
development, but is
only a local optima
Vast majority of apps
factor to a single
machine
Avoid the new-cool-
hotness arguments

74. Factoring -
Adoption

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

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

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

78. Factoring - Tools

79. Factoring -
Tools Gap
Only old fashion
brain power to
consider
application
modeling

80. Factoring -
Tools Gap
Only old fashion
brain power to
consider
application
modeling
Workflow
management

81. Factoring -
Tools Gap
Only old fashion
brain power to
consider application
modeling
Workflow
management
Containerizing
existing apps

82. Factoring -
Tools Available
Boot2Docker
Fig
Vagrant Docker

83. Build and Test
Grids

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

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

86. 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

87. Build and Test
Grids - Benefits

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

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

90. 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

91. 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

92. Build and Test
Grids - Concerns

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

94. Build and Test
Grids - Concerns
Is a container
based test
environment close
enough to
production?
Impedance: how
does the app get to
production if not
by container image?

95. Build and Test
Grids - Business

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

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

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

99. 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

100. 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
Optimization now occurring
more holistically. Revenue
impact is more likely.

101. Build and Test
Grids - Business

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

103. Build and Test Grids -
Business
A Unique Perspective
Development
Velocity is Revenue
Blog: Laundry Ops -
http://bit.ly/1E2gMUS

104. Build and Test Grids -
Business
A Unique Perspective
Development Velocity
is Revenue
Blog: Laundry Ops -
stackengine.com/
laundryops-practical-
devops-at-home/
Now we’re talking
disruption

105. Build and Test
Grids - Adoption

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

107. 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

108. 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

109. 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

110. 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

111. Build and Test
Grids - Tools

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

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

114. 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

115. 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

116. 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 registries very
immature

117. Build and Test Grids
- Tools Available
Jenkins - plugin
Bamboo
Circle CI
Docker Registry
Quay.io

118. System Architecture

119. System Architecture
- Defined
Overloaded term

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

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

122. System Architecture
- Benefits

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

124. 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

125. 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.

126. System Architecture
- Concerns

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

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

129. System Architecture
- Business

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

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

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

133. System Architecture
- Adoption

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

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

136. 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

137. System Architecture
- Tools

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

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

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

141. Food For Thought

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

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

144. Nourishment
Smother Deployment (Continuous
Delivery)
Black box production instrumentation
- Care only about the container
(tools don’t exist)
A/B Testing for Marketing (The Lean
Startup)

145. Nourishment
The future was
already here

146. Nourishment
The future was
already here
Pantheon/
Rackspace blog:
http://bit.ly/
15a2UIW

147. Nourishment
The future was
already here
Pantheon/
Rackspace blog:
http://bit.ly/
15a2UIW
Note the date:
October 7th, 2013

148. Nourishment
The future was already
here
Pantheon/Rackspace
blog: http://bit.ly/
15a2UIW
Note the date: October
7th, 2013
Docker is the _tool_ that
brings containers to the
masses

149. Robots _AND_ Unicorns
Docker - containers for mere mortals.

150. Closing Thoughts

151. Closing Thoughts -
Business

152. 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)

153. 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

154. 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

155. 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
Horses are starting to become unicorns. Evolve or die.

156. Closing Thoughts -
DevOps

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

158. 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

159. 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)

160. 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.

161. Should you be
Considering
Docker
Adoption?

162. audible.com - Maybe the
best DevOps Tool Yet?
The Lean Startup - Reis (tech)
The Goal - Goldratt (Theory of Constraints)
It’s not Luck - Goldratt (Theory of Constraints)
Good to Great - Collins (Culture)
The No Asshole Rule - Sutton (Culture)
The Phoenix Project - Kim (*) (tech)
Continuous Deliver - Humble (*) (hardcore tech)
The Lean Enterprise - Humble (*) (tech)

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