Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
Spesso si pensa che il Machine Learning consista unicamente nella costruzionde di un modello, come ad esempio un Transformer o una CNN. Le cose purtroppo sono più complicate di cosi. Un vero prodotto consiste comunque in un architettura software dove il Machine Learning ne è solamente una parte benchè cruciale. Quindi ci sono molte cose a cui pensare, come ottimizzare la latency o il thoughput, come far si che i vari processi comunichino bene tra di loro, o ancora come passare i dati da un processo ad un altro.
In questo articolo vorrei concentrarmi specialmente su quest’ultimo aspetto, in un’architettura software abbiamo molti processi (che spesso si traducono in servizi indipendenti), e questi processi utlizzano e creano dati che sarano dati in pasto ad altri processi. Pensare a come gestire questo flusso di dati non è una cosa banale.
Esistono principalmente tre modi per passare dati attraverso vari processi:
Questo è il metodo forse più facile ed intuitivo. Supponiamo che il processo A deve processare dei dati e creare un risultato x. Il processo B in seguito necessita di quel risultato x per partire. Quello che possiamo fare è creare un database comune dove A può andare a scrivere i suoi risultati, e dove B può leggere i risultati prodotti da A.
Quali sono i limiti però?
Stiamo supponendo che entrambi i processi A e B abbiano la possibiltà di accedere ad un database comune, ma questo non è sempre possibile. I due processi potrebbero appartenere a due compagnie diverse, e nessuna delle due per esempio vuole dare l’accesso al proprio DB all’altra.
Analizziamo il caso ora in cui i processi si scambiano direttamente i dati utilizzando la rete. La prima cosa che succede è che B deve fare una richiesta per ricevere i dati verso A. In seguito A invierà i dati richiesti direttamente al processo B. Siccome c’è bisogno di una richiesta, questa modalità viene chiamata request-driven.
Questa modalità solitamente viene utilizzata all’interno ad un architettura a microservizi. Si potrebbe parlare moltisimo di questo, ma pensate che un processo sia un servizio a se stante, con un DB locale, e non dipendente (almeno per quanto possibile dagli altri). Questo aiuta a mantenere il codice, perchè possiamo modificare un servizio senza toccare gli altri. Inoltre abbiamo una tolleranza maggiore, perchè se un servizio cade, gli altri continuano a funzionare.
Quindi pensiamo al fatto che a volte questi servizi hanno bisogno di scambiarsi dei dati. Ma quali sono gli standard usati per lo scambia di dati? Ne abbiamo principalmente due, REST e RCP.
REST, che sta per REpresentational State Transfer, è uno standard che facilita la comunicazione tra servizi. Un implementazione di un’archtiettura conforme allo standard REST, è chiamata RESTful. Ad oggi le chiamate REST predominano il web. Ad esempio tutti i moderni tool basati su chatGPT non fanno altro che eseguire una chiamata REST ad un servizio di OpenAI.
RPC è un altro standard. Ad oggi è molto meno usato, ed assomiglia più al richiamare un servizio come se fosse una funzione o metodo all’interno del codice.
Utilizzare il real-time transport può essere utile quando l’architettura è più complicata. Immaginiamotre servizi, che sono per forza di cose dipendenti l’uno dall’altro. Cioè ogni servizio a bisogno di chiedere dati agli altri due per funzionare.
Vedete come con solamente tre servizi le cose possano complicarsi molto. Spesso in prodotti reali i servizi posso essere decine se non centinaia.
Invece di far si che ogni servizio comunichi con tutti gli altri, potremmo creare un broker che si occupi del flusso di dati, quindi ogni servizio dovrà solamente essere collegato al broker.
Questa architettura non è event-drive, cioè il Broker gestisce il corretto flusso di dati allo scaturirsi di particolari eventi. Ci sono due modi di implementare il real-time transport.
Il pubsub, in cui un servizio publica dei dati, taggandolo secondo uno specifico topic. Gli altri servizi sono registrati a quel topic, quindi quando viene publicato qualcosa loro lo leggono imeediatamente. Un pò come quando voi vi iscrivete a diversi journals su Medium per esempio.
Nel message queue model, invece la publicazione di dati ha dei destinatari specifici.
Voglio sottilineare che spesso la creazione di modelli di Machine Learning o Deep Learning costituisce solamente una piccola parte del lavoro quando si crea un prodotto basato su AI. E’ molto importante possedere competenze di software engineer, perchè alla fine della giornata quello che produciamo è un software. Capire come gestire il flusso dai dati è cruciale. Senza dai l’AI non funziona.
Spero che questo articolo vi abbiamo un pò chiarito le idee sui piu comuni tipi di architettare per la gestione del flusso di dati.
È uscito il sesto episodio di Betti-RHC, la serie a fumetti di Red Hot Cyber nata con l'obiettivo di trasformare la cybersecurity awareness in un'esperienza di formazione più semplice, coinvolgente e accessibile. Quello che è nato come un progetto editoriale innovativo è diventato negli anni un vero e proprio corso di cybersecurity awareness a fumetti, adottato da aziende e professionisti per sensibilizzare le persone sui rischi informatici attraverso storie, personaggi ed emozioni. In cinque anni di attività, la serie Betti-RHC ha raggiunto un risultato importante: circa 70.000 copie vendute, a testimonianza dell'interesse crescente delle organizzazioni verso nuovi strumenti per costruire una concreta cultura della sicurezza.
Il sesto episodio porta Betti dentro le nostre case, in un mondo "connesso", dove lampadine, telecamere, assistenti vocali, serrature, sensori ed elettrodomestici intelligenti promettono comfort e sicurezza, ma possono nascondere nuove e insidiose superfici di attacco. Attraverso una nuova avventura, Betti ci accompagna alla scoperta del mondo della domotica e dei dispositivi IoT, mostrando come la poca cautela nell'utilizzo di queste tecnologie possa trasformare oggetti quotidiani in porte d'accesso per chi vuole osservare, controllare o colpire.
Per accompagnare la crescita del progetto abbiamo realizzato il sito ufficiale di Betti-RHC, dove è possibile conoscere meglio la serie, gli episodi e il progetto di cybersecurity awareness sviluppato da Red Hot Cyber. L'obiettivo è continuare a portare la cultura della sicurezza fuori dai tradizionali percorsi formativi standard, utilizzando il linguaggio immediato del fumetto per parlare a dipendenti, professionisti e persone senza competenze tecniche. Per maggiori informazioni su Betti-RHC e sul sesto episodio “Open Mic” è possibile visitare il sito ufficiale: betti.redhotcyber.com.