Pacchettizzata o FaiDaTe?

Piu' che un commento questa e' una risposta ad una 'domanda' fatta da "Cinghiale Mannaro" (vedi Selce). La domanda, riportata qui' per chiarezza, e' la seguente:

Sono i sistemisti che devono mettere su le macchine con i requisiti che i programmatori richiedono (e li richiedono, a differenza dei CL di "davidiana" memoria, con chiarezza e precisione) o sono i programmatori che devono chiedere ai sistemisti CON COSA possono fare le loro applicazioni?

Prima di tutto una precisazione importantissima: i "miei" CL (in genere quando provenivano dalla Yugoslavia) specificavano chiaramente COSA volevano, ed il COSA era categoricamente l'ultimissima versione di qualunque cosa usassero. Il che andrebbe benissimo se non fosse che: 1) non ho un numero infinito di server a disposizione ne' la possibilita' di usare un singolo server per ogni applicazione 2) ogni singola applicazione e' "tarata" per una specifica versione di qualche cosa, ed ovviamente tale qualche cosa va' categoricamente in conflitto con qualsiasi altra versione diversa della stessa cosa (tipico il caso delle maledette librerie di parsing dell'XML), ergo: fare coesistere tutte le diverse versioni su una singola macchina diventa un problema 3) ogni qual volta la maledetta applicazione viene installata non funziona o qualche cosa d'altro smette di funzionare. E chi pensate che sia il povero pirla che deve andare a dare la caccia ai diecimila conflitti tra duecentomila diverse versioni di librerie?

Messa da parte questa precisazione andiamo ad esporre la mia opinione sull'argomento: sono i sistemisti o i programmatori?

Punto di vista del sistemista:

