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