AWS e IBM: un confronto tra servizi IoT: 4 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:02

Oggi confrontiamo due stack che consentono di sviluppare applicazioni IoT nell'ottica di diverse offerte di servizi.

Passaggio 1: funziona come un servizio

FaaS è una categoria di servizi cloud utilizzati per costruire un'architettura "serverless". FaaS consente ai clienti di sviluppare, eseguire e gestire le funzionalità delle applicazioni senza creare e mantenere l'infrastruttura.

Amazon offre AWS Lambda, IBM offre IBM Cloud Functions. Questi servizi sono abbastanza simili, tuttavia Lambda è stato il primo di questo tipo. Usando FaaS puoi eseguire pezzi di codice nel cloud e ogni servizio supporta diversi linguaggi di programmazione.

Funzioni IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# ecc.), Qualsiasi tramite Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Qualsiasi tramite API di runtime

IBM supporta più lingue e con docker è facile utilizzare script scritti in altre lingue. Si può fare anche con Lambda ma non è immediato. Puoi leggere un esempio qui:

Entrambi i servizi hanno dei limiti di utilizzo, li riportiamo in una tabella ed evidenziamo i migliori.

Il prezzo è basato su GigaBytes per secondo (RAM) con l'aggiunta del numero di richieste per AWS Lambda. Ogni servizio ha un piano gratuito e sono quasi equivalenti. Come puoi vedere Lambda è un po' più economico per i GB/s ma ha un costo relativo alle richieste che Cloud Functions non ha, quindi il costo è quasi lo stesso in generale. Ovviamente, se hai bisogno di eseguire attività che consumano memoria e utilizzano poche richieste, dovresti usare Lambda. Il vantaggio principale di IBM Cloud Function, a nostro avviso, è che il suo stack è open source. È completamente basato su Apache OpenWhisk e può essere distribuito anche su un'infrastruttura privata.

Passaggio 2: apprendimento automatico

Un campo in cui gli stack IBM e AWS offrono servizi simili è quello del machine learning: Amazon con il suo SageMaker e IBM con Watson Machine Learning. I due servizi sono per molti aspetti molto simili: entrambi si presentano come strumenti per aiutare i data scientist e gli sviluppatori a costruire, addestrare e quindi distribuire in ambienti pronti per la produzione i loro modelli di machine learning, ma le filosofie che le due aziende adottano variano parecchio. Entrambi i servizi ti consentono di scegliere tra diversi gradi di controllo sui modelli che utilizzi. In Watson ML, hai alcuni modelli incorporati che sono già addestrati per svolgere alcune attività molto specifiche: ad esempio, se vuoi riconoscere quali oggetti sono presenti in un'immagine, basta importare il modello VisualRecognitionV3 e passargli l'immagine vuole analizzare. Puoi anche creare un "modello personalizzato", ma in Watson ML questo significa principalmente prendere un modello già costruito e fare la nostra formazione su di esso, quindi la personalizzazione è piuttosto limitata. È importante notare, tuttavia, che né SageMaker né Watson ML sono gli unici modi per eseguire l'apprendimento automatico sugli stack dei loro sviluppatori, sono solo servizi che mirano a semplificare la vita degli sviluppatori. La piattaforma Watson ML supporta anche molte delle librerie di machine learning più popolari, quindi puoi persino creare un modello da zero con PyTorch, Tensorflow o librerie simili. O usi direttamente quelle librerie o usi i modelli prefabbricati, non ci sono vie di mezzo. Inoltre Watson ML non supporta la libreria scelta da Amazon, Apache MXNet, che invece ha un supporto di prima classe in SageMaker.

L'approccio di Amazon SageMaker, anche quando si utilizzano opzioni integrate, è di livello un po' più basso: invece di farti scegliere tra modelli prefabbricati, ti consente di scegliere tra una pletora di algoritmi di addestramento già implementati, che puoi utilizzare quando crei il tuo modello in modo più tradizionale. Se questi non sono sufficienti, puoi anche utilizzare il tuo algoritmo. Questo modo di fare cose richiede sicuramente più conoscenza su come viene eseguito l'apprendimento automatico rispetto al semplice utilizzo di un modello addestrato in Watson ML.

A prima vista può sembrare che Watson ML sia il modo "facile e veloce", con Amazon SageMaker quello più complesso da configurare. Questo potrebbe non essere del tutto vero da alcuni punti di vista, in quanto SageMaker è strutturato per far funzionare tutto su un Notebook Jupyter, mentre per le stesse funzionalità in Watson ML è necessario impostare molti sottoservizi diversi dall'interfaccia utente web. La pre-elaborazione dei dati ha anche spazi dedicati sul servizio IBM mentre SageMaker si affida a te per fare tutto dal codice nel tuo notebook. Questo, oltre al fatto che i notebook Jupyter non sono esattamente la scelta migliore dal punto di vista dell'ingegneria del software, potrebbe impedire a SageMaker di scalare molto bene in produzione. Entrambi i servizi hanno meccanismi abbastanza buoni e semplici per distribuire il tuo modello e rendere disponibili le relative API nel mondo esterno.

