ELMSLN: Rethinking System Architecture
Download as PPTX, PDF2 likes646 views
The document discusses a rethinking of system design through the elmsln initiative, highlighting the issues with current learning management systems (LMS) and promoting a more flexible, automated architecture using networked Drupal sites. It critiques both build and buy approaches to educational systems, emphasizing lack of control and customization in the buy approach while noting that building leads to rigidity. The proposed solution includes a pattern-based, automated system that scales with institutional needs while maintaining flexibility and local control.
ELMSLN: Rethinking System Architecture
- 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 of today • Issues with today • Design patterns • Examples through ELMS: LN
- 4. https://github.com/elmsln/elmsln https://elmsln.org Star, Follow and Fork!
- 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 10 years
- 8. Build / Buy things doing too much
- 9. Build / 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
- 18. 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
- 19. 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
- 21. 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
- 23. Deployment 3 media.site.com courses.site.com analytics.site.com online.site.com interact.site.com
- 24. Buttercups UK Med Training
- 25. The day after tomorrow
- 26. Organic architecture • System is a fractal of other systems • Cloning • REST and SSH handshakes to unify / self-distribute • DNA • Networks then can replicate, peal off, morph to scale • Evolution • Automation applied to single instance to replicate • Gene Splicing • Virtual Networks of in networks • Gene pool
- 27. Simple Life
- 28. DNA
- 29. Simple to simple
- 30. Simple to simple to simple
- 31. Cool idea + 1
- 34. Future proofing w/o sacrifice
- 35. 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
- 36. The future
- 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)