Servizi di Cloud Computing per Industria 4.0: vantaggi e ostacoli

Quali sono le principali architetture di cloud computing?


La definizione di Cloud come l’insieme di risorse informatiche, e dei relativi servizi erogati, messe in comune attraverso le tecnologie web è oggi la definizione più condivisa, ma forse quella che semplifica molto i concetti e le architetture che ci sono alla base di queste tecnologie.

Agli albori del Cloud i sistemi sono stati classificati in tre sottoinsiemi principali: Software as a Service (SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). Basandosi su questa classificazione è stato definito il cosiddetto modello SPI, le cui lettere si riferiscono al Software, alla Piattaforma e all’Infrastruttura rispettivamente. In Figura 1 sono rappresentati i principali servizi e applicativi software e la loro gestione in accordo alla classificazione SPI.

Figura 1 – Suddivisione dei servizi e degli applicativi software nelle diverse architetture. I principali elementi sono le applicazioni, i dati, l’esecuzione di programmi (Runtime), l’interfacciamento tra i diversi applicativi con l’hardware (Middleware), i Sistemi operativi, le tecniche di virtualizzazione, i server, i dispositivi di raccolta dati e la rete di comunicazione (fonte Autore).

Il Software in un sistema Cloud è di solito basato su applicazioni web o Apps per sistemi mobili e rappresenta a volte l’unica interfaccia con il cliente. Si pensi ad un servizio di posta elettronica basata su Web, un motore di ricerca, un’interrogazione di una mappa. In tutti questi casi la tecnologia sottostante è ignota all’utente, che si limita semplicemente ad usare l’applicativo cosi come è. Ma il più delle volte questo non basta, poiché vi è la necessità di creare degli applicativi personalizzati sulle esigenze della propria impresa. In questo caso di parla di Piattaforme, che contengono algoritmi, sistemi operativi o dispositivi hardware interrogabili dall’utente facendo ricorso alle API (Application Programming Interface), cioè a delle funzioni sviluppate dal fornitore del Cloud, che possono essere invocate da un programma sviluppato dall’utente. Le API possono essere di diversi tipi: da librerie di funzioni che permettono l’interazione con un programma o una piattaforma software a semplicemente una serie di funzioni che uno sviluppatore può utilizzare per abbreviare il suo lavoro. Un esempio alquanto comune è offerto dalle API che permettono di usare Google Maps per diverse finalità: realizzare mappe personalizzate; integrare le mappe in siti web per servizi di ricerca georeferenziati; utilizzare le mappe all’interno di applicazioni per smartphone e tablet.

L’infrastruttura in un contesto Cloud è legata alla possibilità di usare il proprio computer solo come terminale remoto di un sistema di calcolo e di Storage che si trova localizzato in un punto diverso dell’azienda o del mondo. Di fatto questa è la più antica forma di Cloud e riporta agli albori del calcolo informatico.

Tutte e tre le categorie (Software as a Service – SaaS, Platform as a Service – PaaS e Infrastructure as a Service – IaaS) devono avere delle caratteristiche ben definite, affinché si possa implementare con efficacia la strategia digitale desiderata.

La prima caratteristica è quella del On-Demand Self-Service, cioè della opportunità per il cliente di disporre liberamente della capacità di calcolo, senza alcuna iterazione con il fornitore di servizio. L’utente è quindi autonomo nella scelta del livello di servizio secondo una logica di tipo pay-per-use.

La seconda caratteristica è quella del Broad Network Access, cioè la possibilità di accedere ai servizi in qualsiasi momento, in qualsiasi luogo e con qualsiasi dispositivo anche dotato di connessioni di tipo light.

Le prime due caratteristiche sono le più richieste in fase di configurazione di un servizio Cloud, perché sono facilmente associabili a bisogni aziendali ben precisi. A queste si aggiunge il Resource Pooling, cioè la condivisione delle risorse da parte di utenti (e molto spesso clienti) diversi. Questa funzione è fondamentale per un sistema cloud ben dimensionato dal punto di vista di chi deve gestirlo, ma implica, senza che ciò sia evidente all’utente, che questi non abbia alcun controllo sull’uso delle risorse e sulla loro disponibilità. Avere l’esclusiva delle risorse, può dare origine a contrattazioni economiche aggiuntive, o addirittura non previste nel piano del fornitore.

Figura 2 – Architettura di virtualizzazione: più dispositivi virtuali condividono lo stesso server fisico. (fonte VMware)

