This page looks best with JavaScript enabled

#1 "R in Production"

 ·  ☕ 5 min read
    🏷️

Questo blog nasce dal mio desiderio di condividere metodologie e software per portare R in produzione.

Perché “R in Production”

R è uno degli strumenti open source più usati nel mondo per fare Data Science, un settore interdisciplinare che utilizza metodi scientifici, processi, algoritmi e sistemi per estrarre valore dai dati.

Con “sistemi di produzione” si intende quei sistemi che sono utilizzati per produrre valore. Significa che sono strumenti che hanno smesso di essere prototipi e sono utilizzati realmente per fornire un servizio. Di conseguenza, una volta entrati in funzione il business fa affidamento su di essi. Esempi possono essere sistemi critici che devono funzionare 24/7, oppure quelli usati da un’utenza non tecnica dove non c’è l’esperto che può aggiustare il tiro qualora qualcosa vada storto, oppure sono sistemi che devono portare a un risultato in tempi celeri secondo un protocollo ben collaudato.

Sistemi affidabili

In generale sono sistemi a cui viene richiesta una alta qualità in termini di sicurezza, affidabilità e manutenibilità.

Con Sicurezza si intende il processo con cui si prendono misure cautelative per evitare eventi come malfunzionamenti, perdita di dati, manomissioni o furti. Spesso trascurata, è invece di fondamentale importanza sia come forma di tutela pratica, sia perché è un requisito sine-qua-non nelle specifiche di alcuni ambienti aziendali.

L’affidabilità è un requisito fondamentale di un prodotto o servizio per entrare a far parte di una catena produttiva. Si può evidenziare almeno due sue caratteristiche essenziali: deve svolgere correttamente il suo lavoro e non deve interrompere il servizio. La correttezza del suo funzionamento è bene che sia verificata, per esempio con dei test. La robustezza è la caratteristica di un prodotto che rimane sempre reattivo senza finire in vicoli ciechi che causerebbero la temporanea interruzione delle operazioni. Quindi deve tenere presente tutte le possibili azioni dell’utente, essere resistente alla variabilità del dato in ingresso, e rilevare malfunzionamenti anzitempo permettendo al manutentore di intervenire.

La manutenibilità è la facilità con cui si può intervenire su un prodotto che lavora in produzione. Difficilmente un prodotto rimane perfettamente immutato nel tempo. Nei casi più stabili gli interventi riguardano manutenzione di routine, oppure si interviene saltuariamente per la correzione di difetti o la riparazione di un malfunzionamento. Altre volte ci si trova in situazione più dinamiche dove è necessario il rilascio di una nuova funzionalità oppure in generale il soddisfacimento di nuovi requisiti. Questa cosa diventa una vera e propria necessità negli ambienti dove la richiesta di evolvere il prodotto diventa una prassi per cui un team è costantemente al lavoro per creare nuove funzionalità da rilasciare.

Nei tempi recenti queste caratteristiche vengono messe sotto stress da progetti che necessitano di ridurre i tempi di immissione sul mercato (time to market “TTM”), e di sviluppare iterativamente un prodotto minimo funzionante (Minimum Viable Product “MVP”) e di rilasciarlo continuativamente ad intervalli regolari.

Team e collaborazione

Finora abbiamo genericamente parlato delle questioni di business, ma ci sono questioni altrettanto importanti che riguardano le dinamiche e i flussi di lavoro all’interno dell’azienda che fornisce il servizio.
La condivisione e la collaborazione hanno solide basi nella strutturazione del progetto, ed è uno degli obbiettivi delle metodologie di cui voglio parlare. Con “collaborazione” intendo la modalità di integrazione del lavoro dei diversi componenti del team. Mentre con “condivisione” intendo il concetto che un team si avvantaggia se tutti i componenti sono consapevoli di quali siano gli obbiettivi del progetto, le specifiche della soluzione portata, e sono in grado di ottimizzare il proprio lavoro in funzione del lavoro della squadra. Voglio sottolineare ancora che questo si ottiene attraverso il corretto flusso di lavoro e strumenti software adeguati.

Metodologie collaudate

Queste questioni non sono relative unicamente al mondo R o Data Science, sono tematiche di ingegneria del software. Sono quindi già state abbondantemente affrontate ed esistono soluzioni di provata efficacia utilizzate in modo diffuso. Si tratta quindi di conoscere pratiche e strumenti e di applicarle al progetto.

Lo spettro di argomenti che il blog intende affrontare è più ampio di quello qui descritto, ci sono infatti molti compiti che sono di solito affidati ad altri specialisti come sistemisti o altri sviluppatori. È bene che anche il data scientist sia a conoscenza dell’esistenza e del senso di questi strumenti perché in questo modo sarà in grado di creare prototipi production-ready o agevole da portare in produzione. Esempi di questi argomenti sono la mentalità DevOps, che comprende la continua integrazione (Continuous Integration CI) e la continua distribuzione (Continuous Distribution o Continuous Deployment CD), ecc… “Infrastruttura programmabile” (Infrastructure as code IaC), ecc… la sicurezza informatica come dicevamo sopra.

Un altro argomento rilevante per il Data Scientist e cruciale per l’utizzo di R in alcuni progetti è integrazione tra R ed altri sistemi. I quali possono essere databases, tra cui i databases per i “Big Data”, altri software, librerie di altri linguaggi di programmazione, gestionali, strumenti in Cloud e in genere altre piattaforme software aziendali. In generale l’integrazione di applicativi è un insieme di tecniche attraverso le quali è possibile mettere in comunicazione molteplici tipologie di software. Esistono protocolli ben definiti con differenti pro e contro, quindi è bene averne una visione generale per scegliere di volta in volta la soluzione più adeguata.

Ma si può fare veramente con R?

La risposta è SÌ! L’esecuzione di istruzioni R dà luogo ad un processo del tutto simile agli altri linguaggi/software e l’interazione di questo processo con il sistema segue gli stessi protocolli. Quindi quello che posso fare su con linguaggio come Java, Scala o Python lo posso fare con R. Le limitazioni sono essenzialmente due: la disponibilità di librerie e strumenti per agevolare la realizzazione della soluzione scelta e la limitata disponibilità di informazioni e guide in merito. La comunità R e le aziende produttrici di software negli ultimi anni hanno provveduto a riempire il gap producendo soluzioni adeguate e ultimamente la community si è mossa velocemente in questa direzione. I tempi sono maturi per utilizzare R in Produzione.

Avete l’acquolina in bocca? Bene! Perché è la stessa sensazione che avevo io quando ho iniziato, ma ora il tempo è passato e le cose sono più semplici e io non vedo l’ora di condividerle con voi!

Share on