In conclusione, Watson ML si comporta meglio in grandi progetti in cui i notebook Jupyter iniziano a mostrare i loro limiti e dove non è necessaria molta personalizzazione in ciò che fa il modello stesso. SageMaker è molto meglio quando hai bisogno di maggiore flessibilità nella definizione degli algoritmi, ma quando lo usi devi tenere conto del fatto che devi fare affidamento su Jupyter Notebook, che potrebbero non scalare bene in produzione. Una soluzione potrebbe essere quella di disaccoppiare il più possibile il resto del codice dal modello, in modo che il codice nei notebook reali non diventi troppo grande e possiamo organizzare meglio il nostro software negli altri moduli che utilizzano semplicemente l'API del nostro modello.

Passaggio 3: streaming di dati e analisi

I servizi di data streaming sono fondamentali per la gestione e l'analisi in tempo reale di grandi flussi di dati. Questo flusso può essere dal cloud al dispositivo degli utenti, come uno streaming video, o dagli utenti al cloud, come la telemetria IoT e le letture dei sensori. Soprattutto nel secondo caso, potremmo avere una situazione in cui singole fonti caricano piccole quantità di dati ma se consideriamo il throughput complessivo, proveniente da tutti i dispositivi, consuma una notevole larghezza di banda, quindi ha senso utilizzare un servizio specializzato per gestire tali flussi di dati. Senza gestire direttamente questo flusso continuo, dovremmo archiviare le informazioni in arrivo in una memoria temporanea e in un secondo momento elaborarle con un motore di calcolo. Il problema di quest'ultimo approccio è che dovremmo coordinare più servizi diversi per ottenere ciò che un singolo servizio di flusso di dati fa già da solo, aumentando la complessità della manutenzione e della configurazione dell'applicazione. Inoltre, il buffering può in linea di principio rendere la nostra applicazione non più in tempo reale, poiché per elaborare un articolo è necessario che anche tutti gli altri articoli prima di esso vengano elaborati e aggiungendo criteri di precedenza al buffer possano, di nuovo, aumentare drasticamente la complessità. Riassumendo, i servizi di data streaming offrono la gestione del flusso di dati in tempo reale, con una configurazione semplice e possono fornire analisi sui dati in entrata. Qui confrontiamo i due principali servizi di streaming dello stack IBM e AWS, ovvero IBM Streams e AWS Kinesis.

Iniziamo notando che tutte le funzionalità di base che potremmo desiderare da un servizio di streaming sono offerte sia da IBM che da AWS. Queste funzionalità includono velocità di elaborazione praticamente infinita, bassa latenza e analisi dei dati in tempo reale. Poiché stiamo parlando di servizi professionali, entrambi offrono strumenti di livello produttivo per l'implementazione e l'automazione.

Parlando di analisi dei dati, entrambi i servizi lo offrono come optional, facendoti pagare solo se ne hai bisogno o meno. Nel caso di Kinesis, quando non è necessaria l'analisi ma solo la gestione del flusso di dati, i prezzi vengono addebitati per GB elaborati anziché per tempo di elaborazione, come nel caso IBM. Il prezzo per GB sarà generalmente meno costoso del prezzo per volta, poiché paghi solo per il traffico in entrata. Per il resto di questo post prenderemo in considerazione sia IBM Streams che AWS Kinesis con la funzionalità di analisi dei dati abilitata.

Streams e Kinesis forniscono l'integrazione con diversi servizi per la pre-elaborazione e il filtraggio dei dati in ingresso prima di passarli all'analisi dei dati, rispettivamente con Apache Edgent e AWS Lambda. Sebbene questi servizi siano radicalmente diversi l'uno dall'altro, ne parleremo solo dal punto di vista dei due servizi di streaming. La differenza fondamentale tra i due è che Apache Egent viene eseguito sul dispositivo, mentre AWS Lambda viene eseguito sul cloud. Questo porta molti pro e contro: dal lato Lambda abbiamo un servizio flessibile e facile da usare con una perfetta integrazione con Kinesis, ma richiede che i dati siano già caricati nel cloud, perdendo così in efficienza e pagando anche Kinesis per i dati che verranno eventualmente eliminati. Dal lato Edgent invece, abbiamo che la maggior parte del calcolo viene fatto, beh, ai margini della rete (quindi sui dispositivi) prima di caricare dati inutili sul cloud. Lo svantaggio principale è che Edgent è un framework di grandi dimensioni, che potrebbe richiedere tempo per l'impostazione e potrebbe essere complesso da mantenere. Un'altra differenza che potrebbe essere rilevante nella scelta di una piattaforma è che Edent è completamente open source, Lambda no. Questo può essere visto sia come un pro, poiché avere accesso al codice che tu o il tuo cliente eseguirete è sempre una cosa positiva, sia come un contro, perché ci possono essere situazioni in cui hai bisogno di un supporto urgente che non può essere fornito in tutti gli ambienti open source.

