Tutti i MES cloud dicono di essere "sicuri" e "isolati". Le architetture sotto sono tre diverse, con tradeoff opposti. Vediamoli.
Livello 1: shared database, tenant_id discriminator
Tutti i tenant condividono lo stesso database. Ogni record ha una colonna tenant_id. Le query applicative aggiungono sempre WHERE tenant_id = ?.
Pro: economico, scala bene, deploy unico. Contro: un bug applicativo può far vedere dati di un altro tenant. Va difeso con test e auditing rigorosi.
Livello 2: database separato per tenant
Stesso server, ma ogni tenant ha il suo schema/database. Le query non hanno tenant_id ma sono dirette al database del tenant corrente.
Pro: isolamento più forte, migrazioni gestibili per tenant, backup individuali. Contro: più costi di gestione, più connessioni database, scale-out limitato dal numero massimo di schemi per server.
Livello 3: stack dedicato per tenant
Ogni tenant ha la sua VM, il suo database, il suo file storage. Lo stack è effettivamente single-tenant ma orchestrato come SaaS.
Pro: isolamento massimo (a livello hardware), performance dedicate, certificazioni più rigorose. Contro: costo per tenant alto, time-to-onboard maggiore, aggiornamenti più lenti.
Usato in genere per tenant enterprise grandi (>200 PLC, requisiti compliance pesanti).
Cosa offre PLCinCloud
Livello 2 di default (database separato per tenant) per la maggior parte dei clienti — bilancia bene costo, isolamento e operatività. Livello 3 disponibile su contratto enterprise quando richiesto da audit o normative settoriali.