Negli ultimi anni stiamo assistendo a una “democratizzazione” delle piattaforme informatiche in cloud. In particolare, il paradigma denominato “serverless platform” consente di concentrare gli sforzi sul valore distintivo del business di riferimento, riducendo le risorse da investire per la gestione dell’infrastruttura di sistemi IoT (Internet of Things). Un esempio di questo trend è evidente nell’offerta sempre crescente dei cloud provider di soluzioni PaaS[1] (Platform-as-a-Service): datawarehouse gestiti direttamente in modo “trasparente” per gli utenti dai cloud provider, motori di streaming analytics e streaming processing, che consentono di applicare approcci di processamento parallelo ai “big data” che atterrano sulle piattaforme dati sotto forma di stream real time, sono esempi di questo paradigma. In questa breve analisi si valutano i benefici degli approcci serverless e l’impatto sui modelli operativi per l’erogazione dei servizi e il mantenimento di piattaforme di data ingestion, quali ad esempio piattaforme IoT.
Cloud computing non è sempre serverless
È opportuno distinguere il serverless dal cloud computing. Infatti, utilizzare il cloud non significa automaticamente avere una soluzione serverless. Esistono infatti una serie di scenari applicativi dove il cloud viene utilizzato in modo “tradizionale”, ossia assimilato a un data center dove “installare” e configurare (e poi di conseguenza gestire!) delle macchine. Nel caso del cloud si tratta in questo caso di macchine virtuali e non server fisici, ma comunque con relativo sistema operativo da installare, security patch da aggiornare e pacchetti software da mantenere.
In questo caso il cloud computing non viene sfruttato per le caratteristiche PaaS o SaaS[2] offerte sempre di più dal cloud provider, ma viene utilizzato in un approccio più tradizionale definito IaaS[3], che in qualche modo ripercorre il modo consueto di gestire HW e SW, anche se l’hardware viene virtualizzato nel dominio di un data center virtuale.
Questo approccio ha dei limiti non tanto nelle performance, quanto nel fatto che le macchine vanno gestite da una squadra di infrastructure operation che costantemente si occupi di applicare aggiornamenti e gestire e “limare” l’infrastruttura per il suo corretto funzionamento. Per sistemi complessi come piattaforme IoT questo può implicare l’utilizzo di team dedicati al mantenimento dei server, patching dei software installati o nella gestione di sistemi per l’ingestion mediante code (es. Cluster Kafka). Non è insolito avere necessità di installare molteplici patch di sicurezza alla settimana, con conseguenti interventi di manutenzione da programmare e gestire con opportune ridondanze operative (es. ingestion data pipeline ridondanti per consentire l’applicazione di security patch). Sicuramente questo è tipico per aziende che vogliono mantenere una organizzazione del lavoro simile agli sviluppi tradizionali on-prem ma non sfrutta i vantaggi derivanti da un approccio cosiddetto “cloud-native”.
Architettura di un sistema IoT
Per comprendere meglio le caratteristiche relative alla implementazione serverless in un caso concreto, si riporta come esempio l’architettura di riferimento per IoT (in Figura 1 seguente). I dispositivi connessi comunicano verso un device ingestion layer della piattaforma attraverso protocolli IoT (es. MQTT, CoAP, UDP) che quindi deve gestire questo primo layer attraverso una batteria di server di disaccoppiamento (es. server MQTT). I vari messaggi vengono poi inviati a un message layer di disaccoppiamento che consente di agire come “polmone” verso i blocchi funzionali che sono a valle nel core della piattaforma, in particolare le componenti di streaming processing che devono elaborare i dati in streaming (es. per operazioni di consolidamento di sessioni o detection di eventi e generazione allarmi). Il message layer è critico anche per tutte le operazioni di manutenzione e aggiornamento della logica funzionale che inevitabilmente sono necessarie nell’evoluzione dei servizi di una piattaforma. In caso di manutenzione, infatti, è possibile staccare le componenti a valle senza perdita di dati, dal momento che sono persistiti sulle code del message layer per il tempo necessario e possono essere recuperati successivamente.
Le informazioni così processate sono poi tipicamente inserite in un analytical layer che rappresenta il livello in cui i dati sono ritenuti e da cui poi, mediante opportune aggregazioni ed elaborazioni, sono esposte ai servizi per il consumo. Il transactional layer invece rappresenta l’esposizione verso API responsive (es. API per mobile app o dashboard real time) di dati real time che rappresentano lo stato del dispositivo IoT o di dati aggregati da esporre mediante Mobile App o webApp. Completano la blueprint architetturale anche un layer di gestione e configurazione dei dispositivi (es. invio di configurazioni di reporting, setup di soglie di reporting attributi) e un layer per la gestione dell’invio dei messaggi verso i dispositivi IoT (es. per segnalazione allarme verso i dispositivi stessi o di trigger per incrementare la frequenza di campionamento o refresh di uno stato del dispositivo come le sue coordinate geografiche o l’invio di dati in modalità real time di altre informazioni sensìte, come ad esempio il consumo di potenza istantanea per applicazioni energetiche).
Di seguito una tabella comparativa dei tre principali cloud provider con indicazione di alcune possibili opzioni disponibili.
Evoluzione dei modelli operativi: come ridurre il TCO[4]
Un aspetto importante nella scelta degli investimenti è la corretta valutazione dei modelli operativi per supportare lo sviluppo e la gestione di piattaforme IoT che cambia radicalmente se si sceglie un approccio serverless rispetto ad un approccio più tradizionale. Si riporta di seguito a titolo esemplificativo una tabella con comparazione di distribuzione di effort nel caso di implementazione di data pipeline tradizionale (con componenti IaaS come VM gestite direttamente da team infrastrutturali) e nel caso di utilizzo di paradigma serverless. Si prenda nuovamente come esempio lo sviluppo e gestione di una soluzione di streaming ingestion di una piattaforma IoT descritta nel paragrafo precedente. Dal momento che nel caso di soluzione serverless platform le macchine sono gestite direttamente dai runner del framework utilizzato, senza necessità di controllo diretto dell’hardware, le risorse necessarie ad amministrare questi servizi sono in numero decisamente inferiore.
Nel caso di piattaforma IoT il modello architetturale prevede un disaccoppiamento anche per la componente di device management con una batteria di server MQTT o UDP per poter gestire l’ingestion dei dispositivi e gli aspetti di sicurezza relativi alla connessione con i dispositivi: anche in questo mediante soluzioni managed serverless vengono utilizzati servizi cloud native e viene resa di conseguenza trasparente la gestione delle macchine che implementano la batteria di server che quindi possono scalare opportunamente dinamicamente in base al carico in ingresso, senza interventi manuali di operatori.
Infatti va considerato che la soluzione serverless è intrinsecamente dinamica e può scalare verso il basso (ad esempio riducendo drasticamente automaticamente il numero di workers in una data pipeline Dataflow[5] in caso di decremento del traffico dati), di conseguenza annullando notevolmente i costi fissi e minimizzando quelli variabili attraverso inseguimento automatico della domanda di carico, tipico per fenomeni IoT quali carichi notturni o picchi di utilizzo dei dispositivi (es. ore di punta di utilizzo di connected car in casi di smart mobility).
| Tipo di attività | Approccio Serverless | Approccio Tradizionale |
| Gestione fisica macchine (es. Runner streaming pipeline) | 0 | 5 |
| Gestione security patching delle macchine | 0 | 5 |
| Gestione ricambi HW o gestione VM | 0 | 2 |
| Sistemisti per SO | 0 | 4 |
| DBA | 0 | 4 |
| Deploy data pipeline | 1 | 5 |
| Gestione incident | 2 | 5 |
| Sviluppo streaming data pipeline | 2 | 5 message layer (es. Kafka) 3 data pipeline (es. Spark streaming) 2 DBA |
| Gestione message layer | 0 | 5 |
| Gestione device layer | 0 | 5 |
| TOT | 5 | 50 |
Accelerare l’architettura serverless con modelli DevOps
Nel caso di implementazione di architettura serverless, la definizione della infrastruttura assume ancora di più una accezione di configurazione software (in quella che viene definita come infrastructure as a code o IaC), che deve essere adattata e mantenuta nel tempo.
Nel momento in cui l’infrastruttura diventa gestita direttamente dal cloud provider (managed serv è possibile infatti avere dei semplici script che gestiscono il deploy “on demand” di complesse data pipeline applicative, ottimizzando l’infrastruttura sottostante attraverso framework come Dataflow[6].
Nonostante l’infrastruttura sia gestita autonomamente sul cloud, diventa fondamentale implementare le consuete best practices DevOps per poter garantire la tracciabilità dei cambiamenti e la qualità delle soluzioni portate in produzione. Anche se viene minimizzato il codice sviluppato, che diventa focalizzato sulle core business functions e non sulla infrastruttura, gli script di deploy devono essere versionati da sistemi di tracciamento e gestiti opportunamente mediante approcci come GitFlow o altri pattern di deploy.
Un aspetto importante e differente rispetto all’approccio tradizionale è il fatto che il confine tra codice infrastrutturale e codice applicativo diventa più labile: alcune capabilities PaaS infatti si presentano come una configurazione di sistema piuttosto che vero e proprio codice applicativo. Si pensi ad esempio all’uso di Composer (es. DAG Airflow) o alla configurazione di template Dataflow per l’esecuzione di pipeline BigData. In questi casi le componenti di Infrastructure as a code e componenti applicative – intese come business logic – vanno gestite con un approccio unificato e integrato. La distinzione, infatti, tra deploy pipeline applicative e infrastrutturali in questo caso perde gradualmente di significato a favore invece di strumenti e approcci unificati (cosiddette “integrated deploy pipelines”).
Conclusioni
Con l’evoluzione del cloud computing buona parte delle funzionalità che in precedenza dovevano essere gestite mediante una infrastruttura dedicata stanno diventando “managed services” e quindi gestite nativamente dai cloud. Questo fa sì che si possa concentrare gli sforzi sulle componenti applicative, riducendo le risorse per il mantenimento e l’operation dei sistemi abilitanti le piattaforme. Servizi come IoT ingestion, message layer, streaming processing, data warehouse per analytics, possono appoggiarsi su soluzioni managed che riducono drasticamente l’effort di erogazione, cambiando anche i modelli operativi di gestione dei servizi IT che passano quindi da essere modelli focalizzati sulla gestione della infrastruttura, a modelli focalizzati sull’erogazione del valore abilitati dall’utilizzo di capability presenti nel cloud. Questo consente di sfruttare economie di scala, facilitare resilienza nei sistemi e garantire una più ampia scalabilità dei servizi.
- PaaS: Platform as a Service ↑
- SaaS: Software as a Service ↑
- IaaS: Infrastructure as a Service ↑
- TCO: total cost of ownership ↑
- Dataflow è la soluzione che Google ha distribuito come open source col nome di Apache Beam. ↑
- Dataflow è la soluzione che Google ha distribuito come open source col nome di Apache Beam. ↑