Una ulteriore caratteristica di un sistema cloud è la Rapid Elasticity, cioè la possibilità di scalare le risorse in modo automatico, permettendo in linea teorica al cliente di avere a disposizione risorse infinite, e questo è possibile attraverso le tecniche di virtualizzazione, cioè la creazione di dispositivi di calcolo che sono “visibili” solo all’utente come se fossero un dispositivo reale, ma di fatto sono associati a risorse dislocate su elaboratori differenti. Lo scopo della virtualizzazione è quindi quello di eseguire contemporaneamente più istanze di sistemi operativi su un’unica macchina fisica (o su più macchine fisiche) come mostrato in Figura 2. Il vantaggio è che il cliente non dovrà mai reinstallare la sua macchina se avesse bisogno di una macchina più potente, perché basterebbe solo cambiare la potenza del server da parte del fornitore.

Un altro aspetto importante è legato a come i servizi Cloud sono resi disponibili. Ad oggi le modalità di distribuzione del Cloud sono di tre tipi: Pubblico, Privato o Ibrido.

La prima modalità prevede che l’infrastruttura cloud sia di proprietà di una organizzazione (profit o no-profit) che vende i servizi al pubblico o ad un gruppo di imprese. Per chi decide di utilizzare questo modello i benefici sono dati dall’abbattimento dei costi di avviamento e la delega al fornitore della gestione dei rischi (legati all’infrastruttura). In questa modalità di distribuzione un aspetto cruciale concerne le garanzie sulla sicurezza e privacy dei dati, molto importanti in uno scenario aziendale. Esempi di questo tipo di cloud sono AWS di Amazon e Azure di Microsoft.

La seconda modalità, quella del Cloud Privato, prevede che le risorse siano utilizzate per l’uso esclusivo di una singola azienda, o di un gruppo di aziende. In questo caso l’infrastruttura è di proprietà o in leasing di una sola organizzazione. Questo modello garantisce sicuramente una maggiore sicurezza e riservatezza, ma può avere il rischio che alcune delle caratteristiche del Cloud elencate prima venga meno, perché è necessario prevedere a priori possibili espansioni. Esempi di Private Cloud sono quelli forniti da VMware e SalesForce.

L’ultima modalità è quella del Cloud Ibrido, dove l’infrastruttura è formata da uno o più Cloud, che possono essere pubblici o privati, coordinati per comportarsi come una entità unica. L’obiettivo di questo modello è quello di ridurre i limiti dei due modelli precedenti, ottenendo così un servizio più flessibile.

Non si può parlare del Cloud senza fare riferimento ai principali ostacoli alla diffusione del modello in ambito aziendale.

Il primo ostacolo riguarda la disponibilità del servizio: alcuni episodi hanno dimostrato come, in seguito ad incidenti o guasti tecnici, un singolo Cloud provider possa diventare un punto critico per la funzionalità aziendale, per cui molto spesso è necessario pensare a delle architetture ibride, basate su più Cloud, in grado di garantire una continuità di servizio.

Un secondo ostacolo riguarda i dati ed il fatto che molto spesso le API sono di proprietà di un determinato fornitore, per cui diventa difficile utilizzarli con altri fornitori, limitando o impedendo la portabilità in caso di cambio di servizio Cloud. Ciò richiede sempre di più la standardizzazione dei protocolli di archiviazione dei dati e delle API, in modo da garantire la possibilità di scegliere da parte del cliente.

Anche la riservatezza dei dati e la percezione che non sia facile verificare come questa sia garantita dai singoli fornitori rappresentano ostacoli per molti potenziali utenti di servizi Cloud, che ne rimandano l’adozione a causa dell’assenza di chiarezza in questo senso.

Ultimo aspetto è legato al collo di bottiglia sul trasferimento dei dati. Oggi utilizzare un servizio Cloud significa disporre di una banda per il trasferimento dati sufficientemente ampia, cosa che in alcuni territori non è garantita. Pertanto è necessario legare le architetture del Cloud a quelle dell’Edge computing, e alla capacità di gestire porzioni di dati in locale e differirne il trasferimento verso i server centrali, quando la connettività lo permette.

Note e riferimenti

[1] Peter Mell, Timothy Grance (2009), The NIST Definition of Cloud Computing, 2009. Reperibile al sito http://csrc.nist.gov.

[2] IBM, Autonomic Computing: IBMs Perspective on the State of Information Technology, 2001. Reperibile al sito http://www.research.ibm.com/autonomic/manifesto/ autonomic computing.pdf

[3] Chang V., Wills G., De Roure D., A Review of Cloud Business Models and Sustainability, School of Electronics and Computer Science, University of Southampton, 2010.


Agli albori del Cloud i sistemi sono stati classificati in tre sottoinsiemi principali: Software as a Service (SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). Basandosi su questa classificazione è stato definito il cosiddetto modello SPI, le cui lettere si riferiscono al Software, alla Piattaforma e all’Infrastruttura rispettivamente. In Figura 1 sono rappresentati i principali servizi e applicativi software e la loro gestione in accordo alla classificazione SPI.

Comments are closed.