• Interactive online material (book, workbook, course)
• Automatically graded exercises
• Instant feedback
• Peer review (and maybe grading)

• Personalisation, problem randomisation, exercise pools
• Online editors, code testing, highlighting
• Plagiarism, student action tracking
• Analytics, tracking of learning patterns

• Export and import user data
• Security and secrecy
• Forgetting personal data
• Interconnections to other systems

• Extendability, add-ons and extensions
• Existing interfaces: LTI, H5P
• Customisation: teachers own code
• Authenticity of students actions

• Massive online courses
• Responsiveness, scaling
• Robustness, no downtimes!
• Automatic grades and updates to SISU

• Course material production
• Shared materials, cooperation and co-authoring
• Exercise sharing and catalogs
• Course release management

• IT operations are easy: software upgrades, deployment
• All the stuff we don't care about...
• All the stuff I don't know about...

1. Platform to provide robustness and scale
2. Software design to support scale and extensibility
3. DevOps to course material production
4. Tools and automation to support IT operations

Bare-metal:

• good: dedicated resources, speed, easy to understand and operate
• bad: maintenance, no redundancy, power outages, requires knowledge, vertical scaling has a limit

Virtual machines:

• good: maintenance is better than with bare-metal, can be migrated online, backups, easy to deploy multiple versions
• bad: where developer ends and IT operator starts, requires lot of system administration (software upgrades, Ansible, Puppet), scaling is often done manually

Containers:

• good: developer provides full OS environment with the app, service components (Web, DB, FS) can split to different containers, scaling can often be automatic
• bad: managing the complexity is hard, security updates to environment, git clone + django migrate is not enough!

Brief history..

• Unix V7 introduced chroot in 1979 (article)
• Solaris Containers released in Solaris 10, 2004
• "Starting in Linux 3.8 (Feb 18, 2013), unprivileged processes can create user namespaces, which opens up a raft of interesting new possibilities for applications" (lwn.net)
• Docker was released 23 days later on March 13, 2013

Kubernetes

• Container orchestration
• Automating deployment and scaling
• Abstracts computing and storage resources
• Developer provides application as an OS image
• IT operations provide resources
• Supported by many cloud platform providers

Private cloud for teaching

• Information security
• Some level of secrecy required for student solutions
• Ensures low latencies
• Requires a good DevOps skills from IT team

CS Kubernetes

Provides MOOC-Grader and Jupyter Hub for CS

• 3x schedulers: 4-32 CPU, 4-128 GB RAM
• 2x workers: 32 CPU, 128GB RAM
• 2x workers: 16 CPU, 64 GB RAM

• Containers solve scaling..
• But require somewhat microservice design from the application

1. Platform to provide robustness and scale
2. Software design to support scale and extensibility
3. DevOps to course material production
4. Tools and automation to support IT operations

It was easy..

• Desktop apps are simple problem, download and run
• Django apps are also simple, git clone && ./manage.py runserver
• A lot of users → add more cores and RAM

What if there is 10k users, 100k or 1M?

¯\_(ツ)_/¯

Scalability from microservices

• Containers are light-weight "virtual machines" → ideal for microservices
• Interfaces between components → high availability per component → robustness
• Automatic scaling per component → identify problematic components

Distribute development

• Implement features as services → extensibility due common interfaces
• Separate teams can work on different components
• Separation requires problem handling and testing → robustness and better software!
• Failed separation results in a house of cards → problem in one service brings everything down

Downsides..

• "What is part of a release?"
• "How do I install this?"
• "Feature X doesn't work on my machine."
• "We would need 10 virtual machines to set this up"

1. Platform to provide robustness and scale
2. Software design to support scale and extensibility
3. DevOps to course material production
4. Tools and automation to support IT operations

DevOps

• Closes the cap between development and IT operations
• Continuous Integration, i.e. git + automated tests
• Continuous Deployment, i.e. update production on a release push
• Supports agile software development, containers and microservices

Digitalisation in teaching

• First, teachers wrote material with latex and exported pdf. Nice documents for the student to read offline. No interactive elements.
• Then, they clicked in moodle and wrote text boxes. Interactive elements! Often a single release and no rollbacks.

DevOps for teaching

• Course material written in some source format
• ... or use WYSIWYG editor for it
• Text and exercises from different people
• Push material to version control for a release
• Integration tests begin → "Did I break exercises?"
• Automated deployment to test and production environments!

Why?

• Ensure material in production is not broken
• Create multiple releases: eBook vs. course
• Deploy to multiple platforms: A+, TIM, ACOS
• Hide microservice design from the teacher
• Material cooperation between authors

1. Platform to provide robustness and scale
2. Software design to support scale and extensibility
3. DevOps to course material production
4. Tools and automation to support IT operations

Industry tools

• Release services via image repositories: Docker Hub, Google Container Registry
• Software definitions as Helm charts: helm.sh
• Cluster deployment using Helmsman: github

Separation of roles

• Developer produces the software and defines execution environment
• IT operations ensures computing and storage resources
• No need for ops to develop or devs to operate
• Except all the DevOps building all the images 😁

Vision for the future

• no need to care about platform used by students
• material can be distributed via multiple platforms
• teacher creates only part of the material
• availability of interactive elements and exercises
• teacher has visibility over what is working

Teacher has time to provide best of the world learning experience, as the tools are so awesome!

Teacher has analytics and feedback to make it event better!

IT operators can maintain 99.9% service level!

Students are happy as they can read to exams..

We do not implement same features over and over again...

Underway

• Roman - define how material is build (i.e. Makefile)
• Shepherd - CI/CD tool for teaching (i.e. easy to use Gitlab CI / drone.io)
• helmsman and deployment tools for IT

To plan

• ACOS as an exercise catalog and a proxy
• distributed container grader (i.e. MOOC-Grader v2)
• A+ v2