Modelli di servizio di una risorsa cloud

Modelli di servizio di una risorsa cloud definiti dal NIST

I modelli di servizio del cloud definiti dal NIST sono tre:

• Infrastructure as a Service (IaaS): consiste nel fornire al cliente risorse hardware virtualizzate, come macchine virtuali, storage, reti e altre infrastrutture. Il cliente può installare e gestire i propri sistemi operativi, applicazioni e dati, ma non ha il controllo sulle infrastrutture sottostanti.
• Platform as a Service (PaaS): consiste nel fornire al cliente una piattaforma di sviluppo e distribuzione di applicazioni basata sul cloud. Il cliente può creare e gestire le proprie applicazioni usando i linguaggi, gli strumenti e le librerie forniti dal provider, ma non ha il controllo sulle infrastrutture e i sistemi operativi sottostanti.
• Software as a Service (SaaS): consiste nel fornire al cliente un’applicazione software eseguita sul cloud e accessibile tramite un’interfaccia web o un client leggero. Il cliente può usare l’applicazione per le proprie esigenze, ma non ha il controllo né sulle infrastrutture né sulla piattaforma né sul software sottostanti.

Tenendo in considerazione l’evoluzione del cloud dal 2011 conviene affiancare un altro importante modello di servizio lo IaC.

• Infrastructure as a Code (IaC): consiste nel definire e gestire le infrastrutture cloud tramite codice, usando linguaggi specifici o generici. Il cliente può automatizzare e replicare le configurazioni delle infrastrutture, rendendole più agili e scalabili.

Estensioni del modello di servizio SaaS

Nel tempo si sono affermate nella comunicazione alcune particolari specializzazioni dei modello di servizio SaaS. Pur non avendo un riscontro ufficiale NIST, sono entrate nel gergo tecnico-commerciale.

• Business Process as a service: (BPaaS): è l’evoluzione del SaaS inteso come implementazione di uno a o più Service Value Chain (servizio a valore aggiunto) o Service Value System (nei casi più complessi) interamente erogato con software as a service.
• Function as a Service (FaaS): consiste nel fornire al cliente la possibilità di eseguire funzioni di codice senza doversi preoccupare delle infrastrutture, delle piattaforme e dei software sottostanti. Il cliente paga solo per il tempo di esecuzione delle funzioni, che possono essere scatenate da eventi o richieste.
• Backend as a Service (BaaS): consiste nel fornire al cliente un backend per le sue applicazioni mobili o web, che include servizi come autenticazione, database, notifiche, storage e altro. Il cliente può concentrarsi sullo sviluppo del frontend, senza doversi occupare della gestione del backend.
• Data as a Service (DaaS): consiste nel fornire al cliente l’accesso a dati di qualità e aggiornati, provenienti da diverse fonti e formati. Il cliente può integrare i dati nel suo flusso di lavoro, senza doversi preoccupare della raccolta, della pulizia, dell’archiviazione e dell’analisi dei dati. 

Modelli di servizio cloud estesi, con hyperscaler

Proviamo a fornire una spiegazione utilizzando l’infografica.

Alla base abbiamo il servizio di infrastruttura erogato da parte del fornitore del cloud (hyperscaler) tramite farm fisicamente distribuite nel mondo. Esse interconnesse tra loro con linee ad alta velocità in fibra ottica altamente ridondate.  Questo per garantire il livello di alta scalabilità e ridondanza richiesti a garantire la massima qualità di servizio verso l’utente finale, da qui il nome di hyperscaler ultimamente adottato.

Esempi di hyperscaler sono Amazon Web Service, Microsoft Azure, Google Cloud Provider.

Una volta scelto l’hyperscaler dobbiamo acquistare le risorse cloud disponibili scegliendo sovente tra i tre modelli di servizio precedentemente descritti IaaS, PaaS o SaaS.

La scelta su quale modello di servizio impiegare in presenza di diverse disponibilità a parità di offerta, saranno trattati in un apposito articolo di prossima pubblicazione.

“Infrastructure as Code (IaC)”  va considerato come una pratica anche se comporta implicitamente l’adozione di un modello di servizio specifico molto orientato al all’uso di framework DevSecOps uno strumento facilitante la gestione del ciclo di vita delle risorse allocate.

La linea guida è proposta nel framework ben rappresentato dal CAF di Terraform

E’ consigliato  l’impiego quando si gestisce direttamente il ciclo di vita delle risorse cloud.

E’ sperabile sia impiegato dal fornitore a cui demando la gestione su mio mandato.

Va ricordato che:

