Giorgio is back!

Giorgio is back!

Yes, I’m back: this blog has been abandoned for like three years now, and I feel it’s time to bring it back to life. There is no particular reason behind this choice: I just need a virtual place where I can express my ideas and aggregate content I’ve always been disseminating over the internet for free (comments, forum posts, and so on).

New life means new theme (still in its basic version) and new language: some of my old posts are being read trough Google Translator, and as in the last few years my main language (mainly due to my job(s) and relationships) has been english, I have no reason at all to keep posting in italian. It’s just going to restrict my audience.

This time I won’t do what I did in all the previous “renovations”: I won’t destroy the old posts. The first one dates back to 2009 and I think they are a pretty important piece of history for them to disappear from the internet. I’m recovering the backups of the old versions of this blog in order to merge them with this one.

So, what has changed in those three years?

First, and maybe most important choice to date, I decided to put on hold (and then completely abandon) my studies at the University (Politecnico di Milano). This choice has been strongly dictated by the context (I was attending in Italy): although I perfectly understand the importance of learning the basis and developing a method for “doing things”, I felt what I was studying was too far behind reality. Spending years and thousands of euros to end up working as an underpaid intern in some big company was definitely not what I was expecting from my life.

The networking manual we were using (please mind it was 2013 and it was still being printed and was largely adopted) at a certain point stated that Ethernet was being superseded by FastEthernet, and that some big ISPs were deploying experimental long haul GigabitEthernet links. This was way too much (for non technical people reading this post: in 2013 we were already in the Terabit/s era, with multiple 100GigabitEthernet -100 times GbE- being used in long haul transits): reading this sentence, and then seeing that people that was able to get the best marks at the exam while thinking that GbE was the future (and not the past), helped me realize how detached from reality we were.

I decided to stop wasting time and joined CloudAcademy, a company that is trying to explain and show people how to take advantage of cloud services, as the Training Paths Supervisor. Feeling I had to head back to the battlefield, I decided in a few months to move to Enter, an italian ISP/CSP which at the time (late 2013) was working on the launch of a new multi-region OpenStack-based IaaS service, Enter Cloud Suite.

In Enter I have been employed first as a Cloud Architect and then as the Head of Cloud Architecture, with ECS as the main focus: I spent 2 years and a half designing and implementing hosting infrastructures for large scale news and e-commerce websites and designing, implementing and sometimes managing the OpenStack infrastructure behind Enter Cloud Suite. I was focused on the networking stack (both physical and overlay), and this gave me the opportunity to meet some very interesting realities like Cumulus Networks and Mellanox.

Then, in the first months of 2016, Amazon Web Services called: they offered me a position as a Technical Account Manager in London and I decided to accept it and move from Milan: everything happened so quickly I still have to realize what this means.

It’s very hard to explain what does it feel like being part of such a fast growing company, the one that has been the reference for your entire working life. “Work Hard. Have Fun. Make History.” is our slogan, and what it is all about: I’m sitting in the buildings where history is being written, day by day.

That’s it. This is the story of how I ended up writing this post, while laying on the bed in my apartment in Canary Wharf.

This is definitely a new beginning, and not just for this blog.

img_2230

As you wait for the next post, please enjoy the view from my bedroom.

Giorgio

No, non mi occupo di cosmetici.

No, non mi occupo di cosmetici.

Sembra ci sia un tale Giorgio Bonfiglio che sta contattando persone online offrendo un lavoro a domicilio consistente nel confezionare cosmetici. Chiede una cauzione di 35€ da pagare tramite ricarica Postepay per l’invio del primo pacco di materiale, e ovviamente ricevuta questa cauzione non spedisce il pacco.

Ho fatto varie ricerche, e sembra se ne parli solo su questo sito, nei commenti. Il mio simpatico omonimo non sembra nuovo a queste attività: leggo che è già stato arrestato una decina di anni fa per aver sparso in giro una certa quantità di assegni falsi.

