<< Photos

Docker Enables DevOps - Comment

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.

Topics covered:


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

Posted by :  peter88 Post date :  2020-01-06 16:26
Category :  Technology Views :  374

Comment - Previous - Next - Bookmark This
Social Bookmark or Share this page

peter88 last post Image
- Best Friends
- Weekly collection of popular funny memes
- Fall/Halloween Wallpaper Dump
- Halloween Portrait Wallpaper Dump
- Spooky Fun Halloween Wallpaper Dump
- Wtf hair dump
- Bad Hair Mega Dump
- Crazy hair dump
- Nail art dump 2
- Nail art dump
- Nail Dump
- Monkey pox virus - Microbiological aspects
- MonkeyPox Virus
- Monkeypox Outbreak 2022
- Understanding Monkeypox

Tags:

New Comment