Cosa sono le Cloud Native Apps?

Si tratta di applicazioni sviluppate utilizzando esclusivamente servizi cloud gestiti. Per loro natura quindi dispongono di tutti i vantaggi del cloud, con minimo se non nullo intervento dello sviluppatore:

• scalabilità pressochè illimitata
• ridondanza e affidabilità

ma anche

• sicurezza
• provisioning delle risorse
• pay per use
• monitoraggio

Come corollario di questa definizione, una applicazione "cloud native" non solo implica una elevata difficoltà, se non impossibilità, di essere "espiantata" dal cloud, ma ove anche sia possibile ci si dovrebbe interrogare sul senso dell'operazione.

Volendo quindi seguire in modo coerente questa mia definizione è evidente che una applicazione "cloud native" è per sua natura "serverless". In termini più generali si deve considerare che nel "cloud native computing" l'unità base è il (micro) servizio in comunicazione con gli altri via API.

Cosa che la distingue da altre applicazioni "cloud based" che possono arrivare a sfruttare i vantaggi del cloud, ma che per farlo necessitano di una maggiore accortezza da parte di chi sviluppa e di chi definisce e gestisce l'infrastruttura, o perlomeno su entrambi i piani anche se la figura è la stessa come sempre più spesso accade.

Per cui "cloud native" è un sinonimo di "serverless"? In realtà è un concetto diverso che include la tecnologia "serverless" e prevede che ogni aspetto dello sviluppo sia basato su tecnologie esclusivamente cloud, inclusi i processi di gestione del ciclo di vita del software e del sistema.

Un tipico scenario quindi di una applicazione "cloud native" prevede una architettura a microservizi dispiegati in container o servizi FAAS combinati "loosely-coupled" con servizi gestiti xAAS via API.

Un esempio: Kirolive e la Virtual Classroom di UniPV

Un esempio di una applicazione cloud native è il progetto Kirolive, realizzato in questi giorni di emergenza sanitaria per consentire all’Università di Pavia di mettere a disposizione uno strumento per erogare lezioni in diretta ai propri studenti.

L’applicazione è stata realizzata in una settimana attraverso l’integrazione di 2 servizi SAAS e della piattaforma cloud AWS. I servizi sono Bandyer per lo streaming e Google Drive per lo storage delle registrazioni delle lezioni.

Attraverso Kirolive i docenti dell’Università possono attivare una lezione live a cui gli studenti possono chiedere di partecipare. Unicamente agli studenti autorizzati viene inoltrato un link di partecipazione con il quale possono accedere alla lezione.

Il docente trasmette la sua lezione avendo a disposizione i classici strumenti di base per la gestione di un webinar, cioè oltre a diffondere il proprio stream audio/video, la possibilità di condividere il proprio desktop per le presentazioni o inoltrare altre registrazioni video e la possibilità di interagire ricevendo domande o proponendo sondaggi.

Inoltre le lezioni sono registrate e riversate in Google Drive per una fruizione successiva da parte degli studenti autorizzati.

Lo sviluppo è basato sull’utilizzo del framework serverless ed è realizzato secondo i principi cloud native utilizzando esclusivamente servizi AWS gestiti. Il frontend è una applicazione React dispiegata su S3 e servita da Cloudfront, che accede ai servizi attraverso API Gateway. Gli utenti sono autenticati con Cognito, le logiche applicative sono sviluppate in Lambda, i dati salvati su DynamoDB e le interazioni asincrone tra servizi utilizzano SQS / SNS, mentre quelle asincrone con gli utenti inviano messaggi con SES. Gli eventi e le metriche rilevanti sono gestite su Cloudwatch.

Le maggiori criticità per l'Università in questo progetto sono state i tempi e l’impossibilità di avere indicazioni attendibili sui numeri di utilizzo.

Il vantaggio principale in questo caso di un approccio cloud native è stato quello di poter mettere a disposizione in tempi molto brevi una applicazione per un servizio in grado di scalare sui numeri dell’Università di Pavia. Come anche la possibilità per l’Università di accedere ad un modello di costi riconfigurabile di settimana in settimana in funzione dell’utilizzo.