Il problema non è tanto il caso di ominimia, quanto il fatto che io, per chi cerca su Google quello che è anche IL MIO nome, occupo quasi tutta la prima pagina di risultati. Trovare i miei recapiti poi è facilissimo. Ho ricevuto una telefonata, e sono centinaia le persone che sono entrate su questo blog con keyword legate a questi avvenimenti: non me ne ero reso conto, ci sono arrivato solo a posteriori.

Sia chiaro a tutti: quello non sono io. Mi occupo di engineering di infrastrutture, non sono un odontotecnico. Nel 2003 non avevo 48 anni, e soprattutto non ho la passione dei cosmetici.

Mettetevelo in testa.

Design for failure

Design for failure

“Scusa ma non siamo capaci di offrirti la stabilità di cui hai bisogno, potresti pensarci tu?”

(Anonimo Cloud-Eretico sul Design for Failure)

C’erano una volta… gli sviluppatori, e le applicazioni. Gli sviluppatori si concentravano sul codice, dando per scontata la stabilità e la scalabilità dell’infrastruttura sottostante: usavano query SQL indescrivibili, ed era compito del sistemista farle girare velocemente, scrivevano codice senza gestione delle eccezioni perchè era compito del sistemista far si che quel determinato database server fosse sempre disponibile e non restituisse mai errori. Scrivevano software impossibile da distribuire su più macchine perchè tanto il sysadmin, in qualche modo, avrebbe fatto.

La colpa di ogni rallentamento o malfunzionamento di chi era? Del sistemista. Questo ha portato chi si occupa di infrastrutture a progettare soluzioni sempre più avanzate per far sopravvivere l’applicativo alle più inimmaginabili catastrofi, senza che questo subisse mai malfunzionamenti. Qualunque disgrazia fosse accaduta alle macchine che la servivano, l’applicazione sarebbe dovuta rimanere in piedi e funzionante.

Va detto che ci siamo (quasi) riusciti. Grazie alla virtualizzazione siamo arrivati a creare quello che è a tutti gli effetti hardware indistruttubile: la macchina fisica è diventata virtuale e quella virtuale sappiamo muoverla tra diversi nodi senza spegnerla, al solo costo di qualche millisecondo di freeze.

Abbiamo così creato piattaforme che astraevano quasi completamente la complessità sottostante, usando processori virtuali che restavano disponibili anche se quelli fisici prendevano fuoco e dischi virtuali che continuavano a servire dati anche se l’intero rack di storage veniva rubato dagli alieni.

Questa soluzione non era però ottimale: la replica sincrona, per esempio, era possibile solo in ristretti contesti geografici. Il costo di queste soluzioni era spesso proibitivo, e la loro complessità alta e non necessaria. Queste strutture, per quanto immortali potessero essere, erano sempre sotto la stessa autorità amministrativa. Tutto per non dare agli sviluppatori un compito in più: gestire la disponibilità dell’applicazione.

Screen Shot 2014-01-28 at 20.58.15

(Anonimo Cloud-Eretico che non ha compreso il ‘Design for Failure’)

Poi è arrivata una nuova generazione di developers: sviluppatori che volevano più controllo, volevano poter decidere come l’applicazione avrebbe reagito a malfunzionamenti dell’infrastruttura, e soprattutto si rifiutavano di pagare al fornitore complessi meccanismi di failover perchè… non ne avevano bisogno. Sapevano fare di meglio e sapevano farlo in modo più economico ma soprattutto più effettivo, più semplice.

Questi sviluppatori non chiedevano più a chi vendeva infrastrutture hardware immortale, chiedevano semplicemente del ferro: di qualunque tipo, prestazioni, forma, colore e dimensione, ed in ogni luogo. Si sarebbero occupati loro di inoltrare meno richieste ai processori meno potenti, di tenere in RAM i dati se i dischi della macchina erano troppo lenti. Si sarebbero curati loro di evitare di interrogare un database server che non rispondeva più ai comandi.

