In occasione del terzo MongoDB Day di Roma, abbiamo approfondito alcuni concetti di architettura delle applicazioni con Giulio Vezzelli, senior manager, Solutions Architecture, South EMEA in MongoDB.
Partiamo dal recente problema di DynamoDb su un server Amazon in West Virginia: quali consigli architetturali se ne desumono?
I concetti di multi-region e multi-cloud esistono proprio per mitigare situazioni di questo tipo. Un’architettura cloud non progettata per operare su più regioni o su più cloud provider, ha una vulnerabilità: se si dipende da un’unica regione e questa subisce un’interruzione, il servizio diventa indisponibile. Abbiamo investito tanto per garantire la massima flessibilità nel cloud con il nostro servizio MongoDB Atlas, offrendo la possibilità di scegliere region e cloud provider, assicurando resilienza e adempienza a requisiti di performance e località del dato. Un elemento distintivo di MongoDB Atlas è la possibilità di singolo deployment su più cloud provider contemporaneamente.
Le aziende sono consapevoli delle implicazioni operative e strategiche derivanti dall’affidamento a intermediari terzi?
La progettazione di un’architettura cloud richiede l’analisi di un business case, che bilancia le esigenze strategiche e operative con l’investimento necessario.
È cruciale capire il livello di resilienza desiderato, considerando potenziali impatti di un downtime, come perdite economiche, danni alla reputazione o alla fiducia dei clienti.
Con le architetture multi-region e multi-cloud, un servizio critico rimane operativo anche in caso di guasti regionali o interruzioni di un cloud provider. Tuttavia, implementarle richiede costi e competenze tecniche solide.
Come viene garantita la sovranità dei dati a fronte dell’assoggettamento alla giurisdizione statunitense e alle potenziali richieste del Dipartimento di Giustizia USA?
MongoDB offre un differenziatore tecnologico significativo, la Client-Side Field Level Encryption, che consente di cifrare i dati con chiavi in esclusivo possesso del cliente. Né MongoDB, né il cloud provider le conoscono. Il cliente può anche creare chiavi specifiche per ciascun individuo. Con la Queryable Encryption, inoltre, i dati sono interrogati in forma crittografata, soluzione ideale per compliance e sovranità del dato.
Quali linee guida architetturali, analoghe agli standard OWASP, raccomandate per una progettazione sicura del servizio?
Si parte dalla definizione chiara dei requisiti da soddisfare, che guidano le decisioni architetturali. Tra i fattori fondamentali, il livello di servizio atteso (SLA), essenziale per determinare la disponibilità del sistema, spesso misurata dai “nove” (es. 99.9% vs 99.995%). Scelte architetturali avanzate, come multi-region e multi-cloud, permettono di raggiungere livelli di servizio elevati.
Anche data locality e sicurezza sono importanti. La posizione fisica dei dati deve rispettare requisiti normativi, come il GDPR, e ottimizzare le prestazioni riducendo la latenza. Sempre il GDPR introduce requisiti specifici come il diritto all’oblio: la nostra crittografia permette di soddisfare questo mandato grazie alla possibilità di eliminare direttamente le chiavi associate ai dati di un individuo, rendendoli definitivamente inaccessibili.
Si torna quindi sull’encryption, essenziale per proteggere i dati in transito, a riposo e durante l’uso: crittografia avanzata e gestione sicura delle chiavi assicurano conformità e controllo, mentre autenticazione multifattoriale e accessi granulari rafforzano la protezione complessiva.
In ottica di sovranità digitale, è supportata la migrazione su provider europei in alternativa ai grandi hyperscaler globali?
Il nostro obiettivo è offrire la massima flessibilità nel deployment, consentendo ai clienti di integrare la tecnologia con diverse strategie, inclusi scenari multi-cloud e ibridi. Abbiamo partnership con fornitori regionali come il Polo Strategico Nazionale, OVH, Scaleway e Ionos, e supportiamo approcci ibridi che combinano il cloud con infrastrutture on-premises, come nel caso uso di data center per motivi strategici, normativi o operativi.
MongoDB offre un’esperienza d’uso coerente ovunque venga eseguito: su Atlas attraverso AWS, Google Cloud, Azure, su un fornitore regionale oppure on-premise. Le applicazioni possono essere spostate tra ambienti diversi senza modifiche, offrendo agli sviluppatori un’esperienza uniforme e intuitiva grazie al document model basato su JSON.