distributed software services to the cloud without breaking a sweat
DESCRIPTION
More at http://www.codepalousa.comDeploying Software Services in the Cloud!TRANSCRIPT
# finger $(whoami)Login: susan Name: Susan PotterDirectory: /home/susan Shell: /bin/zshOn since Mon 29 Sep 1997 21:18 (GMT) on tty1 from :0No mail on [email protected]:twitter: @SusanPottergithub: mbbx6spp
# finger $(whoami)Login: susan Name: Susan PotterDirectory: /home/susan Shell: /bin/zshOn since Mon 29 Sep 1997 21:18 (GMT) on tty1 from :0No mail on [email protected]:twitter: @SusanPottergithub: mbbx6spp
# finger $(whoami)Login: susan Name: Susan PotterDirectory: /home/susan Shell: /bin/zshOn since Mon 29 Sep 1997 21:18 (GMT) on tty1 from :0No mail on [email protected]:twitter: @SusanPottergithub: mbbx6spp
# finger $(whoami)Login: susan Name: Susan PotterDirectory: /home/susan Shell: /bin/zshOn since Mon 29 Sep 1997 21:18 (GMT) on tty1 from :0No mail on [email protected]:twitter: @SusanPottergithub: mbbx6spp
# finger $(whoami)Login: susan Name: Susan PotterDirectory: /home/susan Shell: /bin/zshOn since Mon 29 Sep 1997 21:18 (GMT) on tty1 from :0No mail on [email protected]:twitter: @SusanPottergithub: mbbx6spp
Scope of Talk
• Approaches
• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices
• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls
• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet
• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?
• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?
• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?
• (not) Release Management• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management
• (not) Monitoring
Scope of Talk
• Approaches• Best Practices• Pitfalls• Possibilities
• (not) Chef vs Puppet• (not) Why Cloud?• (not) Why DevOps?• (not) Which Delivery Model?• (not) Release Management• (not) Monitoring
Cloud
buzzzzz
Cloud: Delivery Models [1/2]
Software(as a Service)
Platform(as a Service)
Infrastructure(as a Service)
Cloud: Delivery Models [1/2]
Software(as a Service)
Platform(as a Service)
Infrastructure(as a Service)
Cloud: Delivery Models [1/2]
Software(as a Service)
Platform(as a Service)
Infrastructure(as a Service)
Cloud: Delivery Models [1/2]
Software(as a Service)
Platform(as a Service)
Infrastructure(as a Service)
Cloud: Delivery Models [2/2]
Cloud: Characteristics
• Instanton-demand
• Managedby others
• Payas you go
• Virtualizedperformance, reliability
• Lack controlpredictability, reliability, quality
• Payas you go!
Cloud: Characteristics
• Instanton-demand
• Managedby others
• Payas you go
• Virtualizedperformance, reliability
• Lack controlpredictability, reliability, quality
• Payas you go!
Cloud: Characteristics
• Instanton-demand
• Managedby others
• Payas you go
• Virtualizedperformance, reliability
• Lack controlpredictability, reliability, quality
• Payas you go!
Cloud: Characteristics
• Instanton-demand
• Managedby others
• Payas you go
• Virtualizedperformance, reliability
• Lack controlpredictability, reliability, quality
• Payas you go!
Cloud: Characteristics
• Instanton-demand
• Managedby others
• Payas you go
• Virtualizedperformance, reliability
• Lack controlpredictability, reliability, quality
• Payas you go!
Cloud: Characteristics
• Instanton-demand
• Managedby others
• Payas you go
• Virtualizedperformance, reliability
• Lack controlpredictability, reliability, quality
• Payas you go!
DevOps
Is it a command?
DevOps: Definition [1/2]
• Share responsibilityacross organizational boundaries
• Invest in peopleby reducing finger pointing [togetherness] and human error [automation]
• Manage infrastructurenot priority queues of production issues
• Make infrastructure predictablerepeatable, testable, deterministic
DevOps: Definition [1/2]
• Share responsibilityacross organizational boundaries
• Invest in peopleby reducing finger pointing [togetherness] and human error [automation]
• Manage infrastructurenot priority queues of production issues
• Make infrastructure predictablerepeatable, testable, deterministic
DevOps: Definition [1/2]
• Share responsibilityacross organizational boundaries
• Invest in peopleby reducing finger pointing [togetherness] and human error [automation]
• Manage infrastructurenot priority queues of production issues
• Make infrastructure predictablerepeatable, testable, deterministic
DevOps: Definition [1/2]
• Share responsibilityacross organizational boundaries
• Invest in peopleby reducing finger pointing [togetherness] and human error [automation]
• Manage infrastructurenot priority queues of production issues
• Make infrastructure predictablerepeatable, testable, deterministic
DevOps: Definition [2/2]
Deployment Pipeline
commit -> production
Deployment Pipeline: Prerequisites
• Design for cloude.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
• Always-ready codebasebuildable, testable, deployable
• Managed infrastructureread: SCM and consistent distribution to target nodes
• Expect [system] failurehandle failures sensibly, policies for timeouts, etc
• Test early and often!outside-in development helps
• Build from the ground uplayer infrastructure, inject configuration at boot/load time
Deployment Pipeline: Prerequisites
• Design for cloude.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
• Always-ready codebasebuildable, testable, deployable
• Managed infrastructureread: SCM and consistent distribution to target nodes
• Expect [system] failurehandle failures sensibly, policies for timeouts, etc
• Test early and often!outside-in development helps
• Build from the ground uplayer infrastructure, inject configuration at boot/load time
Deployment Pipeline: Prerequisites
• Design for cloude.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
• Always-ready codebasebuildable, testable, deployable
• Managed infrastructureread: SCM and consistent distribution to target nodes
• Expect [system] failurehandle failures sensibly, policies for timeouts, etc
• Test early and often!outside-in development helps
• Build from the ground uplayer infrastructure, inject configuration at boot/load time
Deployment Pipeline: Prerequisites
• Design for cloude.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
• Always-ready codebasebuildable, testable, deployable
• Managed infrastructureread: SCM and consistent distribution to target nodes
• Expect [system] failurehandle failures sensibly, policies for timeouts, etc
• Test early and often!outside-in development helps
• Build from the ground uplayer infrastructure, inject configuration at boot/load time
Deployment Pipeline: Prerequisites
• Design for cloude.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
• Always-ready codebasebuildable, testable, deployable
• Managed infrastructureread: SCM and consistent distribution to target nodes
• Expect [system] failurehandle failures sensibly, policies for timeouts, etc
• Test early and often!outside-in development helps
• Build from the ground uplayer infrastructure, inject configuration at boot/load time
Deployment Pipeline: Prerequisites
• Design for cloude.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
• Always-ready codebasebuildable, testable, deployable
• Managed infrastructureread: SCM and consistent distribution to target nodes
• Expect [system] failurehandle failures sensibly, policies for timeouts, etc
• Test early and often!outside-in development helps
• Build from the ground uplayer infrastructure, inject configuration at boot/load time
Deployment: Common Bottlenecks
• Automationbuild, provision, configure, integrate
• Distributionbinaries, assets, configuration
• Timeframerestricted window of time
• Dataschema updates, data migrations
Figure: http://www.flickr.com/people/laenulfean/
Deployment: Common Bottlenecks
• Automationbuild, provision, configure, integrate
• Distributionbinaries, assets, configuration
• Timeframerestricted window of time
• Dataschema updates, data migrations
Figure: http://www.flickr.com/people/laenulfean/
Deployment: Common Bottlenecks
• Automationbuild, provision, configure, integrate
• Distributionbinaries, assets, configuration
• Timeframerestricted window of time
• Dataschema updates, data migrations
Figure: http://www.flickr.com/people/laenulfean/
Deployment: Common Bottlenecks
• Automationbuild, provision, configure, integrate
• Distributionbinaries, assets, configuration
• Timeframerestricted window of time
• Dataschema updates, data migrations
Figure: http://www.flickr.com/people/laenulfean/
Solution Approaches
Solve problems,don’t use tools!
Automation Approaches
Figure: http://www.flickr.com/people/krazydad/
• Full stack server-drivene.g. Chef/Knife, Puppet Master
• Full stack cliente.g. Chef Solo
• Application-tier cliente.g. Capistrano, Vlad the Deployer
• Command & controle.g. Vertibrae (inactive), Nanite
Automation Approaches
Figure: http://www.flickr.com/people/krazydad/
• Full stack server-drivene.g. Chef/Knife, Puppet Master
• Full stack cliente.g. Chef Solo
• Application-tier cliente.g. Capistrano, Vlad the Deployer
• Command & controle.g. Vertibrae (inactive), Nanite
Automation Approaches
Figure: http://www.flickr.com/people/krazydad/
• Full stack server-drivene.g. Chef/Knife, Puppet Master
• Full stack cliente.g. Chef Solo
• Application-tier cliente.g. Capistrano, Vlad the Deployer
• Command & controle.g. Vertibrae (inactive), Nanite
Automation Approaches
Figure: http://www.flickr.com/people/krazydad/
• Full stack server-drivene.g. Chef/Knife, Puppet Master
• Full stack cliente.g. Chef Solo
• Application-tier cliente.g. Capistrano, Vlad the Deployer
• Command & controle.g. Vertibrae (inactive), Nanite
Distribution Approaches
Figure: http://www.flickr.com/people/nsalt
• Shared filesystemless security and reliability in community/public or across
zones/regions
• Pull from source controlhigher time variance as target nodes increase
• Bittorrent or similare.g. Twitter’s Murder
Distribution Approaches
Figure: http://www.flickr.com/people/nsalt
• Shared filesystemless security and reliability in community/public or across
zones/regions
• Pull from source controlhigher time variance as target nodes increase
• Bittorrent or similare.g. Twitter’s Murder
Distribution Approaches
Figure: http://www.flickr.com/people/nsalt
• Shared filesystemless security and reliability in community/public or across
zones/regions
• Pull from source controlhigher time variance as target nodes increase
• Bittorrent or similare.g. Twitter’s Murder
Timeframe Approaches
Figure: http://www.flickr.com/people/athenicsword
• Hot upgradese.g. Erlang/OTP appup/code_change/3
• Rolling upgradesSoftware design considerations
• Environment replacementFlip a switch, acceptance <-> production
Timeframe Approaches
Figure: http://www.flickr.com/people/athenicsword
• Hot upgradese.g. Erlang/OTP appup/code_change/3
• Rolling upgradesSoftware design considerations
• Environment replacementFlip a switch, acceptance <-> production
Timeframe Approaches
Figure: http://www.flickr.com/people/athenicsword
• Hot upgradese.g. Erlang/OTP appup/code_change/3
• Rolling upgradesSoftware design considerations
• Environment replacementFlip a switch, acceptance <-> production
Data Approaches
Figure: http://www.flickr.com/people/shanghaidaddy
• Scriptable schemaAlternative: NoSQL, but. . .
• Automated migrationse.g. Rails’ Migrations
• Sanity checkse.g. cherry picked, consistency checks
Data Approaches
Figure: http://www.flickr.com/people/shanghaidaddy
• Scriptable schemaAlternative: NoSQL, but. . .
• Automated migrationse.g. Rails’ Migrations
• Sanity checkse.g. cherry picked, consistency checks
Data Approaches
Figure: http://www.flickr.com/people/shanghaidaddy
• Scriptable schemaAlternative: NoSQL, but. . .
• Automated migrationse.g. Rails’ Migrations
• Sanity checkse.g. cherry picked, consistency checks
Common Pitfalls & Workarounds
Organizational Culture
Figure: http://www.flickr.com/people/lucgaloppin/
Organizational Culture [Workaround]
Figure: http://www.flickr.com/photos/42682395@N04/
Feature Branching
Figure: http://www.flickr.com/photos/33939293@N02/
Feature Branching [Workaround]
DON’T!
Feature Branching [Workaround]
DON’T!
Live by the meter.Die by the meter.
Figure: WARNING
Live by the meter.Die by the meter. [Workarounds]
Figure: http://www.flickr.com/people/dirkjankraan/
Great Expectations
Figure: http://www.flickr.com/people/atoxinsocks/
Great Expectations [Workaround]
Figure: http://www.flickr.com/people/dirkjankraan/
Note: Design & Idempotency
Figure: A Twitter dialog between me and @jlouis666
Possibilities
Where.next?
Possibilities
• Dynamic resource allocationallocate based on load, time of day, day of week/month
• Canary deployments(e.g. A/B testing)
• Multi-region or multi-providerrelocate based on time of day, failover
Possibilities
• Dynamic resource allocationallocate based on load, time of day, day of week/month
• Canary deployments(e.g. A/B testing)
• Multi-region or multi-providerrelocate based on time of day, failover
Possibilities
• Dynamic resource allocationallocate based on load, time of day, day of week/month
• Canary deployments(e.g. A/B testing)
• Multi-region or multi-providerrelocate based on time of day, failover
Possibilities
• Dynamic resource allocationallocate based on load, time of day, day of week/month
• Canary deployments(e.g. A/B testing)
• Multi-region or multi-providerrelocate based on time of day, failover
Questions?
Figure: http://www.flickr.com/photos/42682395@N04/
@SusanPotter
Questions?
Figure: http://www.flickr.com/photos/42682395@N04/
@SusanPotter