Volevano occuparsi, soprattutto, delle azioni di disaster recovery nel caso in cui un intero datacenter fosse andato a fuoco. Perchè nessuno meglio dello sviluppatore può sapere come deve reagire una applicazione a determinati eventi e di cosa questa ha bisogno.

Hanno poi iniziato a chiamarlo ‘Design for Failure’. La disponibilità non è più compito di chi gestisce l’infrastruttura: è l’applicazione ad esser progettata per far fronte a ogni evento o disgrazia, e la struttura sottostante fa solo il sollevamento pesi.

Nel modello ‘Design for Failure’ ognuno fa il suo lavoro: lo sviluppatore conosce l’applicazione e si occupa di farla funzionare, il gestore dell’infrastruttura si occupa delle prestazioni ma non si infila più in infiniti tunnel senza uscita per garantirne la disponibilità. Tutti risparmiano, perchè è tutto più semplice, con meno sovrapposizioni. Tutti vincono: perde solo chi non ha voglia di innovare.

Ecco perchè questo modello non è un fallimento, come tanti lo descrivono: è il futuro.

Le cose che non sono.

Le cose che non sono.

Ho sempre risposto a tutte le email ricevute, ma recentemente la cosa è un po’ degenerata: ricevo richieste e proposte davvero fuori dal mondo, e questo mi fa perdere un mucchio di tempo (che non ho). Voglio continuare a rispondere a tutti come ho sempre fatto, e questo post, spero, mi salverà dalle 3/4 mail inutili che sono costretto a gestire ogni giorno: spero chiarisca definitivamente cosa sono e cosa faccio, ma soprattutto cosa non sono e cosa non faccio.

Andiamo con ordine.

Primo: Non sono un giornalista e questo non è un sito di news. Non scrivo recensioni sul mio blog ormai da anni e ho cancellato tutti i vecchi articoli. Non chiedetemi se sono disposto a scrivere del vostro servizio su questo sito, dietro compenso o meno. La risposta è e sarà sempre un “no”. Lo stesso dicasi per gli articoli a pagamento in genere. Questo è un blog personale: tecnico, autorevole quanto volete ma pur sempre personale e deve rispecchiare le mie idee e opinioni, senza nessuna sollecitazione esterna.

Secondo: Non sono neanche un PR, quindi per favore non contattatemi chiedendo di testare o usare il vostro servizio affinchè poi possa parlarne in giro o proporlo a qualcuno (mi sono anche sentito chiedere “se ospito il tuo blog sul mio nuovo hosting strafigo, quanti clienti/anno riesci a portarmi?”): non sono interessato a questo tipo di offerte.

Terzo: Quello che invece sono, è un consulente, con un forte background sui sistemi UNIX, sulle infrastrutture di hosting e sul cloud computing in genere (dettagli). Se avete lanciato un nuovo servizio che rientra nelle mie aree di competenza e volete il mio parere, sarò felice di darvelo (dietro compenso o meno, in base a quanto io sia personalmente interessato alla cosa). Tutti i servizi che valuto e che imparo ad usare entrano nel mio bagaglio personale e quindi è possibile io in futuro li utilizzi o li proponga a qualcuno, ma ricordate sempre che, come da secondo punto, mi state pagando per svolgere una analisi, non per farvi pubblicità.

Quarto: Non sono un webdesigner, non so dove lo abbiate letto, quindi fate in modo di non chiedermi più di fare siti web: non ne sono capace. Avete presente la pagina di default di Apache? Ecco, io sono a quei livelli. Quello che posso fare è mettervi in contatto con persone con cui collaboro e di cui mi fido, che al contrario di me i siti li sanno fare. Non fate quindi gli offesi se vi dico che non sarò io ad effettuare il lavoro.

Quinto: Non faccio hosting: no, non ce l’ho uno spazio per ospitare il vostro sito. Come per il quarto punto, posso mettervi in contatto con persone / società con cui collaboro e che fanno hosting, ma non me ne occuperò direttamente. Faccio il sistemista, quindi si, se vi serve qualcuno che progetti e gestisca una struttura dedicata per ospitare il vostro sito, potete contattarmi.

