Getting questions from implementers: If were were to add Ozone IL components to the refapp, how “heavy” would this make the RefApp? E.g. how big in MB?
Checking the size of Odoo, Superset, etc we see these are about the same size as the OMRS application - which basically means a local instance trying to leverage those systems ends up having triple the “size” of unified application on their prem. I’m hearing concern about that. But @gkinyua and I reckon the I/L itself cannot be as big… right?
I wouldn’t be able to tell you offhand exactly, but clearly that’s not the worry in the context of the HIS. Individual components with their databases will easily eat up 95%+ of the disk space footprint.
The IL itself does store messages for queueing purposes, but that’s transient in nature. Since each time a message is delivered the queue is cleared.
Not sure if any of the Ozone team would be able to say more? @achachiez @corneliouzbett @mksrom @ruhanga
The integration layer is mostly made of one reusable Docker image:
This means that running Ozone with multiple integrations (Odoo ↔ OpenMRS, OpenMRS ↔ SENAITE…) will not take much more space than the 500MB of a single EIP Client.
As explained by @mksd the data synced itself won’t account for much space either.
Ozone, with all its components, will take some good space. More than a single application yes.
Usually the disk space itself is not the concern but it is rather the memory (storage being very cheap compared to memory). Running a full-on Ozone HIS (EMR + ERP + LIMS) for a small clinic (say 10-20 users) will work very well on a 16 GB RAM computer.
Regarding Ozone Analytics, it’s not easy to estimate the storage and memory needed. That really depends of its use. Usually analytics tooling is deployed on a different server than the production as those can use up a lot of resources, leaving little for the production application itself.
That said, if O3 Ref App would provide the visual components needed by a small clinic to achieve basic ERP processes or LIMS processes, then we could make sure the ERP and LIMS are running only has headless applications, used only as backend. Thus making the overall resources footprint lighter.
Additional context: I think most Ozone developers are running the stack via GitPod, so in a very minimal instance (single user, though with plenty of spare capacity) it works with 4 CPUs and 8 GB of RAM to serve OpenMRS, Senaite, Odoo, Superset, and the Ozone IL). That’s about the equivalent horsepower of a single Raspberry PI, so with two PI nodes, you could probably run a production-ready instance of Ozone for a small clinic.
Wow - incredibly helpful!! Thank you everyone. Will share this around.