Se si utilizzano delle distribuzioni "pacchettizzate" lo si fa' perche' si vuole usare il meccanismo di aggiornamento della distribuzione il piu' possibile, in modo tale che, quando esce un'aggiornamento si sceglie "aggiorna" (o lo si fa' in automatico mediante uno script) ed il server si mantiene aggiornato da solo. Comodo per il sistemista che non deve correre dietro a tutte le versioni di librerie e perdere le giornate per installare l'aggiornamento di X (per qualunque valore di X). Soprattutto quando i server da mantenere sono tanti e sparsi per il pianeta.

Il rovescio della medaglia e' che la disponibilita' della versione X del prodotto Y e' limitata a quando la casa produttrice della distribuzione decide di metterla a disposizione. Non prima. Se si installa il prodotto senza seguire la procedura (aka: a manella) si rischia di 1) vedersi il prodotto disinstallato e rimpiazzato con una versione diversa al primo aggiornamento o 2) vedere un qualche altro pezzo del sistema smettere di funzionare causa lo stesso aggiornamento o 3) entrambe le cose.

L'alternativa e' perdere ore o giorni per ogni aggiornamento per essere sicuri che versione X del prodotto non entri in conflitto con tutto il resto del sistema, non venga spianata dall'aggiornamento automatico a versione X-1 e cosi' via. Oppure, molto banalmente, non si aggiorna il sistema. Il che e' possibile, ma non raccomandabile.

L'installazione "faidate" e' sempre fattibile se si tratta di un numero limitato di sistemi (il guaio e' che poi questi tendono a moltiplicarsi rapidamente) e se il sistemista e' un tipo efficiente e tiene accuratamente traccia di ogni 'particolarita' del sistema in questione (versioni particolari di librerie, path di installazione non-standard, modifiche a file di configurazione, switch o opzioni particolari di avvio per demoni e cosi' via). Tutto questo richiede un sacco di documentazione (che tende ad andare persa o banalmente non mantenuta) molta cautela e la voglia di leggersi il fottuto manuale prima di fare qualche cosa. Inoltre, se il sistemista in questione si ammala, finisce in ospedale o migra verso altri lidi e viene sostituito, c'e' sempre il pericolo che il nuovo sistemista guardi il server e pensi "eeeeck! questo coso e' vecchio come il cucco/non e' stato aggiornato!", infili il CD e....

Punto di vista del programmatore.

Dato che sto sviluppando una nuova applicazione, l'usare l'ultima versione del compilatore/ambiente/interprete e' la soluzione piu' logica, in alcuni casi e' l'unica soluzione percorribile dato che non era gia' installato da prima.

Quando si cerca di risolvere un qualche strano bug di cui non si riesce a rintracciare un motivo, aggiornare all'ultima versione le librerie o l'ambiente che si usa consente di ottenere migliori informazioni di debug e magari corregge l'errore di suo, quindi meglio tenere il sistema allineato con l'ultima versione.

I manuali e la maggioranza del codice di esempio che si trova in giro si riferiscono all'ultima versione, acquistare manuali sulle versioni precedenti non e' una cosa molto furba.

Ovviamente questi argomenti (perfettamente logici e plausibili) sono in diretto conflitto con quelli precedentemente esposti.

Poi c'e' il discorso "la macchina me la mantengo io tu non devi fare niente". Sorry, ma non funziona cosi'.

Il problema in questo caso e' RESPONSABILITA e CONTROLLO. Il sistemista e' responsabile dei sistemi, se non ne ha il controllo e' fottuto fin dal "via". Sul suo contratto c'e' scritto esattamente questo. Lui e' il responsabile, ergo se qualche cosa non funziona lui e' il primo che prende calci. Pertanto la linea "la macchina la gestisco io" entra in diretto conflitto con questo basilare concetto: se TU hai il controllo IO non voglio avere la responsabilita', ma me la devo prendere, pertanto TU non puoi prendere il controllo. Se il sistemista e' disposto a mollare il controllo c'e' qualche cosa di seriamente sbagliato nella sua testa.

Come si vede i punti sono parecchi, ed ognuno ha una sua importanza, certo dal punto di vista di entrambi e' molto semplice scaricare il problema. Per il programmatore e' molto semplice dire "questo e' quello che voglio e adesso sono cazzi tuoi", per il sistemista e' ancora piu' semplice dire "questo e' quello che abbiamo e adesso sono cazzi tuoi". Ma in questo modo perdono entrambi. Arriviamo quindi al punto finale: programmatore e sistemista devono cooperare.

La cosa migliore e' che i due si siedano intorno ad un tavolo, possibilmente con l'idea che e' meglio uscire dalla stanza con una decisione comune e non con un'ascia in mano e che o vincono entrambi o perdono entrambi, e cerchino di trovare un punto di comune accordo.

Quando potevo (mica tanto spesso), io usavo la seguente "check-list":

Questa applicazione e' possibile farla funzionare usando la versione di $qualunquecosa che e' distribuita?
Esiste un modo per adattarla o e' semplicemente impossibile? (se si tratta di scrivere alcune funzioni "ponte" lo si fa' una volta sola e basta)
Quanto e' "critica"?
E' pensabile di tenere il server non aggiornato finche' la versione giusta non viene distribuita ufficialmente?
E' fattibile l'aggiornamento manuale del server? (aka: se qualche cosa va male il server probabilmente deve essere installato da capo)
Possiamo avere un server dedicato a questa applicazione o dovra' essere condiviso con altre applicazioni?
- Ci sono conflitti con quello che serve per le altre applicazioni?
- E' possibile modificare tali applicazioni per farle funzionare con cio' che serve per questa applicazione?
L'applicazione e' solo interna? (applicazioni interne hanno meno richieste di sicurezza)
L'applicazione usa una versione di $qualchecosa particolare perche' fa uso specifico di cose che sono solo in quella versione o puo' usare la versione che e' gia' installata su un'altro server? (questo e' il caso particolare di databases: tra una versione ed un'altra ci sono differenze, ma se non si usa qualche cosa di specifico e' possibilissimo usare una versione diversa senza grossi problemi)
E' possibile l'aggiornamento di $qualchecosa che e' gia' installato alla versione richiesta senza inficiare tutte le altre cose che lo usano?
Ogni quanto deve essere aggiornata l'applicazione? (se deve essere aggiornata spesso il programmatore dovrebbe pensare ad un sistema automatico di controllo ed installazione delle librerie o altra roba che viene usata, una specie di "install" che eviti al sistemista di dover ogni volta controllare tutto da zero)

Il problema ovviamente si complica se altri attori entrano in scena. Se il database e' mantenuto da un DBA, questo deve essere incluso nella discussione, se il server e' mantenuto presso un centro-dati esterno o qualcun'altro si occupa di backup questo qualcuno dovra' essere consultato. E cosi' via.

In conclusione: non c'e' una risposta A o B. Sistemisti e programmatori devono (o dovrebbero) comunicare. Il problema e' che molto spesso il sistemista non ha mai fatto il programmatore per davvero e non ha idea di quanto sia una rottura di scatole il riscrivere del codice che funziona per adattarlo a funzionare con una libreria che non funziona, mentre il programmatore non ha idea di quanto sia una rottura di scatole l'aggiornare manualmente 10 servers per tenere dietro a 100 versioni diverse di librerie che vanno in conflitto le une con le altre.

Davide Bianchi
30/01/2009 10:12

Commenti & Opinioni

Pacchettizzata o FaiDaTe?

7 messaggi this document does not accept new posts

7 messaggi this document does not accept new posts