LNCD and The Cloud

LNCD and The Cloud

C7f3b4756d808ef0e2548bd0965ac225?s=128

Nick Jackson

July 05, 2012
Tweet

Transcript

  1. 3.

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

    Supporting Staff, Students and Academics • Few Members, Other Responsibilities
  2. 4.

    A FEW PROBLEMS • Cross Department = Distributed • R&D

    = Unsupported • Wide Remit = Need Scalability • Small Team = Large Workload
  3. 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.
  4. 7.

    A FEW OF OUR FAVOURITES • Twitter • Campfire •

    Dropbox • Pivotal Tracker • Jenkins • Puppet • Google Analytics • New Relic • Pingdom
  5. 9.
  6. 11.
  7. 12.
  8. 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
  9. 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
  10. 16.
  11. 17.
  12. 18.
  13. 19.
  14. 22.
  15. 23.
  16. 24.
  17. 26.
  18. 27.
  19. 28.
  20. 29.
  21. 30.
  22. 32.
  23. 33.
  24. 34.
  25. 35.
  26. 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
  27. 39.
  28. 40.
  29. 41.
  30. 42.
  31. 43.
  32. 44.
  33. 45.

    ‣ build servers ‣ install dependencies ‣ configure environment ‣

    configure services ‣ configure firewall ‣ configure infrastructure ‣ move code to servers ‣ run acceptance tests ‣ update routing
  34. 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.
  35. 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.
  36. 52.

    w c d d d c w w w server

    manifest (cache server) server manifest (web server) server manifest (database server)
  37. 53.
  38. 54.
  39. 55.
  40. 56.
  41. 57.
  42. 58.
  43. 59.
  44. 60.
  45. 61.
  46. 63.
  47. 64.
  48. 65.
  49. 66.
  50. 67.
  51. 68.
  52. 70.
  53. 71.
  54. 72.
  55. 73.
  56. 74.
  57. 76.
  58. 77.
  59. 78.
  60. 82.
  61. 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
  62. 84.

    WE USE... • Rackspace Cloud UK • Replicate ‘classic’ servers

    in the cloud • Servers, file storage, DNS, load balancing
  63. 85.

    EVEN CLOUDIER... • Pagoda Box or Heroku • Totally abstracted

    hosting • Focus on development, ignore infrastructure • Scale on demand with zero downtime
  64. 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
  65. 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
  66. 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
  67. 89.
  68. 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
  69. 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
  70. 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?)
  71. 93.

    INTEGRATE INTERNALLY • Forces you to build better APIs •

    Lets you spot bottlenecks before the public • Encourages scaleable and portable stuff by default
  72. 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