Download as PDF, PPTX
Uploaded byBoyd Hemphill
Docker Enables DevOps
The document discusses the evolution of DevOps since its inception in Austin in 2012, highlighting the shift from a tools focus to a broader philosophy that embeds technology within business operations for mutual benefit. It emphasizes the significant role of tools like Docker in enhancing deployment efficiencies and the need for systemic changes in architecture to realize long-term advantages. Ultimately, it calls for developer-driven initiatives to maximize the potential benefits of adopting such technologies within organizations.
More Related Content
![Learning the Alphabet: A/B, CD and [E-Z] in the Docker Datacenter by Brett Ti...](https://cdn.slidesharecdn.com/ss_thumbnails/alphabet-160624232958-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Docker Enables DevOps
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Docker Enables DevOps
- 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 AustinDevOps 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 AustinDevOps 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 AustinDevOps 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 … Whatis DevOps?
- 10. Is DevOps aProcess?
- 11. Is it anintersection of overlapping concerns?
- 12. Is DevOps aCulture?
- 13. So … Whatis DevOps? DevOps is a Philosophy
- 14. So … Whatis DevOps? DevOps is a Philosophy All of the previous are models for implementation
- 15. DevOps: DevOps isthe way in which a technology organization embeds itself in a business to the benefit of that business.
- 16.
- 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 doourselves a disservice by naming technology with tools.
- 27. Ideally We doourselves a disservice by naming technology with tools. We should be talking about “solving a config management problem,” not “writing Chef code”
- 28. Realistically Good toolsenable a technology to be consumed by mere mortals
- 29. Realistically Good toolsenable 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 toolsenable 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 toolsenable 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.
- 34. Density - Defined The amount of idle compute on a host tends to zero
- 35.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 70. Factoring - Business Unclear
- 71. Factoring - Business Unclear Could speed up development, but is only a local optima
- 72.
- 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.
- 77. Factoring - ToolsGap Application modeling simplification
- 78. Factoring - ToolsGap Application modeling simplification Workflow management
- 79. Factoring - ToolsAvailable 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 TestGrids - Business A Unique Perspective Development Velocity is Revenue
- 99. Build and TestGrids - Business A Unique Perspective Development Velocity is Revenue Laundry Ops
- 100. Build and TestGrids - 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 TestGrids - Tools Available Jenkins - plugin Bamboo Docker Repository Quay.io
- 114.
- 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.
- 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.
- 138. Deployment - Defined Docker Deployment promises A/B deployment
- 139. Deployment - Defined Docker Deployment promises A/B deployment Promises rolling release and rollback
- 140.
- 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.
- 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.
- 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.
- 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.
- 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.
- 160. Nourishment Black boxproduction instrumentation - Care only about the container (tools don’t exist)
- 161. Nourishment Black boxproduction instrumentation - Care only about the container (tools don’t exist) A/B Testing for Marketing
- 162. Nourishment Black boxproduction instrumentation - Care only about the container (tools don’t exist) A/B Testing for Marketing On Demand infrastructure (Pantheon)
- 163.
- 164. Closing Thoughts - Business
- 165. Business Developer adoptionof 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 adoptionof 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 adoptionof 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 adoptionof 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 thoughtleaders are responsible for the holistic impact of technology decisions at the business level!
- 171. DevOps DevOps thoughtleaders 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 thoughtleaders 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 thoughtleaders 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 forYour Time and Comments. Boyd Hemphill @behemphi @stackengine