Google ha ucciso Golang. Con un colpo secco.

Sono sempre stato un grande fan di Golang, il linguaggio di programmazione compilato che Google ha creato diversi anni fa. E’ un linguaggio semplice, performante, ha una curva di apprendimento veloce, e per un architetto che voglia fare un prototipo, e’ perfetto. Purtroppo, google ha deciso di ucciderlo.

Prima di parlare del perche’ e del cosa, parliamo del come. 

Ogni compagnia ha un “core business”. I dipartimenti che hanno il core business sono quelli “politicamente” piu’ forti, gli altri li subiscono. Per esempio, il dipartimento che fu responsabile di Kubernetes ovviamente ha ottenuto per google una grande visibilita’ , il che aiuta google, ma in caso di una disputa col core business, verrebbero licenziati loro.

Cosa significa? Significa che in caso ci sia un periodo di magra, ci saranno dei tagli: ma non andranno MAI ad impattare il “core business”. Pagheranno sempre gli altri dipartimenti. 

Ora, il core business di Google e’ raccogliere dati e processarli, sia per utenti privati (cioe’ per la pubblicita’) sia per agenzie governative americane, che accedono ai sistemi di google (per legge, negli USA) e che comprano (in maniera “coperta”) i sistemi di datamining, per trattare i dati, in questo modo finanziando google. Non e’ da sottovalutare questo ultimo introito, e c’e’ chi pensa che i giganti USA non potrebbero vivere senza i soldi delle agenzie governative.

Per questa ragione, il prodotto o il dipartimento che non raccolgono abbastanza dati vengono tagliati. Potrete trovare la lista dei prodotti che non raccoglievano abbastanza dati qui:

https://killedbygoogle.com/

Questa “google graveyard” e’ la lista di prodotti che, per mancato successo commerciale o per caratteristiche tecniche, non raccoglievano abbastanza dati per google, da soddisfare il core-business di google. Al momento della contesa, cioe’ al momento di distribuire il budget per i dipartimenti, core business prevale e loro vengono chiusi.


Il core business non agisce sugli altri dipartimenti sempre in questo modo. Alcuni hanno la possibilita’ di emendare, e cominciare a raccogliere dati. Un esempio, quello di cui parlo in questo post, e’ golang, il linguaggio di programmazione inventato da google.

Cosa succede? Succede che “core business” ha imposto a golang di piazzare strumentazione per telemetria nel compilatore, e di riflesso anche nella runtime engine dei software che compilate con quel compilatore.

In pratica, non solo google vuole spiare il programmatore, ma vuole spiare chi usa il software scritto in golang.

Ecco il thread ove se ne discute:

https://github.com/golang/go/discussions/58409

Come potete vedere, prima cercano di convincere tutti che “sarebbe un bene per i programmatori” (nonostante golang arrivi gia’ con uno strumento di profilazione) , ma cerca di dimostrare cose come “il GDPR vale solo se gestisci dei PII” , leggenda metropoliana molto diffusa negli USA, che ha portato molti fraintendimenti:

I metadati non sono innocui come credete.

Tutta la discussione avviene in malafede, ed e’ visibile quando si parla di opt-in e opt-out.

Dei provvidenziali utenti che si definiscono “programmatori” sostengono, di fatto, che sarebbe meglio per il programmatore se l’opt-in fosse automatico, mentre l’opt-out fosse volontario.

  • opt-in e’ il processo con cui il compilatore comincia a spiarvi. Secondo google, deve essere il default, a meno di non disabilitarlo.
  • opt-out e’ il processo con cui smettete di usare la “telemetria”, ovvero lo spionaggio, che deve essere volontario, ovvero richiede un’azione.

Perche’ e’ fondamentale? Perche’ molto del software che trovate su github, o anche nel mio repository, e’ scritto in go e nel Dockerfile per creare l’immagine si limita a fare “go build”. Questo significa che, se in un domani il compilatore da opt-in per default, tutto il software open source compilato automaticamente comincera’ a fare telemetria.

Insomma, siccome il software opensource non spia (o spia di meno) gli utenti perche’ il codice e’ leggibile, mettono il codice malizioso nel compilatore e lo piazzano nel runtime al momento della competizione.

Cosa ne penso?

 

Andiamo al “perche'” questo e’ sbagliato. Il problema e’ che esistono dei mondi (enterprise, corporate, telco, gas&oil, etc) ove esistono dipartimenti IT, i quali creano regole per garantire , se non la sicurezza, alcune buone pratiche che garantiscono la sicurezza.

Un’architettura molto usata, per fare un esempio, e’ quella “3 tier”, cioe ogni sistema somiglia schematicamente a questo:

Come vedete, il Tier 1 ha i cosiddetti frontend, (dietro un firewall, naturalmente), che agiscono come elemento di separazione. Poi , dietro un secondo firewall, c’e’ la business logic, che voi forse chiamate “backend” quando dite di essere backend developers. Infine, dietro un altro firewall, ci sono i dati, cioe’ il nuovo petrolio.

L’utente si trova a sinistra in questo schema.

Come potete immaginare, il backend NON si connette MAI ad internet. Esso puo’ leggere il database, ma se vuole comunicare con l’esterno perche’ e’ necessario lo fa dopo aver chiesto una “Security Exception”, e attraverso un outbound proxy che si deve per forza trovare nella zone di frontend. E deve avere strumenti di sicurezza, cioe’ il firewall lo lascia andare solo in determinati posti.

