Cavolo, Google, non volevo scrivere di nuovo un blog. Ho così tanto da fare. Mantenere un blog richiede tempo, energia e creatività che potrei utilizzare meglio: i miei libri, , il mio gioco e così via. Ma mi hai davvero infastidito, quindi devo scriverlo.
Quindi mettiamoci una pietra sopra.
Inizierò con una piccola ma istruttiva storia dal periodo in cui ho appena iniziato a lavorare in Google. So che ultimamente ho parlato molto male di Google, ma mi dispiace vedere la mia azienda prendere regolarmente decisioni commerciali incompetenti. Detto ciò, va dato atto: l'infrastruttura interna di Google è davvero straordinaria, si può dire senza dubbio che oggi non ci sia niente di meglio. I fondatori di Google erano ingegneri di gran lunga migliori di quanto io possa mai diventare, e questa storia lo conferma.
Comincerò con un po' di retroscena: Google ha una tecnologia di archiviazione dati chiamata . È stato un notevole traguardo tecnico, uno dei primi (se non il primo) sistemi di archiviazione «scalabile all'infinito» per coppie «chiave-valore» (key-value store, K/V): essenzialmente, l'inizio del NoSQL. Al giorno d'oggi, Bigtable si comporta ancora bene in uno spazio piuttosto affollato di archivi K/V, ma all'epoca (2005) era incredibilmente innovativo.
Un aspetto interessante di Bigtable è che avevano oggetti interni di piano di controllo (come parte dell'implementazione) chiamati tablet-server, con grandi indici, e a un certo punto diventarono un collo di bottiglia per la scalabilità del sistema. Gli ingegneri di Bigtable si sono interrogati su come realizzare la scalabilità e all'improvviso si sono resi conto che potevano sostituire i tablet-server con altri archivi Bigtable. Quindi Bigtable è parte dell'implementazione di Bigtable. Questi archivi sono presenti a tutti i livelli.
Un altro aspetto interessante è che per un certo periodo Bigtable è diventato popolare e onnipresente all'interno di Google, e ogni team aveva il proprio archivio. Durante una riunione di venerdì, Larry Page chiese casualmente: «Perché abbiamo più di un Bigtable? Perché non ne possiamo usare solo uno?» Teoricamente, un solo archivio dovrebbe essere sufficiente per tutte le esigenze di storage di Google. Certo, non sono mai passati a uno solo per pratiche ragioni di sviluppo (ad esempio, le conseguenze di un potenziale guasto), ma la teoria era interessante. Un solo archivio per l'intero universo.A proposito, qualcuno sa se Amazon ha fatto qualcosa di simile con il suo Sable?)
In un modo o nell'altro, ecco la mia storia.
All'epoca lavoravo in Google da poco più di due anni, e un giorno ricevetti un'email dal team di ingegneria di Bigtable con un contenuto simile a questo:
Caro Steve,
Ciao dal team di Bigtable. Volevamo informarti che nel 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, facci sapere se puoi pianificare un po 'di tempo per collaborare su questo problema.
Tanti saluti,
Il team di Bigtable
In Google ricevi molte email, quindi a prima vista l'ho letto più o meno così:
Gentile destinatario,
Ciao da un qualche team. Vogliamo informarti che bla bla bla bla bla. Bla bla bla bla bla bla, e bla bla bla immediatamente.
Per favore, facci sapere se puoi dedicare parte del tuo prezioso tempo a bla bla bla.
Tanti saluti,
Qualche team
Stavo per eliminarlo subito, ma nel profondo della mia coscienza ho avvertito una sensazione pesante e dolorosa che non era proprio come una lettera formale, anche se è chiaro, che c'era un errore con il destinatario, perché non ho mai usato Bigtable.
Ma era strano.
Il resto della giornata ho alternato 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 della lettera non mi abbandonava con un crescente senso di leggera ansia.
Hanno chiaramente nominato il mio nome. E la lettera è stata inviata al mio indirizzo email, non a qualcun altro, e non è una cc: o bcc:. Il tono è molto personale e chiaro. Potrebbe essere 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 naturalmente, avevo sotto controllo lo storage BigTable. Cosa? Ho guardato il suo contenuto e—non ci posso credere! Era dell'incubatore Codelab, dove ero rimasto durante la mia prima settimana di lavoro in Google nel giugno 2005. Codelab ti costringeva a avviare Bigtable per registrare alcuni valori, e apparentemente non ho mai chiuso quello storage dopo. Era ancora attivo, anche se erano passati più di due anni.
Ci sono alcuni aspetti notevoli in questa storia. Innanzitutto, il lavoro di Bigtable era così insignificante nella scala di Google che ci sono voluti due anni prima che qualcuno notasse lo storage in più, e ciò solo perché la versione del binario era obsoleta. Per confronto, una volta stavo considerando di utilizzare per il mio gioco online. A quel tempo, questo servizio costava circa $16.000 all'anno per vuoto Bigtable su GCP. Non dico che vi stiano ingannando, ma, a mio parere, sono molti soldi per un database totalmente inutile.
Un altro aspetto notevole è che lo storage ha continuato a funzionare per due anni. Che diavolo? I data center vanno e vengono; subiscono interruzioni, passano attraverso manutenzioni programmate, cambiano continuamente. L'hardware viene aggiornato, gli switch vengono sostituiti, tutto viene costantemente migliorato. Come diavolo sono riusciti a mantenere la mia applicazione attiva per due anni nonostante tutti questi cambiamenti? Questo può sembrare un risultato modesto nel 2020, ma tra il 2005 e il 2007 era piuttosto impressionante.
E l'aspetto più straordinario è che un team di ingegneri esterni in un altro stato si rivolge a me, proprietario di un'esigua, praticamente vuota istanza di Bigtable, che ha zero traffico negli ultimi due anni - e offre aiuto per aggiornarla.
Li ho ringraziati, ho eliminato lo storage e la vita ha ripreso il suo corso. Ma tredici anni dopo, penso ancora a quella mail. Perché a volte ricevo email simili da Google Cloud. Sono formulate così:
Gentile utente di Google Cloud,
Ti informiamo che interromperemo il servizio [importante servizio che stai utilizzando] a partire da agosto 2020, dopo di che non potrai più aggiornare le tue istanze. Ti consigliamo di passare all'ultima versione attualmente in fase di beta testing, che non ha alcuna documentazione, nessun percorso di migrazione e che è già obsoleta con il nostro gentile aiuto.
Ci impegniamo a fare in modo che questa modifica abbia un impatto minimo su tutti gli utenti della piattaforma Google Cloud.
Amici per sempre,
Piattaforma Cloud di Google
Ma di solito non leggo queste email, perché in realtà dicono questo:
Gentile destinatario,
Vattene al diavolo. Vattene, vattene, vattene. Abbandona tutto ciò che stai facendo, perché non ha importanza. Ciò che conta è il nostro tempo. Stiamo sprecando tempo e denaro a mantenere la nostra spazzatura, e siamo stanchi di questo, quindi non la manterremo più. Quindi lascia perdere i tuoi maledetti piani e inizia a scavare nella nostra pessima documentazione, implorando briciole sui forum, e, a proposito, la nostra nuova spazzatura è completamente diversa dalla vecchia spazzatura, perché abbiamo rovinato parecchio questo design, eh eh, ma questo è un tuo problema, non nostro.
Continuiamo a fare sforzi affinché tutti i tuoi sviluppi diventino inutilizzabili entro un anno.
Per favore, vattene.
Piattaforma Cloud di Google
E il fatto è che ricevo email di questo tipo circa una volta al mese. Accade così spesso e così costantemente che inevitabilmente mi ha allontanato da GCP verso il campo degli oppositori del cloud. Non voglio più 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é non l'ho neanche lontanamente finito di criticare, diamo un'occhiata al lavoro dell'azienda in altre aree. Gli ingegneri di Google sono orgogliosi della loro disciplina nello sviluppo software, e questo in realtà crea problemi. L'orgoglio è una trappola per gli imprudenti, ha portato molti dipendenti di Google a pensare che le loro soluzioni siano sempre giuste e che la correttezza (secondo qualche definizione vaga e indefinita) sia più importante della cura per i clienti. neanche lontanamente Ci sono alcuni esempi arbitrari presi da altri grandi progetti al di fuori di Google, ma spero che vediate questo schema ovunque. Si riassume nel seguente modo:
la retrocompatibilità sostiene la vitalità e la rilevanza dei sistemi per decenni La retrocompatibilità è un obiettivo di progettazione per tutti i sistemi di successo destinati a.
uso aperto, cioè realizzati con codice sorgente aperto e/o secondo standard aperti. Sento di dire qualcosa di troppo ovvio, che rende tutti addirittura a disagio, ma no. È una questione politica, quindi ci vogliono esempi. использования, то есть реализованных с открытым исходным кодом и/или на открытых стандартах. Я чувствую, что говорю что-то слишком очевидное, что всем даже неудобно, но нет. Это политический вопрос, поэтому нужны примеры.
Il primo sistema che sceglierò è il più vecchio: GNU Emacs, una sorta di ibrido tra Blocco Note di Windows, il kernel del sistema operativo e la Stazione Spaziale Internazionale. È un po' difficile da spiegare, ma in due parole, Emacs è una piattaforma creata nel 1976 (sì, quasi cinquant'anni fa) per la programmazione, progettata per aumentare la tua produttività, ma si presenta come un editor di testo.
Utilizzo Emacs ogni singolo giorno. Sì, uso anche IntelliJ ogni giorno, che è già diventato una potente piattaforma di strumenti. Ma scrivere estensioni per IntelliJ è un compito molto più ambizioso e complesso rispetto alla scrittura di estensioni per Emacs. E cosa ancora più importante, tutto ciò che è stato scritto per Emacs è destinato a rimanere per sempre.
Continua a utilizzare software che ho scritto per Emacs nel 1995. E sono sicuro che qualcuno utilizzi moduli scritti per Emacs nella metà degli anni '80, se non prima. Di tanto in tanto possono richiedere piccole modifiche, ma è davvero piuttosto raro. Non so nulla di ciò che ho mai scritto per Emacs (e ho scritto molto) che richiederebbe di ricostruire l'architettura.
In Emacs c'è una funzione chiamata make-obsolete per le entità obsolete. La terminologia di Emacs per concetti informatici fondamentali (ad esempio, cosa significa «finestra») spesso differisce dalle convenzioni del settore, perché Emacs le ha introdotte molto tempo fa. È un rischio tipico per chi è stato avanti nel suo tempo: tutti i tuoi termini diventano obsoleti. Ma in Emacs esiste davvero un concetto di obsolescenza, che nel loro gergo viene chiamato obsolescenza.
Tuttavia, nel mondo di Emacs sembra esserci un'altra definizione lavorativa. Un'altra filosofia fondamentale, se vuoi.
Nel mondo di Emacs (e in molte altre aree che esploreremo di seguito) lo status di API obsolete significa fondamentalmente: «Non dovresti davvero usare questo approccio, poiché, anche se funziona, presenta vari svantaggi che elencheremo qui. Ma, alla fine, è una tua scelta».
Nel mondo di Google, lo status di un prodotto obsoleto significa: «Stiamo violando i nostri impegni nei tuoi confronti». È davvero così. Questo è ciò che significa in sostanza. Questo implica che ti costringeranno a fare del lavoro regolarmente potenzialmente molto lavoro, come punizione per aver creduto in loro. : abbiamo il miglior software. Il più veloce! Segui le istruzioni, avvia la tua applicazione o servizio e poi, puff, 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 ha il sapore di . Non credo che sia in realtà obsolescenza pianificata nello stesso senso di Apple. Ma Google ha sicuramente in programma di far fallire i tuoi programmi, in modo indiretto. Lo so perché ho lavorato lì come ingegnere per oltre 12 anni. Hanno raccomandazioni interne vaghe su quanto debba essere rispettata 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 far fallire l'intero sistema".
Il problema è molto più serio di quanto pensano, e persisterà per molti anni, poiché la cura dei clienti non fa parte del loro DNA. Maggiori dettagli su questo di seguito.
Attualmente, voglio fare un'affermazione audace: Emacs ha avuto successo in larga misura e perfino per lo più perché prendono sul serio la retrocompatibilità. Questo è effettivamente il tema del nostro articolo. I sistemi open source di successo e longevi devono la loro riuscita alle microcomunità che vivono intorno a estensioni/plugin. Questa è l'ecosistema. Ho già riflettuto sul concetto di piattaforme e su quanto siano importanti, e su come Google, nella sua intera storia aziendale, non abbia mai compreso cosa comporta la creazione di una piattaforma open source di successo, ad eccezione di Android o Chrome.
In effetti, dovrei menzionare brevemente Android, perché sicuramente ci avete pensato.
Prima di tutto, Android non è Google. Non hanno praticamente nulla in comune l'uno con l'altro. Android è un'azienda che è stata acquistata da Google nel luglio 2005, e a questa azienda è stato permesso di operare in gran parte in modo autonomo, rimanendo sostanzialmente intatta nel corso degli anni. Android è un noto stack tecnologico e altrettanto nota organizzazione controversa. Come ha detto un dipendente di Google, «non puoi semplicemente entrare in Android».
In un precedente articolo ho già riflettuto su quanto fossero scadenti alcune delle prime decisioni di design di Android. Accidenti, quando scrivevo quell'articolo, stavano distribuendo una cosa ridicola chiamata «applicazioni istantanee», che ora (sorpresa!) , e mi dispiace se siete stati abbastanza sprovveduti da seguire Google e trasferire i vostri contenuti in queste applicazioni istantanee.
Ma c'è una differenza, una differenza fondamentale, che è che le persone di Android comprendono davvero l'importanza delle piattaforme e si impegnano a mantenere la funzionalità delle vecchie applicazioni Android. In effetti, i loro sforzi per mantenere la compatibilità inversa sono così estremi che anche io, durante il mio breve periodo nel team Android qualche anno fa, ho cercato di convincerli a rinunciare al supporto per alcuni dei dispositivi e API più datati (ero nel torto, come in molte altre cose del passato e del presente. Scusate, ragazzi di Android! Ora che sono stato in Indonesia, capisco perché abbiamo bisogno di loro).
Le persone di Android sostengono la compatibilità inversa fino a estremi quasi inconcepibili, accumulando un'enorme quantità di debito tecnico obsoleto nei loro sistemi e nelle loro catene di strumenti. Oh, avreste dovuto vedere alcune delle cose folli che devono fare nel loro sistema di build, e tutto questo in nome della compatibilità.
Per questo conferisco ad Android il prestigioso premio "Non sei Google". Non vogliono veramente diventare Google, che non sa creare piattaforme sostenibili, ma Android lo fa. sa, come farlo. E quindi Google agisce con molta saggezza in un certo senso: lascia le persone su Android fare tutto a modo loro.
Tuttavia, le app istantanee per Android sono state un'idea piuttosto sciocca. E sapete perché? Perché richiedevano di riscrivere e riprogettare la vostra applicazione! Come se le persone potessero semplicemente riscrivere due milioni di applicazioni. Suppongo che le app istantanee fossero un'idea di qualche dipendente di Google.
Ma qui c'è una differenza. La retrocompatibilità comporta costi elevati. Android sopporta personalmente questi costi, mentre Google insiste affinché sia voi, un cliente a pagamento.
Puoi vedere l'impegno di Android per la retrocompatibilità nelle sue API. Quando hai quattro o cinque sottosistemi diversi per eseguire praticamente la stessa cosa, è un chiaro segno che c'è un impegno per la retrocompatibilità. Questo, nel mondo delle piattaforme, è sinonimo di impegno verso i tuoi clienti e il tuo mercato.
Il principale problema di Google qui è il loro orgoglio per l'igiene ingegneristica. Non amano avere molti modi diversi di fare la stessa cosa, specialmente quando modalità più vecchie e meno desiderabili coesistono con quelle nuove e più eleganti. Questo aumenta la curva di apprendimento per nuovi utenti del sistema, aumenta il peso del supporto per API obsolete, rallenta l'introduzione di nuove funzionalità, e il principale peccato è che è brutto. Google è come la Lady Ascot di "Alice nel Paese delle Meraviglie" di Tim Burton:
Lady Ascot:
— Alice, sai cos'è che temo di più?
— La caduta 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 comune tra i programmatori Java, persino più che in molti altri linguaggi di programmazione. Nella stessa Java, il linguaggio principale e le librerie, l'obsolescenza delle API avviene continuamente.
Prendiamo solo uno dei migliaia di esempi, è considerata obsoleta. È diventata obsoleta dal rilascio di Java 1.2 nel dicembre 1998. Sono passati 22 anni da allora.
Ma il mio codice reale in produzione continua a terminare thread ogni giorno. È una cosa buona? Assolutamente! Voglio dire, certo, se riscrivessi il codice oggi, lo implementerei in un modo diverso. Ma il codice del mio gioco, che ha reso felici centinaia di migliaia di persone negli ultimi due decenni, è scritto utilizzando la funzione di chiusura dei thread che rimangono in sospeso troppo a lungo, e 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 thread specifici è del tutto innocua.. Non c'è bisogno di spendere tempo e sforzi riscrivendo questo codice, e un ringraziamento va a Larry Ellison (forse) per non avermi costretto a riscriverlo.
Forse Oracle capisce anche le piattaforme. Chi lo sa.
Le prove possono essere incontrate in tutte le principali API Java, che sono permeate da onde di obsolescenza, simili alle linee di un ghiacciaio nel canyon. Nella libreria Java Swing è facile trovare cinque o sei diversi gestori di navigazione da tastiera (KeyboardFocusManager). In realtà è difficile trovare un'API Java che non sia obsoleta. Ma funzionano ancora! Penso che il team Java eliminerà realmente le API solo se l'interfaccia solleverà un problema di sicurezza lampante.
Ecco il punto, ragazzi: noi, sviluppatori di software, siamo tutti molto occupati e in ogni area del software ci confrontiamo con alternative concorrenti. In qualsiasi momento, i programmatori del linguaggio X considerano il linguaggio Y come una possibile sostituzione. Oh, non mi credete? Volete parlare di Swift? Dite che tutti stanno migrando a Swift e che nessuno lo abbandona, giusto? Wow, quanto poco sapete. Le aziende considerano i costi per i team di sviluppo mobile doppi (iOS e Android) — e iniziano a capire che questi sistemi di sviluppo cross-platform con nomi bizzarri, come Flutter e React Native, funzionano davvero, e grazie a loro possono dimezzare le dimensioni dei loro team mobili o, al contrario, renderli due volte più produttivi. Ci sono in ballo soldi reali. Sì, ci sono compromessi, ma dall'altra parte, soldo.
Supponiamo ipoteticamente che Apple, per qualche motivo, seguisse l'esempio di Guido van Rossum e dichiarasse che Swift 6.0 non è retrocompatibile con Swift 5.0, molto come Python 3 non è compatibile con Python 2.
Forse ho raccontato questa storia dieci anni fa, ma quindici anni fa sono stato al campo O’Reilly’s Foo Camp con Guido, seduto in una tenda con Paul Graham e un sacco di grandi nomi. Stavamo soffrendo nel calore torrido aspettando l'arrivo di Larry Page con il suo elicottero privato, mentre Guido parlava monotono del "Python 3000", che aveva chiamato in base agli anni che ci sarebbero voluti per migrare. Continuavamo a chiedergli perché stesse rompendo la compatibilità, e lui rispondeva: “Unicode”. E noi chiedevamo, se avessimo dovuto 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:
Gentile destinatario,
Vorremmo ricordarti che il supporto per Python 2 è scaduto, quindi vaffanculo
… e così via. Il ciclo della vita.
Ma il fatto è che ogni sviluppatore ha una scelta. E se li costringi a riscrivere il codice abbastanza spesso, potrebbero anche pensare a altri varianti. Non sono vostri prigionieri, anche se vorreste. Sono vostri ospiti. Python rimane un linguaggio di programmazione molto popolare, ma, accidenti, Python 3(000) ha creato un tale caos nelle sue comunità e tra gli utenti delle sue comunità che le conseguenze non possono essere risolte da ben 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 in qualcos'altro oltre Python, anche se poteva essere scritto in Python, se Guido non avesse bruciato tutto? È difficile da dire, ma Python ha chiaramente sofferto. È un enorme caos e tutti ne stanno perdendo.
Quindi, poniamo che Apple prenda esempio da Guido e rompa la compatibilità. Cosa pensate che accadrà? Beh, forse l'80-90% degli sviluppatori riscriveranno il loro software, se ne avranno la possibilità. In altre parole, il 10-20% della base utenti se ne andrà automaticamente verso un linguaggio concorrente, come Flutter.
Fai questo un paio di volte e perderai metà della tua base utenti. Proprio come nello sport, anche nel mondo della programmazione l'attuale forma conta. tutto. Chiunque perda la metà degli utenti in cinque anni sarà considerato un Grande Grosso Fallimento. Devi essere al passo con i tempi nel mondo delle piattaforme. Ma proprio qui, l'abbandono del supporto per le versioni obsolete ti porterà alla rovina. Perché ogni volta che ti liberi di parte degli sviluppatori, (a) li perdi per sempre, perché si arrabbiano con te per la violazione del contratto, e (b) li dai in pasto ai tuoi concorrenti.
E ironicamente, anche io ho aiutato Google a diventare così capriccioso da ignorare la retrocompatibilità quando ho creato Grok, un sistema di analisi e comprensione del codice sorgente che rende più facile l'automazione e l'equipaggiamento di strumenti basati sul codice – simile a un IDE, ma qui il servizio cloud conserva le viste materializzate di tutti i miliardi di righe di codice sorgente di Google in un grande data warehouse.
Grok ha fornito ai googler una potente base per l'automazione del refactoring in tutta la base di codice (letteralmente in tutto Google). Il sistema calcola non solo le tue dipendenze ascendenti (da cui dipendi), ma anche discendenti (che dipendono da voi), quindi quando cambiate API sapete chi state rompendo! 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 sviluppato, potete automatizzare completamente il processo.
Questo consente al codice di Google di essere internamente quasi sovrannaturale «pulito», poiché hanno questi servitori robotici che girano per casa e puliscono automaticamente tutto, se rinominano SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName, perché qualcuno ha deciso che era un brutto nipote e doveva essere addormentato.
E, a dire il vero, funziona abbastanza bene per Google… internamente. Voglio dire, sì, la comunità Go in Google sorride bonariamente alla comunità Java in Google a causa della loro abitudine di rifattorizzare continuamente. Se rilanci qualcosa N volte, significa che non solo lo avete rovinato N-1 volte, ma dopo un po' diventa chiaro che probabilmente lo avete rovinato anche al N-esimo tentativo. Ma, in generale, rimangono al di sopra di questo trambusto e mantengono il codice «pulito».
I problemi iniziano quando cercano di imporre un atteggiamento simile ai loro clienti cloud e agli utenti di altre API.
Vi ho dato una breve introduzione su Emacs, Android e Java; ora diamo un'occhiata all'ultima piattaforma di successo a lungo termine: il Web stesso. Potete immaginare quante iterazioni ha attraversato l'HTTP dal 1995, quando usavamo i tag e le icone "In sviluppo" sulle pagine web.
Ma funziona ancora! E queste pagine funzionano ancora! Sì, ragazzi, i browser sono i campioni mondiali della retrocompatibilità. Chrome è un altro esempio di una piattaforma rara di Google, dove tutto è assemblato correttamente e, come avrete già indovinato, Chrome agisce efficacemente come un'azienda isolata dal resto di Google.
Vorrei anche ringraziare i nostri amici tra gli sviluppatori di sistemi operativi: Windows, Linux, NON APPLE SEI APPLE, FreeBSD e così via, per il grande lavoro che hanno svolto sulla retrocompatibilità delle loro piattaforme di successo (Apple ottiene al massimo un tre meno perché continua a rompere tutto senza alcun motivo valido, ma in qualche modo la comunità riesce a gestire tutto in ogni rilascio, e fino ad ora i container con OS X non sono ancora completamente obsoleti… per ora).
Ma aspetta, dirai tu. Non stiamo confrontando mele con arance — sistemi software autonomi su una macchina, come Emacs/JDK/Android/Chrome, con sistemi multi-server e API, come nei servizi cloud?
Beh, ne ho scritto ieri su Twitter, ma nello stile di Larry Wall (il creatore del linguaggio di programmazione Perl — nota dell'autore) secondo il principio "fallimento/ successo", ho cercato la parola deprecated sui siti per sviluppatori di Google e Amazon. E anche se AWS ha centinaia molte più offerte di servizi rispetto a GCP, la documentazione per sviluppatori di Google menziona la deprecazione circa sette volte più spesso.
Se qualcuno di Google sta leggendo, sicuramente è pronto a tirare fuori i diagrammi nello stile di Donald Trump, mostrando che in realtà stanno facendo tutto giusto e che non dovrei fare confronti ingiusti come "il numero di menzioni della parola obsoleta rispetto al numero di servizi".
Ma dopo tanti anni, Google Cloud rimane ancora al terzo posto (non ho mai scritto un articolo sul tentativo fallito di arrivare al secondo posto), ma se si crede ai bene informati, ci sono alcune preoccupazioni che potrebbero presto scendere al quarto posto.
Non ho argomenti solidi per "dimostrare" la mia tesi. Tutto ciò che ho sono esempi vividi che ho accumulato in 30 anni di lavoro come sviluppatore. Ho già menzionato la natura profondamente filosofica di questo problema; in un certo senso è politicizzato nelle comunità di sviluppatori. Alcuni credono che i creatori delle piattaforme dovrebbero preoccuparsi della compatibilità, mentre altri pensano che sia una responsabilità utenti (degli stessi sviluppatori). Una delle due cose. E in effetti, non è una questione politica quando decidiamo chi deve sostenere i costi per problemi comuni?
Quindi questa è la politica. E sicuramente ci saranno risposte indignate al mio intervento.
Come utente Dalla mia esperienza con la piattaforma cloud di Google e come utente AWS per due anni (lavorando presso Grab), posso dire che c'è una grande differenza tra le filosofie di Amazon e Google quando si tratta di priorità. Non sviluppo attivamente su AWS, quindi non so bene quanto spesso rimuovano le API obsolete. Ma ho il sospetto che ciò non accada così frequentemente come in Google. E credo sinceramente che questa fonte di continui dibattiti e delusioni in GCP sia uno dei maggiori fattori che ostacolano lo sviluppo della piattaforma.
So di non aver citato esempi specifici di sistemi GCP di cui è stata interrotta la supporto. Posso dire che praticamente tutto ciò che ho usato, dalle reti (dalle più vecchie a VPC) ai fornitori di storage (Cloud SQL v1-v2), Firebase (ora Firestore con un API completamente diversa), App Engine (meglio non cominciare nemmeno), ai punti finali cloud Cloud Endpoint e fino a… non so — assolutamente tutto questo richiedeva di riscrivere il codice ogni 2-3 anni al massimo, e non hanno mai automatizzato la migrazione per voi, anzi spesso . Sembra quasi che sia così che deve andare.
E ogni volta che guardo ad AWS, mi chiedo come mai sono ancora su GCP. Non hanno certamente bisogno di clienti. Hanno bisogno di acquirenti. Capisci la differenza? Lascia che te lo spieghi.
Google Cloud ha un , dove le persone offrono le loro soluzioni software e, per evitare l'effetto di un ristorante vuoto, dovevano riempirlo con alcune offerte, quindi hanno stipulato un contratto con Bitnami per creare una serie di soluzioni che vengono distribuite "con un solo clic", o devo scrivere io stesso "soluzioni", perché queste non risolvono affatto niente. Esistono solo come dei segnaposto, come riempitivi di marketing, e a Google non è mai importato se alcuni strumenti funzionano realmente. Conosco i product manager che erano al timone, e posso garantirti che a queste persone non interessa.
Prendiamo ad esempio una soluzione che si dice venga distribuita "con un solo clic". . Sono davvero stufo delle disavventure di Google Cloud SQL, così ho iniziato a considerare come alternativa la creazione di un proprio cluster Percona. E questa volta Google sembrava aver fatto un buon lavoro, promettendo di risparmiare un po' di tempo e fatica con un solo click!
Bene, partiamo. Clicchiamo sul link e premiamo questo pulsante. Selezioniamo 'Sì' per accettare tutte le opzioni predefinite e avviare il cluster nel nostro progetto Google Cloud. Ah ah, non funziona. Niente di questa roba funziona. Lo strumento non è mai stato testato ed è 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 funzionano. È una totale oscurità, decisamente da evitare.
Ma Google sta proprio invitando a usarli. Vogliono che tu li compri.Per loro è una transazione. Non vogliono nient'altro supportare. Non fa parte del DNA di Google. Sì, gli ingegneri si supportano a vicenda, come dimostra la mia esperienza con Bigtable. Ma nei prodotti e servizi destinati alle persone comuni sono stati sempre implacabili nel , che non è redditizio, anche se ha milioni di utenti.
E questo rappresenta un vero problema per GCP, perché questo DNA è alla base di tutte le offerte cloud. Non si sforzano di supportare nulla; è ben noto che rifiutano di ospitare (come servizio gestito) software di terze parti. fino a quando, fino a quando AWS non farà lo stesso e non costruirà un business di successo attorno ad esso, e quando i clienti lo richiederanno esplicitamente. Tuttavia, è necessario fare degli sforzi affinché Google supporti qualcosa.
Questa mancanza di cultura del supporto, combinata con il principio "rompiamo per rendere più bello", allontana gli sviluppatori da loro.
E non è affatto positivo se vuoi costruire una piattaforma a lungo termine.
Google, svegliati, accidenti. Siamo nel 2020. Stai ancora perdendo. È tempo di guardarsi in faccia e chiedersi se davvero vuoi rimanere nel business del cloud.
Se vuoi rimanere, allora smettila di distruggere tutto.. Ragazzi, voi siete ricchi. Noi, sviluppatori, no. Quindi, quando si tratta di chi si assumerà il peso della compatibilità, dovete farlo voi. Non a noi.
Perché ci sono almeno altri tre ottimi cloud. Ci attirano.
E ora andrò avanti a riparare tutti i miei sistemi rotti. Ahimè.
Alla prossima volta!
P. S. Aggiornamento dopo aver letto alcune discussioni su questo articolo (le discussioni sono ottime, tra l'altro). Il supporto per Firebase non è stato interrotto, e non ci sono piani, di cui io sappia. Tuttavia, hanno un fastidioso bug di streaming che fa fermare il client Java nell'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 workaround, devo riavviare l'app GAE ogni giorno. E così è da quattro anni! Ora hanno Firestore. Ci vorrà molto lavoro per migrare, poiché è un sistema completamente diverso, e il bug di Firebase non sarà mai risolto. Che conclusione si può trarre? Potete ottenere aiuto, se lavori in un'azienda. Probabilmente sono l'unico che usa Firebase su GAE, perché registro meno di 100 chiavi in un'applicazione nativa al 100%, e smette di funzionare ogni paio di giorni a causa di un noto bug. Cosa posso 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 nessun servizio, e SimpleDB è un ottimo esempio. Le mie supposizioni che in AWS non ci siano problematiche legate alla cessazione del supporto come in Google sembrano essere giustificate.
Inoltre, ho notato che 20 giorni fa il team di Google App Engine ha interrotto il hosting di una libreria critica di Go, chiudendo l'applicazione GAE da uno sviluppatore principale di Go. È davvero una situazione ridicola.
Finalmente, ho sentito che i Googler stanno già discutendo di questo problema e in generale concordano con me (vi adoro, ragazzi!). Ma sembra che lo considerino un problema irrisolvibile, perché nella cultura di Google non è mai esistita una corretta struttura di incentivazione. Penso che sarebbe bello ritagliarsi un po' di tempo per discutere dell'incredibile esperienza avuta lavorando con gli ingegneri di AWS quando ero in Grab. Magari in futuro, spero!
E sì, nel 2005 avevano davvero diversi tipi di carne di squalo su un gigantesco buffet nel palazzo 43, e io adoravo di più la carne degli squali martello. Tuttavia, nel 2006 Larry e Sergey eliminarono tutti gli snack poco salutari. Quindi, durante la storia di Bigtable nel 2007, non c'erano davvero squali e vi ho ingannato miseramente.
Quando ho esaminato Bigtable quattro anni fa (più o meno), il costo era esattamente quello. Sembra che ora sia leggermente diminuito, ma è ancora davvero tantissimo per uno spazio di archiviazione dati vuoto, specialmente considerando che la mia prima storia mostra quanto sia insignificante una grande tabella vuota su quella scala.
Mi dispiace di aver offeso la comunità Apple e di non aver detto nulla di buono su Microsoft e così via. Avete tutti ragione, apprezzo molto tutte le discussioni che ha generato questo articolo! Ma a volte è necessario sollevare un po' di polvere per avviare una discussione, capite cosa intendo?
Grazie per aver letto.
Aggiornamento 2, 19.08.2020. Stripe !
Aggiornamento 3, 31.08.2020. Sono stato contattato da un ingegnere di Google nel Cloud Marketplace, che si è rivelato essere un mio vecchio amico. Voleva scoprire perché C2D non funzionava e alla fine abbiamo capito: il motivo è che ho creato la mia rete anni fa, e C2D non funziona nelle reti obsolete a causa della mancanza del parametro subnet nei loro modelli. Penso che sarebbe meglio per i potenziali utenti di GCP assicurarsi di avere ingegneri sufficientemente esperti in Google...
Fonte: habr.com