Sesto: Non offro consulenze gratuite travestite da consigli: non basta che nella mail che mi scrivete sostituiate la parola “consulenza” con la parola “consiglio” perchè un complesso lavoro retribuito diventi un atto di beneficienza. Amo gli scambi di sapere con i miei “parigrado”, e ritengo il dialogo e la condivisione fondamentali in questo ambiente. Ma se mi state contattando perchè io vi aiuti in una scelta o perchè io dall’alto vi risolva un problema, non c’è nessuna condivisione, il trasferimento di informazioni è unilaterale e che lo chiamiate “consiglio” o “consulenza”, si tratta di un lavoro che deve essere retribuito. Non fatevi ingannare dal tempo che impiego per dare una risposta: se mi viene chiesto quale software io ritenga più opportuno per creare una struttura di private cloud, la risposta consiste in circa 12 lettere. Pur essendo vero che si scrivono in 4 secondi, per arrivare a quella risposta che si basa sull’esperienza ho dovuto spendere una enormità di soldi, tempo e risorse in genere, che in qualche modo devono rientrare.

Settimo: Non sono un senzatetto. Sono sempre interessato a offerte di lavoro o anche a richieste di collaborazione non retribuite in vari tipi di progetti, ma per favore evitate di farmi perdere tempo con proposte ridicole come “Ciao, per 50€ mi installeresti un server di posta?”: per certe cifre, semplicemente non ne vale la pena e preferisco usare quel tempo per riposarmi.

Scusate la freddezza.

Era necessaria.

Giorgio

Ingegneria del Cloud Computing

Ingegneria del Cloud Computing

Glossy Blue Cloud with ShadowMi auguro di non essere più su questo pianeta il giorno in cui qualcuno istituirà il corso di laurea in Ingegneria del Cloud Computing. Se dovessi ancora essere qui quando quel momento arriverà… ragazzi, sapete cosa fare.

La scorsa settimana ho scoperto che ci sono università che offrono corsi in materia di cloud: per ora si tratta di singoli corsi, i nostri classici 10 CFU. Mi sono documentato, ho cercato i programmi, le slide ed il materiale didattico. Il risultato è stato catastrofico: ho avuto modo di notare quanto il modello di insegnamento “passivo” universitario possa impoverire i concetti. Mi rendo conto che il problema sia il modello in sè (lo confermano persone parecchio più autorevoli di me) e so anche che impoverisce ogni materia, non solo il cloud, ma quest’ultimo mi tocca più da vicino, e penso di avere le competenze per cercare (e trovare, ovviamente) il pelo nell’uovo nonchè il diritto (dovere?) di criticare.

Faccio una premessa (e vi avviso già che me la tirerò non poco). Sono sul campo dal 2006/2007: gli anni in cui venivano lanciate le prime offerte “cloud” (2/3 anni prima del vero e proprio boom). Sono di quelli che l’hanno visto nascere e crescere, di quelli che hanno fatto in tempo a chiedersi “cos’è sta roba?” e che a questa domanda hanno trovato 150 risposte diverse, che hanno visto lanciarsi sul mercato i player che oggi sono i “big” del settore, sono tra quelli che hanno partecipato alle discussioni sullo sviluppo o anche solo sul naming dei vari componenti che lo rendono possibile.

Ho visto scorrere sangue in conseguenza a domande come “Hey, cos’è il cloud?”, date le centinaia di opinioni diverse in merito. Fin dagli albori ho iniziato a intravedere i vantaggi (e le sfide) che questo nuovo modello portava, e ho subito iniziato a lavorarci (forse sarebbe più onesto dire “giocarci”, almeno per quanto riguarda i primi tempi): è stato amore a prima vista. Ci ho dedicato, in un modo o nell’altro, ogni giorno della mia vita professionale fino ad oggi, e continuo a farlo. So come si usa, so come lo si rende possibile, so perchè va usato e quando.

