1. Docker EnablesDevOpsBoyd E. Hemphill@behemphi @stackengine

2. HistoryStarted AustinDevOps In 2012 3. HistoryStarted AustinDevOps In 2012At Feedmagnet,Chef saved mybacon learned Iwas doing DevOpsat Chef Conf 4. HistoryStarted Austin DevOpsIn 2012At Feedmagnet, Chefsaved my baconlearned I was doingDevOps at Chef ConfOur first host andsponsor wasCopperEgg 5. HistoryStarted Austin DevOps In2012At Feedmagnet, Chef savedmy bacon learned I wasdoing DevOps at Chef ConfOur first host and sponsorwas CopperEggAfter moving from a toolsfocus to philosophy andmodels have grown to 700members 6. HistoryStarted Austin DevOps In 2012At Feedmagnet, Chef saved mybacon learned I was doingDevOps at Chef ConfOur first host and sponsor wasCopperEggAfter moving from a toolsfocus to philosophy and modelshave grown to 700 membersEnded up at StackEngine whenthe CopperEgg founders startedthis venture 7. What is TheGoal of YourCompany? 8. What is TheGoal of YourCompany?Make Money! 9. So What isDevOps? 10. Is DevOps a Process? 11. Is it an intersection ofoverlapping concerns? 12. Is DevOps a Culture? 13. So What isDevOps?DevOps is aPhilosophy 14. So What isDevOps?DevOps is aPhilosophyAll of the previousare models forimplementation 15. DevOps:DevOps is the wayin which atechnologyorganizationembeds itself in abusiness to thebenefit of thatbusiness. 16. Business BasicsProfit 17. First PrinciplesProfitBusiness Value 18. Profit, Revenue &CostProfit = Revenue -Cost 19. Profit, Revenue &CostProfit = Revenue -CostDrive Cost to $0and you are out ofbusiness 20. Profit, Revenue &CostProfit = Revenue -CostDrive Cost to $0and you are out ofbusinessIncreasing Revenuehas no theoreticalcap 21. Tools vs.TechnologyTools have theirgreatest impact oncost 22. Tools vs.TechnologyTools have theirgreatest impact oncostTools are the resultof implementing aDevOps model 23. Tools vs.TechnologyTools have theirgreatest impact oncostTools are the resultof implementing aDevOps modelTechnology enablesrevenue creation 24. Tools vs.TechnologyTools have their greatestimpact on costTools are the result ofimplementing a DevOpsmodelTechnology enablesrevenue creationTechnology enables thecreation of new DevOpsmodels. 25. Tools v. TechVirtualizationConfigurationManagementContinuous IntegrationContinuous DeliveryService DiscoveryContainersVmware, AWS, HerokuCFEngine, Puppet, Chef,AnsibleGo, Hudson, Jenkins, TravisArtifactory, Nexus,ShippableZookeeper, etcd, consul(no SaaS yet)FreeBSD Jails, LXC, Docker 26. IdeallyWe do ourselves a disservice bynaming technology with tools. 27. IdeallyWe do ourselves a disservice bynaming technology with tools.We should be talking about solvinga config management problem, notwriting Chef code 28. RealisticallyGood tools enable a technology tobe consumed by mere mortals 29. RealisticallyGood tools enable a technology tobe consumed by mere mortalsCFEngine has been around a longtime, but Puppet and Chef raised theconfig management conversation 30. RealisticallyGood tools enable a technology to beconsumed by mere mortalsCFEngine has been around a long time,but Puppet and Chef raised the configmanagement conversationVMware is world class virtualization, butAWS brought virtualization to the masses. 31. RealisticallyGood tools enable a technology to be consumed bymere mortalsCFEngine has been around a long time, but Puppetand Chef raised the config management conversationVMware is world class virtualization, but AWS broughtvirtualization to the masses.Twitter, Facebook, Google, Pantheon have all be usingcontainers for some years. Docker brings containersto conversations to all phases of the SDLC 32. Docker - Opportunity& ConsequenceDensityFactoringBuild and TestSystem Architecture 33. Density 34. Density - DefinedThe amount of idlecompute on a hosttends to zero 35. Density - Benefits 36. Density - BenefitsReduces VMconsumption thusreducing cost 37. Density - BenefitsReduces VMconsumption thusreducing costReduces powerconsumption in aphysical setting 38. Density - Concerns 39. Density - ConcernsFewer VMs in fewerphysical locations 40. Density - ConcernsFewer VMs in fewerphysical locationsLocation of VMs orHardware criticallyimportant 41. Density - ConcernsFewer VMs in fewerphysical locationsLocation of VMs orHardware criticallyimportantSpare capacity onhosts not there tosave you duringusage spikes 42. Density - ConcernsFewer VMs in fewer physicallocationsLocation of VMs orHardware criticallyimportantSpare capacity on hosts notthere to save you duringusage spikesYACL - Yet anothercomplexity layer: containerson vms on hardware 43. Density - ConcernsFewer VMs in fewer physicallocationsLocation of VMs or Hardwarecritically importantSpare capacity on hosts notthere to save you duringusage spikesYACL - Yet anothercomplexity layer: containerson vms on hardwareContainer Sprawl 44. Density - Business 45. Density - BusinessReduces VMconsumption thusreducing cost 46. Density - BusinessReduces VMconsumption thusreducing costHelpful by notenough to merit thedifficulty of amigration 47. Density - Adoption 48. Density - AdoptionPurely a production concern 49. Density - AdoptionPurely a production concernDiscussed a great deal, butimplementation implications toolarge 50. Density - AdoptionPurely a production concernDiscussed a great deal, butimplementation implications toolargeRevolution, not evolution 51. Density - AdoptionPurely a production concernDiscussed a great deal, butimplementation implications toolargeRevolution, not evolutionTools just not there yet 52. Density - Tools 53. DensityTools GapScheduling that islocation aware -bin packingproblem 54. DensityTools GapScheduling that islocation aware -bin packingproblem 55. DensityTools GapScheduling that islocation aware - binpacking problemInventorymanagementimagescontainershosts 56. DensityTools AvailableStackEngineTutumFleetDiesControl CenterDockerRed HatGoogleAWS 57. FactoringDistributed Applications 58. Factoring -DefinedReduce yourproductiontopology to asingle machine 59. Factoring -DefinedReduce yourproductiontopology to asingle machineWorks great formany applications 60. Factoring -DefinedReduce yourproductiontopology to asingle machineWorks great formany applicationsVagrant is a killertool 61. Factoring -Benefits 62. Factoring -BenefitsVagrant multi-machineis resourcehungry. Run asingle VM withmultiple containers 63. Factoring -BenefitsVagrant multi-machineis resourcehungry. Run asingle VM withmultiple containersDeveloper, not Ops,driven 64. Factoring -BenefitsVagrant multi-machineis resource hungry. Runa single VM withmultiple containersDeveloper, not Ops,drivenDevelopers need notlearn configmanagement, onlyDockerfile 65. Factoring -Concerns 66. Factoring -ConcernsImpedence: How doBuild, QA and Opsteams becomeaware of configchange 67. Factoring -ConcernsImpedence: How doBuild, QA and Opsteams becomeaware of configchangeDoes Dockerfilehave enough power 68. Factoring -ConcernsImpedence: How doBuild, QA and Opsteams become awareof config changeDoes Dockerfile haveenough powerIs it necessary, orjust cool? (sharding) 69. Factoring -Business 70. Factoring -BusinessUnclear 71. Factoring -BusinessUnclearCould speed updevelopment, but isonly a local optima 72. Factoring -Adoption 73. Factoring -AdoptionBy far the most common adoptionpath 74. Factoring -AdoptionBy far the most common adoptionpathTypically seen in shops whereVagrant perceived as complex 75. Factoring -AdoptionBy far the most common adoptionpathTypically seen in shops whereVagrant perceived as complexOften gains traction in Build/QA 76. Factoring - Tools 77. Factoring -Tools GapApplicationmodelingsimplification 78. Factoring -Tools GapApplicationmodelingsimplificationWorkflowmanagement 79. Factoring -Tools AvailableBoot2DockerFigVagrant Docker 80. Build and TestGrids 81. Build and TestGrids - DefinedTesting a numberof languageversions andenvironments inparallel 82. Build and TestGrids - DefinedTesting a numberof languageversions andenvironments inparallelVery important toinstalled software 83. Build and TestGrids - DefinedTesting a number oflanguage versions andenvironments in parallelVery important toinstalled softwareExample Testing onCentos 6.5, Ubuntu14.04 and CoreOs, withthe last three stableDocker releases 84. Build and TestGrids - Benefits 85. Build and TestGrids - BenefitsContainers come upfast making forshorter builds 86. Build and TestGrids - BenefitsContainers come upfast making forshorter buildsMultiple containerson a build agentimproves density 87. Build and TestGrids - BenefitsContainers come upfast making for shorterbuildsMultiple containers ona build agent improvesdensityMakes it possible to testmany morepermutations of systemenvironments 88. Build and TestGrids - BenefitsContainers come up fastmaking for shorter buildsMultiple containers on abuild agent improvesdensityMakes it possible to testmany more permutationsof system environmentsPotential for more buildparallelism 89. Build and TestGrids - Concerns 90. Build and TestGrids - ConcernsIs a containerbased testenvironment closeenough toproduction 91. Build and TestGrids - ConcernsIs a container basedtest environmentclose enough toproductionImpedance: howdoes the containerget from build ortest environment toproduction 92. Build and TestGrids - Business 93. Build and TestGrids - BusinessIncreased griddensity reducescosts 94. Build and TestGrids - BusinessIncreased griddensity reducescostsReducing buildtimes increaseinnovation 95. Build and TestGrids - BusinessIncreased griddensity reduces costsReducing build timesincrease innovationReducing build timesincreasedevelopment velocity 96. Build and TestGrids - BusinessIncreased grid densityreduces costsReducing build timesincrease innovationReducing build timesincrease developmentvelocityIncrease test speed keepsQA from becoming abottleneck to increasedevelopment velocity 97. Build and TestGrids - Business 98. Build and Test Grids -BusinessA Unique PerspectiveDevelopmentVelocity is Revenue 99. Build and Test Grids -BusinessA Unique PerspectiveDevelopmentVelocity is RevenueLaundry Ops 100. Build and Test Grids -BusinessA Unique PerspectiveDevelopmentVelocity is RevenueLaundry OpsNow we talkingdisruption 101. Build and TestGrids - Adoption 102. Build and TestGrids - AdoptionNext most common adoption path 103. Build and TestGrids - AdoptionNext most common adoption pathSee as an efficient way to bring upmany copies of a test environmentefficiently 104. Build and TestGrids - AdoptionNext most common adoption pathSee as an efficient way to bring upmany copies of a test environmentefficientlySurprisingly few producing acontainer from the build system 105. Build and TestGrids - AdoptionNext most common adoption pathSee as an efficient way to bring upmany copies of a test environmentefficientlySurprisingly few producing a containerfrom the build systemThe final mile 106. Build and TestGrids - AdoptionNext most common adoption pathSee as an efficient way to bring up manycopies of a test environment efficientlySurprisingly few producing a container fromthe build systemThe final mileProduction adoption creating impedance 107. Build and TestGrids - Tools 108. Build and TestGrid - Tools GapBuild systems notcontainer aware 109. Build and TestGrid - Tools GapBuild systems notcontainer awareBuild systems donot produce dockerimages 110. Build and TestGrid - Tools GapBuild systems notcontainer awareBuild systems donot produce dockerimagesBuild systems donot treat images asartifacts 111. Build and TestGrid - Tools GapBuild systems notcontainer awareBuild systems do notproduce docker imagesBuild systems do nottreat images as artifactsDeployment systems arestill, as a whole,immature 112. Build and TestGrid - Tools GapBuild systems notcontainer awareBuild systems do notproduce docker imagesBuild systems do not treatimages as artifactsDeployment systems arestill, as a whole, immaturePrivate repos veryimmature 113. Build and Test Grids- Tools AvailableJenkins - pluginBambooDocker RepositoryQuay.io 114. System Architecture 115. System Architecture- DefinedOverloaded term 116. System Architecture- DefinedOverloaded termIs concerned withhow the variousservices of asoftware systeminteract 117. System Architecture- DefinedOverloaded termIs concerned withhow the variousservices of asoftware systeminteractNetwork, Data flow,request path, jobmanagement 118. System Architecture- Benefits 119. System Architecture- BenefitsA separation ofconcerns leads to acode to theinterface paradigm 120. System Architecture- BenefitsA separation ofconcerns leads to acode to theinterface paradigmMicro teams micro-servicescan moveat their own pace 121. System Architecture- BenefitsA separation ofconcerns leads to acode to the interfaceparadigmMicro teams micro-servicescan move attheir own paceOnly coordinationbetween teams is onbreaking changes. 122. System Architecture- Concerns 123. System Architecture- ConcernsVery few codersout there who get it 124. System Architecture- ConcernsVery few codersout there who get itVery few modelsfor mere mortals toreason from 125. System Architecture- Business 126. System Architecture- BusinessExtraordinaryincrease inDevelopment Teamvelocity 127. System Architecture- BusinessExtraordinaryincrease inDevelopment TeamvelocityTrue competitiveadvantage 128. System Architecture- BusinessExtraordinaryincrease inDevelopment TeamvelocityTrue competitiveadvantageBecause of difficult inadoption, advantagewill be lasting 129. System Architecture- Adoption 130. System Architecture- AdoptionMicro service architecture is veryrare in the wild (unicorns) 131. System Architecture- AdoptionMicro service architecture is veryrare in the wild (unicorns)Investment to move existingapplications is high risk 132. System Architecture- AdoptionMicro service architecture is veryrare in the wild (unicorns)Investment to move existingapplications is high riskMost shops are not mature/agileenough to realize the benefit 133. System Architecture- Tools 134. System Architecture- Tools GapMeaningfulmaterials on microservicearchitectures 135. System Architecture- Tools GapMeaningfulmaterials on microservicearchitecturesMeaningfulmaterials on asyncsystems 136. System Architecture- Tools Available12factor.net? 137. Deployment 138. Deployment -DefinedDocker Deploymentpromises A/Bdeployment 139. Deployment -DefinedDocker Deploymentpromises A/BdeploymentPromises rollingrelease androllback 140. Deployment -Benefits 141. Deployment -BenefitsEasier to reasonabout deploymentoperations 142. Deployment -BenefitsEasier to reasonabout deploymentoperationsConfiguration isnot a concern,handled bydevelopment team 143. Deployment -Concerns 144. Deployment -ConcernsAny discussion ofrollback thatinvolves a datastore is still handwaving 145. Deployment -ConcernsAny discussion ofrollback thatinvolves a datastore is still handwavingComplexity:Different servicesneed to be deployedin different ways 146. Deployment -ConcernsAny discussion of rollbackthat involves a data storeis still hand wavingComplexity: Differentservices need to bedeployed in different waysA/B deployment makes anumber of assumptionsabout applicationarchitecture 147. Deployment -ConcernsAny discussion of rollbackthat involves a data storeis still hand wavingComplexity: Differentservices need to bedeployed in different waysA/B deployment makes anumber of assumptionsabout applicationarchitectureNo tools for the job 148. Deployment -Business 149. Deployment -BusinessDecreasesdeploymentfriction 150. Deployment -BusinessDecreasesdeploymentfrictionFeatures get toproduction fasterand more reliably 151. Deployment -BusinessDecreasesdeployment frictionFeatures get toproduction fasterand more reliablySignificant, lastingcompetitiveadvantage 152. Deployment -Adoption 153. Deployment -AdoptionShops adopting CoreOS must adoptthis some level of A/B deployment 154. Deployment -AdoptionShops adopting CoreOS must adoptthis some level of A/B deploymentLack of tools is impeding adoption 155. Deployment - Tools 156. Deployment - ToolsGapA production readycontainer imagehas no place to go 157. Deployment - ToolsGapA production readycontainer imagehas no place to goVersion awarescheduling - I havea new version of x,how do I deploy itbased on policy y? 158. Deployment - ToolsAvailableNone yetWorking on itStackEngineTutumFleetDiesRed HatGoogleAWS 159. Food For Thought 160. NourishmentBlack box productioninstrumentation - Care only aboutthe container (tools dont exist) 161. NourishmentBlack box productioninstrumentation - Care only aboutthe container (tools dont exist)A/B Testing for Marketing 162. NourishmentBlack box productioninstrumentation - Care only aboutthe container (tools dont exist)A/B Testing for MarketingOn Demand infrastructure(Pantheon) 163. Closing Thoughts 164. Closing Thoughts -Business 165. BusinessDeveloper adoption of Docker isonly valuable as a first step. There isnot enough benefit from it alone tojustify the effort, it must informsystem architecture and productionoperations (over time) 166. BusinessDeveloper adoption of Docker is onlyvaluable as a first step. There is notenough benefit from it alone to justify theeffort, it must inform system architectureand production operations (over time)Dockers system architecture ramificationshave the potential to provide a significantand lasting competitive advantage 167. BusinessDeveloper adoption of Docker is only valuable as a firststep. There is not enough benefit from it alone to justifythe effort, it must inform system architecture andproduction operations (over time)Dockers system architecture ramifications have thepotential to provide a significant and lastingcompetitive advantageUnlike most ops driven improvements derived fromapplying DevOps thinking, this must be developer drivensince its greatest benefit is derived from systemarchitecture 168. BusinessDeveloper adoption of Docker is only valuable as a firststep. There is not enough benefit from it alone to justify theeffort, it must inform system architecture and productionoperations (over time)Dockers system architecture ramifications have the potentialto provide a significant and lasting competitive advantageUnlike most ops driven improvements derived from applyingDevOps thinking, this must be developer driven since itsgreatest benefit is derived from system architectureThe deployment model for Docker is promising, but stillonly done by unicorns (e.g. Netflix) 169. Closing Thoughts -DevOps 170. DevOpsDevOps thought leaders areresponsible for the holistic impactof technology decisions at thebusiness level! 171. DevOpsDevOps thought leaders are responsiblefor the holistic impact of technologydecisions at the business level!DevOps thought leaders should beworking with peers and collaboratorsin their company to determine if theycan derive the proposed businessbenefits 172. DevOpsDevOps thought leaders are responsible for theholistic impact of technology decisions at thebusiness level!DevOps thought leaders should be working withpeers and collaborators in their company todetermine if they can derive the proposed businessbenefitsModels must be developed that provide sensibledirection for implementation (evolution notrevolution) 173. DevOpsDevOps thought leaders are responsible for the holisticimpact of technology decisions at the business level!DevOps thought leaders should be working with peersand collaborators in their company to determine ifthey can derive the proposed business benefitsModels must be developed that provide sensibledirection for implementation (evolution notrevolution)Tools are not there yet. Companies are showing up withthe mission to address this, but it is very early days. 174. Should you beConsideringDockerAdoption? 175. Thank You for Your Time andComments.Boyd Hemphill@behemphi@stackengine