[La prima parte di questa serie di dieci articoli ha esplorato gli elementi specifici da considerare quando si pianifica una nuova soluzione di Industrial Internet of Things, IIoT, dall’identificazione del proprio modello di business, alla pianificazione delle infrastrutture, all’analisi delle prospettive future del proprio settore e ha fatto riferimento allo sviluppo di MindSphere di Siemens su AWS. La seconda parte che prosegue a con questo articolo, esamina in modo specifico i vantaggi della progettazione sul cloud di AWS. Le indicazioni e le riflessioni contenute in questi articoli sono attribuite ad Alex Casalboni, Senior Developer Advocate AWS].
Leggi il primo articolo: Come costruire una soluzione IIoT su cloud con AWS
Leggi il secondo articolo: Piattaforme di Industrial IoT, come pianificare l’ecosistema di riferimento
Leggi il terzo articolo: Linee guida per progettare una soluzione IIoT sul cloud di AWS
Leggi il quarto articolo: Progettare una piattaforma IIoT su cloud: il tema della scalabilità
Leggi il quinto articolo: IIoT su cloud, come progettare per avere una distribuzione più rapida
Consideriamo in questo articolo i casi d’uso in multi-tenancy. Cosa succede se un’azienda ha bisogno che uno dei suoi clienti abbia accesso ai dati che sta raccogliendo?
Ad esempio, un produttore di impianti e uno dei suoi più grandi produttori di apparecchiature possono entrambi avere tenant separati sulla piattaforma e devono condividere i dati: il produttore di apparecchiature può avere bisogno di vedere i dati per la manutenzione e il produttore dell’impianto può avere bisogno di vedere i dati dell’intero impianto. In questi casi, sarà necessario disporre di un meccanismo di condivisione dei dati.
Una piattaforma IIoT utilizzabile a livello globale
Concepiamo la piattaforma pensando a clienti multi-regionali. Una piattaforma IIoT deve essere progettata fin da subito per l’accessibilità globale se ci si vuole rivolgere a clienti che hanno sedi in più regioni del mondo.
L’approccio allo sviluppo di una piattaforma al servizio dei clienti globali sarà quindi influenzato da diversi fattori.
La conformità normativa avrà un impatto sui luoghi in cui i dati possono essere memorizzati e su come e quando è possibile accedervi. Determinerà anche se si desidera offrire meccanismi di sincronizzazione/replicazione dei dati per favorire la disponibilità multiregionale o il failover. Da un punto di vista funzionale, sarà necessario considerare i casi d’uso che si desidera supportare in combinazione con la loro frequenza e il volume dei dati.
La migliore pratica comune è quella di lasciare che sia il cliente a decidere in quale regione vanno memorizzati i dati. Molti clienti richiederanno che i loro dati siano conservati localmente e Aws offre ai clienti la possibilità di decidere in quale regione vogliono consumare i servizi.
Dall’altro lato, i clienti potrebbero richiedere la possibilità di utilizzare i dati in modo interregionale. Ad esempio, potrebbero avere impianti di produzione in più regioni e volere che i dati siano memorizzati localmente per ogni impianto e richiedere allo stesso tempo l’utilizzo di dashboard interregionali e servizi di analisi per i dati di tutti gli impianti.
Per questo motivo sarà necessario fornire meccanismi per l’aggregazione interregionale, e determinare quali servizi vengono forniti come servizi globali e quali sono replicati in più regioni.
Ci sono altre complessità nel dare accessibilità globale.
Ecco alcuni elementi che si vedono comunemente quando si persegue questo percorso:
- Supporto multiregionale: Ciò comporta la messa a disposizione della piattaforma IIoT in più di una regione Aws, compresa l’archiviazione dei dati e l’utilizzo di alcuni o di tutti i servizi. Questo richiede di definire un approccio di rilascio per replicare l’insieme di soluzioni IIoT in un’altra regione Aws. Mentre i dati saranno archiviati localmente nella regione, bisognerà decidere se i servizi IIoT rimarranno globali (nella regione Aws primaria), se diventeranno regionali (replicati in ogni regione Aws supportata) o se diventeranno un mix a seconda del servizio. Ad esempio, potreste voler disporre di servizi di autenticazione globale e di servizi di dati centralizzati per i dispositivi, mentre l’elaborazione delle serie temporali dei dispositivi IoT rimarrebbe a livello regionale e locale.
- Supporto multi-tenant: il supporto multi-tenant comprende l’isolamento dei tenant e la separazione dei dati. Ciò richiede la separazione dei dati a livello di tenant ed il rispetto di questa separazione da parte di tutti i servizi della piattaforma in ogni regione.
- Uso interregionale: ciò comporta meccanismi di interrogazione e aggregazione dei dati in più regioni all’interno dello stesso tenant e richiede che si decida dove avverrà l’aggregazione. Si potrebbero stabilire servizi globali nella regione primaria per servire come punti di aggregazione che interagiscono con più regioni per le richieste relative ai servizi. Ciò si tradurrà in un sovraccarico di traffico interregionale reindirizzando il traffico dati verso la regione primaria. In alternativa, si può pensare di lasciare la logica di aggregazione al cliente e servire solo gli endpoint regionali. In questo modo si eviterebbe la necessità di traffico interregionale e si ridurrebbe l’overhead della piattaforma, ma si creerebbe una maggiore dipendenza sul client.
- Utilizzo cross-tenant: questo implica l’esistenza di meccanismi che consentono la condivisione e l’aggregazione dei dati tra più tenant, comprese le politiche di accesso ai dati per il controllo granulare dei permessi. Tali meccanismi possono includere la replica dei dati tra i diversi tenant o la creazione di pool di dati condivisi.
Implementare i building block
Lo sviluppo di una piattaforma IIoT multi-regione e multi-tenancy non è facile o veloce da implementare ed è necessario bilanciare vari elementi:.
- Segmentazione dei dati. In primo luogo, è necessario un modo coerente per segmentare i set di dati per poter applicare le regole giuste al livello appropriato, sulla base delle norme di conformità, delle leggi locali o di quanto scritto nel contratto.
- Strumenti di elaborazione dei dati. La segmentazione dei dati è vincolata dagli strumenti utilizzati, in quanto è necessario procedere nel modo che gli strumenti sono in grado di gestire. Ad esempio, potete eseguire la replica granulare di segmenti di dati tra le varie regioni senza dover introdurre molti strumenti aggiuntivi?
- Economie di scala. Si tratta di scegliere quando separare o condividere l’infrastruttura e quando non farlo. Se si separa l’infrastruttura per tenant, si avrà una crescita lineare dei costi man mano che il numero di inquilini cresce. Se si lavora completamente su infrastrutture condivise, allora si ottimizza l’efficienza di utilizzo e i relativi costi. Tuttavia, in alcune occasioni il vostro caso d’uso può crescere al di là dei benefici della scala delle infrastrutture condivise, il che può indurvi a passare a un uso dedicato.
- In alcuni casi, può essere meglio avere un’infrastruttura dedicata per ogni tenant per aumentare la trasparenza, permettendo di facilitare il monitoraggio dei costi o l’utilizzo della licenza. Per esempio, potreste avere flussi separati di Amazon Kinesis.
Come adottare metriche orientate al business
In questo flusso bisogna necessariamente considerare i costi operativi. Il raggiungimento dell’efficienza dei costi non dovrebbe essere l’obiettivo finale di un progetto, ma è importante che i team comprendano le metriche di business per poter bilanciare gli sforzi di ottimizzazione dei costi con le metriche di eccellenza operativa.
La priorità principale di ogni team dovrebbe essere sempre quella di raggiungere i propri obiettivi operativi di performance.
Ciò richiederà di stabilire indicatori di performance per i loro prodotti. Per questo, è fondamentale comprendere il contesto di business del prodotto che stanno sviluppando.
I clienti pagheranno in base al valore che il prodotto apporta loro, non a quello che costa. Quando si cerca di determinare il costo del prodotto, i team dovrebbero cercare il costo totale, comprese le infrastrutture e gli sforzi operativi e non considerare solo il costo delle licenze infrastrutturali ed i costi operativi.
A volte un servizio gestito ha un prezzo più alto rispetto all’alternativa non gestita, ma comporta anche una significativa riduzione degli sforzi operativi, prendete l’esempio di gestire un cluster Kafka di notevoli dimensioni invece di affidarvi ad Amazon Kinesis per il monitoraggio delle partizioni e per scalare gli shard.
Anche all’interno del portafoglio Aws, è possibile scegliere tra diversi livelli di gestione del servizio, si pensi per esempio ad Aws Fargate, che ha un prezzo per host più alto rispetto agli host di Amazon ECS, ma elimina lo sforzo operativo di gestione dei cluster di container.
Replicate questo sforzo in più regioni man mano che crescete, e vedrete come un’attenzione solo sul prezzo diretto di un servizio può spostare la vostra attenzione dal raggiungimento degli obiettivi di business.
In definitiva, l’economia può variare tra i diversi servizi, e il picco dei rendimenti può arrivare a scale diverse. Il raggiungimento di una particolare dimensione può essere un fattore scatenante per i team per riconsiderare le loro opzioni tecnologiche, ma confrontate sempre i costi di licenza del software e di l’infrastruttura, ed i costi operativi, rispetto a una semplice chiamata API con un servizio gestito da Aws.
Conclusioni
La creazione di una piattaforma IIoT è un processo difficile. Ci si troverà di fronte a sfide impegnative e le risorse diventeranno rapidamente difficili da allocare. Sfruttare il cloud per la vostra infrastruttura allevierà alcuni vincoli, offrendo inoltre la possibilità di ridurre o azzerare il tempo e le competenze necessarie per la manutenzione del proprio hardware, migliorando rapidamente le funzionalità della piattaforma grazie ai servizi cloud già esistenti.
Il prossimo articolo di questa serie si concentra sulla connettività e sull‘utilizzo di dispositivi industriali sul campo.
Leggi tutti gli articoli della serie
Piattaforme di Industrial IoT, come pianificare l’ecosistema di riferimento
Linee guida per progettare una soluzione IIoT sul cloud di AWS
Progettare una piattaforma IIoT su cloud: il tema della scalabilità
IIoT su cloud, come progettare per avere una distribuzione più rapida