So che adesso i programmatori mi diranno “muh microservices”, e la mia risposta e’ che o li piazzi nel transaction tier o te li ficchi nel culo, e a nessun architetto, dipartimento di operations o dipartimento di sicurezza interessa la tua opinione. Almeno, in nessuna azienda seria.

Un altro modo e’ quello di avere piu’ zone, e una vera e propria matrice di connessioni. Potete pensare a questo:

ovviamente, a seconda delle zone, esse potranno o meno comunicare le une con le altre. E’ un approccio piu’ moderno, piu’ flessibile, ma considerate che tutti i “salsicciotti beige” sono, di fatto, dei firewall. Questo vi fa capire quanta paranoia ci sia.

Dopo che google avra’ inserito il suo spyware nel compilatore, dovremo andare a chiedere alle aziende di inserire nelle loro reti dei software che vogliono parlare con l’esterno, da una qualsiasi parte della loro rete. 

Sapete cosa vi diranno i dipartimenti di operations e security? Vi indicheranno il cartello che sta all’entrata del dipartimento:


Il mondo telco e’ ancora peggiore, perche’ si fonda su tre concetti: inband, outband, offband. E c’e’ una regoletta scritta e reiterata dalla LEGGE in tutti i paesi europei, secondo la quale QUALSIASI sistema di control plane e’ offband. Idem per tutto cio’ che gli somiglia.

In pratica, tutti gli OSS, BSS, EMS, e tutte le interfacce di amministrazione e controllo, devono essere offband. E ci sono fior di firewall e allarmi a riguardo: nessuno ci deve entrare da fuori. 

Immaginate quindi che ad un certo punto qualcuno ( per esempio: https://opennetworking.org/) si trovi con interi stack scritti in golang, che devono convincere le telco (mediante system integrators o aziende di consulenza) a piazzare in rete. La rete 5G e’ piena di questi middleware, e se girate per il sito notate che sono scritti in golang.

Morale: sono migrati da python a golang, e ora migreranno ad altro.


Il problema della fiducia.

Certo, per ora google offre un metodo per fare opt-out, ma in futuro potrebbe cambiare idea.  Il guaio e’ che nessun manager o dipartimento vogliono essere colti in fallo da una decisione improvvisa di google, e dover migrare in un momento qualsiasi: di conseguenza penseranno di migrare via da golang, lentamente, ma preventivamente.

Complimenti google, hai appena ucciso il tuo nuovo linguaggio. E non se ne accorgera’ nessuno, perche’ avendo un 3% del market share globale, la sua morte passera’ completamente inosservata.

Just another gravestone in the google graveyard.


Sinora lo strumento di telemetria non e’ ancora stato inserito. Ci sono altre aziende, come Apple, che hanno messo lo strumento di telemetria dentro il loro linguaggio di programmazione. Indovinate un po’ in quante corporate, enterprise o telco trovate linguaggi scritti in questo linguaggio che comincia per s e finisce per t. Apple.  Punto.


Mitigazione.

Esiste anche un altro compilatore go, di LLVM, che e’ opensource e utilizza parte del compilatore gnu. La prima cosa fa fare, per chi deve pubblicare patch e altro, dopo l’inserimento del malware nel compilatore, sara’ di tenere il codice ma cambiare compilatore.

https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gccgo/

Occorrono alcuni cambiamenti del codice, ma e’finanziariamente accettabile.

Poiche’ google e’ anche nota per fare patent harassment, e’ visibile all’orizzonte il momento in cui google decidera’ che golang e’ solo suo. Quindi si tratta di uno strumento di mitigazione ma non di una soluzione.

L’unica vera soluzione e’ la migrazione.

verso dove?


Vista la tipologia di backend scritti in go, esistono dei linguaggi “naturalmente” indicati per sostituirlo. Vediamoli.

Linguaggio Pro Contro
Rust Toolchain simile a golang, safe threads, efficiente quanto go. Opensource. Il programmatore deve pensare un sacco. Occorrono programmatori col cervello. Costano piu’ delle scimmie javascript o java.
ADA Si e’ evoluto molto ed e’ paragonabile a golang. E’ molto piu’ safe sotto ogni aspetto. Produce eseguibili efficenti. E’ testatissimo e usato in aereospaziale e mondo mission-critical. Ha ancora una grossa fanbase. Opensource. Il programmatore deve pensare un sacco. Occorrono programmatori col cervello. Costano piu’ delle scimmie javascript o java.
C++ Si evolve di continuo , allontanandosi dal C, e in quanto ad efficienza del codice e’ praticamente imbattibile. Ha una cardinalita’ immensa, che si traduce in una potenza immensa. Opensource. Il programmatore deve pensare un sacco. Per usare le ultime versioni deve essere l’equivalente di un mandarino cinese. Occorrono programmatori senior col cervello. Costano piu’ delle scimmie javascript o java.

Personalmente sono indeciso tra questi. Del resto, uno non esclude l’altro, a seconda dell’ambito.


Cosa succedera’a Kubernetes , Docker e a tutti gli altri sistemi scritti in golang?

Beh, il fatto e’ che quando si parla di sicurezza e GDPR, i clienti diventano isterici, e tendono a liberarsi degli incomodi. Se si ventilasse, o si ventilera’, la possibilita’ di finire in un guaio per via di queste telemetrie, o pretenderanno (qualora possibile) che tutto sia compilato senza telemetria, oppure (quando non sara’ piu’ possibile fare opt-out), semplicemente migreranno ad altro.


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *