[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
Il cammino verso la scalabilità IIoT
I servizi cloud AWS sono creati per una scalabilità senza sforzo, ma entro i limiti del servizio stesso.
Molti hanno una scalabilità automatizzata che aggiungerà risorse in più zone di disponibilità o addirittura su più regioni man mano che si cresce.
Tuttavia, la scalabilità non riguarda solamente le configurazioni di elaborazione fisica orizzontale e verticale, ma anche i servizi hardware e software correlati.
Dovete anche progettare in modo intelligente la vostra piattaforma IIoT per gestire tutti i tipi di scalabilità, altrimenti rischiate di non essere in grado di gestire i carichi dei vari casi d’uso.
Prendere in considerazione i limiti dei servizi AWS
Ogni servizio AWS ha alcuni limiti flessibili ed altri limiti più rigidi.
Sia che utilizziate i vostri microservizi con auto-scaling policy su macchine virtuali (Amazon EC2), container (Amazon ECS/EKS), o serverless (AWS Lambda), il vostro carico di lavoro richiederà un’infrastruttura fisica. Questa infrastruttura, che è gestita per voi, ha dei limiti.
I limiti flessibili vi proteggono da una capacità eccessiva che potrebbe non essere necessaria e può essere aumentata su richiesta.
I limiti rigidi sono radicati nella progettazione del servizio AWS e non possono essere modificati.
Ad esempio, se si utilizza Amazon Kinesis Streams per l’elaborazione dei dati, è possibile attivare un’azione di aumento o riduzione della scalabilità solo due volte ogni 24 ore; le tabelle abilitate per lo streaming di DynamoDB hanno un limite di 1.000 scritture al secondo.
Scalare può avvenire automaticamente per un servizio, ma può comunque richiedere un tempo di avvio per il caricamento dell’infrastruttura (per il rifornimento di un altro container o infrastruttura sottostante su cui il carico è in esecuzione o per riorganizzare il carico sulla nuova infrastruttura).
Siate consapevoli di tutti i limiti del servizio e costruite una soluzione che funzioni entro questi limiti.
Considerare i limiti della soluzione/piattaforma IIoT
Una volta che la piattaforma è pronta per l’uso, come affronterete i picchi inaspettati che raggiungono i limiti del servizio? Se aprite le API della vostra piattaforma allo sviluppo di terzi, questo porta imprevedibilità all’uso effettivo della vostra piattaforma in qualsiasi momento e nuove applicazioni potrebbero utilizzare le vostre API con più traffico di quanto la vostra piattaforma possa gestire.
Questo vi porterà a raggiungere i limiti di servizio dei vostri servizi AWS sottostanti (sia in base ai limiti rigidi che alla vostra configurazione) e potenzialmente causare disservizi o perdita di dati.
Volete gestire queste situazioni in modo proattivo o reattivo? Oppure volete assicurarvi che non si verifichino?
Per evitare queste situazioni, potreste sovradimensionare la vostra infrastruttura per coprire i picchi di utilizzo. Se non siete in grado di prevedere le vostre effettive esigenze in un determinato momento, questo può essere d’aiuto, ma è molto costoso.
Un modo migliore per gestire i limiti di capacità è quello di comunicare un modello di responsabilità condivisa, definendo le condizioni di utilizzo della soluzione/piattaforma IIoT e riportando i limiti attuali della piattaforma agli sviluppatori mentre ne misurate l’utilizzo – alti, bassi, picchi e medie giornaliere/settimanali.
Tuttavia, l’utilizzo non intenzionale o non pianificato dei servizi IIoT può comunque verificarsi, quindi dovete essere pronti a gestirlo. Potreste far rispettare i limiti del vostro servizio IIoT spingendo gli sviluppatori a segnalare le loro esigenze di capacità al momento della registrazione.
Un altro modo per gestire i carichi è quello di far sì che i vostri dispositivi sul campo inviino notifiche quando i limiti stanno per essere raggiunti. Queste notifiche possono far scattare i servizi IIoT per allocare più capacità.
Nel complesso, se non si pongono limiti su come la vostra piattaforma può essere utilizzata, prima o poi, la stabilità della vostra piattaforma può diventare un problema.
I limiti di servizio di AWS riducono il potenziale impatto negativo causato dal consumo eccessivo di risorse da parte di un singolo cliente sul resto dei clienti.
Questo è un modello nello sviluppo della piattaforma e come ogni altra piattaforma condivisa, o multi-tenant, anche MindSphere utilizza i limiti per gestire il carico della sua infrastruttura sottostante.
Dare le giuste dimensioni all’infrastruttura
La giusta dimensione della vostra infrastruttura va di pari passo con la gestione di picchi di utilizzo anticipati o imprevisti, e con la capacità di calcolo che rilasciate quando non è più necessaria. All’inizio, stabilite le politiche di base e di scalabilità e ottimizzate la loro configurazione per adattarla al meglio al comportamento del carico di lavoro.
Il giusto dimensionamento va anche oltre la produzione. Infatti, gli sviluppatori spesso trascurano il costo dell’implementazione dell’infrastruttura in più fasi.
I vostri ingegneri hanno intenzione di sviluppare e testare 24 ore su 24? In caso contrario, allora è meglio ricorrere a politiche di auto-scaling più aggressive: tempi di avvio e di arresto programmati per le vostre risorse, o addirittura utilizzare l’implementazione on-demand dei vostri ambienti.
Quando vi muovete lungo le fasi dallo sviluppo alla produzione, replicate i costi, quindi cercate di renderli il più bassi possibile.
Stabilite le regole di utilizzo dei diversi ambienti. Sfruttate le diverse famiglie e dimensioni di istanza per soddisfare al meglio le vostre esigenze. Evitate di replicare i costi non necessari in tutte le fasi.
Ad esempio, se il vostro modello d’uso presenta molti picchi, valutate il passaggio a una famiglia di istanze T3.
Con l’ampia scelta di tipi di istanze EC2, con le capacità di automazione come l’autoscaling e lo scaling basato su metriche utilizzando Amazon CloudWatch e AWS Lambda, è possibile ottenere risparmi significativi sui costi non solo in produzione ma anche negli ambienti di sviluppo e di test.
