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.

PuppetConf 2016: Successful Puppet Implementation in Large Organizations – James Sweeny, Puppet

387 views

Published on

Here are the slides from James Sweeny's PuppetConf 2016 presentation called Successful Puppet Implementation in Large Organizations. Watch the videos at https://www.youtube.com/playlist?list=PLV86BgbREluVjwwt-9UL8u2Uy8xnzpIqa

Published in: Technology
  • Be the first to comment

PuppetConf 2016: Successful Puppet Implementation in Large Organizations – James Sweeny, Puppet

  1. 1. Successful Puppet Implementation in Large Organizations James Sweeny Puppet, Inc.
  2. 2. You will hear me blather about: DevOps and Puppet Large vs. Small/Medium Orgs Deployment Strategies Common Roadblocks and Pitfalls
  3. 3. Who am I?
  4. 4. This talk is not about… ●  Scaling Puppet ●  High Availability ●  Monitoring ●  Security
  5. 5. Section ## (if desired) and/or Subtitle
  6. 6. Leading platform. Datacenter standard. Experience Founded in 2005 Scale More than 10 million nodes managed Ecosystem Deep partnerships with datacenter titans Customers 1,000+ enterprise customers Community 4,200+ community-contributed modules Users 30,000+ organizations using Puppet Backing
  7. 7. DevOps - CAMS ●  Culture ●  Automation ●  Measurement ●  Sharing
  8. 8. How most companies see it ●  Culture ● Automation ●  Measurement ●  Sharing
  9. 9. How they should see it ●  Culture ●  Automation ●  Measurement ●  Sharing
  10. 10. Puppet is (just) a tool.
  11. 11. Puppet doesn’t… ●  Do everything ●  Fix broken culture ●  Shuffle the org chart ●  Train your staff ●  Get you out of an abusive MSP relationship
  12. 12. But it can… ●  Help you to understand your own systems ●  Provide a focal point and a Lingua Franca ●  Save time and open new opportunities ●  Act as a force multiplier for velocity, consistency, and reliability
  13. 13. Puppet code is state!
  14. 14. Infrastructure as Code ●  Puppet code describes the entire system (or everything you care about) ●  The code is the system ●  Changing the code is the same as changing the server ●  Designing, provisioning, changing all rolled into one
  15. 15. What is a “Large” Organization?
  16. 16. Large Organizations… ●  Complex org chart ●  Separation of concerns ●  Many teams ●  Many distinct business functions ●  Headcount, not node count
  17. 17. Naïve Deployment Example
  18. 18. Server Application In house software, provides business value
  19. 19. Server Middleware Apache, IIS, Oracle, etc.
  20. 20. Server Management Netbackup, SEP, Nagios agents, etc.
  21. 21. Server OS Windows, Linux, Solaris, etc.
  22. 22. Server in a small company OS Management Middleware Application Developer(s) Operations/IT
  23. 23. Developer(s) Operations/IT
  24. 24. DevOps! OS Management Middleware Application Developer(s) Operations/IT
  25. 25. Problem in Large Organizations ●  Many “development” teams ●  “Operations/IT” is highly fractured ●  Many overlay teams
  26. 26. App teams Release team Middleware Windows Security Linux
  27. 27. … But it’s usually worse ●  Multiple variants of each team ●  Windows/Linux/Solaris/AIX… ●  Secure vs. Non-secure ●  Different team for each Management product ●  Overlays for compliance, security, governance… ●  Changing ownership depending on lifecycle stages
  28. 28. Crazy Org Charts ●  CIO ●  SVP Engineering —  Middleware —  Windows Engineering —  Unix Engineering —  Backup Team —  Monitoring Team ●  SVP Application Engineering —  Hundreds of app teams —  Release Engineering ●  SVP Security and Compliance ●  …
  29. 29. Journey, not a sprint
  30. 30. So what *does* work? (Reduce the problem domain)
  31. 31. Start small, shallow, and wide Option #1
  32. 32. Shallow and Wide OS Management Middleware Application OS Management Middleware Application OS Management Middleware Application Single Team Unmanaged
  33. 33. Shallow and Wide ●  Start with one existing team (usually the one with root/Administrator) ●  Do minimal work ●  Get comfortable with Puppet and version control ●  Don’t boil the ocean
  34. 34. Shallow and Wide (evolution) ●  Add new teams as responsibilities expand ●  Share code repository ●  Central module repository ●  Slowly work up the stack
  35. 35. Platform as a Service Option #2
  36. 36. Platform as a Service OS Management Middleware Application OS Management Middleware Application OS Management Middleware Application Single Team Unmanaged (Legacy)
  37. 37. Platform as a Service ●  Puppet is hidden from customers (App/ Dev teams) ●  Limited, but complete stacks provided ●  Likely need to build/use an additional interface ●  Exceptions to normal policies
  38. 38. Platform as a Service (evolution) ●  Accept Puppet code contributions from other teams ●  Add additional Middleware and OS platforms ●  Decommission/migrate legacy servers
  39. 39. Which is right for us?
  40. 40. Shallow and Wide ●  Most successful real-world ●  Most flexible early on ●  Easiest way to learn your org ●  Gives time to evolve ●  Business value not as easily apparent
  41. 41. PaaS ●  Single team can own and slowly grow ●  Very high upfront cost ●  Quick wins for new applications ●  Side-by-side with legacy for longer (or forever) ●  No benefit to legacy fleet
  42. 42. Other Options
  43. 43. Hybrid Approaches ●  Grant limited Hiera exposure ●  Mix of Options 1 & 2 ●  Puppet as a Service ●  Multiple agents
  44. 44. The “Puppet Team”
  45. 45. “Puppet Team” ●  Over time, role becomes advisory ●  Own the initial workflow, Puppet infrastructure, supporting services ●  Become Puppet SMEs
  46. 46. Who is the “Puppet Team” ●  Technical experts on your existing systems ●  Can cut red tape ●  Have root/Admin already ●  Eager to learn, excited to solve problems ●  Dedicated to big picture success
  47. 47. Likely Roadblocks
  48. 48. “That’s not how we do it” The internal “standard”
  49. 49. Battling “That’s not how we do it” ●  Prefer Industry standards to esoteric ones ●  Software owners must articulate reasoning ●  Make your case to “SMEs” ●  Use political pressure as a last resort
  50. 50. Plan, Build, Run Probably the reason everything is awful
  51. 51. Plan, Build, Run ●  Diffusion of responsibility ●  Conflicting sources of truth ●  Destroys feedback loops ●  Massively slows change ●  Puppet makes it obsolete
  52. 52. Politics
  53. 53. Politics ●  Have well connected people committed to Puppet ●  Need strong management ●  Understand other groups needs ●  Be willing to prove real value before winning other groups ●  “Puppet won’t steal your job”
  54. 54. Final Advice
  55. 55. More tips ●  Learn/know your own systems ●  Always question internal dogma ●  Limit scope, standardize, leave things out ●  Think “shift left” ●  Don’t overbuild!
  56. 56. Must See Presentations ●  Charlie Sharpsteen on performance tuning, 1:30PM Terrace Salon ●  Martin Jackson on collaboration culture, 11:15AM Friday, Grand Hall ●  Russ Mull and Zack Smith on Puppet HA, 2:30PM Friday, California room ●  Multi-tenant station in the Exhibit Hall

×