Un'altra caratteristica che possiamo menzionare è l'auto-scalabilità di Kinesis delle risorse allocate. Infatti, l'hardware che offre è composto da una serie di cosiddette Kinesis Processing Units (KPU) che funzionano in parallelo, dove una KPU offre 1 vCore e 4GB di RAM. Il loro numero dipende dalle esigenze dell'applicazione e sono allocati in modo dinamico e automatico (quello che paghi è infatti il tempo della CPU moltiplicato per il numero di KPU), ricorda solo che è una politica di Kinesis farti pagare una KPU in più se usi un Java applicazione. IBM Streams, invece, non fornisce questo tipo di flessibilità, offrendoti un container con hardware fisso, maggiori dettagli quando si parla di prezzi. D'altra parte, IBM Streams è più aperto di Kinesis, poiché si interfaccia alla WAN tramite protocolli di uso comune, come HTTP, MQTT e così via, mentre Kinesis è chiuso all'ecosistema AWS.

Come confronto finale parliamo dei prezzi e lasciatemi dire che IBM non funziona alla grande su questo punto. Abbiamo configurato diverse soluzioni per tre diverse categorie (basic, high-end, ultra-high-end) sia per IBM che per AWS e confronteremo il loro prezzo. Nella configurazione base abbiamo una KPU AWS, menzionata in precedenza, contro una soluzione IBM con lo stesso hardware. Per la fascia alta abbiamo 8 KPU in esecuzione parallele per Kinesis e 2 container sempre in parallelo per IBM, ognuna con 4 vCore e 12GB di RAM. Sempre IBM propone nella fascia ultra alta un unico container con 16 vCore e 128GB di RAM, mentre abbiamo omesso una soluzione equivalente per AWS, poiché se qualche applicazione richiedesse questa grande quantità di RAM non sarebbe possibile eseguirla su diverse KPU. I prezzi che riportiamo sono espressi in $/mese considerando un utilizzo 24/7. Per la configurazione base abbiamo per IBM e AWS rispettivamente 164$ e 490$, per l'high-end 1320$ e 3500$, per l'ultra-high-end AWS non viene considerato e c'è solo IBM con 6300$. Da questi risultati possiamo vedere che Kinesis funziona meglio per l'utente quotidiano fino al livello aziendale, mentre manca di opzioni per gestire direttamente l'analisi dei dati che richiedono un'enorme quantità di potenza di calcolo. Kinesis offre un miglior rapporto prestazioni/$ rispetto a IBM Streams, aiutato anche dall'allocazione dinamica di piccoli blocchi di risorse solo quando necessario, mentre IBM ti offre un container fisso. In questo modo, se il tuo carico di lavoro è caratterizzato da picchi, con IBM sei costretto a sovrastimare le tue esigenze applicative e configurare una soluzione nel peggiore dei casi. IBM offre tariffe orarie invece di pagare l'intero mese, ma non è automatizzato come Kinesis.

Passaggio 4: architettura IoT

La configurazione dei dispositivi per aws iot è abbastanza semplice rispetto a ibm watson iot. Perché in ibm watson iot l'autenticazione è per dispositivo con token e una volta visualizzato il token non verrà mai più visualizzato. Tornando alla parte dei prezzi, l'ibm watson iot è piuttosto costoso rispetto a aws iot. Quindi, il prezzo in ibm watson iot charge si basa su per dispositivo, archiviazione dati, traffico dati. Ma in aws iot possiamo pagare l'importo una volta e possiamo aggiungere più dispositivi e dati pubblicati dai dispositivi e consegnati ai dispositivi.

Inizia con il tuo dispositivo, che sia un sensore, un gateway o qualcos'altro, e lascia che ti aiutiamo a connetterti con il cloud.

I dati del tuo dispositivo sono sempre al sicuro quando ti connetti al cloud utilizzando il protocollo di messaggistica MGTT aperto e leggero o HTTP. Con l'aiuto di protocolli e node-red possiamo connettere il nostro dispositivo con la piattaforma iot e accedere a dati in tempo reale e storici.

Usa le nostre API sicure per connettere le tue app ai dati dei tuoi dispositivi.

Crea applicazioni all'interno del nostro servizio cloud per interpretare i dati.