Dannazione, Google, non volevo più scrivere sul blog. Ho così tanto da fare. Scrivere sul blog richiede tempo, energia e creatività che potrei impiegare al meglio: i miei libri, , il mio gioco e così via. Ma mi hai fatto arrabbiare abbastanza da doverlo scrivere.
Quindi facciamola finita.
Vorrei iniziare con una breve ma istruttiva storia di quando ho iniziato a lavorare in Google. So di aver parlato molto male di Google ultimamente, ma è frustrante quando la mia azienda prende regolarmente decisioni aziendali incompetenti. Detto questo, l'infrastruttura interna di Google è davvero straordinaria e probabilmente non c'è niente di meglio oggi. I fondatori di Google erano ingegneri di gran lunga migliori di quanto io non sarò mai, e questa storia non fa che dimostrarlo.
Innanzitutto, un po' di contesto: Google ha una tecnologia di archiviazione dati chiamata Fu un risultato tecnico notevole, uno dei primi (se non il primo) archivi chiave-valore (K/V) "infinitamente scalabili": in pratica, l'inizio di NoSQL. Oggi, Bigtable prospera ancora nell'affollato spazio degli archivi K/V, ma all'epoca (2005) era incredibilmente interessante.
Un aspetto curioso di Bigtable è che aveva oggetti del piano di controllo interno (come parte dell'implementazione) chiamati tablet server, con indici di grandi dimensioni, e a un certo punto sono diventati un collo di bottiglia nella scalabilità del sistema. Gli ingegneri di Bigtable stavano cercando di capire come implementare la scalabilità e si sono resi conto che potevano sostituire i tablet server con altri store Bigtable. Quindi Bigtable fa parte dell'implementazione di Bigtable. Questi store sono presenti a tutti i livelli.
Un altro dettaglio interessante è che i Bigtable sono diventati popolari e onnipresenti all'interno di Google per un certo periodo, con ogni team che disponeva del proprio spazio di archiviazione. Così, durante una delle riunioni del venerdì, Larry Page chiese casualmente: "Perché abbiamo più di un Bigtable? Perché non solo uno?". In teoria, un solo spazio di archiviazione dovrebbe essere sufficiente per tutte le esigenze di archiviazione di Google. Naturalmente, non sono mai passati a uno solo per motivi pratici di sviluppo (come le conseguenze di un potenziale guasto), ma la teoria era interessante. Un solo spazio di archiviazione per l'intero universo (A proposito, qualcuno sa se Amazon ha fatto la stessa cosa con il suo Sable?)
Comunque, ecco la mia storia.
All'epoca lavoravo in Google da poco più di due anni e un giorno ho ricevuto un'email dal team di ingegneri di Bigtable che diceva più o meno così:
Caro Steve,
Un saluto dal team di Bigtable. Desideriamo informarti che stai utilizzando un binario Bigtable molto, molto vecchio presso [nome del data center]. Questa versione non è più supportata e vogliamo aiutarti a migrare alla versione più recente.
Per favore, fatemi sapere se potete fissare un appuntamento per lavorare insieme su questo argomento.
Ti auguro il meglio,
Team Bigtable
Google ti invia un sacco di posta, quindi a prima vista leggo qualcosa del genere:
Gentile destinatario,
Saluti da parte di alcuni membri del team. Vogliamo informarvi che bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla, e bla-bla-bla immediatamente.
Fateci sapere se potete riservare un po' del vostro prezioso tempo per blah blah blah.
Ti auguro il meglio,
Qualche squadra
L'ho quasi cancellato subito, ma al limite della coscienza ho sentito una sensazione dolorosa e dolorosa che era non proprio sembra una lettera formale però ovviamente, che l'indirizzo era sbagliato perché non ho utilizzato Bigtable.
Ma era strano.
Per il resto della giornata ho pensato alternativamente al lavoro e a che tipo di carne di squalo provare nelle micro-cucine, di cui almeno tre erano abbastanza vicine da poter essere colpite da un lancio di biscotti ben mirato dalla mia sedia, ma il pensiero di scrivere continuava a tornarmi in mente con un crescente senso di lieve disagio.
Hanno detto chiaramente il mio nome. E l'email è stata inviata al mio indirizzo email, non a quello di qualcun altro, e non è in copia per conoscenza né in copia nascosta. Il tono è molto personale e chiaro. Forse c'è qualche errore?
Alla fine, la curiosità ha avuto la meglio e sono andato a dare un'occhiata alla console Borg nel data center che avevano menzionato.
E infatti, avevo un repository BigTable in gestione. Cosa? Ne ho guardato il contenuto, ed ecco fatto! Proveniva dall'incubatore Codelab in cui lavoravo durante la mia prima settimana in Google, nel giugno 2005. Codelab ti faceva avviare un BigTable per scriverci dei valori, e a quanto pare non ho mai chiuso il repository da allora. Era ancora in esecuzione, più di due anni dopo.
Ci sono alcuni aspetti degni di nota in questa storia. Innanzitutto, Bigtable era così insignificante alle dimensioni di Google che ci sono voluti due anni prima che qualcuno si accorgesse dello spazio di archiviazione aggiuntivo, e solo perché la versione binaria era obsoleta. A titolo di paragone, una volta ho pensato di usare per il mio gioco online. All'epoca, il servizio costava circa 16 dollari all'anno per svuotare Bigtable su GCP. Non sto dicendo che ti stanno truffando, ma secondo me sono un sacco di soldi per un database vuoto.
Un altro aspetto degno di nota è che lo stoccaggio ancora funzionante dopo due anniMa che diavolo? I data center vanno e vengono; subiscono interruzioni, sono sottoposti a manutenzione programmata, cambiano continuamente. L'hardware viene aggiornato, gli switch vengono sostituiti, tutto viene migliorato continuamente. Come diavolo hanno fatto a mantenere il mio software funzionante per due anni con tutti questi cambiamenti? Potrebbe sembrare un risultato modesto nel 2020, ma nel 2005-2007 era piuttosto impressionante.
E l'aspetto più meraviglioso è che un team di ingegneri esterni in qualche altro stato si sta rivolgendo a me, il proprietario di una piccola istanza Bigtable praticamente vuota, che ha traffico zero negli ultimi due anni e stanno offrendo il loro aiuto per aggiornarlo.
Li ho ringraziati, ho eliminato il vault e la vita è tornata come al solito. Ma tredici anni dopo, penso ancora a quell'email. Perché a volte ricevo email come questa da Google Cloud. Hanno questo aspetto:
Gentile utente di Google Cloud,
Ti ricordiamo che la manutenzione per [un servizio importante che utilizzi] terminerà ad agosto 2020, dopodiché non potrai più aggiornare le tue istanze. Ti consigliamo di eseguire l'aggiornamento alla versione più recente, che è in fase di beta testing, non ha documentazione, non ha un percorso di migrazione ed è stata pre-deprecata con il nostro gentile aiuto.
Ci impegniamo a garantire che questa modifica abbia un impatto minimo su tutti gli utenti della piattaforma Google Cloud.
Migliori amici per sempre,
Piattaforma Google Cloud
Ma difficilmente leggo quelle lettere perché ciò che dicono in realtà è:
Gentile destinatario,
Vaffanculo. Vaffanculo, vaffanculo, vaffanculo. Butta via tutto quello che stai facendo perché non importa. Ciò che conta è il nostro tempo. Spendiamo tempo e soldi per sostenere la nostra roba, e ne siamo stanchi, quindi non la sosterremo più. Quindi abbandona i tuoi fottuti piani e inizia a rovistare nella nostra documentazione di merda, implorando frammenti sui forum, e a proposito, la nostra nuova roba è completamente diversa dalla vecchia perché abbiamo rovinato parecchio questo design, eh, ma questo è un problema tuo, non nostro.
Continuiamo a lavorare sodo per rendere tutti i vostri sviluppi inutilizzabili entro un anno.
Per favore, vai a farti fottere,
Piattaforma Google Cloud
Il fatto è che ricevo queste lettere circa una volta al mese. Succede così spesso e costantemente che sono inevitabili. spinto via Mi sto allontanando da GCP per passare al campo anti-cloud. Non accetto più di dipendere dai loro sviluppi proprietari, perché in effetti è più facile per un DevOps supportare un sistema open source su una VM nuda che cercare di stare al passo con Google e la sua politica di chiusura dei prodotti "obsoleti".
Prima di tornare a Google Cloud, perché io anche vicino Non abbiamo finito di criticarli, diamo un'occhiata al lavoro dell'azienda in altri ambiti. Gli ingegneri di Google sono orgogliosi della loro disciplina nell'ingegneria del software, ed è proprio questo a causare i veri problemi. L'orgoglio è una trappola per gli incauti e ha portato molti dipendenti di Google a pensare che le loro decisioni siano sempre giuste e che avere ragione (secondo una definizione vaga e confusa) sia più importante che preoccuparsi dei clienti.
Vi darò qualche esempio casuale tratto da altri grandi progetti al di fuori di Google, ma spero che vedrete questo schema ovunque. Funziona così: La retrocompatibilità mantiene i sistemi attivi e rilevanti per decenni.
La compatibilità con le versioni precedenti è un obiettivo di progettazione per tutti i sistemi di successo destinati a aperto utilizzo, ovvero implementato con open source e/o standard aperti. Mi sembra di dire qualcosa di così ovvio da risultare scomodo per tutti, ma no. Questa è una questione politica, quindi servono esempi.
Il primo sistema che sceglierò è 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 poche parole, Emacs è una piattaforma creata nel 1976 (sì, quasi mezzo secolo fa) per programmare e aumentare la produttività, mascherata però da editor di testo.
Uso Emacs ogni giorno. Sì, uso anche IntelliJ ogni giorno, che è diventato una potente piattaforma di strumenti a sé stante. Ma scrivere estensioni per IntelliJ è un compito molto più ambizioso e impegnativo che scrivere estensioni per Emacs. E, cosa ancora più importante, tutto ciò che si scrive per Emacs viene preservato. eternamente.
Utilizzo ancora software che ho scritto per Emacs nel 1995. E sono sicuro che ci siano altri che usano moduli scritti per Emacs a metà degli anni '80, se non prima. Potrebbero richiedere piccole modifiche di tanto in tanto, ma è davvero piuttosto raro. Non conosco nulla di ciò che ho scritto per Emacs (e ne ho scritti molti) che abbia richiesto una riprogettazione.
Emacs ha una funzione chiamata make-obsolete per le entità obsolete. La terminologia di Emacs per i concetti informatici fondamentali (come il significato di una "finestra") spesso differisce dalle convenzioni del settore perché Emacs li ha inventati molto tempo fa. Questo è il tipico rischio di essere in anticipo sui tempi: tutti i termini sono errati. Ma Emacs ha un concetto di obsolescenza, che nel loro gergo è chiamato obsolescenza.
Ma nel mondo di Emacs, sembra esserci una definizione operativa diversa. Una filosofia di fondo diversa, se vogliamo.
Nel mondo di Emacs (e in molti altri ambiti che tratteremo più avanti), lo stato di deprecazione delle API significa sostanzialmente "Non dovresti davvero usare questo approccio, perché, sebbene funzioni, presenta diverse carenze che elencheremo qui. Ma alla fine, la scelta è tua".
Nel mondo di Google, essere un prodotto deprecato significa "Non stiamo mantenendo la promessa fatta a te". È vero. È questo che significa in sostanza. Significa che ti faranno... regolarmente per fare un po' di lavoro, forse molto lavoro, come punizione per aver creduto in loro : Abbiamo il software migliore. Il più veloce! Segui le istruzioni, avvii la tua app o il tuo servizio e, bam, un anno o due dopo si rompe.
È come vendere un'auto usata che sicuramente si romperà dopo 1500 km.
Si tratta di due definizioni filosofiche molto diverse di "obsolescenza". La definizione di Google fa schifo. Non ci credo. infatti Obsolescenza programmata nello stesso senso di Apple. Ma Google ha sicuramente intenzione di distruggere il tuo software, in modo indiretto. Lo so perché ho lavorato lì come ingegnere del software per oltre 12 anni. Hanno vaghe linee guida interne su quanta retrocompatibilità mantenere, ma in definitiva spetta a ogni singolo team o funzione. Non ci sono linee guida a livello aziendale o ingegneristico, e la raccomandazione più audace in termini di cicli di deprecazione è "prova a dare ai clienti 6-12 mesi per aggiornare prima di distruggere l'intero sistema".
Il problema è molto più grande di quanto pensino e persisterà per anni a venire perché l'assistenza clienti non è nel loro DNA. Ne parleremo più avanti.
A questo punto affermerò con audacia che Emacs ha avuto un grande successo e persino fondamentalmente Perché prendono molto sul serio la retrocompatibilità. In effetti, questa è la tesi del nostro articolo. I sistemi aperti di successo e longevi devono il loro successo alle micro-comunità che vivono attorno a loro da decenni. estensioni/pluginEcco cos'è un ecosistema. Ho già parlato della natura delle piattaforme e della loro importanza, e di come Google non abbia mai capito, in tutta la sua storia aziendale, cosa significhi creare una piattaforma aperta di successo, a parte Android o Chrome.
In realtà dovrei menzionare brevemente Android perché è probabilmente quello che stai pensando.
In primo luogo, Android non è GoogleNon hanno quasi nulla in comune. Android è un'azienda che è stata acquisita da Google nel luglio 2005, ha potuto operare in modo più o meno autonomo ed è rimasta sostanzialmente invariata negli anni successivi. Android è un noto stack tecnologico e un'organizzazione altrettanto nota per essere spinosa. Come ha detto un dipendente di Google, "Non puoi semplicemente entrare in Android".
In un articolo precedente, ho parlato di quanto fossero sbagliate alcune delle prime decisioni di design di Android. Cavolo, quando ho scritto quell'articolo, stavano lanciando questa schifezza chiamata "app istantanee", che ora (sorpresa!) e capisco se sei stato così stupido da ascoltare Google e spostare i tuoi contenuti su queste app istantanee.
Ma qui c'è una differenza, una differenza significativa, ovvero che i ragazzi di Android capiscono davvero quanto siano importanti le piattaforme e fanno di tutto per far funzionare le vecchie app Android. In effetti, i loro sforzi per mantenere la retrocompatibilità sono così estremi che persino io, durante il mio breve incarico nella divisione Android qualche anno fa, mi sono ritrovato a cercare di convincerli a interrompere il supporto per alcuni dei dispositivi e delle API più vecchi (mi sbagliavo, come mi è capitato con tante cose passate e presenti. Mi dispiace, ragazzi di Android! Ora che sono stato in Indonesia, capisco perché ne abbiamo bisogno).
Gli sviluppatori di Android portano la retrocompatibilità a livelli quasi inimmaginabili, accumulando un'enorme quantità di debito tecnico legacy nei loro sistemi e nelle loro toolchain. Oddio, dovresti vedere le cose assurde che devono fare nel loro sistema di build, tutto in nome della compatibilità.
Per questo, do ad Android l'ambito premio "Non sei Google". Non vogliono certo essere come Google, che non è in grado di costruire piattaforme durevoli, ma Android... egli sa, come farlo. E quindi Google si sta comportando in modo molto intelligente in un certo senso: permette alle persone di fare le cose a modo loro su Android.
Ma le app Android Instant erano un'idea piuttosto stupida. E sapete perché? Perché richiedevano riscrivi e riprogetta la tua applicazione! Come se la gente volesse semplicemente riscrivere due milioni di app. Immagino che le Instant Apps siano state un'idea di qualche dipendente di Google.
Ma c'è una differenza. La retrocompatibilità ha un costo. Android ne sostiene l'onere, mentre Google insiste affinché sia sostenuto da si, un cliente pagante.
L'impegno di Android per la retrocompatibilità è evidente nelle sue API. Quando quattro o cinque sottosistemi diversi svolgono letteralmente la stessa funzione, è un chiaro segno che l'impegno per la retrocompatibilità è fondamentale. Che nel mondo delle piattaforme è sinonimo di impegno verso i clienti e il mercato.
Il problema principale di Google in questo caso è il suo orgoglio per la propria igiene ingegneristica. Non gli piace quando ci sono molti modi diversi per fare la stessa cosa, con metodi più vecchi e meno desiderabili che si affiancano a metodi più nuovi e più sofisticati. Questo aumenta la curva di apprendimento per i nuovi arrivati nel sistema, aumenta l'onere del supporto alle API legacy, rallenta la velocità delle nuove funzionalità e, il peccato principale, è la bruttezza. Google è come Lady Ascot in Alice nel Paese delle Meraviglie di Tim Burton:
Lady Ascot:
- Alice, sai di cosa ho più paura?
— Il declino dell'aristocrazia?
- Avevo paura che avrei nipoti brutti.
Per comprendere il compromesso tra bellezza e praticità, diamo un'occhiata alla terza piattaforma di successo (dopo Emacs e Android) e vediamo come funziona: Java stesso.
Java ha molte API deprecate. La deprecazione è molto diffusa tra i programmatori Java, persino più diffusa che nella maggior parte dei linguaggi di programmazione. Java stesso, il linguaggio principale e le sue librerie, deprecano continuamente le API.
Per fare solo un esempio tra migliaia, è considerato obsoleto. È obsoleto dal rilascio di Java 1.2 nel dicembre 1998. Sono passati 22 anni da quando è stato deprecato.
Ma il mio vero codice in produzione continua a uccidere i thread ogni giornoÈ una buona cosa? Assolutamente! Voglio dire, certo, se dovessi riscrivere il codice oggi, lo implementerei diversamente. Ma il mio gioco, che ha reso felici centinaia di migliaia di persone negli ultimi due decenni, è codificato con una funzione per chiudere i thread che rimangono in sospeso per troppo tempo, e io... non ho mai dovuto cambiarloConosco il mio sistema meglio di chiunque altro, ho letteralmente 25 anni di esperienza di lavoro con esso in produzione e posso dirti con certezza: nel mio caso, chiudere questi flussi di lavoro specifici è assolutamente senza valoreNon vale la pena perdere tempo e fatica per riscrivere questo codice, e un plauso a Larry Ellison (credo) per il fatto che Oracle non mi abbia fatto riscriverlo.
Probabilmente anche Oracle è a conoscenza delle piattaforme. Chissà.
Ne sono prova le API principali di Java, che sono disseminate di ondate di deprecazioni come le linee dei ghiacciai in un canyon. Nella libreria Java Swing si possono trovare facilmente cinque o sei diversi gestori di focus da tastiera. In effetti, è difficile trovare un'API Java che non sia deprecata. Ma funzionano ancora! Credo che il team Java rimuoverebbe davvero un'API solo se l'interfaccia causasse un evidente problema di sicurezza.
Ecco il punto, gente: noi sviluppatori software siamo tutti super impegnati e, in ogni ambito del software, ci troviamo di fronte a alternative concorrenti. In qualsiasi momento, i programmatori del linguaggio X stanno prendendo in considerazione il linguaggio Y come possibile sostituto. Oh, non mi credete? Volete dire Swift? Tipo, tutti stanno migrando a Swift e nessuno lo abbandona, vero? Wow, ne sapete così poco. Le aziende stanno calcolando i costi dei doppi team mobile (iOS e Android) e stanno iniziando a rendersi conto che questi sistemi di sviluppo multipiattaforma con nomi buffi come Flutter e React Native funzionano davvero e che possono dimezzare le dimensioni dei loro team mobile o renderli due volte più produttivi. C'è un sacco di soldi in gioco. Sì, ci sono dei compromessi, ma d'altra parte, è mooooooltoooooolto.
Supponiamo ipoteticamente che Apple abbia seguito stupidamente l'esempio di Guido van Rossum e abbia dichiarato che Swift 6.0 era retrocompatibile con Swift 5.0, proprio come Python 3 era incompatibile con Python 2.
Probabilmente ho raccontato questa storia dieci anni fa, ma circa quindici anni fa sono andato al Foo Camp di O'Reilly con Guido, ed ero in una tenda con Paul Graham e un gruppo di pezzi grossi. Eravamo seduti sotto il caldo soffocante, in attesa che Larry Page partisse con il suo elicottero personale, e Guido continuava a parlare di "Python 3000", che aveva chiamato così in onore del numero di anni che ci sarebbero voluti perché tutti migrassero a quel sistema operativo. Continuavamo a chiedergli perché stesse violando la compatibilità, e lui rispondeva "Unicode". E noi gli chiedevamo, se avessimo dovuto riscrivere il nostro codice, quali altri vantaggi avremmo ottenuto? E lui rispondeva: "Yooooooooooooooouuuuuuuniiiiiiicoooooooode".
Se installi Google Cloud Platform SDK ("gcloud"), riceverai la seguente notifica:
Gentile destinatario,
Vorremmo ricordarti che il supporto per Python 2 è deprecato, quindi vaffanculo...
… e così via. Il cerchio della vita.
Ma il fatto è che ogni sviluppatore ha una scelta. E se li costringi a riscrivere il codice abbastanza spesso, potrebbero anche prendere in considerazione altro Opzioni. Non sono tuoi ostaggi, non importa quanto tu lo voglia. Sono tuoi ospiti. Python è ancora un linguaggio di programmazione molto popolare, ma, accidenti, Python 3(000) ha creato un tale caos per sé stesso, per le sue comunità e per gli utenti delle sue comunità che le conseguenze non sono state chiarite per quindici anni.
Quanto software Python è stato riscritto in Go (o Ruby, o qualche altra alternativa) a causa di questa incompatibilità con le versioni precedenti? Quanto nuovo software è stato scritto in un linguaggio diverso da Python, anche se... potrebbe essere scritto in Python se Guido non avesse bruciato l'intero villaggio? È difficile dirlo, ma Python ha chiaramente sofferto. È un gran pasticcio, e tutti ci rimettono.
Quindi, supponiamo che Apple segua l'esempio di Guido e interrompa la compatibilità. Cosa pensi che succederà in seguito? Beh, forse l'80-90% degli sviluppatori riscriverà il proprio software, se possibile. In altre parole, il 10-20% della base utenti migrerà automaticamente a un linguaggio concorrente, come Flutter.
Ripetendo questa operazione più volte, perderai metà della tua base utenti. Proprio come nello sport, anche nel mondo della programmazione la forma fisica è importante. tuttoChiunque perda metà dei propri utenti in cinque anni sarà un grande perdente. Bisogna essere al passo con i tempi nel mondo delle piattaforme. Ma è qui che non supportare le versioni precedenti ti ucciderà nel tempo. Perché ogni volta che ti sbarazzi di un gruppo di sviluppatori, (a) li perdi per sempre perché sono arrabbiati con te per aver infranto il contratto e (b) li cedi alla concorrenza.
Ironicamente, ho anche contribuito a trasformare Google in una prima donna retrocompatibile quando ho creato Grok, un sistema di analisi e comprensione del codice sorgente che semplifica l'automazione e la creazione di strumenti di codice basati sul codice stesso, come un IDE, ma in cui un servizio cloud archivia rappresentazioni materializzate di tutti i miliardi di righe di codice sorgente di Google in un grande data warehouse.
Grok ha fornito ai dipendenti di Google un potente framework per il refactoring automatico dell'intera base di codice (letteralmente tutto Google). Il sistema non solo individua le dipendenze upstream (da cosa si dipende), ma anche discendente (dipende da te), quindi quando modifichi la tua API, sai a tutti che stai violando le regole! Quindi, quando apporti una modifica, puoi verificare che ogni utente della tua API abbia aggiornato alla nuova versione e, in realtà, spesso con lo strumento Rosie che hanno sviluppato, puoi automatizzare completamente il processo.
Ciò consente al codice di base di Google di essere internamente "pulito" in modo quasi soprannaturale, poiché hanno questi servitori robotici che corrono per casa e puliscono automaticamente tutto se rinominano SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName perché qualcuno ha deciso che era un nipote brutto e che doveva essere soppresso.
E, francamente, funziona piuttosto bene per Google... internamente. Voglio dire, sì, la comunità Go di Google ride bonariamente della comunità Java di Google per la loro abitudine di refactoring continuo. Se si refactorizza qualcosa N volte, significa non solo che si è sbagliato N-1 volta, ma dopo un po' diventa abbastanza chiaro che probabilmente si è sbagliato anche all'ennesimo tentativo. Ma nel complesso, rimangono al di sopra di tutto questo trambusto e mantengono il codice "pulito".
I problemi iniziano quando cercano di imporre questo atteggiamento ai loro clienti cloud e agli utenti di altre API.
Vi ho dato una breve introduzione a Emacs, Android e Java; diamo un'occhiata all'ultima piattaforma di successo e longeva: il Web stesso. Potete immaginare quante iterazioni abbia attraversato HTTP dal 1995, quando usavamo i tag lampeggianti. e le icone "In costruzione" sulle pagine web.
Ma funziona ancora! E queste pagine funzionano ancora! Sì, gente, i browser sono i campioni mondiali di retrocompatibilità. Chrome è un altro esempio della rara piattaforma Google che ha la testa avvitata correttamente e, come avrete intuito, Chrome opera di fatto come un silos separato dal resto di Google.
Voglio anche ringraziare i nostri amici della comunità dei sistemi operativi: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, ecc., per aver fatto un lavoro così eccezionale di retrocompatibilità sulle loro piattaforme di successo (Apple prende al massimo una C-, perché rompe le cose in continuazione senza una buona ragione, ma in qualche modo la comunità riesce a risolvere il problema con ogni versione, e i contenitori OS X non sono completamente obsoleti... ancora).
Ma aspetta, dirai. Non stiamo forse paragonando mele e arance, sistemi software autonomi su una singola macchina, come Emacs/JDK/Android/Chrome, con sistemi multi-server e API, come nei servizi cloud?
Beh, ne ho parlato su Twitter ieri, ma nello stile "fa schifo/regole" di Larry Wall, ho cercato la parola deprecato sui siti degli sviluppatori di Google e Amazon. E mentre AWS ha centinaia di Sebbene esistano più servizi offerti rispetto a GCP, la documentazione per gli sviluppatori di Google menziona la deprecazione circa sette volte più spesso.
Se qualcuno di Google sta leggendo questo, probabilmente sarà pronto a tirare fuori qualche grafico in stile Donald Trump per dimostrare che stanno effettivamente facendo le cose per bene e che non dovrei fare paragoni ingiusti come "numero di volte in cui viene usata la parola deprecato rispetto al numero di servizi".
Ma dopo tutti questi anni, Google Cloud è ancora il servizio n. 3 (non ho mai scritto un articolo sul fallito tentativo di diventare il n. 2), ma se si deve credere agli addetti ai lavori, c'è chi teme che possa presto scendere al n. 4.
Non ho argomenti convincenti per "dimostrare" la mia tesi. Ho solo esempi coloriti che ho accumulato in 30 anni di esperienza come sviluppatore. Ho già accennato alla natura profondamente filosofica di questo problema; per certi versi, è politicizzato nella comunità degli sviluppatori. Alcuni pensano che creatori le piattaforme dovrebbero preoccuparsi della compatibilità, mentre altri pensano che sia una preoccupazione gli utenti (gli sviluppatori stessi). Una delle due cose. E poi, non è forse una questione politica decidere chi dovrebbe farsi carico dei costi dei problemi comuni?
Quindi questa è politica. E sicuramente ci saranno reazioni rabbiose al mio discorso.
Come utente Come utente di Google Cloud Platform e di AWS da due anni (lavorando per Grab), posso affermare che c'è un'enorme differenza tra la filosofia di Amazon e quella di Google in termini di priorità. Non sviluppo attivamente su AWS, quindi non ho idea di quanto spesso rimuovano le vecchie API. Ma sospetto che non accada così spesso come con Google. E credo sinceramente che questa fonte di costante dibattito e frustrazione in GCP sia uno dei principali fattori che frenano la piattaforma.
So di non aver citato esempi specifici di sistemi GCP che verranno dismessi. Posso dirvi che praticamente tutto ciò che ho usato, dal networking (dal più vecchio al VPC) allo storage (Cloud SQL v1-v2), Firebase (ora Firestore con un'API completamente diversa), App Engine (non fatemi nemmeno iniziare), Cloud Endpoints, a... non so... assolutamente tutto questo ti hanno costretto a riscrivere il codice dopo 2-3 anni al massimo, e non hanno mai automatizzato la migrazione per te, ma spesso Come se dovesse essere così.
E ogni volta che guardo AWS, mi chiedo perché diavolo sono ancora su GCP. Chiaramente non hanno bisogno di clienti. Hanno bisogno покупателиCapisci la differenza? Lascia che te lo spieghi.
Google Cloud ha dove le persone propongono le loro soluzioni software, e per evitare l'effetto ristorante vuoto, avevano bisogno di riempirlo con qualche proposta, così hanno stipulato un contratto con un'azienda chiamata Bitnami per sviluppare una serie di soluzioni che si implementano con "un clic", o dovrei scrivere "soluzioni" perché queste non risolvono nulla. Esistono solo come caselle da spuntare, come riempitivo di marketing, e a Google non è mai importato se qualcuno di quegli strumenti funzionasse davvero. Conosco i product manager che si occupavano di tutto questo, e posso assicurarvi che a queste persone non importa un fico secco.
Prendiamo ad esempio una soluzione con presunta distribuzione "one-click". Ero stufo delle buffonate di Google Cloud SQL, quindi ho iniziato a valutare la possibilità di creare un mio cluster Percona come alternativa. E per una volta, Google sembrava aver fatto una buona cosa: mi avrebbe fatto risparmiare tempo e fatica con un semplice clic!
Ok, eccoci qui. Andiamo al link e clicchiamo su quel pulsante. Selezioniamo "Sì" per accettare tutte le impostazioni predefinite e distribuire il cluster sul nostro progetto Google Cloud. Ahah, non funziona. Nessuna di queste schifezze funziona. Lo strumento non è mai stato testato e ha iniziato a marcire fin dal primo minuto, e non mi sorprenderebbe se più della metà delle "soluzioni" fossero distribuzioni con un clic (ora capiamo il perché delle virgolette). affatto non funzionano. È un posto completamente buio, è meglio non entrare.
Ma Google è diretto призывает li usi. Vogliono che tu li usi. compratoPer loro è una transazione. Non vogliono niente. per supportareNon fa parte del DNA di Google. Certo, gli ingegneri si supportano a vicenda, come dimostra la mia storia su Bigtable. Ma nei prodotti e nei servizi per le persone comuni, sempre erano spietati in , che non soddisfa i requisiti di redditività, nonostante abbia milioni di utenti.
E questo è un vero problema per GCP, perché è il DNA di tutte le offerte cloud. Non vogliono supportare nulla; notoriamente si rifiutano di ospitare (come servizio gestito) qualsiasi software di terze parti. fino afinché AWS non farà lo stesso e non costruirà un business di successo attorno a questo, e quando i clienti chiederanno letteralmente la stessa cosa. Ma ci vuole un certo impegno per convincere Google a supportare qualsiasi cosa.
Questa mancanza di cultura di supporto, unita alla mentalità del "rompiamolo per renderlo più bello", allontana gli sviluppatori da loro.
E questa non è una buona cosa se si vuole costruire una piattaforma duratura.
Google, svegliati, accidenti. Siamo nel 2020. Stai ancora perdendo. È ora di guardarti allo specchio e decidere se vuoi davvero rimanere nel business del cloud.
Se vuoi restare, allora smettila di rompere tuttoVoi siete ricchi. Noi sviluppatori no. Quindi, quando si tratta di decidere chi si assumerà l'onere della compatibilità, dovrete farlo voi. Non noi.
Perché ci sono almeno altre tre nuvole davvero belle. Mi chiamano.
Adesso vado a riparare tutti i miei sistemi rotti. Sospiro.
Alla prossima!
P.S. Aggiornamento dopo aver letto alcune delle discussioni su questo articolo (tra l'altro, sono ottime). Il supporto a Firebase non è stato interrotto e, a quanto mi risulta, non ci sono piani in tal senso. Tuttavia, hanno un fastidioso bug di streaming che causa l'arresto del client Java in App Engine. Uno dei loro ingegneri mi ha aiutato a risolvere questo problema. quando lavoravo a Google, ma non hanno mai effettivamente risolto il bug, quindi ho una pessima soluzione alternativa: devo riavviare l'app GAE ogni giorno. Ed è così da quattro anni! Ora hanno Firestore. Ci vorrà molto lavoro per migrare a questo sistema, dato che è completamente diverso, e il bug di Firebase non verrà mai risolto. Cosa possiamo concludere? Puoi ottenere assistenza, se lavori in un'aziendaProbabilmente sono l'unico che usa Firebase su GAE perché scrivo meno di 100 chiavi in un'app nativa al 100% e si blocca ogni due giorni a causa di un bug noto. Cosa posso dire se non che usatelo a vostro rischio e pericolo? Sto passando a Redis.
Ho anche sentito alcuni utenti AWS più esperti affermare che AWS generalmente non disapproverà mai alcun servizio, e SimpleDB ne è un ottimo esempio. La mia supposizione che AWS non sia affetto dallo stesso problema di disapprovazioni di Google sembra corretta.
Inoltre, ho notato che 20 giorni fa il team di Google App Engine ha interrotto l'hosting di una libreria Go critica, chiudendo l'app GAE di uno degli sviluppatori Go principali. Davvero stupido.
Infine, ho sentito i dipendenti di Google discutere di questo problema e in genere sono d'accordo con me (vi voglio bene ragazzi!). Ma sembra che considerino il problema irrisolvibile perché la cultura di Google non ha mai avuto la giusta struttura di incentivi. Ho pensato che sarebbe stato utile prendermi un po' di tempo per parlare dell'esperienza assolutamente straordinaria che ho avuto lavorando con gli ingegneri AWS quando ero in Grab. Spero di poterlo fare in futuro!
E sì, nel 2005 c'erano diversi tipi di carne di squalo nel buffet gigante dell'Edificio 43, e il mio preferito era lo squalo martello. Tuttavia, nel 2006, Larry e Sergey avevano eliminato tutti gli snack poco salutari. Quindi, al tempo della storia di Bigtable del 2007, non c'erano davvero squali, e vi ho mentito.
Quando ho esaminato il cloud Bigtable quattro anni fa (più o meno), questo era il prezzo. Ora sembra essere sceso un po', ma è ancora molto alto per un archivio dati vuoto, soprattutto considerando che il mio primo articolo mostra quanto sia irrilevante un Big Table vuoto alla loro scala.
Mi dispiace di aver offeso la community Apple e di non aver detto nulla di carino su Microsoft ecc. Avete ragione, apprezzo molto tutta la discussione che questo articolo ha generato! Ma a volte è necessario smuovere un po' le acque per far partire la conversazione, no?
Grazie per aver letto.
Aggiornamento 2, 19.08.2020. Stripe !
Aggiornamento 3, 31.08.2020/2/2: Sono stato contattato da un ingegnere di Google di Cloud Marketplace, che si è rivelato essere un mio vecchio amico. Voleva sapere perché CXNUMXD non funzionava e alla fine abbiamo scoperto che il problema era dovuto al fatto che avevo creato la mia rete qualche anno prima e che CXNUMXD non funzionava sulle reti legacy a causa di un parametro di subnet mancante nei loro template. Credo che i potenziali utenti di GCP dovrebbero assicurarsi di conoscere abbastanza ingegneri di Google…
Fonte: habr.com
