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 : 441 | ||
New Comment
