La transizione al cloud che le PMI stanno compiendo in questi anni ha portato molti vantaggi in termini di sicurezza, affidabilità e risparmio. Si tratta però di un percorso che richiede tempo e competenze per trasformare le infrastrutture legacy delle aziende in infrastrutture agili, modulari e in grado di rispondere velocemente alle mutazioni del mercato. Se fino a pochi anni fa la sfida era passare dall’on-premise al cloud, oggi stiamo gradualmente evolvendo da infrastrutture cloud IaaS ad infrastrutture managed/serverless, per consentire agli sviluppatori di concentrarsi sulle logiche di business. Cosa devono sapere aziende e sviluppatori per migrare a serverless in AWS e approdare a questo paradigma?  

Nel parleremo nella nuova edizione di GoServerless! in programma il 15 maggio nella sede milanese di AWS. L’evento, giunto alla sua terza edizione, prevede diverse sessioni di formazione e presentazione di case history, con la possibilità di confrontarsi direttamente con i Solution Architect di AWS e di ELEVA. La partecipazione è gratuita fino ad esaurimento posti, previa iscrizione sul sito dell’evento (Go Serverless 2025! – ELEVA). Vi anticipiamo qui alcuni dei temi più salienti. 

• Proteggere i dati: perché le aziende stanno migrando a serverless in AWS 

• Quali ostacoli comporta la migrazione a serverless delle applicazioni 

• Case history di migrazione al cloud AWS con infrastruttura gestita: M-Score Bonehealth 

Proteggere i dati: perché le aziende stanno migrando a serverless in AWS 

Proteggere i dati è una condizione alla base di qualsiasi servizio digitale. In alcuni settori specifici, come quello medico o finanziario, lo è ancora di più e il passaggio al cloud rappresenta un fattore chiave sul piano della sicurezza. Sebbene le infrastrutture legacy di alcune aziende o di interi settori possano rallentare un percorso che oggi è per lo più culturale, migrare al cloud AWS applicazioni, siti web, database, archivi, server fisici o virtuali e persino interi data center, non è solo possibile, ma porta anche diversi vantaggi.  

Affidarsi a un’architettura a servizi gestiti o serverless significa costruire un ambiente più sicuro, automatizzato e facile da mantenere.  È la soluzione ideale per chi ha bisogno di controllo, tracciabilità e affidabilità, anche con un team ridotto. Vediamo perché. 

• Riduce il rischio di errore umano 
  Pipeline di rilascio ben strutturate assicurano ambienti coerenti, sicuri e facilmente replicabili. 
• Protegge i dati sensibili alla fonte 
  I dati possono essere crittografati in-transit e at-rest sfruttando i più elevati standard di sicurezza. 
• Semplifica la conformità 
  I servizi gestiti offrono strumenti nativi per rispettare regolamenti come GDPR e NIS2, riducendo complessità e rischi. 
• Accelera il time-to-market  
  Riducendo la complessità dell’infrastruttura, si può spostare il focus sul codice. Costruire, testare e lanciare nuovi prodotti diventa un processo più fluido ed efficiente. Ogni applicazione può scalare automaticamente in base alle variazioni di traffico, senza interventi manuali e con costi ottimizzati in ottica pay-as-you-go. 

Quali ostacoli comporta la migrazione a serverless delle applicazioni 

Migrare a serverless le applicazioni può essere complesso, specie in presenza di sistemi legacy che si basano su logiche di infrastruttura diverse. La transizione può essere ostacolata sia da fattori tecnici che di approccio, vediamo quali. 

Cultura e resistenza al cambiamento 

Molte aziende temono i cambiamenti infrastrutturali, soprattutto se mancano competenze interne su AWS. L’adozione di una nuova tecnologia richiede formazione, nuove competenze e un cambio di mentalità all’interno dei team di sviluppo e operativi. 

Revisione dell’architettura delle applicazioni 

Non tutte le applicazioni sono immediatamente compatibili con un’architettura serverless. In alcuni casi è necessario riprogettare intere applicazioni monolitiche, suddividendole in microservizi. Un passaggio che può richiedere una transizione lunga e graduale, ma con enormi vantaggi in termini di manutenibilità e flessibilità. 

Acquisizione di competenze in ambito DevOps  

Definire criteri di Infrastructure as Code (IaC), attraverso strumenti come AWS CloudFormation, consente di automatizzare la gestione continua dell’infrastruttura, per favorire future modifiche e integrazioni di nuove feature. Queste pratiche permetteranno ai developer di migliorare la propria esperienza di sviluppo e concertarsi solo sulla business logic, abbracciando gradualmente cultura e competenze in ambito DevOps. L’IaC, inoltre, aiuta a ridurre gli errori umani, garantire coerenza nelle configurazioni e accelerare il provisioning delle risorse necessarie. 