Il sistema informativo in cloud denominato ecosistema cloud per essere native e private richiede, tra l’altro, che la maggioranza delle risorse cloud sia erogata tramite modello di servizio SaaS al più PaaS, dove non possibile il SaaS, gestito con framework DevSecOps ed impiego della tecnica e strumenti IaC.

Approfondimenti sui modelli di servizio

Il modello di servizio IaaS

Tornando all’infografica, il modello di servizio IaaS è il modello di servizio più semplice la cui gestione non differisce sostanzialmente da servizi erogati su ambienti virtuali. Questi servizi sono di uso comune nell’organizzazione aziendale. Questo facilità e velocizza l’impiego nei primi passi di adozione del cloud.  

Un sistemista può facilmente acquisire la competenza per gestire nel cloud le attività che già svolge nel classico quotidianamente.

Contrattualmente l’hyperscaler mi garantisce la disponibilità ed il grado di disponibilità e scalabilità hardware richiesti ma la responsabilità di gestione della risorsa è a mio carico diretto.

Modello di servizio PaaS

Il modello di servizio PaaS una parte di gestione è presa in carico dall’hyperscaler.

Normalmente la configurazione di base e l’installazione sono a carico dell’hyperscaler mentre il cliente si occupa della configurazione dei servizi di running.

Due esempi tra tutti:

• la piattaforma Kubernetes nella quale la componente di hosting di base è erogata direttamente dall’hyperscaler ma la distribuzione dei container e dei servizi periferici sono a carico del cliente.
• Il database server, la cui installazione e configurazione è demandata all’hyperscaler mentre le istanze delle singole basi dati sono a carico del cliente.

Il caso del database server si presta immediatamente al confronto con la soluzione IaaS dove viene allocata una macchina virtuale con pre-installato un sistema operativo la cui configurazione è a carico del cliente e sul quale sempre il cliente installa un database server.

Modello di servizio SaaS

Una risorsa cloud rilasciata con modello di servizio SaaS vede la maggiore responsabilità a carico dell’hyperscaler.
Il cliente interviene nella configurazione di esecuzione, non nella parametrizzazione generale della risorsa. Il cliente non interviene nella gestione del ciclo vita della risorsa. Per esempio i bug fixing di sicurezza, e gli aggiornamenti tecnici della risorsa sono gestiti, pianificati dal fornitore che provvede a pubblicare il piano di aggiornamento.
Il cliente è tenuto ad essere informato; viene comunque informato attraverso notifiche per i cambi di edizione e versione della risorsa cloud con eventuali introduzioni di non compatibilità a ritroso delle funzionalità erogate dalla piattaforma. La verifica della compatibilità di utilizzo da parte di altre risorse cloud o applicative è a carico del cliente.

Sempre utilizzando il caso di esempio di impiego di una risorsa cloud del tipo database server, nel caso di una risorsa cloud con modello di servizio SaaS  si andrà ad acquistare una istanza di una singola base dati. Si dovrà, come prima, dichiarandone il modello di impiego previsto, la stima delle risorse da impiegare in termini di disponibilità, scalabilità e cosi via.

Come cliente avrò la possibilità di costruire la struttura della base dati e utilizzarla.

Business Process as a Service

“Business Process as a Service” si presta ad una ampia gamma di interpretazioni.

Si fornisce l’interpretazione nell’ambito dell’ecosistema informativo cloud native.

Si può parlare di BPaaS quando un intero ecosistema cloud native è in grado di gestire le funzionalità a livello di processo per una specifica organizzazione.

Come organizzazione utilizzo il PBaaS per integrare o sostituire un processo esistente, la cui completa gestione è a carico del fornitore.

Un (ampio) insieme di risorse cloud costituisce un ecosistema informativo cloud, quando siano tutte organizzate per fornire un servizio finito.  

Per maggiori informazioni sull’ecosistema informativo cloud si può fare riferimento all’articolo Ecosistema informativo cloud native.

Per un approfondimento sulla possibilità di rappresentare un ecosistema informativo come servizio si può fare riferimento all’articolo Ecosistema informativo con ITIL 4

Tornando al caso d’uso utilizzato, che prevede la necessità di gestire una base dati, qualora sia fornita tramite un BPaaS esso fornirà la progettazione e realizzazione del modello dati cosi come dei sottosistemi informativi collegati alla comunicazione da e verso la base dati nei formati concordati a livello di specifica.

Il fornitore del BPaaS risponderà anche della conformità e rispetto delle normative di sicurezza e protezione dei dati e delle eventuali identità digitali gestite, nonché ovviamente del livello di servizio richiesto contrattualmente.

La sfida per il fornitore è grande.

L’opportunità per il cliente alta nel vedere la realizzazione di una soluzione dati realizzata in tempi brevi e certi, conforme alle normative nazionali ed internazionali.