GetLatestVersion – Italia

Language selector

Quelli di GLV - Episodio 1 - Due chiacchiere con Alessandro Alpi

Introduzione

La nuova serie “Quelli di GLV” è iniziata. Insieme a Giuliano Latini si è parlato del topic DevOps su database. Qui di seguito il transcript dell’intervista e il link a youtube:

Transcript

  • Qual è la differenza più sostanziale tra codice e database?

    sì, molto spesso arriviamo a chiederci questa cosa perché sembra che esistano tutte queste differenze tra database e codice in realtà non è poi così vero. Tuttavia, mi piace dare fondamentalmente due risposte: La prima, è che dal punto di vista di strutture e in generale definizione di quello che sono gli oggetti e database non viene praticamente neanche una, sempre parlando di file che vengono salvati su un source control. la seconda, invece è che da tutti gli altri punti di vista siamo all’estremo opposto. Infatti, abbiamo caratteristiche come persistenza, e quindi tutto quello che ne deriva in termini di regressione e potenziale perdita di dati, e in generale mancanza di compilazione, senza la quale è molto spesso è difficile controllare se tutto quanto funzionerà, se pure ci siano dei pattern da seguire. In definitiva, se vogliamo dare una sola risposta, possiamo dire che dal punto di vista di controllo di codice sorgente non abbiamo poi tutte queste differenze, mentre ne abbiamo tante quando si arriva allo step di deploy e quindi all’ambiente.

  • Quali sono i primi due scenari tipici che ritrovi spesso?

    Legandosi un pochino alla domanda di prima, nel flusso intero che va da sviluppo a produzione diciamo, direi che il primo scenario è quello appunto in cui esiste un server centrale di sviluppo, che in realtà è anche il server di produzione. è vero, sicuramente, che a volte ci sono anche problemi economici per quanto riguarda le licenze, però questa pratica è sicuramente sconsigliata, perché si finisce in un mondo in cui conflitti, violazioni di accesso ai dati, rischi di non poter configurare i permessi a modo e quindi di buttar via completamente il lavoro di produzione (senza volerlo, ovviamente). Il problema è che molto spesso è così e, in tali casi, non si riesce a raggiungere facilmente nemmeno un primo step di migrazione, che prevederebbe quantomeno in controllo del codice sorgente isolato. Il secondo scenario più comune, è quello in cui non è possibile fare deploy in produzione, se non passando da un cosiddetto gatekeeper. È piuttosto comune, infatti, avere a che fare con aziende che non hanno direttamente la gestione dell’infrastruttura di produzione. In quel caso, può succedere che non ci sia neanche un canale telematico. Le uniche possibilità sono quelle di mandare un pacchetto da far eseguire ai responsabili dall’altra parte. Potete capire qui la natura dei problemi che si presentano e anche se l’azienda con cui si lavora è disponibile a fare di tutto, ci sono dei blocchi burocratici anche, insuperabili. il concetto però è sempre lo stesso, sulla pipeline si tende a dimenticare o a voler ignorare, la parte dei dati, rimandando tutto al gestioni speciali, se presenti.

  • Accompagnando aziende, dove trovano più problemi nel cambio di approccio?

    questa è una domanda molto interessante, perché cominciamo a parlare di scenari reali e di come le persone si sono attrezzate per gestire i propri sistemi, quindi di esperienze dirette. e sai come sono interessato a capire come le persone risolvano i problemi all’interno delle loro realtà. Di difficoltà sono incontrano tantissime soprattutto quando l’azienda che vado a seguire non è minimamente avvezza a tutti quei concetti che ruotano intorno al topic in questione che è devops. Però se volessi fare una classifica delle prime tre, direi che sicuramente il primo problema è la mancanza di conoscenza del glossario tecnico riguardanti le pratiche suggerite. Quindi molto spesso è fondamentale trovarsi ore a discutere di termini con i quali si lavorerà nelle giornate a venire. sembra scontata questa cosa, ma credo che non riguardi soltanto il mondo dei database, bensì un po’ tutto il mondo della IT. Certo, essendo stato il mondo del database visto sempre come statico e un po’ più indietro rispetto a quello dello sviluppo (non dimentichiamo che con “mondo dati"si intende sia sviluppo che parte operations commerciale per il resto dei dipartimenti IT) è sicuramente più probabile trovare anche meno documentazione mentre il mondo dello sviluppo è sommerso di nuovi termini regolarmente. In seconda posizione invece, una volta superato il problema del glossario, direi che c'è, come la chiamo io, la mania del server centrale di sviluppo, anche conosciuto come mancanza di una sandbox per il database. E quindi, da qui, nascono una marea di problemi che rendono molto più complesso il passaggio, ad esempio, verso una continuous integration. Ovviamente non ci fermiamo a questo, ma diciamo che il primo problema che si verifica e che tipicamente blocca le idee del tuo interlocutore, perché qui c'è da migrare veramente tanto, sia in termini di cultura che in termini di infrastruttura e procedure. Al terzo posto, un grande classico, la mania di voler usare uno strumento a priori. Molto spesso si parte con idee e per concetti e, una volta entrati, si cambia completamente il punto di vista. Anche perché, uno strumento deve essere a supporto, non dimentichiamolo.

  • Come reagiscono i DBA o i DB Dev abituati a stare su IDE dedicati al solo database?

    Hai detto bene, c'è sempre una forte comunità di persone che lavorano solo sul database e solo in termini di sviluppo. Non sto parlando di data scientist, ma di figure che si dedicano a sviluppare su database, come accade per store procedure e funzioni. Purtroppo non riesco a distinguere uno sviluppatore che faccia solo questo rispetto a una persona che sviluppi semplicemente back-end, perciò, anche in questo caso, mi sento di sconsigliare la creazione di un silo isolato. Tornando a noi, ci sono tante persone impiegate su management studio, per capirci. Diciamo che molto spesso sono spaventate quando si approccia alla migrazione. Caso diverso e invece quello di sviluppatori abituati ai progetti database in visual studio. E ancora più distante è il caso delle nuove leve abituate a usare i nuovi strumenti come visual studio code o Azure data studio. Diciamo che per tutti questi casi, in maniera più o meno indolore, possiamo ridurre la curva di apprendimento e rendere più tranquilli i lavoratori di questo tipo approcciando allo strumento giusto quantomeno in un primo step per poi arrivare ad avere confidenza con un po’ tutto il mondo degli strumenti DevOps. quindi chi più chi meno, la paura c'è, ma è più quella del cambiamento. Per i dba é un po’ diverso. Un amministratore utilizza tanti strumenti è l’obiettivo finale è quello di stare sulla produzione. perciò mi sento di dire che una figura di questo tipo molto spesso è alleggerita dall’automazione, poiché cadendo i famosi gatekeeper cala anche il lavoro di deploy in produzione. Aumenta quello del controllo della qualità e della monitorizzazione dei sistemi, che sempre fa parte di devops. In definitiva, non è uno scoglio impossibile da superare, certamente impegnativo.

  • Come cambia la gestione del DB e quindi il ruolo del DBA in una trasformazione verso DevOps?

    Bella domanda. Anche perché non è detto che il dba sia da tutti considerato allo stesso modo. Ci sono aziende per cui un dba è la persona che fa i rilasci, altre per cui è quello che sviluppa le stored procedure e “conosci un po’ di più il database”, altri ancora invece, in cui non solo è tutto quanto detto prima ma è anche colui che controlla i sistemi di produzione via monitoring. Fin dall’inizio della mia carriera, che al contrario di quanto si può pensare è stata da sviluppatore full stack, costretto a diventarlo dalla natura della nostra attività negli anni in cui ho iniziato, ho sempre ricercato un lavoro che fosse effettivamente quello per cui la definizione di dba nasce. Quindi parliamo di teoria di database e topologie, design e architettura, conoscenza di sottosistemi e non solo del servizio database, monitoring e ottimizzazione delle performance, ecc. È stata veramente dura poter fare tutte queste cose e devo dire che ci sono riuscito solo quando sono andato a lavorare all’estero. Sono allora ho iniziato anche ad aggiungere le pratiche DevOps. Quindi il ruolo del dba, seguendo la definizione, vedrebbe il suo lavoro aumentato in termini di cultura devops e diminuito in termini di attività. L’attenzione viene spostata sulla qualità, sulle decisioni per la parte di automazione, sulla monitorizzazione dei sistemi non classica, ma proattiva (con questo intendo avere a che fare con strumenti e API utili a rimuovere gli interventi manuali). Se si parla delle figure di cui ho parlato poco fa, ovviamente cambia tutto. Si tratta quindi di capire che cosa si intende per dba.

  • La fiducia nei rilasci?

    Esatto, proprio in base a quanto appena detto, in teoria, la fiducia dovrebbe piano piano arrivare, dal momento in cui le procedure scritte per l’automazione cominciano a non farsi più sentire. Praticamente, quando ci si dimentica di una cosa e questa continua ad andare senza problemi, siamo arrivati al punto desiderato. Ma anche in questo caso, il problema è la paura del cambiamento, non tanto la fiducia in uno strumento. Molto spesso si parte prevenuti pensando presuntuosamente che le proprie procedure funzioneranno comunque è sempre meglio di un sistema progettato allo scopo. E probabilmente all’inizio è anche vero. Ma dopo una fase di verifica, correzione e controllo costante, lo strumento lo possiamo dimenticare, mentre un elemento scritto da noi che non prevedeva casi futuri poiché è troppo custom, sarà sempre fonte di ulteriore lavoro di fix e potenziale regressione anche sulla linea di deploy. Il rilascio a database é decisamente impegnativo, non dimentichiamo i punti di diversità detti prima. Qui abbiamo data loss, continuità di business, qualità del dato, persistenza. Insomma, é delicata la faccenda. Quindi si può facilmente capire il motivo della scarsa fiducia. É comprensibile. Però, una volta pensata una pipeline semplice ed efficace, credetemi, dormirete sonni molto più tranquilli e avrete sempre meno bisogno di tempo o meglio, creerete sempre meno debito tecnico.

  • Consiglio finale?

    Solo uno? Difficile. Lasciami dare almeno un consiglio per la parte di sviluppo e uno per la parte deploy, per favore. Quando iniziamo a sviluppare una soluzione e abbiamo una parte di database, qualunque sia la sua natura, cerchiamo di entrare nel mood del mondo dello sviluppo. Con ciò intendo: ragionare in termini di repository, source control e branching style, strumenti di sviluppo e contribuzioni a librerie open source. Il tutto in maniera collaborativa, con lo scopo di dare quanto prima la propria versione del codice modificato, pensando sempre a come andremo “in produzione”. Quando facciamo il passo verso il rilascio, impostiamo la nostra mente sulla qualità e gli ambienti. Perciò: prevenire regressioni con pratiche di test automatici, provare prima dei rilasci i nostri script di deploy automaticamente, definire i concetti di artefatti e capire l’esigenza dell’ambiente verso cui andiamo a fare deploy. Orientati a seguire che quanto appena rilasciato funzioni perfettamente. Infine, trasversalmente, impariamo ad approcciare in maniera iterativa alle nostre implementazioni e in ultimo, ma non per importanza, parlare tutti la stessa lingua, anche coi clienti. Ma questo va fuori dal topic dell’intervista, magari uno di noi parlerà di Domani Driven Design.

comments powered by Disqus
Menu

Language selector