[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à
La flessibilità dei cicli di sviluppo e di rilascio sono la chiave del successo di un progetto IIoT. L’allineamento corretto e ponderato dei team interni per ottimizzare l’efficienza al fine di accelerare i cicli di sviluppo è di fondamentale importanza.
A livello di base evitate di fare tutto in una volta, formate piccoli team sulla base dei microservizi, riducete le dipendenze tra essi e fornite ai team gli strumenti e i processi necessari per un rilascio più rapido.
Ridurre le dipendenze di rilascio tra i team
È consigliabile strutturare i team di sviluppo di un progetto IIoT sulla base dei microservizi e disassociare quest’ultimi per ridurre le dipendenze di rilascio.
L’adozione di DevOps come strategia per ogni team di sviluppo e la fornitura degli strumenti e processi necessari per un’implementazione veloce, frequente e indipendente, consentono una maggiore indipendenza dei team su piccola scala.
Ma man mano che la vostra area di azione aumenta, cresce anche la complessità e mentre sulla piattaforma vengono resi disponibili più prodotti e servizi, è necessario assicurarsi che le API non perdano la loro indipendenza.
Alla fine, se avete più team che si sviluppano all’interno della stessa area di prodotti/servizi, è consigliabile co-localizzarli per ridurre le barriere di comunicazione.
La collaborazione diventa certamente un problema su scala globale se i vostri team hanno solo una finestra di tempo limitata per interagire.
Per questo tipo di situazione, la gestione delle dipendenze dei team è fondamentale e richiede di trovare il giusto equilibrio tra gli estremi di un approccio monolitico e un modello completamente distribuito. Se non si riesce a trovare il giusto equilibrio, si avrà una duplicazione degli sforzi o un monolite troppo rigido che rallenta tutti i team.
La chiave è avere una buona scomposizione dei servizi e farli evolvere nel tempo. Sfruttare i principi del framework AWS Well-Architected aiuterà in questo percorso.
AWS offre anche più livelli su cui i microservizi dei diversi team possono essere condivisi o separati, anche sul singolo servizio AWS, sul virtual private cloud (VPC) o sull’account.
Decidete quando preferite che i team rilascino servizi sullo stesso cluster, all’interno dello stesso VPC e dello stesso account, e quando volete imporre la separazione per una maggiore indipendenza e tolleranza ai fallimenti.
Un altro modo per organizzare i team è quello di renderli clienti l’uno dell’altro, assegnando quindi i responsabili dei prodotti all’interno di ogni team per pianificare e dare priorità alle nuove funzionalità in base alla roadmap.
Infine, potreste voler creare un team specializzato su tecnologie cloud per aiutare a implementare l’infrastruttura di base, come i cluster di calcolo e di database.
Questo favorirà le migliori pratiche infrastrutturali per l’implementazione IIoT in modo altamente flessibile, scalabile e sicuro, oltre ad accelerare la standardizzazione e la maturità dei team DevOps.
Stabilire standard e strumenti minimi
Creare un toolkit comune tra i team per lo sviluppo, la collaborazione e la comunicazione. La produzione di design pattern comuni consente di condividere facilmente le migliori pratiche in materia di rilasci e operazioni, soprattutto quando si lavora con un team globale.
Gli standard minimi per il ciclo di sviluppo dovrebbero includere strumenti, framework e modelli architetturali, oltre a pipeline predefinite di CI/ CD, framework approvati per l’Infrastructure as Code (comprese le policy ed i template di Infrastructure as Code per l’alta disponibilità), auto-scaling, backup/ripristino dei dati, rilasci blue/green sui vostri cluster applicativi e dei database, template per l’utilizzo di container Docker con servizi come Amazon Elastic Container Service, e così via.
È importante stabilire anche un processo comune a tutta la piattaforma IIoT per la certificazione delle immagini del sistema operativo e per la manutenzione, avendo un catalogo di immagini sempre aggiornate. Questo fornisce una libreria open source centralizzata, anziché una libreria separata per ogni team.
Monitorare lo stato dei rilasci
Definire le metriche per valutare la salute di un rilascio prima di iniziare a rilasciare le prime versioni dei servizi. Questo stabilisce gli obiettivi e la direzione corretta per tutti i team. All’inizio, lasciate che i team monitorino e reagiscano alle metriche manualmente durante il ciclo di rilascio.
Maggiore è la frequenza delle nuove versioni, migliore sarà la comprensione della salute dei rilasci che i team svilupperanno. Man mano che i team acquisiscono esperienza, iniziate ad automatizzare le reazioni, ad esempio completando un rollback ad una versione precedente basata sulle metriche.
Infine, dovreste iniziare a utilizzare traffico sintetico per monitorare lo stato dei vostri microservizi al di là delle finestre di rilascio.
Favorire la sperimentazione
Anche in ambito IIoT avere procedure standard per i rilasci e per i test è obbligatorio, ma è anche necessario lasciare spazio alla sperimentazione e alla casualità.
Il vostro processo di implementazione potrebbe richiedere che ogni team rilasci tramite una pipeline basata su Infrastructure as Code. Ma è importante dare ai team un modo per sperimentare al di là del processo di rilascio formale, ad esempio fornendo l’accesso ad account o sandbox temporanee per provare nuovi servizi e modelli architetturali.
Allo stesso modo è obbligatorio disporre di procedure standard per i test. Tuttavia, questo non vi preparerà all’ignoto o all’imprevisto. Dovrete fare test out-of-the-box, come le giornate di sperimentazione e le giornate di ingegneria del caos.
Per esempio, per scoprire dove si nascondono colli di bottiglia e guasti nel sistema, potreste voler iniettare diversi tipi di carichi di lavoro con diversa frequenza mentre spegnete casualmente alcune istanze. C’è un comune malinteso che tali formati di test tolgano il tradizionale ruolo di test e di garanzia della qualità.
La gestione della casualità e dei guasti può addirittura rendere le persone nervose, tuttavia, l’introduzione di un certo grado di casualità nei vostri processi operativi è essenziale per ottenere una migliore comprensione di come si comporta il sistema.
Scoprire i colli di bottiglia del sistema IIoT attraverso la sperimentazione e la casualità è un elemento chiave dell’apprendimento, in grado di dare agli sviluppatori l’opportunità di identificare le ragioni alla base del fallimento. Imparare da questi fallimenti vi aiuterà a capire come il sistema si comporta in circostanze insolite, il che è fondamentale se volete avere un sistema distribuito altamente resiliente.
