Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Development Operations: Take Back Your Infrastructure

2,426 views

Published on

Published in: Technology, Business
  • Be the first to comment

Development Operations: Take Back Your Infrastructure

  1. 1. Development OperationsTake Back Your Infrastructure Mark Stanislav <mark.stanislav@gmail.com>
  2. 2. Me
  3. 3. MeSenior Linux Administrator for a managedservices provider in Michigan
  4. 4. MeSenior Linux Administrator for a managedservices provider in MichiganAdmin experience in start-up, small business,corporate, and education environments
  5. 5. MeSenior Linux Administrator for a managedservices provider in MichiganAdmin experience in start-up, small business,corporate, and education environmentsPreviously a professional web programmer
  6. 6. MeSenior Linux Administrator for a managedservices provider in MichiganAdmin experience in start-up, small business,corporate, and education environmentsPreviously a professional web programmer Dev + Ops = Why we are here! ;)
  7. 7. The Definition of DevOps“A set of processes, methods and systems forcommunication, collaboration and integrationbetween departments for Development(Applications/Software Engineering), TechnologyOperations and Quality Assurance (QA).” -Wikipedia, “DevOps”
  8. 8. The Definition of DevOps“A set of processes, methods and systems forcommunication, collaboration and integrationbetween departments for Development(Applications/Software Engineering), TechnologyOperations and Quality Assurance (QA).” -Wikipedia, “DevOps” ...okay, but what is DevOps?
  9. 9. DevOps From The Community
  10. 10. DevOps From The Community“So, the Devops movement is characterized by people with amultidisciplinary skill set - people who are comfortable withinfrastructure and configuration, but also happy to roll up their sleeves,write tests, debug, and ship features.”- Stephen Nelson-Smith, agilesysadmin.net
  11. 11. DevOps From The Community“So, the Devops movement is characterized by people with amultidisciplinary skill set - people who are comfortable withinfrastructure and configuration, but also happy to roll up their sleeves,write tests, debug, and ship features.”- Stephen Nelson-Smith, agilesysadmin.net“DevOps helps to enable IT alignment by aligning development andoperations roles and processes in the context of shared businessobjectives. Both development and operations need to understand thatthey are part of a unified business process.”-Damon Edwards, dev2ops.org
  12. 12. DevOps From The Community“So, the Devops movement is characterized by people with amultidisciplinary skill set - people who are comfortable withinfrastructure and configuration, but also happy to roll up their sleeves,write tests, debug, and ship features.”- Stephen Nelson-Smith, agilesysadmin.net“DevOps helps to enable IT alignment by aligning development andoperations roles and processes in the context of shared businessobjectives. Both development and operations need to understand thatthey are part of a unified business process.”-Damon Edwards, dev2ops.org“DevOps is all about trying to avoid that epic failure and workingsmarter and more efficiently at the same time. It is a framework ofideas and principles designed to foster cooperation, learning andcoordination between development and operational groups.”-James Turnbull, kartar.net
  13. 13. “If culture isnt the first part of explaining DevOps,youve missed the point.” - John Willis, DTO Solutions
  14. 14. This is not DevOps culture.
  15. 15. ...nor is this...
  16. 16. ...and DevOps culture is certainly not this!
  17. 17. DevOps Culture is About...
  18. 18. DevOps Culture is About...Working in operations because you care about the efficacyof infrastructure and success of your team
  19. 19. DevOps Culture is About...Working in operations because you care about the efficacyof infrastructure and success of your teamConsidering your ability to have a greater impact on anorganization beyond your own job title
  20. 20. DevOps Culture is About...Working in operations because you care about the efficacyof infrastructure and success of your teamConsidering your ability to have a greater impact on anorganization beyond your own job titleCommunication that has no concern with cubicle walls,geography, or corporate hierarchy
  21. 21. DevOps Culture is About...Working in operations because you care about the efficacyof infrastructure and success of your teamConsidering your ability to have a greater impact on anorganization beyond your own job titleCommunication that has no concern with cubicle walls,geography, or corporate hierarchyOperations and development working more efficiently withless push & pull for agreement
  22. 22. DevOps Culture is About...Working in operations because you care about the efficacyof infrastructure and success of your teamConsidering your ability to have a greater impact on anorganization beyond your own job titleCommunication that has no concern with cubicle walls,geography, or corporate hierarchyOperations and development working more efficiently withless push & pull for agreementUnderstanding that your job is more than a job, and thatyour work more than a mere checklist
  23. 23. Developers vs. Operations
  24. 24. Developers vs. OperationsDevelopers: “Hi Ops, Ruby just rolled a really important newrelease and we’d like to start testing it in an identical, newstaging environment this week.”
  25. 25. Developers vs. OperationsDevelopers: “Hi Ops, Ruby just rolled a really important newrelease and we’d like to start testing it in an identical, newstaging environment this week.”Operations: “Okay, well we understand the desire to do so,but we can’t just roll out a staging environment that quicklyand certainly not one with full parity to the existing one.”
  26. 26. Developers vs. OperationsDevelopers: “Hi Ops, Ruby just rolled a really important newrelease and we’d like to start testing it in an identical, newstaging environment this week.”Operations: “Okay, well we understand the desire to do so,but we can’t just roll out a staging environment that quicklyand certainly not one with full parity to the existing one.”Developers: “Hi Ops, we know that you guys have 13,000servers in five data centers on three continents, but if youcould delete /etc/foobar on servers with Apache 2.2.4 only,that would be great! Oh, and in the next 30 minutes or so?”
  27. 27. Developers vs. OperationsDevelopers: “Hi Ops, Ruby just rolled a really important newrelease and we’d like to start testing it in an identical, newstaging environment this week.”Operations: “Okay, well we understand the desire to do so,but we can’t just roll out a staging environment that quicklyand certainly not one with full parity to the existing one.”Developers: “Hi Ops, we know that you guys have 13,000servers in five data centers on three continents, but if youcould delete /etc/foobar on servers with Apache 2.2.4 only,that would be great! Oh, and in the next 30 minutes or so?”Operations: “Is this April 1st or something? No.”
  28. 28. The Agile Manifesto
  29. 29. The Agile Manifesto“...software development methodologies based on iterative and incremental development...”
  30. 30. The Agile Manifesto “...software development methodologies based on iterative and incremental development...”Close, daily co-operation between business people anddevelopers
  31. 31. The Agile Manifesto “...software development methodologies based on iterative and incremental development...”Close, daily co-operation between business people anddevelopersProjects are built around motivated individuals, who shouldbe trusted
  32. 32. The Agile Manifesto “...software development methodologies based on iterative and incremental development...”Close, daily co-operation between business people anddevelopersProjects are built around motivated individuals, who shouldbe trustedWorking software is delivered frequently
  33. 33. The Agile Manifesto “...software development methodologies based on iterative and incremental development...”Close, daily co-operation between business people anddevelopersProjects are built around motivated individuals, who shouldbe trustedWorking software is delivered frequentlySustainable development, able to maintain a constant pace
  34. 34. The Agile Manifesto “...software development methodologies based on iterative and incremental development...”Close, daily co-operation between business people anddevelopersProjects are built around motivated individuals, who shouldbe trustedWorking software is delivered frequentlySustainable development, able to maintain a constant paceRegular adaptation to changing circumstances
  35. 35. What Developers Have
  36. 36. What Developers HaveFrameworks allowing for consistency & rapid development
  37. 37. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revert
  38. 38. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a project
  39. 39. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a projectUnit testing of code to watch for regression issues
  40. 40. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a projectUnit testing of code to watch for regression issuesTiered development environments (dev, test, review, live)
  41. 41. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a projectUnit testing of code to watch for regression issuesTiered development environments (dev, test, review, live)Files that adhere to a logical hierarchy (MVC folder structure)
  42. 42. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a projectUnit testing of code to watch for regression issuesTiered development environments (dev, test, review, live)Files that adhere to a logical hierarchy (MVC folder structure)Agile practices for team interaction and transparency
  43. 43. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a projectUnit testing of code to watch for regression issuesTiered development environments (dev, test, review, live)Files that adhere to a logical hierarchy (MVC folder structure)Agile practices for team interaction and transparencyOrganizational software to keep track of project goals/tasks
  44. 44. What Developers HaveFrameworks allowing for consistency & rapid developmentVersioned repositories of code with the ability to revertAccountability for code that is committed to a projectUnit testing of code to watch for regression issuesTiered development environments (dev, test, review, live)Files that adhere to a logical hierarchy (MVC folder structure)Agile practices for team interaction and transparencyOrganizational software to keep track of project goals/tasksIntegrated Development Environments (IDE)
  45. 45. Physical InfrastructureGood Bad
  46. 46. Physical Infrastructure,
  47. 47. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure
  48. 48. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure Ability to track down a damaged patch cable faster
  49. 49. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure Ability to track down a damaged patch cable faster Less distraction from seeing link/error lights on devices
  50. 50. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure Ability to track down a damaged patch cable faster Less distraction from seeing link/error lights on devices Mitigated risk of having cables accidentally unplugged
  51. 51. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure Ability to track down a damaged patch cable faster Less distraction from seeing link/error lights on devices Mitigated risk of having cables accidentally unplugged New/potential employees to be excited to come to work
  52. 52. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure Ability to track down a damaged patch cable faster Less distraction from seeing link/error lights on devices Mitigated risk of having cables accidentally unplugged New/potential employees to be excited to come to work Upgrading hardware/components is less of a hassle
  53. 53. Physical Infrastructure,Better Physical Infrastructure Allows... Easier server replacement in the event of a system failure Ability to track down a damaged patch cable faster Less distraction from seeing link/error lights on devices Mitigated risk of having cables accidentally unplugged New/potential employees to be excited to come to work Upgrading hardware/components is less of a hassle A lasting satisfaction for all involved that we “did things right”
  54. 54. What “Old” Operations Has
  55. 55. What “Old” Operations HasLots of BASH/PERL scripts for automation & deployment
  56. 56. What “Old” Operations HasLots of BASH/PERL scripts for automation & deploymentSSH for-loops (e.g. for i in `cat serverlist.txt`; do ping $i; done)
  57. 57. What “Old” Operations HasLots of BASH/PERL scripts for automation & deploymentSSH for-loops (e.g. for i in `cat serverlist.txt`; do ping $i; done)Tarballs of directories for configuration management
  58. 58. What “Old” Operations HasLots of BASH/PERL scripts for automation & deploymentSSH for-loops (e.g. for i in `cat serverlist.txt`; do ping $i; done)Tarballs of directories for configuration managementFile comparisons (diff -uNr) to check for inconsistencies
  59. 59. What “Old” Operations HasLots of BASH/PERL scripts for automation & deploymentSSH for-loops (e.g. for i in `cat serverlist.txt`; do ping $i; done)Tarballs of directories for configuration managementFile comparisons (diff -uNr) to check for inconsistenciesHand editing of monitoring configuration files for new servers
  60. 60. What “Old” Operations HasLots of BASH/PERL scripts for automation & deploymentSSH for-loops (e.g. for i in `cat serverlist.txt`; do ping $i; done)Tarballs of directories for configuration managementFile comparisons (diff -uNr) to check for inconsistenciesHand editing of monitoring configuration files for new servers“If that servers dies, everything is going to fall apart...”
  61. 61. What “Old” Operations HasLots of BASH/PERL scripts for automation & deploymentSSH for-loops (e.g. for i in `cat serverlist.txt`; do ping $i; done)Tarballs of directories for configuration managementFile comparisons (diff -uNr) to check for inconsistenciesHand editing of monitoring configuration files for new servers“If that servers dies, everything is going to fall apart...” =(
  62. 62. Knowing all of this...We need to do better.
  63. 63. Knowing all of this...We need to do better. Configuration management
  64. 64. Knowing all of this...We need to do better. Configuration management Consistent task automation
  65. 65. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments
  66. 66. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments Revert ‘bad’ infrastructure
  67. 67. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments Revert ‘bad’ infrastructure Accountability for changes
  68. 68. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments Revert ‘bad’ infrastructure Accountability for changes An IDE to build infrastructure
  69. 69. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments Revert ‘bad’ infrastructure Accountability for changes An IDE to build infrastructure Behavior Driven Development
  70. 70. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments Revert ‘bad’ infrastructure Accountability for changes An IDE to build infrastructure Behavior Driven Development Auto-generation of monitoring
  71. 71. Knowing all of this...We need to do better. Configuration management Consistent task automation Portability of environments Revert ‘bad’ infrastructure Accountability for changes An IDE to build infrastructure Behavior Driven Development Auto-generation of monitoring THE ABILITY TO BE AGILE!
  72. 72. Configuration Management
  73. 73. Configuration ManagementInfrastructure as Code (Puppet)
  74. 74. Configuration ManagementInfrastructure as Code (Puppet)file { “/etc/resolv.conf”: owner => “root”, mode => “0644”;}
  75. 75. Configuration ManagementInfrastructure as Code (Puppet) file { “/etc/resolv.conf”: package { “openssh”: owner => “root”, ensure => latest; mode => “0644”; } }
  76. 76. Configuration ManagementInfrastructure as Code (Puppet) file { “/etc/resolv.conf”: package { “openssh”: owner => “root”, ensure => latest; mode => “0644”; } } tidy { "/tmp": age => "1w", matches => *.temp"; }
  77. 77. Configuration ManagementInfrastructure as Code (Puppet) file { “/etc/resolv.conf”: package { “openssh”: owner => “root”, ensure => latest; mode => “0644”; } } tidy { "/tmp": service { “named”: age => "1w", ensure => running, matches => *.temp"; enable => true; } }
  78. 78. Consistent Task AutomationMarrionette-Collective (mCollective)
  79. 79. Consistent Task AutomationMarrionette-Collective (mCollective) RPC-based framework for server orchestration and/or parallel jobs
  80. 80. Consistent Task AutomationMarrionette-Collective (mCollective) RPC-based framework for server orchestration and/or parallel jobs Publish-Subscribe model using ActiveMQ/RabbitMQ for queues
  81. 81. Consistent Task AutomationMarrionette-Collective (mCollective) RPC-based framework for server orchestration and/or parallel jobs Publish-Subscribe model using ActiveMQ/RabbitMQ for queues Leverages meta-data (ohai, facter, custom files, etc.) to limit scope
  82. 82. Consistent Task AutomationMarrionette-Collective (mCollective) RPC-based framework for server orchestration and/or parallel jobs Publish-Subscribe model using ActiveMQ/RabbitMQ for queues Leverages meta-data (ohai, facter, custom files, etc.) to limit scope redacted
  83. 83. Portability of Environments a.k.a. The Promise of Cloud Computing
  84. 84. Portability of Environments a.k.a. The Promise of Cloud ComputingCloud-vendor portability using Puppet, Chef, or otherwise
  85. 85. Portability of Environments a.k.a. The Promise of Cloud ComputingCloud-vendor portability using Puppet, Chef, or otherwiseDisaster recovery warm-site with full system parity
  86. 86. Portability of Environments a.k.a. The Promise of Cloud ComputingCloud-vendor portability using Puppet, Chef, or otherwiseDisaster recovery warm-site with full system parityEasy duplication of environments (e.g. new staging)
  87. 87. Portability of Environments a.k.a. The Promise of Cloud ComputingCloud-vendor portability using Puppet, Chef, or otherwiseDisaster recovery warm-site with full system parityEasy duplication of environments (e.g. new staging)Treat your infrastructure (non-cloud) as ephemeral
  88. 88. Portability of Environments a.k.a. The Promise of Cloud ComputingCloud-vendor portability using Puppet, Chef, or otherwiseDisaster recovery warm-site with full system parityEasy duplication of environments (e.g. new staging)Treat your infrastructure (non-cloud) as ephemeralReduction in downtime for failed servers/services
  89. 89. Portability of Environments a.k.a. The Promise of Cloud Computing Cloud-vendor portability using Puppet, Chef, or otherwise Disaster recovery warm-site with full system parity Easy duplication of environments (e.g. new staging) Treat your infrastructure (non-cloud) as ephemeral Reduction in downtime for failed servers/services“The cloud means nothing unless you can quicklydeploy, configure, maintain, and destroy hosts withoutintervention.” - Me, right now.
  90. 90. Version Controlled Infrastructure
  91. 91. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code
  92. 92. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”]
  93. 93. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”] Reversion [“Revert to version 302 of the configuration!”]
  94. 94. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”] Reversion [“Revert to version 302 of the configuration!”] Differentials [“Which change caused this issue?”]
  95. 95. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”] Reversion [“Revert to version 302 of the configuration!”] Differentials [“Which change caused this issue?”] Environments [“Let’s test this change in staging, first.”]
  96. 96. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”] Reversion [“Revert to version 302 of the configuration!”] Differentials [“Which change caused this issue?”] Environments [“Let’s test this change in staging, first.”] Branches [“I’ve got a few new features to push I tested.”]
  97. 97. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”] Reversion [“Revert to version 302 of the configuration!”] Differentials [“Which change caused this issue?”] Environments [“Let’s test this change in staging, first.”] Branches [“I’ve got a few new features to push I tested.”] History [“Let’s review what we did this year...”]
  98. 98. Version Controlled Infrastructure Infrastructure as code begs to be controlled like other code Accountability [“Who committed this change & when?”] Reversion [“Revert to version 302 of the configuration!”] Differentials [“Which change caused this issue?”] Environments [“Let’s test this change in staging, first.”] Branches [“I’ve got a few new features to push I tested.”] History [“Let’s review what we did this year...”]Developers can submit pull requests to infrastructure!
  99. 99. Gepetto: An IDE for Puppet
  100. 100. Cucumber-Puppet, BDD
  101. 101. Cucumber-Puppet, BDDFeature: General catalog policy In order to ensure applicability of a hosts catalog As a manifest developer I want all catalogs to obey some general rules Scenario Outline: Compile and verify catalog Given a node specified by "features/yaml/<hostname>.example.com.yaml" When I compile its catalog Then compilation should succeed And all resource dependencies should resolve Examples: | hostname | | localhost | Isn’t this awesome?* Yanked from: http://projects.puppetlabs.com/projects/cucumber-puppet/wiki
  102. 102. Monitoring Auto-Generation
  103. 103. Monitoring Auto-GenerationNew hosts automatically receive: Nagios service + host checks custom to services running Munin plugins configured for services/network interfaces
  104. 104. Monitoring Auto-GenerationNew hosts automatically receive: Nagios service + host checks custom to services running Munin plugins configured for services/network interfacesRemoved hosts automatically: Delete all Munin/Nagios checks to clean-up
  105. 105. Monitoring Auto-GenerationNew hosts automatically receive: Nagios service + host checks custom to services running Munin plugins configured for services/network interfacesRemoved hosts automatically: Delete all Munin/Nagios checks to clean-up Automagicness!
  106. 106. Other Cool DevOpsy Stuff...
  107. 107. Other Cool DevOpsy Stuff...“The Foreman”: http://theforeman.org Web interface for managing/interacting w/ Puppet hosts Provision servers with Kickstart, Jumpstart and Preseed
  108. 108. Other Cool DevOpsy Stuff...“The Foreman”: http://theforeman.org Web interface for managing/interacting w/ Puppet hosts Provision servers with Kickstart, Jumpstart and Preseed“Rundeck”: http://rundeck.org/ Distributed command execution via SSH w/ workflows Role-based authentication w/ AD & LDAP support
  109. 109. Other Cool DevOpsy Stuff...“The Foreman”: http://theforeman.org Web interface for managing/interacting w/ Puppet hosts Provision servers with Kickstart, Jumpstart and Preseed“Rundeck”: http://rundeck.org/ Distributed command execution via SSH w/ workflows Role-based authentication w/ AD & LDAP support“Vagrant”: http://vagrantup.com/ Automated virtual machine creation using VirtualBox Provisioning of virtual environments using Chef or Puppet
  110. 110. The Ability to be Agile...
  111. 111. The Ability to be Agile...Quickly & consistently deploy replicas of existing environments
  112. 112. The Ability to be Agile...Quickly & consistently deploy replicas of existing environmentsIdentify & revert issues in deployed infrastructure with ease
  113. 113. The Ability to be Agile...Quickly & consistently deploy replicas of existing environmentsIdentify & revert issues in deployed infrastructure with easeExecute commands in parallel to hosts within a concise scope
  114. 114. The Ability to be Agile...Quickly & consistently deploy replicas of existing environmentsIdentify & revert issues in deployed infrastructure with easeExecute commands in parallel to hosts within a concise scopeDevelop tests to ensure infrastructure is meeting needs
  115. 115. The Ability to be Agile...Quickly & consistently deploy replicas of existing environmentsIdentify & revert issues in deployed infrastructure with easeExecute commands in parallel to hosts within a concise scopeDevelop tests to ensure infrastructure is meeting needsAutomatically deploy monitoring of hosts/services easily
  116. 116. Developers vs. Operations, Redux
  117. 117. Developers vs. Operations, Redux Developers: “Hi Ops, Ruby just rolled a really important new release and we’d like to start testing it in an identical, new staging environment this week.”
  118. 118. Developers vs. Operations, Redux Developers: “Hi Ops, Ruby just rolled a really important new release and we’d like to start testing it in an identical, new staging environment this week.” Operations: “Sure! Would you prefer these hosts to be staged in EC2, Rackspace Cloud, or locally with Vagrant? Would you like us to deploy your current codebase as well?”
  119. 119. Developers vs. Operations, Redux Developers: “Hi Ops, Ruby just rolled a really important new release and we’d like to start testing it in an identical, new staging environment this week.” Operations: “Sure! Would you prefer these hosts to be staged in EC2, Rackspace Cloud, or locally with Vagrant? Would you like us to deploy your current codebase as well?” Developers: “Hi Ops, we know that you guys have 13,000 servers in five data centers on three continents, but if you could delete /etc/foobar on servers with Apache 2.2.4 only, that would be great! Oh, and in the next 30 minutes or so?”
  120. 120. Developers vs. Operations, Redux Developers: “Hi Ops, Ruby just rolled a really important new release and we’d like to start testing it in an identical, new staging environment this week.” Operations: “Sure! Would you prefer these hosts to be staged in EC2, Rackspace Cloud, or locally with Vagrant? Would you like us to deploy your current codebase as well?” Developers: “Hi Ops, we know that you guys have 13,000 servers in five data centers on three continents, but if you could delete /etc/foobar on servers with Apache 2.2.4 only, that would be great! Oh, and in the next 30 minutes or so?” Operations: “How about the next 3 minutes or so?”
  121. 121. Developers vs. Operations, Redux Developers: “Hi Ops, Ruby just rolled a really important new release and we’d like to start testing it in an identical, new staging environment this week.” Operations: “Sure! Would you prefer these hosts to be staged in EC2, Rackspace Cloud, or locally with Vagrant? Would you like us to deploy your current codebase as well?” Developers: “Hi Ops, we know that you guys have 13,000 servers in five data centers on three continents, but if you could delete /etc/foobar on servers with Apache 2.2.4 only, that would be great! Oh, and in the next 30 minutes or so?” Operations: “How about the next 3 minutes or so?”# mc-filemgr -W “apache=2.2.4” --file /etc/foobar remove
  122. 122. But it does take time & effort!
  123. 123. But it does take time & effort!Acceptance that the currentmethods have room to improve
  124. 124. But it does take time & effort!Acceptance that the currentmethods have room to improveA team commitment to openlyengage new practices + tools
  125. 125. But it does take time & effort!Acceptance that the currentmethods have room to improveA team commitment to openlyengage new practices + toolsLearning Puppet DSL or Ruby
  126. 126. But it does take time & effort!Acceptance that the currentmethods have room to improveA team commitment to openlyengage new practices + toolsLearning Puppet DSL or RubyPlanning for implementation
  127. 127. But it does take time & effort!Acceptance that the currentmethods have room to improveA team commitment to openlyengage new practices + toolsLearning Puppet DSL or RubyPlanning for implementationTime allocation to deploy newinfrastructure and test!
  128. 128. But it does take time & effort!Acceptance that the currentmethods have room to improveA team commitment to openlyengage new practices + toolsLearning Puppet DSL or RubyPlanning for implementationTime allocation to deploy newinfrastructure and test!Potential overhead costs forinfrastructure or service fees
  129. 129. Thank You! Questions? mark.stanislav@gmail.com @markstanislav http://www.uncompiled.com/ https://github.com/mstanislav/

×