LNCD and The Cloud

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
10. TWITTER Public chatter, engagement and arranging lunch.
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.
19. SHARE
20. Share files and code. Share planning.
21. DROPBOX File sharing, synchronisation.
25. GITHUB Code sharing, issue tracking
31. PIVOTAL TRACKER Task management and workflow planning.
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.
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)
61. ANALYSE
62. GOOGLE ANALYTICS User behaviour and goal conversion.
69. NEW RELIC Application and server performance.
75. PINGDOM Uptime monitoring and alerting.
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