Rethinking system design

elmsln.org

@btopro

Come get a sticker like this one

In dribs and drabswe will change the world

Project LeadELMS Initiative

Instructional Systems ArchitectE-Learning InstituteCollege of Arts & ArchitecturePenn State University

@btopro (aka Bryan Ollendyke)

Rethinking system architecture

• Review of today

• Issues with today

• Design patterns

• Examples through ELMS: LN

https://github.com/elmsln/elmslnhttps://elmsln.org

Star, Follow and Fork!

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?

=

Today

Today…and the last 10 years

Build / Buy things doing too much

Build / Buy things doing too much*cough* LMS *cough*

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

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

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

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 tosegment their clients

Deployments of today

Deployment architecture• Tokenize criteria

• Replicate applying tokens 1,000s of times

• Scale capacity 1,000s of times through replication

Deployments of today

Middleware approach

collegeD.url.com

url.com

collegeE.url.com

collegeF.url.com

collegeC.url.com

collegeB.url.com

collegeA.url.com

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

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

ELMSLN Deployments

sciences.psu.edu

elmsln.psu.edu

smeal.psu.edu

hhd.psu.edu

aanda.psu.edu

ag.psu.edu

stem-researchethics.org

One of those deployments

media.site.com

courses.site.com

blog.site.com

analytics.site.com

studio.site.comonline.site.com

interact.site.com

Deployment 2

media.site.com

courses.site.com

blog.site.com

studio.site.comonline.site.com

Deployment 3

media.site.com

courses.site.com

analytics.site.com

online.site.com

interact.site.com

Buttercups UK Med Training

The day after tomorrow

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

Simple Life

DNA

Simple to simple

Simple to simple to simple

Cool idea + 1

Graduated Cool idea

Complexity from simplicity

Future proofing w/o sacrifice

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

The future

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)

Questions

@btopro

elmsln.org