This is probably not a practical experiment, but just a late night musing.
I’m currently upgrading the OS on the Raspberry Pi 4 that I primarily use for running Pi-hole, and I got to wondering a bit about what it would take to get Open edX to run usably well (for a small group of users) on that hardware. I tried to avoid any drastic architectural changes while thinking about this, but I do think that it would require some alternate implementations of existing interfaces.
Assumptions:
- Hardware is a Raspberry Pi 4 with 2 GB of RAM
- OS is Raspberry Pi OS Lite (64-bit).
- Must run LMS, Studio, and the MFEs used by those applications.
Things that are absolutely necessary:
- Python gunicorn workers + celery workers, though maybe only one of each.
- Redis: cache + celery backend
- nginx :both as proxy to gunicorn and to serve MFE domains
Things that I’d cut:
- Elasticsearch
- MySQL
- MongoDB
- Forums service
This setup would lean very heavily on SQLite, for both the Django ORM and to substitute for MongoDB. Doing the latter would require building on (subclassing?) DjangoFlexPersistenceBackend to allow it to store definitions and structures in the ORM. Likewise, there would be some SQLite/Django-ORM-backed equivalent to MongoContentStore for storing course static assets. If we want to make the SQLite database the single artifact that needs to be backed up, we could also make a storages backend for it as well.
I think that might work? Honestly, I don’t know if there’s any real use case for a system this resource starved to run Open edX (as opposed to an Raspberry Pi with, say, 8 GB of RAM, but it’s fun to think about.