Monitoraggio e gestione 

Le applicazioni serverless richiedono strumenti avanzati di monitoraggio per gestire eventuali errori e ottimizzare prestazioni e sicurezza. Amazon CloudWatch, CloudTrail o AWS Systems Manager sono solo alcuni esempi di servizi utili a tracciare le richieste e analizzare il comportamento dell’applicazione in tempo reale, oltre che ad automatizzare processi che prima venivano svolti manualmente. 

Case history di migrazione al cloud AWS con infrastruttura gestita: M-Score Bonehealth 

M-Score Bonehealth Srl è una startup italiana attiva nel settore HealthTech. Ha sviluppato M-Score, una piattaforma basata su intelligenza artificiale per l’analisi automatizzata delle immagini da risonanza magnetica lombari, in grado di stimare la probabilità di osteoporosi in modo rapido, non invasivo e predittivo. Il team ELEVA di cloud architecht certificati AWS ha contribuito a realizzare un’infrastruttura solida, sicura e completamente gestita, su cui l’azienda potesse scalare la propria soluzione AI. 

 La sfida 

Come molte startup in crescita, M-Score Bonehealth aveva bisogno di: 

• Mettere in sicurezza dati estremamente sensibili, trattandosi di immagini mediche e informazioni legate alla salute. 

• Garantire la privacy dei pazienti, assicurandosi che il sistema fosse conforme al GDPR e pronto per un futuro allineamento alla direttiva NIS2. 

• Liberare il team di sviluppo da attività infrastrutturali, per concentrarsi sull’evoluzione del prodotto 

• Evitare di aggiornare manualmente ogni server fisico presente nei centri medici in cui la soluzione è in uso 

La soluzione 

• Realizzazione dell’ambiente di produzione e di staging 
  Per non dover gestire manualmente gli aggiornamenti dei server fisici in ogni centro medico è stata realizzata una soluzione ibrida. Nella configurazione della CI/CD è stata creato un ambiente di staging su AWS che replica la configurazione dei server installati presso i centri medici. In tal modo, quando lo sviluppatore deve rilasciare aggiornamenti all’applicativo, il testing avviene esclusivamente su AWS. In seguito, tramite l’agent installato sulle macchine on-prem, gli aggiornamenti vengono rilasciati contemporaneamente su tutti i centri medici.  

• Backend  
  Il backend è stato realizzato sfruttando il servizio Elastic Beanstalk, pubblicando su internet l’applicazione tramite Application Load Balancer protetto da Web Application Firewall. In ogni centro medico viene configurato l’ambiente client. In tal modo, gli operatori accederanno all’applicazione sfruttando i server on-prem. 

• Anonimizzazione dei dati sanitari 
  Le radiografie vengono caricate in cloud con ID univoci, senza nomi né dati anagrafici associati, garantendo il pieno rispetto della privacy. 

• Infrastruttura finale 
  Ogni centro medico che comunica con l’app ha un server fisico con due server virtuali; gli operatori utilizzano l’applicazione deployata localmente in cui sono memorizzati i dati anagrafici degli utenti. I risultati delle analisi, memorizzati localmente, vengono anonimizzati ed inviati al cloud AWS attraverso una rete sicura di tipo zero trust. 

Sicurezza e Compliance: risultati chiave 

• Tutti i dati sono crittografati sia in-transit sia at-rest. 

• Le immagini sono anonimizzate alla fonte, prima di essere inviati su cloud di AWS. 

• Il sistema è progettato per essere scalabile, resiliente e privacy-by-design. 

• L’intervento rientra pienamente nei requisiti del GDPR e anticipa il percorso di compliance della futura normativa NIS2  

Conclusioni 

Anche per realtà con infrastrutture on-prem e sistemi legacy, è possibile migrare al cloud adottando un approccio cloud native. Questa case history mostra come sviluppare un sistema che gestisce dati sensibili (nello specifico, informazioni e immagini mediche) senza doversi preoccupare di architettura, compliance e sicurezza dei dati, concentrandosi esclusivamente sugli aspetti di sviluppo, in un’ottica di integrazione continua. 

Vuoi saperne di più? Approfondiremo gli aspetti più tecnici durante il nostro evento GoServerless! Iscriviti subito per partecipare e richiedere tutti i materiali dell’evento.