Una delle doti che il nostro tempo sta perdendo post dopo post, indipendentemente dal fatto che la piattaforma sia (sulla carta) di puro svago come Instagram o sia (sulla carta) orientata al lavoro come Linkedin, è la credibilità.

Ci sono dozzine di persone che parlano di tecnologie rivoluzionarie o competenze straordinarie che, inesorabilmente falliscono alla prova dei fatti.

Molta forma e poca sostanza.

In questo marasma però, se si è ben attenti ad osservare, si trovano persone che quella credibilità la emanano con ogni frase, poiché questa è basata su percorsi autentici e fattuali. Una di queste persone è certamente Kelsey Hightower.

Partendo da Python, passando per Puppet, poi CoreOS ed infine Kubernetes, ciascuna fase della carriera di Hightower è stata densa di azioni pratiche che ne hanno attestato il ruolo di figura preminente nel mondo Kubernetes, ed in generale della tecnologia.

Insomma, è raro trovare affermazioni banali quando Hightower parla, ricorderete quando abbiamo riportato la sua affermazione “Se tra vent’anni parleremo ancora di Kubernetes, allora avremo fallito.“, ed una ulteriore dimostrazione arriva dall’intervista riportata da The New Stack che contiene numerosissimi spunti di riflessione.

Il tema è relativo allo scaling, a quali siano cioè le modalità più produttive e professionali per creare infrastrutture in grado di reggere urti derivanti da picchi di richieste. In poche parole, come rendere le proprie infrastrutture di classe Enterprise.

Su tutte, tre affermazioni sono particolarmente illuminanti, la prima a proposito del fascino (leggi marketing) che certe soluzioni – e le aziende che le promuovono – esercitano sui potenziali clienti:

Don’t just chase scale because you’re fascinated by others’ scaling strategies and achievements. You need to really experience some pain personally first.

Non inseguire la scalabilità solo perché sei affascinato dalle strategie e dai successi degli altri: devi prima sperimentare un po’ di dolore in prima persona.

La seconda, a proposito del criterio con cui le scelte architetturali dovrebbero essere effettuate:

Make the best choice you can for now. Change isn’t failure — plan for it; don’t fear it.

Fai la scelta migliore possibile per il momento. Il cambiamento non è un fallimento: pianificalo, non temerlo.

La terza ed ultima, a proposito dell’umiltà che ci vorrebbe in ogni scelta:

Some things just aren’t meant for everyone. Understand who your users are, how they work, and what tools they use — then build with that in mind.

Alcune cose semplicemente non sono fatte per tutti. Comprendi chi sono i tuoi utenti, come lavorano e quali strumenti usano — e costruisci tenendo questo a mente.

Tre frasi che potrebbero tranquillamente essere usate in contesti che esulano dalla tecnologia e, proprio per questo, molto preziose.

Il consiglio, in ogni caso, è di guardare l’intero video che riportiamo qui di seguito: