Ma non quel che trovi

Il nuovo che (dis)avanza

di

thumbnail

08

gen

2018

Vi prendereste la responsabilità di mantenere lucido ed in forma un F-16 Fighting Falcon per andare al lavoro ogni mattina?

Se state progettando un applicativo informatico per il vostro server non lasciatevi abbagliare: lasciare quel vecchio metodo da quel buon libro per il nuovo framework du jour non è sempre una buona idea.

Lo ammetto, non ho ancora provato quell’ultimo framework JavaScript per creare un web service in quattro linee di codice. Non ho neanche provato quel servizio PaaS di cui si vocifera tra i forum, che sembra una panacea e dovrebbe esser capace di orchestrare al posto mio tutti i componenti server-side attraverso una singola interfaccia web.

Poi non ho mai mai messo in produzione quel sistema di creazione di container che sembrano macchine virtuali ma non lo sono e permette di avere tanti piccoli filesystem uno affianco all’altro, uno per ogni servizio.

Troppo comodo

Oggi sembra che le soluzioni per progettare un servizio informatico debbano obbligatoriamente vendersi come automobili: comodissime, elegantissime, sostitutive. Per ogni problema scopro di avere più soluzioni di quelle che mi servono e tutte sembrano saper fare meglio quello che già mi illudevo (a quanto pare) di saper fare prima.

Da sviluppatore non improvvisato, però, percepisco una pericolosa differenza. Una differenza che all’inizio sembrava sottile e col passare dei mesi sta diventando rilevante e preoccupante.

Nel complesso, meglio

Nella vita di un programmatore avere a che fare con sistemi complessi significa avere a che fare con software complessi. Potrà sembrare tautologico, ma software semplici hanno bug semplici e quelli complessi hanno bug complessi.

Nell’osservare il fiorire di tanti e diversi strumenti all-in-one pronti a sostituire la vecchia torre di inossidabili pratiche mi sono chiesto, col tempo, se il valore aggiunto apportato dal nuovo potesse tenere il passo con la complessità introdotta da un sistema integrato out-of-the-box. La mia risposta nel tempo è scivolata dal crediamoci, al forse, al ma anche no e vorrei spiegarvi il perché.

Mi scopro circondato da svariati esempi di progetti costruiti con dipendenze oltremodo complesse scelte da autori che non si curano dei dettagli fuori dalla pagina di quickstart. Il punto è semplice: è vero che non sempre è necessario affrontare la complessità di un sistema, ma è certo che bisognerà farlo quando si romperà qualcosa (e state certi che lo farà) e costerà. Aggiungere ad un sistema una dipendenza per la quale non si è ancora capaci di fare debugging è un rischio sul budget, perché si traduce nel procrastinare lo studio di uno strumento complesso.

Datacenter Scale

Se si ragionasse con lo hardware come si ragiona attualmente con il software.

 

L’alternativa c’è ed è quello che c’era prima: una pila di strumenti reduci da tante battaglie, qualche script, buone pratiche e tante man page. Una domanda che mi pongo e che invito altri colleghi a porsi più spesso è se conoscono che cosa starebbe andando a rimpiazzare con il luccicante nuovo l’opaco vecchio.

Perché è necessario rimpiazzare i makefile? Perché vi siate avvalsi di un package manager interno? Perché evitare un semplice shell script? Perché vi siete dimenticati dell’esistenza di SSH?

Sai quel che lasci

Vorrei semplicemente sapere se chi inventa nuovi sistemi integrati in sostituzione di quelli già presenti conosca approfonditamente quanto sta andando a rimpiazzare, soprattutto le implicazioni storiche del perché finora si è fatto così.

La mia non vuole essere una critica al valore aggiunto apportato dai Docker, dai Gulp, dagli Chef, dai Puppet e da tutto l’ecosistema che ruota intorno alla metodologia DevOps, ma un sincero avvertimento.

Imparare a programmare con JavaScript

Partire bene aiuta a valutare i framework.

 

Rischi e ricompense

Penso che la direzione intrapresa – le conversioni facili a strumenti intricati – porteranno a sistemi informatici generalmente più fragili. Se invece lo strumento maneggiato è conosciuto in tanti e diversi dettagli, se si prevede di utilizzarlo al 90% e non al 10%, se non sarà un cannone per sparare alle formiche, allora costituirà una risorsa e non una bomba ad orologeria. In tutti gli altri casi il rischio sarà alto.

Una soluzione dalla provata solidità nel tempo, che mostra sulla pelle le cicatrici del veterano, è con ogni probabilità più resiliente e conveniente sul lungo termine.

Il tempo guadagnato – quello sì – può essere dedicato al nuovo ma, invece che su una macchina di sviluppo o produzione, in una macchina virtuale sotto una pioggia di stress test.




Giacomo Cappellini (@Arkanoid) è da cinque anni analista programmatore e tool-maker di applicazioni per smartphone e tablet, da dieci anni deviato nel multidisciplinare mondo dello sviluppo di videogiochi cross-platform. Nonostante una grave e particolare forma di ossessione verso lo how-it’s-done, trova ancora tempo e modo per parlarne.

Letto 1.811 volte | Tag: , , ,

Lascia il tuo commento