So che sono stato molto assente dal blog in questo mese, ho in realtà lavorato dietro le quinte per il Canale Vimeo di Juku ed in alcune attività di consulenza per la virtualizzazione che hanno assorbito il 110% del mio tempo (alcune volte anche del tempo libero), ma a parte questo ho sempre tenuto un occhio su twitter seguendo tutti gli argomenti che amo di più: virtualizzazione e storage.
Blah, Blah, Stacks
Ultimamente c'è stato parecchio chiacchiericcio sugli stack (specialmente su twitter) su qual'è lo stack migliore, chi è più integrato, chi ha meno pezzi e chi è più bravo a venderlo.
Su Juku siamo sempre stati abbastanza ottimisti riguardo agli stack, definendoli una buona scelta di piattaforma per molti clienti, specialmente quelli con problemi di staff IT, ma riflettendoci sopra recentemente ho quasi cambiato idea sull'argomento, una delle frasi che sento spesso dire di più quando si discutono gli stack è: (traducendo a braccio) "Se stai comprando uno stack, è come andare a comprare un' auto da un concessionario, altrimenti è come costruire un'auto in kit".
F1 IT Team
E se invece avessi un team a livello "Formula 1" che può costruire e mantenere uno stack tecnologico usando tecnologia 'best-of-breed' senza doversi blindare ad un vendor?
Questo è il mio punto: nei tempi d'oro, quando il tizio del mainframe arrivava on-site lui era quello che comandava, lui aveva la conoscenza del sistema, mentre le persone all'interno dell'azienda sapevano solo come "operare" il computer, non conoscevano praticamente nulla del monolite IBM, e molte volte non gli interessava proprio, sapevano solo quello che dovevano sapere e delegavano tutto il resto a mamma IBM.
Poi arrivarono gli anni '80 e i '90 e gli "open system" rivoluzionarono tutto, ad un tratto tutte le aziende avevano un "system engineer", una persona che conosceva come le cose funzionavano all'interno, una persona che sapeva come gestire i compiti di amministratore del sistema, guadagnando una conoscenza intima di come le cose funzionavano all'interno dell'azienda riguardo all'IT e di cosa funzionava meglio per loro. Questo è il tipo di "feeling" che nessuno può imparare in una settimana di training ed è molto spesso dove cadono molti progetti di outsourcing, cioè dove l'outsourcer non raggiunge lo stesso livello di confidenza con le applicazioni IT e con il business a cui sta fornendo servizio.
Costruirsela da soli non è un crimine!
Ora se avete seguito il mio percorso logico fino a qui, pensate alla conoscenza che il vostro reparto IT ha riguardo ai vostri processi di business, alle customizzazioni, alla vostra infrastruttura e cosa potrebbero fare se gli deste l'abilità di costruire uno stack con i pezzi migliori di tecnologia, magari con l'aiuto di un partner di fiducia (un vendor, un VAR, scegliete voi).
Questo è quello a cui mi riferisco, i passati decenni ci hanno dato tonnellate di conoscenza sulle complessità dell'IT, perché sprecare tutto nel nome della "singola gola da strozzare"? e a proposito di questo punto, provate a chiedere al vostro sysadmin quando è stata l'ultima volta che un team di supporto (escludendo Oracle 🙂 ) ha rifiutato di dare supporto scaricando la colpa sulla schiena di un altro vendor.