Ecco perchè secondo me con l’università non può funzionare:

  • Nel cloud, in tutte le sue forme (SaaS/PaaS/IaaS) ci sono ancora troppe di discussioni aperte (la definizione stessa non è univoca). C’è parecchia instabilità, su tutti i livelli: com’è possibile insegnarne una singola versione, facendola passare per verità rivelata? Com’è possibile pretendere che qualcuno impari questa “verità rivelata” da un libro, quando se ci si mettesse a studiare su Google (anche se, purtroppo, non sembra pratica comune) emergerebbero milioni di opinioni diverse su ogni singola parola? Stiamo forse nuovamente premiando chi si mette li piegato sul libro e impara tutto a memoria senza mai guardarsi intorno?
  • I professori che tengono questi corsi, a quanto ho visto, non sono esattamente dei giovincelli. Parlo di persone che hanno passato gli ultimi 20/30 anni di vita nella didattica. Questo fa di loro degli ottimi professori, ma forse non ne fa degli ottimi insegnanti per un modello, il cloud computing, che esiste si e no da 6 anni: quante ore possono averci dedicato sul campo? Zero? Forse non sono nemmeno stati in prima linea abbastanza tempo per comprendere come mai è nato, quali sono le richieste che l’hanno fatto crescere, ed in quali ambiti si colloca. Come insegnano, ma soprattutto cosa insegnano? Parlano forse per sentito dire come la peggior pettegola di paese?
  • La volatilità dei concetti è estrema: parlando in generale, e non del singolo servizio dello specifico fornitore, quello che è vero oggi potrebbe non esserlo più domani. La difficoltà nello spiegare cosa sia un’istanza cloud è enorme: chiedetemi piuttosto cos’è un’istanza Amazon EC2, che a differenza della prima è qualcosa di ben definito.

Con questa poca esperienza e con questa miriade di discussioni attualmente in sviluppo, come si può pretendere di valutare con un numero le competenze di uno studente?

Mi spiego con un esempio: 4 anni fa, lo storage a blocchi tra le nuvole era presente in due forme. Quella persistente, affidabile, ultra ridondata ma tremendamente lenta, e quello locale, più veloce ma estremamente instabile e inaffidabile. Era opinione comune che i RDBMS “classici” come MySQL e Oracle non potessero essere spostati nella cloud, perchè avidi di IOPS. Se qualcuno mi avesse chiesto di elencare le differenze tra un VPS ed un Cloud Server avrei sicuramente citato questo punto: 4 anni fa, sarebbe stato parte della definizione.

Poi le cose sono cambiate: è arrivato chi ha messo una SAN ad alte prestazioni dietro agli hypervisor, offrendo storage ridondato ma ad alte prestazioni. Amazon ha lanciato gli EBS con “Provisioned IOPS”, che permettono di prevedere e garantire le prestazioni di un certo storage. Altri player hanno messo sul mercato soluzioni SSD-based sulle quali quasi non ci si accorge di essere in un ambiente virtuale.

Nel giro di pochi mesi, la “lentezza” dei dischi è sparita dalla definizione: non era più parte del cloud. MySQL tra le nuvole è diventato d’un tratto non solo possibile ma anche ottimale. Tutto è cambiato, di nuovo. A che cosa sarebbe servito spendere 10 CFU, 300 ore di studio, per imparare definizioni che erano già predestinate a diventare superate (e quindi, sbagliate)?

Questa è per tutti una grande occasione per buttare via il modello di insegnamento verticale, che evidentemente in questa materia non può funzionare, e per comprendere la dinamicità con cui ci si deve formare in un ambiente lavorativo, in contrasto con quello scolastico.

Lasciate che ad insegnarvi il cloud siano le centinaia di persone che l’hanno fatto, e non dei professori che, mentre tutti noi traslocavamo tra le nuvole, erano in aula a spiegare.

%d bloggers like this: