Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LNCD and The Cloud

LNCD and The Cloud

C7f3b4756d808ef0e2548bd0965ac225?s=128

Nick Jackson

July 05, 2012
Tweet

More Decks by Nick Jackson

Other Decks in Technology

Transcript

  1. LNCD Making life easy with cloud services

  2. NICK JACKSON @jacksonj04 http://lncn.eu/me/nijackson

  3. ABOUT LNCD • Cross-Department Team • Research & Development •

    Supporting Staff, Students and Academics • Few Members, Other Responsibilities
  4. A FEW PROBLEMS • Cross Department = Distributed • R&D

    = Unsupported • Wide Remit = Need Scalability • Small Team = Large Workload
  5. AWESOME FORCE Six developers (not all full-time) are actively working

    on 10 major projects, a similar number of side-projects, side-interests around the University, maintaining servers and infrastructure for those projects and supporting and teaching others. With time to spare.
  6. THE SOLUTION • Communicate • Share • Analyse • Automate

    • Iterate • Integrate
  7. A FEW OF OUR FAVOURITES • Twitter • Campfire •

    Dropbox • Pivotal Tracker • Jenkins • Puppet • Google Analytics • New Relic • Pingdom
  8. COMMUNICATE

  9. None
  10. TWITTER Public chatter, engagement and arranging lunch.

  11. None
  12. None
  13. USERS ARE OUT THERE • A phone number isn’t enough

    • An email address isn’t enough • Get on Facebook • Get on Twitter • Google yourself
  14. COMPANIES ARE OUT THERE • Competitors (and potential partners) are

    online too • Mention something cool on Twitter, see who responds • Listen for something cool on Twitter and respond
  15. CAMPFIRE Internal chatter, status updates and remote control.

  16. None
  17. None
  18. None
  19. SHARE

  20. Share files and code. Share planning.

  21. DROPBOX File sharing, synchronisation.

  22. None
  23. None
  24. None
  25. GITHUB Code sharing, issue tracking

  26. None
  27. None
  28. None
  29. None
  30. None
  31. PIVOTAL TRACKER Task management and workflow planning.

  32. None
  33. None
  34. None
  35. AUTOMATE

  36. http://lncn.eu/qsz7

  37. ‣ run lint ‣ run lines of code analysis ‣

    run dependency analysis ‣ run mess detector ‣ run code style analysis ‣ run copy/paste detection ‣ generate code api documentation ‣ perform token replacement ‣ run unit testing ‣ generate browsable code ‣ generate violation reports ‣ generate code statistics report ‣ bundle for distribution
  38. JENKINS Testing, documentation and QA.

  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. ‣ build servers ‣ install dependencies ‣ configure environment ‣

    configure services ‣ configure firewall ‣ configure infrastructure ‣ move code to servers ‣ run acceptance tests ‣ update routing
  46. PUPPET Configuration management and deployment.

  47. IN THE OLD DAYS... 1. Download server X, version Y.

    2. Install packages Foo, Bar, Bar-Dev and Bazbox-1.2. 3. Edit FooConfig.conf and change line 27 to a haiku on the futility of life. 4. Reboot.
  48. IN THE OLD DAYS... 374. Realise you installed Qux-Utils-1.05 not

    Qux-Utils-1.05b. 375. Reboot. Again. 376. If you used the hotfix in step 182, jump to step 407. If not, recompile --with-dribbly-candle. Virgin sacrifice may be necessary if you don’t have DribbleLib already installed. 377. Give up.
  49. permissions users files packages firewall config keys & certificates environment

    vars git repositories
  50. server manifest (cache server)

  51. server manifest (cache server) server manifest (web server) server manifest

    (database server) w c d
  52. w c d d d c w w w server

    manifest (cache server) server manifest (web server) server manifest (database server)
  53. None
  54. None
  55. None
  56. None
  57. None
  58. None
  59. None
  60. None
  61. ANALYSE

  62. GOOGLE ANALYTICS User behaviour and goal conversion.

  63. None
  64. None
  65. None
  66. None
  67. None
  68. None
  69. NEW RELIC Application and server performance.

  70. None
  71. None
  72. None
  73. None
  74. None
  75. PINGDOM Uptime monitoring and alerting.

  76. None
  77. None
  78. None
  79. DIY METRICS If you can find something to measure, measure

    it
  80. •Downloads of files •Number of users •Sign-up rates •‘Last run’

    times
  81. DISPLAY IT If you can’t see it, you don’t know

    it
  82. SCALE

  83. CLOUD HOSTING • Creating new servers is easy (we’ve partially

    automated it) • Configuring servers is now easy (hooray for Puppet) • Deployment is easy (hooray for Jenkins) • We can scale to match real-time demand
  84. WE USE... • Rackspace Cloud UK • Replicate ‘classic’ servers

    in the cloud • Servers, file storage, DNS, load balancing
  85. EVEN CLOUDIER... • Pagoda Box or Heroku • Totally abstracted

    hosting • Focus on development, ignore infrastructure • Scale on demand with zero downtime
  86. MOVING ON... • Building in-house cloud platform using OpenStack •

    Runs on commodity hardware, not ‘enterprise-grade’ • Provides ‘application’ bundles that can be easily reused
  87. CLOUD: THE BENEFITS • Potential cost saving through reduced overspend

    • Ability to adapt quickly • Can make disaster recovery very easy • Potential for improved resiliency (platform dependent) • Possible integration with existing infrastructure
  88. CLOUD: THE DOWNSIDE • Can be ultimately more expensive (especially

    external) • A certain element of mystery (depending on platform) • Tendency to build processes around provider • Horrible (but not insurmountable) data protection aspects
  89. INTEGRATE

  90. IT’S AN OPEN WORLD, DEAL WITH IT • If your

    software can’t integrate, it’s a second class citizen • Design with this in mind • Find and engage with people (remember Communicate?) • Doesn’t stop you having value, just moves where it is
  91. BUILD APIS • APIs let your application talk to things

    • APIs mean you can re-use functionality easily • APIs mean 3rd parties use your product as a platform
  92. BUILD CLEVER APIS • Use tools at your disposal (remember

    Analyse?) to see inside • Use sensible exchange formats • Be RESTful — make your API behave as expected • Document it all (remember Automate?)
  93. INTEGRATE INTERNALLY • Forces you to build better APIs •

    Lets you spot bottlenecks before the public • Encourages scaleable and portable stuff by default
  94. INTEGRATE EXTERNALLY • Why waste effort building something yourself? •

    Hook in to external services so they do the hard work • Find people (remember Connect?) and get in touch
  95. IN SUMMARY....

  96. http://lncd.org/tools