Rethinking system design
•Download as PPTX, PDF•
0 likes•99 views
Rethinking system design - Reviews different patterns for system architecture and provides examples using the ELMSLN initiative. - The ELMSLN is a series of networked Drupal sites per course that are built on demand and kept manageable through automation and DevOps. - There is a push to move away from monolithic learning management systems towards more flexible, distributed models that better match the needs of individual organizations.
Report
Share
Rethinking system design
- 1. Rethinking system design elmsln.org @btopro Come get a sticker like this one In dribs and drabs we will change the world
- 2. Project Lead ELMS Initiative Instructional Systems Architect E-Learning Institute College of Arts & Architecture Penn State University @btopro (aka Bryan Ollendyke)
- 3. Rethinking system architecture • Review different patterns • Examples through ELMS: LN • This doesn’t place blame, these are just different examples
- 5. ELMSLN is a series of networked Drupal sites per course. Automation / DevOps keep the process manageable New fully configured Drupal-based RESTful networks are built on demand. Networks are formed of Services (per course) and Authorities (per learning network) New idea New Distribution New domain New tool What is it?
- 6. Today
- 7. Today… and the last 20 years
- 8. Build things doing too much
- 9. Buy things doing too much *cough* LMS *cough*
- 10. Today: Buy • Pros: • Single system / address • Easy to promote / point to • Pay the bill, be done • Uniformity • Cons: • Lack of control • $$$$$$$$$$$$ • Customization difficult • Lengthy contracts (years at time) • Direction set by vendor (Mediacore’s great!) • Institutional concepts wrapped into system design
- 11. Today: Build • Pros: • Easy to promote / point to • Easy to put out fire (one location) • Easier to support • Uniformity • Cons: • Lack of flexibility • People / $$$$$$ • Uniformity • Building institutional concepts into system design
- 12. Building institutional concepts • Replicated in every system purchased or created • Hierarchy • Institution, College, Department • Roles • Student, faculty, staff, instructional designer, etc • Concepts • Course, Section, Offering, Semesters
- 13. How many employees did ____ hire? • To support our institution, how many employees do they hire when we buy in? • zero or close to zero • A sales person probably clicks a button, fills out our “tokens” and “deploys” to a new domain • Deployment architecture taken into account to segment their clients
- 15. Deployment architecture • Tokenize criteria • Replicate applying tokens 1,000s of times • Scale capacity 1,000s of times through replication
- 16. Jenkins example
- 19. Characteristics • Load / risk distributed across servers mirroring institutional concept • Possibility for local control / contribution / resource sharing in process • Central IT can still push out standardized security, design, as needed • Vanity URLs now possible • Simplified user management (1 less structure to account for) • Robots / automation keep it from chaos • More options / flexibility
- 20. Pattern based system automation • Abstraction at upper layers can always be applied deeper • Just ask Docker community • Break system goal into discrete functions • Utilize REST and automation to unify experience • Deploy as multiple pieces
- 22. One of those deployments media.site.com courses.site.com blog.site.com analytics.site.com studio.site.com online.site.com interact.site.com
- 24. Deployment 3 media.site.com courses.site.com analytics.site.com online.site.com interact.site.com
- 25. Buttercups UK Med Training
- 26. The day after tomorrow
- 27. Organic architecture • System is a fractal of other systems • Cloning • REST and SSH handshakes to unify / self-distribute • DNA • Networks then can replicate, peel off, morph to scale • Evolution • Automation applied to single instance to replicate • Gene Splicing • Virtual Networks of networks • Gene pool
- 28. Simple Life
- 29. DNA
- 30. Simple to simple
- 31. Simple to simple to simple
- 32. Cool idea + 1
- 35. Future proofing w/o sacrifice
- 36. Characteristics • Start deployments small, scale out as they grow • Deployment architecture matches needs of area deploying • Possibility for local control / contribution / resource sharing in process • Central IT can still push out standardized security, design, as needed • Robots / automation keep it from chaos • More options / flexibility
- 37. ELMS:LN current runs on • Cloud Servers (Digital Ocean, AWS EC2) • TravisCI (cloud based test bed) • VMHost Servers (7 at PSU) • Laptops (via Vagrant, same as • Soon ChromeBit (anything w/ 2 gigs of ram)