Deploying distributed software services to the cloud without breaking a sweat

2,443 views
2,385 views

Published on

Deploying distributed software services to the cloud without breaking a sweat.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,443
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Deploying distributed software services to the cloud without breaking a sweat

  1. 1. # 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 me@susanpotter.netPlan: twitter: @SusanPotter github: mbbx6spp
  2. 2. # 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 me@susanpotter.netPlan: twitter: @SusanPotter github: mbbx6spp
  3. 3. # 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 me@susanpotter.netPlan: twitter: @SusanPotter github: mbbx6spp
  4. 4. # 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 me@susanpotter.netPlan: twitter: @SusanPotter github: mbbx6spp
  5. 5. # 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 me@susanpotter.netPlan: twitter: @SusanPotter github: mbbx6spp
  6. 6. Scope of Talk • Approaches
  7. 7. Scope of Talk • Approaches • Best Practices
  8. 8. Scope of Talk • Approaches • Best Practices • Pitfalls
  9. 9. Scope of Talk • Approaches • Best Practices • Pitfalls • Possibilities
  10. 10. Scope of Talk • Approaches • (not) Chef vs Puppet • Best Practices • Pitfalls • Possibilities
  11. 11. Scope of Talk • Approaches • (not) Chef vs Puppet • Best Practices • (not) Why Cloud? • Pitfalls • Possibilities
  12. 12. Scope of Talk • Approaches • (not) Chef vs Puppet • Best Practices • (not) Why Cloud? • Pitfalls • (not) Why DevOps? • Possibilities
  13. 13. Scope of Talk • Approaches • (not) Chef vs Puppet • Best Practices • (not) Why Cloud? • Pitfalls • (not) Why DevOps? • Possibilities • (not) Which Delivery Model?
  14. 14. Scope of Talk • Approaches • (not) Chef vs Puppet • Best Practices • (not) Why Cloud? • Pitfalls • (not) Why DevOps? • Possibilities • (not) Which Delivery Model? • (not) Release Management
  15. 15. Scope of Talk • Approaches • (not) Chef vs Puppet • Best Practices • (not) Why Cloud? • Pitfalls • (not) Why DevOps? • Possibilities • (not) Which Delivery Model? • (not) Release Management • (not) Monitoring
  16. 16. Cloud buzzzzz
  17. 17. Cloud: Delivery Models [1/2] Software (as a Service) Platform (as a Service) Infrastructure (as a Service)
  18. 18. Cloud: Delivery Models [1/2] Software (as a Service) Platform (as a Service) Infrastructure (as a Service)
  19. 19. Cloud: Delivery Models [1/2] Software (as a Service) Platform (as a Service) Infrastructure (as a Service)
  20. 20. Cloud: Delivery Models [1/2] Software (as a Service) Platform (as a Service) Infrastructure (as a Service)
  21. 21. Cloud: Delivery Models [2/2]
  22. 22. Cloud: Characteristics • Instant on-demand
  23. 23. Cloud: Characteristics • Instant • Virtualized on-demand performance, reliability
  24. 24. Cloud: Characteristics • Instant • Virtualized on-demand performance, reliability • Managed by others
  25. 25. Cloud: Characteristics • Instant • Virtualized on-demand performance, reliability • Managed • Lack control by others predictability, reliability, quality
  26. 26. Cloud: Characteristics • Instant • Virtualized on-demand performance, reliability • Managed • Lack control by others predictability, reliability, quality • Pay as you go
  27. 27. Cloud: Characteristics • Instant • Virtualized on-demand performance, reliability • Managed • Lack control by others predictability, reliability, quality • Pay • Pay as you go as you go!
  28. 28. DevOps Is it a command?
  29. 29. DevOps: Definition [1/2] • Share responsibility across organizational boundaries
  30. 30. DevOps: Definition [1/2] • Share responsibility across organizational boundaries • Invest in people by reducing finger pointing [togetherness] and human error [automation]
  31. 31. DevOps: Definition [1/2] • Share responsibility across organizational boundaries • Invest in people by reducing finger pointing [togetherness] and human error [automation] • Manage infrastructure not priority queues of production issues
  32. 32. DevOps: Definition [1/2] • Share responsibility across organizational boundaries • Invest in people by reducing finger pointing [togetherness] and human error [automation] • Manage infrastructure not priority queues of production issues • Make infrastructure predictable repeatable, testable, deterministic
  33. 33. DevOps: Definition [2/2]
  34. 34. Deployment Pipeline commit -> production
  35. 35. Deployment Pipeline: Prerequisites • Design for cloud e.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O
  36. 36. Deployment Pipeline: Prerequisites • Design for cloud e.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O • Always-ready codebase buildable, testable, deployable
  37. 37. Deployment Pipeline: Prerequisites • Design for cloud e.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O • Always-ready codebase buildable, testable, deployable • Managed infrastructure read: SCM and consistent distribution to target nodes
  38. 38. Deployment Pipeline: Prerequisites • Design for cloud e.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O • Always-ready codebase buildable, testable, deployable • Managed infrastructure read: SCM and consistent distribution to target nodes • Expect [system] failure handle failures sensibly, policies for timeouts, etc
  39. 39. Deployment Pipeline: Prerequisites • Design for cloud e.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O • Always-ready codebase buildable, testable, deployable • Managed infrastructure read: SCM and consistent distribution to target nodes • Expect [system] failure handle failures sensibly, policies for timeouts, etc • Test early and often! outside-in development helps
  40. 40. Deployment Pipeline: Prerequisites • Design for cloud e.g. decentralized, layered, parallelized, collaborating single purpose services, async I/O • Always-ready codebase buildable, testable, deployable • Managed infrastructure read: SCM and consistent distribution to target nodes • Expect [system] failure handle failures sensibly, policies for timeouts, etc • Test early and often! outside-in development helps • Build from the ground up layer infrastructure, inject configuration at boot/load time
  41. 41. Deployment: Common Bottlenecks • Automation build, provision, configure, integrate Figure: http://www.flickr.com/people/laenulfean/
  42. 42. Deployment: Common Bottlenecks • Automation build, provision, configure, integrate • Distribution binaries, assets, configuration Figure: http://www.flickr.com/people/laenulfean/
  43. 43. Deployment: Common Bottlenecks • Automation build, provision, configure, integrate • Distribution binaries, assets, configuration • Timeframe restricted window of time Figure: http://www.flickr.com/people/laenulfean/
  44. 44. Deployment: Common Bottlenecks • Automation build, provision, configure, integrate • Distribution binaries, assets, configuration • Timeframe restricted window of time • Data schema updates, data migrations Figure: http://www.flickr.com/people/laenulfean/
  45. 45. Solution Approaches Solve problems, don’t use tools!
  46. 46. Automation Approaches • Full stack server-driven e.g. Chef/Knife, Puppet Master Figure: http://www.flickr.com/people/krazydad/
  47. 47. Automation Approaches • Full stack server-driven e.g. Chef/Knife, Puppet Master • Full stack client e.g. Chef Solo Figure: http://www.flickr.com/people/krazydad/
  48. 48. Automation Approaches • Full stack server-driven e.g. Chef/Knife, Puppet Master • Full stack client e.g. Chef Solo • Application-tier client e.g. Capistrano, Vlad the Deployer Figure: http://www.flickr.com/people/krazydad/
  49. 49. Automation Approaches • Full stack server-driven e.g. Chef/Knife, Puppet Master • Full stack client e.g. Chef Solo • Application-tier client e.g. Capistrano, Vlad the Deployer • Command & control e.g. Vertibrae (inactive), Nanite Figure: http://www.flickr.com/people/krazydad/
  50. 50. Distribution Approaches • Shared filesystem less security and reliability in community/public or across zones/regions Figure: http://www.flickr.com/people/nsalt
  51. 51. Distribution Approaches • Shared filesystem less security and reliability in community/public or across zones/regions • Pull from source control higher time variance as target nodes increase Figure: http://www.flickr.com/people/nsalt
  52. 52. Distribution Approaches • Shared filesystem less security and reliability in community/public or across zones/regions • Pull from source control higher time variance as target nodes increase • Bittorrent or similar e.g. Twitter’s Murder Figure: http://www.flickr.com/people/nsalt
  53. 53. Timeframe Approaches • Hot upgrades e.g. Erlang/OTP appup/code_change/3Figure: http://www.flickr.com/people/athenicsword
  54. 54. Timeframe Approaches • Hot upgrades e.g. Erlang/OTP appup/code_change/3 • Rolling upgrades Software design considerationsFigure: http://www.flickr.com/people/athenicsword
  55. 55. Timeframe Approaches • Hot upgrades e.g. Erlang/OTP appup/code_change/3 • Rolling upgrades Software design considerations • Environment replacement Flip a switch, acceptance <-> productionFigure: http://www.flickr.com/people/athenicsword
  56. 56. Data Approaches • Scriptable schema Alternative: NoSQL, but. . .Figure: http://www.flickr.com/people/shanghaidaddy
  57. 57. Data Approaches • Scriptable schema Alternative: NoSQL, but. . . • Automated migrations e.g. Rails’ MigrationsFigure: http://www.flickr.com/people/shanghaidaddy
  58. 58. Data Approaches • Scriptable schema Alternative: NoSQL, but. . . • Automated migrations e.g. Rails’ Migrations • Sanity checks e.g. cherry picked, consistency checksFigure: http://www.flickr.com/people/shanghaidaddy
  59. 59. Common Pitfalls & Workarounds
  60. 60. Organizational Culture Figure: http://www.flickr.com/people/lucgaloppin/
  61. 61. Organizational Culture [Workaround] Figure: http://www.flickr.com/photos/42682395@N04/
  62. 62. Feature Branching Figure: http://www.flickr.com/photos/33939293@N02/
  63. 63. Feature Branching [Workaround]
  64. 64. Feature Branching [Workaround] DON’T!
  65. 65. Live by the meter.Die by the meter. Figure: WARNING
  66. 66. Live by the meter.Die by the meter. [Workarounds] Figure: http://www.flickr.com/people/dirkjankraan/
  67. 67. Great Expectations Figure: http://www.flickr.com/people/atoxinsocks/
  68. 68. Great Expectations [Workaround] Figure: http://www.flickr.com/people/dirkjankraan/
  69. 69. Note: Design & Idempotency Figure: A Twitter dialog between me and @jlouis666
  70. 70. Possibilities Where.next?
  71. 71. Possibilities
  72. 72. Possibilities • Dynamic resource allocation allocate based on load, time of day, day of week/month
  73. 73. Possibilities • Dynamic resource allocation allocate based on load, time of day, day of week/month • Canary deployments (e.g. A/B testing)
  74. 74. Possibilities • Dynamic resource allocation allocate based on load, time of day, day of week/month • Canary deployments (e.g. A/B testing) • Multi-region or multi-provider relocate based on time of day, failover
  75. 75. Questions? Figure: http://www.flickr.com/photos/42682395@N04/
  76. 76. Questions? Figure: http://www.flickr.com/photos/42682395@N04/ @SusanPotter

×