Perbacco, Google, non volevo tornare a scrivere un blog. Ho così tante cose da fare. Tenere un blog richiede tempo, energia e creatività che potrei usare per cose più utili: i miei libri, , il mio gioco e così via. Ma mi hai davvero fatto arrabbiare, quindi devo scriverlo.
Quindi, finiamo con questo.
Inizierò con una piccola ma istruttiva storia di quando ho iniziato a lavorare in Google. So che ultimamente ho detto molte cose negative su Google, ma mi infastidisce quando la mia stessa azienda prende regolarmente decisioni aziendali incompetenti. Detto ciò, bisogna riconoscere: l'infrastruttura interna di Google è davvero straordinaria, si può affermare con certezza che oggi non c'è nulla di meglio. I fondatori di Google erano ingegneri di gran lunga migliori di quanto io possa mai diventare, e questa storia lo conferma.
Prima un po' di contesto: Google ha una tecnologia di archiviazione dati chiamata . È stata una meravigliosa conquista tecnica, una delle prime (se non la prima) archiviazione chiave-valore "infinita": in sostanza, l'inizio di NoSQL. Oggi Bigtable si sta ancora comportando bene in uno spazio piuttosto affollato di archiviazioni K/V, ma all'epoca (2005) era veramente fantastico.
Un dettaglio interessante su Bigtable è che avevano oggetti interni di piano di controllo (come parte dell'implementazione) chiamati server tablet, con indici grandi, e ad un certo punto divennero un collo di bottiglia nella scalabilità del sistema. Gli ingegneri di Bigtable si sono chiesti come implementare la scalabilità, e all'improvviso hanno capito che potevano sostituire i server tablet con altri archivi Bigtable. Quindi Bigtable è parte dell'implementazione di Bigtable. Questi archivi ci sono a tutti i livelli.
Un altro dettaglio interessante è che per un certo periodo Bigtable è diventato popolare e onnipresente all'interno di Google, e ogni team aveva il proprio storage. Così, durante una delle riunioni del venerdì, Larry Page chiese distrattamente: "Perché abbiamo più di un Bigtable? Perché non accontentarci di uno solo?" Teoricamente, un singolo storage avrebbe dovuto bastare per tutte le necessità di archiviazione di Google. Certo, non sono mai passati a un solo storage per ragioni pratiche di sviluppo (ad esempio, le conseguenze di un potenziale guasto), ma l'idea era interessante. Un storage per l'intero universo (a proposito, qualcuno sa se Amazon ha fatto qualcosa del genere con il suo Sable?)
In ogni caso, ecco la mia storia.
All'epoca lavoravo in Google da poco più di due anni, e un giorno ricevetti una email dal team di ingegneria di Bigtable che conteneva più o meno questo:
Caro Steve,
Saluti dal team di Bigtable. Vogliamo informarti che nel data center [nome del data center] stai utilizzando un file binario di Bigtable molto, molto vecchio. Questa versione non è più supportata e vogliamo aiutarti a passare all'ultima versione.
Per favore, fammi sapere se puoi pianificare del tempo per lavorare insieme su questa questione.
Tanti saluti,
Il team di Bigtable
In Google ricevi molte email, quindi a prima vista lessi circa così:
Caro destinatario,
Saluti da qualche team. Vogliamo farti sapere che bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, e bla-bla-bla immediatamente.
Per favore, facci sapere se puoi pianificare un po' del tuo prezioso tempo per bla-bla-bla.
Tanti saluti,
Qualche team
Stavo quasi per eliminarlo immediatamente, ma alla periferia della mia coscienza avvertii un pesante, fastidioso sentore che questo non è proprio un'email formale, anche se evidentemente, c'era un errore con il destinatario, perché non usavo Bigtable.
Ma era strano.
Il resto della giornata passai alternando pensieri sul lavoro e su quale tipo di carne di squalo provare nella microcucina, di cui almeno tre erano abbastanza vicine da poterci arrivare con un preciso lancio di un biscotto, ma il pensiero dell'email non mi lasciava con una crescente sensazione di leggera ansia.
Hanno chiaramente nominato il mio nome. E la lettera è stata inviata al mio indirizzo email, e non a quello di qualcun altro, e non è cc: o bcc:. Il tono è molto personale e chiaro. Forse è un errore?
Finalmente, la curiosità ha preso il sopravvento e sono andato a dare un'occhiata alla console Borg nel data center che hanno menzionato.
E ovviamente, avevo sotto il mio controllo un archivio BigTable. Cosa?! Ho dato un’occhiata al suo contenuto, e — accidenti! Era dal laboratorio Codelab, dove ero stato durante la mia prima settimana di lavoro in Google nel giugno 2005. Codelab ti costringeva a lanciare Bigtable, affinché tu registrassi alcuni valori, e evidentemente non ho chiuso l’archivio dopo. Era ancora attivo, nonostante fossero passati più di due anni.
Ci sono alcuni aspetti notevoli in questa storia. Innanzitutto, l'uso di Bigtable era così insignificante nel contesto di Google che solo dopo due anni qualcuno ha notato l'archivio in più, e solo perché la versione del binario era scaduta. Per fare un confronto, una volta stavo considerando l’uso di per il mio gioco online. All'epoca, il servizio costava circa $16.000 all'anno per un Bigtable vuoto su GCP. Non dico che ti stiano ingannando, ma a mio avviso, è una grossa somma per un dannato database vuoto.
Un altro aspetto notevole è che l'archivio era ancora attivo dopo due anni. Che diavolo? I data center vanno e vengono; attraversano interruzioni, subiscono manutenzione programmata, cambiano costantemente. L'hardware viene aggiornato, gli switch vengono spostati, tutto viene continuamente migliorato. Come diavolo sono riusciti a mantenere il mio programma attivo per due anni nonostante tutti questi cambiamenti? Può sembrare un risultato modesto nel 2020, ma tra il 2005 e il 2007 era molto impressionante.
E il maggior aspetto sorprendente è che un team di ingegneri esterni in un altro stato si rivolge a me, proprietario di un piccolo, praticamente vuoto esempio di Bigtable, che ha zero traffico negli ultimi due anni — e offre assistenza per aggiornarlo.
Li ho ringraziati, ho eliminato l'archivio, e la vita è andata avanti. Ma tredici anni dopo, penso ancora a quella lettera. Perché a volte ricevo lettere simili da Google Cloud. Sembrano così:
Gentile utente di Google Cloud,
Ti ricordiamo che interromperemo il servizio [servizio importante che utilizzi] a partire da agosto 2020, dopodiché non potrai aggiornare le tue istanze. Ti consigliamo di passare all'ultima versione in fase di beta testing, priva di documentazione, senza alcuna procedura di migrazione e che è già obsoleta con il nostro gentile aiuto.
Ci impegniamo a garantire che questo cambiamento abbia un impatto minimo su tutti gli utenti della piattaforma Google Cloud.
Migliori amici per sempre,
Piattaforma Cloud Google
Ma in realtà leggo raramente queste lettere, perché in esse si dice quanto segue:
Caro destinatario,
Va' a quel paese. Va' a quel paese, va' a quel paese, va' a quel paese. Lascia perdere tutto ciò che stai facendo, perché non importa. Ciò che conta è il nostro tempo. Spendiamo tempo e denaro per mantenere le nostre cose, e siamo stanchi di questo, quindi non le supporteremo più. Pertanto, abbandona i tuoi piani e comincia a scavare nella nostra documentazione scadente, chiedendo pezzi di informazioni nei forum; e, a proposito, la nostra nuova roba è completamente diversa dalla vecchia, perché abbiamo rovinato abbastanza il design, eh, ma questo è un tuo problema, non nostro.
Continuiamo a fare sforzi affinché tutte le tue sviluppature diventino inutilizzabili in un anno.
Per favore, vai a quel paese,
Piattaforma Cloud Google
E la questione è che ricevo lettere del genere circa una volta al mese. Succede così spesso e in modo così costante che inevitabilmente mi ha allontanato da GCP in un campo di opposizione al cloud. Non sono più disposto a dipendere dai loro sviluppi proprietari, perché in realtà è più facile per un DevOps mantenere un sistema open source su una semplice macchina virtuale, piuttosto che cercare di tenere il passo con Google e la sua politica di chiusura dei prodotti "obsoleti".
Prima di tornare a Google Cloud, perché io neanche lontanamente non ho finito di criticarli, diamo un'occhiata al lavoro dell'azienda in alcune altre aree. Gli ingegneri di Google sono orgogliosi della loro disciplina nello sviluppo software, e proprio questo crea problemi. L'orgoglio è una trappola per gli imprudenti, ha fatto pensare a molti dipendenti di Google che le loro decisioni siano sempre corrette e che la correttezza (secondo una qualche definizione vaga) sia più importante della cura per i clienti.
Ecco alcuni esempi casuali da altri grandi progetti al di fuori di Google, ma spero che vediate questo modello ovunque. Si riassume nel seguente modo: la retrocompatibilità sostiene la longevità e la rilevanza dei sistemi per decenni.
La retrocompatibilità è l'obiettivo di design di tutti i sistemi di successo destinati a uso aperto, cioè realizzati con codice open source e/o su standard aperti. Sento di dire qualcosa di troppo ovvio, che addirittura mette a disagio, ma così non è. È una questione politica, quindi ci vogliono esempi.
Il primo sistema che scelgo, il più vecchio: GNU Emacs, è una sorta di ibrido tra il Blocco Note di Windows, il kernel del sistema operativo e la Stazione Spaziale Internazionale. È un po' difficile da spiegare, ma in breve Emacs è una piattaforma creata nel 1976 (sì, quasi mezzo secolo fa) per la programmazione, per migliorare la tua produttività, ma si maschera da editor di testo.
Uso Emacs ogni giorno. Sì, uso anche IntelliJ ogni giorno, che a sua volta è diventato una potente piattaforma di strumenti. Ma scrivere estensioni per IntelliJ è un compito molto più ambizioso e complesso rispetto a scrivere estensioni per Emacs. E cosa ancor più importante, tutto ciò che è stato scritto per Emacs rimane per sempre..
Utilizzo ancora il software che ho scritto per Emacs nel 1995. E sono sicuro che ci siano persone che usano moduli scritti per Emacs a metà degli anni '80, se non prima. Di tanto in tanto possono richiedere piccole modifiche, ma questo accade davvero molto raramente. Non so nulla di ciò che ho mai scritto per Emacs (e ne ho scritto molto) che necessitasse di una riscrittura dell'architettura.
In Emacs esiste una funzione chiamata make-obsolete per entità obsolete. La terminologia di Emacs per concetti informatici fondamentali (ad esempio, cosa si intende per «finestra») spesso differisce dalle convenzioni di settore, poiché Emacs li ha introdotti molto tempo fa. Questo è un tipico rischio per chi ha anticipato i propri tempi: tutti i vostri termini sono imprecisi. Ma in Emacs esiste effettivamente un concetto di obsolescenza, che nel loro gergo è chiamato obsolescenza.
Ma nel mondo di Emacs, sembra esserci un'altra definizione operativa. Un'altra filosofia fondamentale, se vuoi.
Nel mondo di Emacs (e in molti altri ambiti che esamineremo di seguito), lo stato delle API obsolete significa principalmente: «Non dovresti davvero utilizzare questo approccio, perché, anche se funziona, presenta vari difetti che elencheremo qui. Ma, alla fine, è una tua scelta».
Nel mondo di Google, lo stato di un prodotto obsoleto significa: «Violiamo i nostri impegni nei tuoi confronti». E questo è vero. Ecco cosa significa essenzialmente. Significa che ti costringeranno a effettuare regolarmente alcuni lavori, forse un gran lavoro, in punizione per aver creduto nella loro : abbiamo il miglior software. Il più veloce! Fai tutto secondo le istruzioni, avvii la tua applicazione o il tuo servizio, e poi - bam, dopo un anno o due si rompe.
È come vendere un'auto usata che sicuramente si romperà dopo 1500 km.
Queste sono due definizioni filosofiche completamente diverse di «obsolescenza». La definizione di Google puzza di . Non credo che sia è davvero obsolescenza pianificata nello stesso senso in cui la intende Apple. Ma Google pianifica sicuramente di far fallire i tuoi programmi, in modo indiretto. Lo so perché ho lavorato lì come ingegnere informatico per oltre 12 anni. Hanno raccomandazioni interne vaghe su quanto dovrebbe essere mantenuta la retrocompatibilità, ma alla fine dipende da ogni singolo team o servizio. Non ci sono raccomandazioni a livello aziendale o ingegneristico, e la raccomandazione più audace in termini di cicli di obsolescenza è «cerca di dare ai clienti 6-12 mesi per aggiornarsi, prima di rompere l'intero sistema».
Il problema è molto più serio di quanto pensino e persisterà per molti anni, poiché la cura dei clienti non fa parte del loro DNA. Maggiori dettagli di seguito.
Al momento, mi appresto a fare un'affermazione audace: Emacs ha avuto un grande successo in larga misura e anche principalmente perché prendono molto sul serio la compatibilità all'indietro. In effetti, questo è il tema del nostro articolo. I sistemi aperti di successo e di lunga durata devono il loro successo alle microcomunità che vivono intorno a estensioni/plugin. Questa è l'ecosistema. Ho già riflettuto sull'essenza delle piattaforme e su quanto siano importanti, e su quanto Google, in tutta la sua storia aziendale, non abbia mai compreso cosa significhi creare una piattaforma open source di successo, a parte Android o Chrome.
In effetti, dovrei menzionare brevemente Android, perché probabilmente ci hai già pensato.
Per prima cosa, Android non è Google. Non hanno praticamente nulla in comune. Android è un'azienda acquistata da Google nel luglio 2005, a questa azienda è stato permesso di operare in modo più o meno autonomo ed è rimasta in gran parte intatta nel corso degli anni. Android è un famoso stack tecnologico e un'organizzazione altrettanto famosa per la sua scarsa accessibilità. Come ha detto un dipendente di Google, "non puoi semplicemente entrare in Android".
In uno dei miei articoli precedenti, ho già riflettuto su quanto fossero scadenti alcune delle prime decisioni di design di Android. Accidenti, quando scrivevo quel pezzo, stavano lanciando spazzature chiamate "app istantanee", che ora (sorpresa!) , e mi dispiace se sei stato abbastanza sciocco da seguire Google e trasferire i tuoi contenuti in queste app istantanee.
Ma qui c'è una differenza, una differenza sostanziale, che consiste nel fatto che le persone di Android capiscono davvero quanto siano importanti le piattaforme e si sforzano di mantenere l'usabilità delle vecchie applicazioni Android. In effetti, i loro sforzi per mantenere la compatibilità retroattiva sono così estremi che anch'io, durante il mio breve periodo nel team Android alcuni anni fa, cercavo di convincerli a rinunciare al supporto per alcuni dei dispositivi e API più vecchi (mi sbagliavo, così come su molte altre cose del passato e del presente. Scusate, ragazzi di Android! Ora, dopo essere stato in Indonesia, capisco perché ci servono).
Le persone di Android mantengono la compatibilità retroattiva fino a quasi livelli inimmaginabili, il che accumula un'enorme quantità di debito tecnico obsoleto nei loro sistemi e catene di strumenti. Oh cielo, avreste dovuto vedere alcune cose folli che devono fare nel loro sistema di build, e tutto ciò in nome della compatibilità.
Per questo motivo assegno ad Android il prestigioso premio "Non sei Google". Non vogliono davvero diventare Google, che non riesce a creare piattaforme durevoli, mentre Android sa come farlo. conosce, ecco perché Google si comporta molto saggiamente in un certo senso: lascia che le persone di Android facciano le cose a modo loro.
Tuttavia, le app istantanee per Android erano piuttosto un'idea stupida. E sapete perché? Perché richiedevano di riscrivere e riprogettare la propria app! Come se le persone potessero semplicemente riscrivere due milioni di applicazioni. Suppongo che le app istantanee siano state l'idea di qualche Googler.
Ma qui c'è una differenza. La compatibilità retroattiva comporta costi significativi. Android stesso si fa carico di questi costi, mentre Google insiste affinché questi costi siano sostenuti farete, da un cliente a pagamento.
È possibile vedere l'impegno di Android per la compatibilità retroattiva nelle sue interfacce API. Quando hai quattro o cinque sottosistemi diversi per eseguire letteralmente la stessa cosa, è un chiaro segno che alla base c'è un impegno per la compatibilità retroattiva. Cosa che nel mondo delle piattaforme è sinonimo di impegno verso i propri clienti e il proprio mercato.
Il principale problema di Google qui è il loro orgoglio per la propria igiene ingegneristica. Non gli piace quando ci sono molti modi diversi di fare la stessa cosa, e i vecchi, meno desiderabili metodi siedono accanto ai nuovi, più stravaganti metodi. Questo aumenta la curva di apprendimento per i neofiti del sistema, aumenta il carico di supporto per le API obsolete, rallenta la velocità delle nuove funzionalità e il peccato principale è che non è estetico. Google è come Lady Escot di 'Alice nel Paese delle Meraviglie' di Tim Burton:
Lady Escot:
— Alice, sai di cosa ho più paura?
— Del declino dell'aristocrazia?
— Temevo di avere nipoti brutti.
Per comprendere il compromesso tra bello e pratico, diamo un'occhiata alla terza piattaforma di successo (dopo Emacs e Android) e vediamo come funziona: Java stessa.
In Java ci sono molte API obsolete. L'obsolescenza è molto popolare tra i programmatori Java, anche più che in molti altri linguaggi di programmazione. Nella stessa Java, il linguaggio principale e le librerie, le API obsolescenti compaiono continuamente.
Se prendiamo solo uno dei mille esempi, è considerata obsoleta. È diventata obsoleta dal rilascio di Java 1.2 nel dicembre 1998. Sono passati 22 anni da allora che è obsoleta.
Ma il mio reale codice in produzione continua a chiudere i thread ogni giorno. È una cosa buona? Assolutamente! Voglio dire, certo, se avessi riscritto il codice oggi, lo avrei implementato in modo diverso. Ma il codice del mio gioco, che ha reso felici centinaia di migliaia di persone negli ultimi due decenni, è scritto con la funzione di chiusura dei thread, che rimangono attivi troppo a lungo, e io non ho mai dovuto cambiarlo. Conosco il mio sistema meglio di chiunque altro, ho letteralmente 25 anni di esperienza con esso in produzione, e posso dire con certezza: nel mio caso, la chiusura di questi specifici thread di lavoro è completamente inoffensiva. Non vale la pena perdere tempo ed energia a riscrivere questo codice, e grazie a Larry Ellison (probabilmente) se Oracle non mi ha costretto a riscriverlo.
Probabilmente, anche Oracle sa come gestire le piattaforme. Chi lo sa.
Puoi incontrare prove in tutte le API Java chiave, pervase da onde di obsolescenza, simili alle linee di un ghiacciaio in un canyon. Nella libreria Java Swing, è facile trovare cinque o sei diversi manager per la navigazione tramite tastiera (KeyboardFocusManager). In realtà è difficile trovare una API Java che non sia obsoleta. Ma funzionano ancora! Penso che il team Java rimuoverà realmente l'API solo se l'interfaccia causerà un problema di sicurezza eclatante.
Ecco il punto, ragazzi: noi, sviluppatori software, siamo tutti molto occupati e in ogni campo del software ci troviamo di fronte a alternative concorrenti. In qualsiasi momento, i programmatori del linguaggio X considerano il linguaggio Y come una possibile sostituzione. Oh, non ci credi? Vuoi nominare Swift? Diciamo che tutti migrano a Swift e nessuno lo abbandona, giusto? Cavolo, quanto poco sai. Le aziende considerano i costi per i team di sviluppo mobile doppi (iOS e Android) — e cominciano a capire che questi sistemi di sviluppo cross-platform con nomi ridicoli, come Flutter e React Native, funzionano davvero, e con il loro aiuto possono ridurre le dimensioni dei loro team mobili della metà o, al contrario, rendere il lavoro due volte più produttivo. In gioco ci sono soldi veri. Sì, ci sono dei compromessi, ma dall'altra parte ci sono dei d-e-n-a-r-i.
Supponiamo ipoteticamente che Apple per stupidità prenda spunto da Guido van Rossum e dichiarasse che Swift 6.0 non è retrocompatibile con Swift 5.0, proprio come Python 3 non è compatibile con Python 2.
Probabilmente ho raccontato questa storia dieci anni fa, ma quindici anni fa sono andato al camp di O’Reilly’s Foo Camp con Guido, ero in tenda con Paul Graham e un sacco di grossi nomi. Stavamo seduti sotto il caldo estenuante aspettando che Larry Page arrivasse in elicottero privato, mentre Guido blaterava monotono di "Python 3000", che ha chiamato così per il numero di anni che ci vorrebbero a tutti per migrarci. Continuavamo a chiedergli perché violasse la compatibilità, e lui rispondeva: "Unicode". E noi continuavamo a chiedere, se dovevamo riscrivere il nostro codice, quali altri vantaggi avremmo visto? E lui rispondeva "Yoooooooooooooouuuuuuuniiiiiiicoooooooode".
Se installi il Google Cloud Platform SDK (“gcloud”), riceverai la seguente notifica:
Caro destinatario,
Vorremmo ricordarvi che il supporto per Python 2 è obsoleto, quindi se ne vada.
… e così via. Il ciclo della vita.
Ma il fatto è che ogni sviluppatore ha una scelta. E se costringete a riscrivere il codice troppo spesso, potrebbero anche considerare di altri cercare alternative. Non sono vostri prigionieri, per quanto possiate desiderarlo. Sono vostri ospiti. Python rimane un linguaggio di programmazione molto popolare, ma, accidenti, Python 3(000) ha creato così tanto caos tra le sue comunità e gli utenti delle sue comunità che le conseguenze non possono essere messe in ordine da quindici anni.
Quante applicazioni Python sono state riscritte in Go (o Ruby, o qualche altra alternativa) a causa di questa incompatibilità? Quanto nuovo software è stato scritto su qualcosa di diverso da Python, anche se poteva essere scritto in Python, se Guido non avesse bruciato il villaggio? È difficile dirlo, ma Python ha chiaramente subito danni. È un grande disastro e tutti perdono.
Quindi, supponiamo che Apple prenda esempio da Guido e interrompa la compatibilità. Cosa pensate che succederà dopo? Beh, forse l'80-90% degli sviluppatori riscriverà il proprio software, se possibile. In altre parole, il 10-20% della base utenti passerà automaticamente a un linguaggio concorrente, come Flutter.
Fate questo un paio di volte e perderete metà della vostra base utenti. Come nello sport, anche nel mondo della programmazione l’attuale forma conta. tutto. Chiunque perda metà degli utenti in cinque anni sarà considerato un Grande Grosso Fallito. Dovete essere al passo nei mondi delle piattaforme. Ma proprio qui, abbandonare il supporto per le versioni più vecchie nel tempo vi porterà alla rovina. Perché ogni volta che vi liberate di una parte degli sviluppatori, (a) li perdete per sempre, perché sono arrabbiati con voi per la violazione del contratto, e (b) li cedete ai vostri concorrenti.
Ironia della sorte, ho anche aiutato Google a diventare una primadonna che ignora la compatibilità retroattiva quando ho creato Grok, un sistema di analisi e comprensione del codice sorgente che facilita l'automazione e l'equipaggiamento di strumenti basati sul codice stesso — sembra un IDE, ma qui il servizio Cloud memorizza le rappresentazioni materializzate di tutti i miliardi di righe di codice sorgente di Google in un grande database.
Grok ha fornito ai Googlers una potente base per eseguire il refactoring automatizzato dell'intera base di codice (letteralmente in tutto Google). Il sistema calcola non solo le vostre dipendenze ascendenti (da cui dipendete), ma anche discendenti (che dipendono da voi), quindi quando cambiate API sapete esattamente chi potrebbe rompersi! In questo modo, quando apportate modifiche, potete verificare che ogni consumatore della vostra API si sia aggiornato alla nuova versione, e in realtà spesso con lo strumento Rosie, che hanno scritto, potete automatizzare completamente il processo.
Questo permette alla base di codice di Google di essere internamente quasi "pulita" in modo soprannaturale, poiché questi servitori robotici si aggirano per tutta la casa e puliscono automaticamente tutto, se rinominano SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName, perché qualcuno ha deciso che fosse un brutto nipote e che dovesse essere soppiantato.
E, a dire il vero, funziona piuttosto bene per Google... internamente. Voglio dire, sì, la comunità Go di Google si diverte bonariamente a deridere la comunità Java di Google per la loro abitudine al refactoring continuo. Se ripristinate qualcosa N volte, significa che non solo l'avete rovinato N-1 volte, ma dopo un po' diventa chiaro che probabilmente l'avete rovinato anche nel tentativo N. Ma, in grande misura, riescono a rimanere al di sopra di questa confusione e mantenere il codice "pulito".
I problemi iniziano quando cercano di imporre questo atteggiamento ai loro clienti cloud e agli utenti di altre API.
Vi ho presentato brevemente Emacs, Android e Java; ora diamo un'occhiata all'ultima piattaforma longeva di successo: il Web stesso. Potete immaginare quante iterazioni ha attraversato HTTP dal 1995, quando usavamo i tag lampeggianti e le icone "In sviluppo" sulle pagine web.
Ma funziona ancora! E quelle pagine funzionano ancora! Sì, ragazzi, i browser sono i campioni mondiali della retrocompatibilità. Chrome è un altro esempio raro di una piattaforma Google i cui componenti sono assemblati correttamente e, come avrete già indovinato, Chrome agisce efficacemente come un'azienda isolata separata dal resto di Google.
Voglio anche ringraziare i nostri amici tra gli sviluppatori di sistemi operativi: Windows, Linux, NON APPLE MAI APPLE, FreeBSD e così via, per il grande lavoro di retrocompatibilità che hanno svolto sulle loro piattaforme di successo (Apple riceve al massimo un tre con meno, dato che rompono tutto senza alcuna giustificazione, ma in qualche modo la comunità riesce ad affrontare tutto ciò in ogni rilascio, e finora i container con OS X non sono ancora del tutto obsoleti… per ora).
Ma aspetta, dirai. Non stiamo forse confrontando mele con arance: sistemi operativi autonomi su una sola macchina, come Emacs/JDK/Android/Chrome, con sistemi multi-server e API, come nei servizi cloud?
Bene, ne ho scritto ieri su Twitter, ma nello stile di Larry Wall (il creatore del linguaggio di programmazione Perl — nota dell'editore) secondo il principio 'schifo/rulez' ho cercato la parola deprecated sui siti per sviluppatori di Google e Amazon. E sebbene AWS abbia centinaia di volte in più offerte di servizi rispetto a GCP, la documentazione per sviluppatori di Google menziona l'obsolescenza circa sette volte più spesso.
Se qualcuno di Google legge questo, sicuramente sono pronti a tirare fuori i grafici nello stile di Donald Trump, per dimostrare che stanno facendo tutto correttamente, e che non dovrei fare confronti ingiusti, come 'il numero di menzioni della parola deprecated in base al numero di servizi'.
Ma dopo tutti questi anni, Google Cloud rimane ancora il servizio n. 3 (non ho mai scritto l'articolo sulla mia mancata rincorsa al n. 2), ma se si devono credere alle voci, ci sono alcune preoccupazioni che potrebbe presto scendere al n. 4.
Non ho argomenti validi per 'dimostrare' la mia tesi. Tutto ciò che ho sono esempi vivaci che ho accumulato in 30 anni di lavoro come sviluppatore. Ho già accennato alla natura profondamente filosofica di questo problema; in un certo senso è politicizzata nelle comunità di sviluppatori. Alcuni credono che i creatori delle piattaforme debbano preoccuparsi della compatibilità, mentre altri credono che sia responsabilità utenti (degli sviluppatori stessi). Uno dei due. E in effetti, non è una questione politica quando decidiamo chi deve sostenere i costi per i problemi comuni?
Quindi è politica. E sicuramente ci saranno risposte furiose al mio intervento.
Come utente della piattaforma cloud di Google, e anche come utente AWS per due anni (lavorando in Grab), posso dire che c'è una grande differenza tra le filosofie di Amazon e Google quando si tratta di priorità. Non sto sviluppando attivamente su AWS, quindi non so bene quanto spesso rimuovano le vecchie API. Ma ho il sospetto che non accada così frequentemente come in Google. E credo sinceramente che questa fonte di continue dispute e delusioni in GCP sia uno dei maggiori fattori che frena lo sviluppo della piattaforma.
So che non ho citato esempi specifici di sistemi GCP di cui è stata interrotta la supporto. Posso dire che praticamente tutto quello che ho usato, dalle reti (dalle più vecchie a VPC) ai magazzini (Cloud SQL v1-v2), Firebase (ora Firestore con un API completamente diversa), App Engine (non cominciamo nemmeno), ai punti di accesso cloud Cloud Endpoint e fino a… non so - assolutamente tutto questo mi ha costretto a riscrivere il codice al massimo ogni 2-3 anni, e non hanno mai automatizzato per voi la migrazione, e spesso . Come se dovesse andare così.
E ogni volta che guardo a AWS, mi chiedo perché diavolo sono ancora su GCP. Chiaramente non hanno bisogno di clienti. Hanno bisogno di acquirenti. Capisci la differenza? Lascia che spieghi.
Google Cloud ha , dove le persone offrono le loro soluzioni software, e per evitare l'effetto di un ristorante vuoto, era necessario riempirlo con alcune offerte, quindi hanno stipulato un contratto con l'azienda Bitnami per creare un sacco di soluzioni che si distribuiscono "con un clic del mouse", o devo scrivere da solo "soluzioni", perché queste non risolvono un bel niente. Esistono solo come bandierine, come riempitivo di marketing, e Google non si è mai curato se uno qualsiasi di questi strumenti funziona realmente. Conosco produttori che erano al comando e posso assicurarvi che a questi persone non interessa.
Prendiamo, ad esempio, una soluzione di distribuzione che si presume "con un clic del mouse" . Sono stanco a morte dei trucchi di Google Cloud SQL, quindi ho iniziato a considerare come alternativa la creazione di un mio cluster Percona. E questa volta Google sembrava aver fatto la cosa giusta, avevano intenzione di farmi risparmiare un po' di tempo e fatica con un solo clic di bottone!
Ottimo, andiamo. Clicchiamo sul link e premiamo questo pulsante. Selezioniamo "Sì" per accettare tutte le impostazioni predefinite e distribuire il cluster nel nostro progetto Google Cloud. Ah, ah, non funziona. Niente di questo schifo funziona. Lo strumento non è mai stato testato, ha cominciato a marcire fin dal primo minuto e non mi sorprenderà se più della metà delle "soluzioni" per il deployment con un clic (ora capiamo perché le virgolette) non funziona affatto. È un'oscurità assoluta, meglio non entrarci.
Ma Google vi invita direttamente a usarli. Vogliono che tu acquisti.Per loro è una transazione. Non vogliono niente supportare. Non fa parte del DNA di Google. Sì, gli ingegneri si supportano a vicenda, come dimostra la mia storia con Bigtable. Ma nei prodotti e nei servizi per le persone comuni sono sempre stati spietati nel che non rientri nei parametri di profittabilità, anche se ha milioni di utenti.
E questo rappresenta un serio problema per GCP, perché questo DNA è alla base di tutte le offerte cloud. Non si sforzano di mantenere nulla; è ben noto che si rifiutano di ospitare (come servizio gestito) qualsiasi software di terze parti fino a quando, fino a quando AWS non fa lo stesso e costruisce un business di successo attorno a esso, e quando i clienti ne richiedono letteralmente lo stesso. Tuttavia, è necessario fare uno sforzo per costringere Google a mantenere qualcosa.
Questa mancanza di cultura del supporto, insieme al principio "rompiamo per rendere più bello", aliena gli sviluppatori.
E non è molto positivo se vuoi costruire una piattaforma di lunga durata.
Google, svegliati, diamine. Siamo nel 2020. Stai ancora perdendo. È il momento di guardarti allo specchio e chiederti se vuoi davvero rimanere nel business del cloud.
Se vuoi rimanere, devi smetterla di rompere tutto.Ragazzi, siete ricchi. Noi, sviluppatori, no. Quindi, quando si tratta di chi dovrebbe prendersi l'onere della compatibilità, dovete farvelo carico voi. Non noi.
Perché ci sono almeno altri tre cloud davvero buoni. Ti attirano.
Ora vado a riparare tutti i miei sistemi rotti. Ah.
Fino alla prossima volta!
P. S. Aggiornamento dopo aver letto alcune discussioni su questo articolo (le discussioni sono fantastiche, tra l'altro). Il supporto per Firebase non è cessato e non ci sono piani, di cui io sia a conoscenza, per farlo. Tuttavia, hanno un brutto bug di streaming che fa fermare il client Java su App Engine. Uno dei loro ingegneri mi ha aiutato a risolvere questo problema, quando lavoravo in Google, ma non hanno mai realmente risolto il bug, quindi ho un brutto lavoro attorno ad esso, devo riavviare l'applicazione GAE ogni giorno. E così da quattro anni! Ora hanno Firestore. Ci vorrà molto lavoro per migrare, poiché si tratta di un sistema completamente diverso, e il bug di Firebase non sarà mai corretto. Qual è la conclusione? Puoi ottenere aiuto, se lavori in un'azienda. Probabilmente sono l'unico a utilizzare Firebase su GAE, perché registro meno di 100 chiavi nell'applicazione nativa al 100%, e smette di funzionare ogni paio di giorni a causa di un bug noto. Cosa si può dire, se non usarlo a proprio rischio e pericolo. Sto passando a Redis.
Ho anche visto alcuni utenti AWS più esperti dire che AWS di solito non interrompe mai il supporto per alcun servizio, e SimpleDB è un ottimo esempio. Le mie supposizioni che in AWS non ci sia quella malattia dell'interruzione del supporto come in Google sembrano giustificate.
Inoltre, ho notato che 20 giorni fa il team di Google App Engine ha rotto l'hosting di una libreria critica di Go, chiudendo l'applicazione GAE di uno dei principali sviluppatori di Go. È davvero ridicolo.
Infine, ho sentito che i googler stanno già discutendo di questo problema e in generale sono d'accordo con me (vi voglio bene, ragazzi!). Ma sembra che considerino la questione irrisolvibile, perché nella cultura di Google non c'è mai stata una vera struttura di incentivi. Penso che sarebbe bello ritagliare un po' di tempo per discutere dell'assolutamente incredibile esperienza di lavorare con gli ingegneri AWS, quando lavoravo in Grab. Magari in futuro, spero!
E sì, nel 2005 avevano davvero diversi tipi di carne di squalo su un gigantesco buffet presso il recinto 43, e a me piaceva di più la carne degli squali a testa piatta. Tuttavia, nel 2006 Larry e Sergey eliminarono tutti gli snack poco salutari. Quindi, durante la storia di Bigtable nel 2007, in effetti non c'erano squali e vi ho ingannato in modo vile.
Quando ho guardato Bigtable nel cloud quattro anni fa (più o meno), il costo era esattamente questo. Sembra che ora sia leggermente diminuito, ma è ancora un sacco di soldi per un deposito dati vuoto, soprattutto considerando che la mia prima storia mostra quanto sia irrilevante un grande tavolo vuoto su scala.
Mi dispiace aver offeso la comunità Apple e non aver detto niente di buono su Microsoft e così via. Avete tutti ragione, apprezzo molto tutte le discussioni che ha sollevato questo articolo! Ma a volte è necessario suscitare un po' di polemica per avviare il dibattito, capite?
Grazie per la lettura.
Aggiornamento 2, 19.08.2020. Stripe !
Aggiornamento 3, 31.08.2020. Un ingegnere di Google del Cloud Marketplace mi ha contattato, ed era un mio vecchio amico. Voleva capire perché C2D non funzionava, e alla fine abbiamo scoperto: il motivo è che ho creato la mia rete diversi anni fa, e C2D non funziona nelle reti obsolete a causa dell'assenza del parametro subnet nei loro modelli. Penso che i potenziali utenti di GCP dovrebbero assicurarsi di avere ingegneri di Google che siano abbastanza esperti...
Fonte: habr.com
