Accidenti a Google, non volevo più scrivere sul blog. Ho così tanto da fare. Bloggare richiede tempo, energia e creatività, che potrei mettere a frutto: i miei libri, , il mio gioco e così via. Ma mi hai fatto incazzare abbastanza da dover scrivere questo.
Quindi finiamola con questo.
Vorrei iniziare con una storia breve ma istruttiva di quando ho iniziato a lavorare in Google. So di aver detto molte cose negative su Google ultimamente, ma mi dà fastidio quando la mia azienda prende regolarmente decisioni aziendali incompetenti. Allo stesso tempo bisogna darglielo: l'infrastruttura interna di Google è davvero straordinaria, si può dire con certezza che oggi non c'è niente di meglio. I fondatori di Google erano ingegneri molto migliori di quanto lo sarò mai io, e questa storia non fa altro che confermare questo fatto.
Innanzitutto, un po’ di background: Google ha una tecnologia di archiviazione dei dati chiamata . È stato un risultato tecnico notevole, uno dei primi (se non il primo) archivio di valori-chiave (K/V) "infinitamente scalabili": essenzialmente l'inizio di NoSQL. Al giorno d'oggi Bigtable se la cava ancora bene nello spazio di archiviazione K/V piuttosto affollato, ma all'epoca (2005) era sorprendentemente interessante.
Una cosa divertente di Bigtable è che avevano oggetti del piano di controllo interno (come parte dell'implementazione) chiamati server tablet, con indici di grandi dimensioni, e ad un certo punto diventavano un collo di bottiglia durante il ridimensionamento del sistema. Gli ingegneri di Bigtable erano perplessi su come implementare la scalabilità e all'improvviso si sono resi conto che potevano sostituire i server tablet con altri dispositivi di archiviazione Bigtable. Quindi Bigtable fa parte dell'implementazione Bigtable. Questi impianti di stoccaggio sono presenti a tutti i livelli.
Un altro dettaglio interessante è che per un po’ Bigtable è diventato popolare e onnipresente all’interno di Google, con ogni team che aveva il proprio repository. Così, in uno degli incontri del venerdì, Larry Page ha chiesto casualmente di sfuggita: “Perché abbiamo più di un Bigtable? Perché non solo uno?" In teoria, uno spazio di archiviazione dovrebbe essere sufficiente per tutte le esigenze di archiviazione di Google. Naturalmente non ne hanno mai scelto uno solo per ragioni pratiche di sviluppo (come le conseguenze di un potenziale fallimento), ma la teoria era interessante. Un unico deposito per l'intero Universo (A proposito, qualcuno sa se Amazon ha fatto lo stesso 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'e-mail dal team di ingegneri di Bigtable che diceva più o meno questo:
Caro Steve,
Un saluto dal team di Bigtable. Desideriamo informarti che presso [data center name] stai utilizzando un file binario Bigtable molto, molto vecchio. Questa versione non è più supportata e vogliamo aiutarti a eseguire l'aggiornamento alla versione più recente.
Per favore fatemi sapere se potete programmare un po' di tempo per lavorare insieme su questo problema.
Ti auguro il meglio,
Squadra Bigtable
Su Google ricevi moltissima posta, quindi a prima vista ho letto qualcosa del genere:
Gentile destinatario,
Ciao da qualche squadra. Vogliamo comunicarlo bla bla bla bla bla. Bla bla bla bla bla bla, e bla bla bla subito.
Per favore fateci sapere se potete programmare un po' del vostro tempo prezioso per blah blah blah.
Ti auguro il meglio,
Una specie di comando
L'ho quasi cancellato subito, ma ai margini della mia coscienza ho sentito una sensazione dolorosa e fastidiosa non proprio sembra una lettera formale però ovviamente, che il destinatario si è sbagliato perché non ho utilizzato Bigtable.
Ma era strano.
Ho trascorso il resto della giornata pensando alternativamente al lavoro e a che tipo di carne di squalo provare nella microcucina, di cui almeno tre erano abbastanza vicini da colpire dalla mia sedia con un lancio ben mirato di un biscotto, ma il il pensiero di scrivere non mi ha mai lasciato con un crescente sentimento di lieve ansia.
Hanno detto chiaramente il mio nome. E l'e-mail è stata inviata al mio indirizzo e-mail, non a quello di qualcun altro, e non è cc: o bcc:. Il tono è molto personale e chiaro. Forse questo è una specie di errore?
Alla fine, la curiosità ha avuto la meglio e sono andato a vedere la console Borg nel data center che hanno menzionato.
E, naturalmente, avevo in gestione lo spazio di archiviazione BigTable. Scusa, cosa? Ho guardato il suo contenuto e wow! Proveniva dall'incubatore Codelab in cui mi trovavo durante la mia prima settimana in Google nel giugno 2005. Codelab ti ha costretto a eseguire Bigtable per scrivere alcuni valori lì, e apparentemente non ho mai chiuso l'archiviazione. Funzionava ancora anche se erano passati più di due anni.
Ci sono diversi aspetti degni di nota in questa storia. Innanzitutto il lavoro di Bigtable era così insignificante rispetto alla scala di Google che solo due anni dopo qualcuno si accorse dello spazio di archiviazione aggiuntivo e solo perché la versione del codice binario era obsoleta. Per fare un confronto, una volta ho considerato l'utilizzo per il mio gioco online. All'epoca, questo servizio costava circa $ 16 all'anno. svuotare Bigtable su GCP. Non sto dicendo che ti stanno truffando, ma secondo la mia opinione personale, sono un sacco di soldi per un fottuto database vuoto.
Un altro aspetto degno di nota è quello dello stoccaggio ancora funzionante dopo due anni. WTF? I data center vanno e vengono; subiscono interruzioni, sono sottoposti a manutenzione programmata, cambiano continuamente. L'hardware viene aggiornato, gli interruttori vengono scambiati, tutto viene costantemente migliorato. Come diavolo sono riusciti a mantenere attivo il mio programma per due anni con tutti questi cambiamenti? Questo può sembrare un risultato modesto nel 2020, ma nel 2005-2007 è stato piuttosto impressionante.
E l'aspetto più meraviglioso è che un team di ingegneri esterno in qualche altro stato si avvicina a me, il proprietario di una piccola istanza quasi vuota di Bigtable, che ha traffico zero negli ultimi due anni e offrono aiuto per aggiornarlo.
Li ho ringraziati, ho cancellato la memoria e la vita è andata avanti come al solito. Ma tredici anni dopo, penso ancora a quella lettera. Perché a volte ricevo email simili da Google Cloud. Sembrano così:
Gentile utente di Google Cloud,
Ti ricordiamo che interromperemo il servizio [servizio essenziale che usi] a partire da agosto 2020, dopodiché non potrai aggiornare le tue istanze. Ti consigliamo di eseguire l'aggiornamento alla versione più recente, che è in fase di beta testing, non ha documentazione, nessun percorso di migrazione ed è 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 di Google
Ma non leggo quasi mai lettere del genere, perché in realtà dicono:
Gentile destinatario,
Vai all'inferno. Vaffanculo, vaffanculo, vaffanculo. Lascia perdere tutto quello che fai perché non ha importanza. Ciò che conta è il nostro tempo. Perdiamo tempo e denaro mantenendo le nostre schifezze e ne siamo stanchi quindi non le supportiamo più. Quindi piantala con i tuoi maledetti piani e inizia a scavare nella nostra documentazione di merda, implorando frammenti sui forum, e comunque, la nostra nuova merda è completamente diversa dalla vecchia merda, perché abbiamo incasinato piuttosto male questo progetto, eh, ma questo è il tuo problema, non il nostro.
Continuiamo a impegnarci per garantire che tutti i vostri sviluppi diventino inutilizzabili entro un anno.
Per favore, vaffanculo
Piattaforma cloud di Google
E il fatto è che ricevo lettere del genere circa una volta al mese. Ciò accade così spesso e così costantemente che inevitabilmente spinto via io da GCP al campo anti-cloud. Non sono più d'accordo nel dipendere dai loro sviluppi proprietari, perché in effetti è più facile per i devops mantenere un sistema open source su una semplice macchina virtuale piuttosto che cercare di tenere il passo con Google con la sua politica di chiusura dei prodotti "obsoleti".
Prima di tornare su Google Cloud perché I anche vicino Non finiamo di criticarli, diamo un'occhiata alle prestazioni dell'azienda in alcune altre aree. Gli ingegneri di Google sono orgogliosi della loro disciplina di ingegneria del software, e questo è ciò che effettivamente causa 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 prendersi cura dei clienti.
Fornirò alcuni esempi casuali da altri grandi progetti al di fuori di Google, ma spero che vedrai questo schema ovunque. È il seguente: la compatibilità con le versioni precedenti mantiene i sistemi vivi e aggiornati per decenni.
La compatibilità con le versioni precedenti è l'obiettivo di progettazione di tutti i sistemi di successo progettati per aperto utilizzo, cioè implementato con codice open source e/o standard aperti. Mi sembra di dire una cosa troppo ovvia che mette addirittura a disagio tutti, ma no. Questa è una questione politica, quindi sono necessari esempi.
Il primo sistema che sceglierò è il più vecchio: GNU Emacs, che è 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 poche parole Emacs è una piattaforma creata nel 1976 (sì, quasi mezzo secolo fa) per programmare per renderti più produttivo, ma mascherato da editor di testo.
Uso Emacs ogni singolo giorno. Sì, utilizzo anche IntelliJ ogni giorno, è diventato una potente piattaforma di strumenti a sé stante. Ma scrivere estensioni per IntelliJ è un compito molto più ambizioso e complesso che scrivere estensioni per Emacs. E, cosa ancora più importante, tutto ciò che è stato scritto per Emacs viene preservato eternamente.
Utilizzo ancora il software che ho scritto per Emacs nel 1995. E sono sicuro che qualcuno stia usando moduli scritti per Emacs a metà degli anni '80, se non prima. Potrebbero richiedere qualche modifica di tanto in tanto, ma questo è davvero piuttosto raro. Non conosco nulla di quello che ho scritto per Emacs (e ho scritto molto) che richiedesse una riarchitettura.
Emacs ha una funzione chiamata make-obsolete per le entità obsolete. La terminologia di Emacs per i concetti fondamentali del computer (come ad esempio cosa sia una "finestra") spesso differisce dalle convenzioni del settore perché Emacs le ha introdotte molto tempo fa. Questo è un pericolo tipico di chi è in anticipo sui tempi: tutti i tuoi termini sono errati. Ma Emacs ha un concetto di deprecazione, che nel loro gergo si chiama obsolescenza.
Ma nel mondo Emacs sembra esserci una definizione operativa diversa. Una filosofia di fondo diversa, se vuoi.
Nel mondo di Emacs (e in molte altre aree, di cui parleremo più avanti), lo stato di API deprecate significa sostanzialmente: "Non dovresti davvero usare questo approccio, perché anche se funziona, soffre di vari difetti di cui parleremo". elenca qui. Ma alla fine la scelta è tua."
Nel mondo di Google, essere obsoleti significa: "Violiamo il nostro impegno nei tuoi confronti". Questo è vero. Questo è ciò che significa essenzialmente. Ciò significa che ti costringeranno regolarmente fare un po' di lavoro, forse molto lavoro, come punizione per aver creduto in loro : Abbiamo il miglior software. Il più veloce! Fai tutto secondo le istruzioni, avvii la tua applicazione o servizio e poi bam, dopo un anno o due si rompe.
È come vendere un'auto usata che si romperà definitivamente dopo 1500 km.
Queste sono due definizioni filosofiche completamente diverse di “obsolescenza”. La definizione di odore di Google . Non ci credo infatti obsolescenza pianificata nello stesso senso di Apple. Ma Google sta sicuramente pianificando di interrompere i vostri programmi, in modo indiretto. Lo so perché ho lavorato lì come ingegnere del software per oltre 12 anni. Hanno vaghe linee guida interne su quanta compatibilità con le versioni precedenti dovrebbe essere seguita, ma alla fine dipende da ogni singolo team o servizio. Non esistono raccomandazioni a livello aziendale o tecnico e la raccomandazione più audace in termini di cicli di obsolescenza è "cercare di concedere ai clienti 6-12 mesi per eseguire l'aggiornamento prima di danneggiare l'intero sistema".
Il problema è molto più grande di quanto pensino e persisterà negli anni a venire perché l’attenzione al cliente non è nel loro DNA. Maggiori informazioni su questo argomento di seguito.
A questo punto farò una dichiarazione audace sul fatto che Emacs ha successo in larga misura e in modo uniforme fondamentalmente perché prendono molto sul serio la compatibilità con le versioni precedenti. In realtà, questa è la tesi del nostro articolo. I sistemi aperti di successo e di lunga durata devono il loro successo alle microcomunità che vivono intorno a loro da decenni estensioni/plugin. Questo è l'ecosistema. Ho già parlato della natura delle piattaforme e di quanto siano importanti, e di come Google non abbia mai capito in tutta la sua storia aziendale cosa implica la creazione di una piattaforma aperta di successo al di fuori di Android o Chrome.
In realtà dovrei menzionare brevemente Android perché probabilmente ci stai pensando.
In primo luogo, Android non è Google. Non hanno quasi nulla in comune tra loro. Android è un'azienda acquistata da Google nel luglio 2005, alla quale è stato consentito di operare più o meno autonomamente ed è rimasta sostanzialmente intatta negli anni successivi. Android è un famigerato stack tecnologico e un'organizzazione spinosa altrettanto famigerata. Come ha detto un Googler, “Non puoi semplicemente accedere ad Android”.
In un articolo precedente, ho discusso di quanto fossero sbagliate alcune delle prime decisioni di progettazione di Android. Diamine, quando ho scritto quell'articolo stavano lanciando schifezze chiamate "app istantanee" che ora sono (sorpresa!) , e sono solidale se fossi così stupido da ascoltare Google e spostare i tuoi contenuti in queste app istantanee.
Ma qui c'è una differenza, una differenza significativa, ovvero che gli utenti Android comprendono davvero quanto siano importanti le piattaforme e fanno del loro meglio per mantenere funzionanti le vecchie app Android. In effetti, i loro sforzi per mantenere la compatibilità con le versioni precedenti sono così estremi che persino io, durante il mio breve periodo presso la divisione Android qualche anno fa, mi sono ritrovato a cercare di convincerli a eliminare il supporto per alcuni dei dispositivi e delle API più vecchi (mi sbagliavo , come in molte altre cose passate e presenti. Scusate ragazzi Android! Ora che sono stato in Indonesia, capisco perché ne abbiamo bisogno).
Gli utenti Android spingono la retrocompatibilità a estremi quasi inimmaginabili, accumulando enormi quantità di debito tecnico legacy nei loro sistemi e toolchain. Oh mio Dio, dovresti vedere alcune delle cose folli che devono fare nel loro sistema di build, tutto in nome della compatibilità.
Per questo conferisco ad Android l'ambito premio "Non sei Google". In realtà non vogliono diventare Google, che non sa creare piattaforme durevoli, ma Android egli sa, come farlo. E quindi Google è molto intelligente sotto un aspetto: consentire alle persone di fare le cose a modo loro su Android.
Tuttavia, le app istantanee per Android erano un'idea piuttosto stupida. E sai perché? Perché hanno chiesto riscrivere e riprogettare la tua applicazione! È come se le persone semplicemente riscrivessero due milioni di applicazioni. Immagino che Instant Apps sia stata un'idea di qualche Googler.
Ma c'è una differenza. La compatibilità con le versioni precedenti ha un costo elevato. Android stesso sostiene l’onere di questi costi, mentre Google insiste affinché l’onere venga sostenuto si, cliente pagante.
Puoi vedere l'impegno di Android per la compatibilità con le versioni precedenti nelle sue API. Quando hai quattro o cinque sottosistemi diversi che fanno letteralmente la stessa cosa, è un segno sicuro che c'è un impegno verso la compatibilità con le versioni precedenti al centro. Che nel mondo delle piattaforme è sinonimo di impegno verso i tuoi clienti e il tuo mercato.
Il problema principale di Google qui è il loro orgoglio per la loro igiene ingegneristica. A loro non piace quando ci sono molti modi diversi per fare la stessa cosa, con i vecchi modi meno desiderabili accanto a quelli nuovi e più elaborati. Aumenta la curva di apprendimento per chi è nuovo al sistema, aumenta l'onere di mantenere le API legacy, rallenta la velocità delle nuove funzionalità e il peccato capitale è che non è carino. Google - come Lady Ascot di Alice nel Paese delle Meraviglie di Tim Burton:
Signora Ascot:
- Alice, sai di cosa ho più paura?
- Il declino dell'aristocrazia?
- Avevo paura che l'avrei fatto 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 stesso.
Java ha molte API obsolete. La deprecazione è molto popolare tra i programmatori Java, ancora più popolare che nella maggior parte dei linguaggi di programmazione. Java stesso, il linguaggio principale e le librerie deprecano costantemente le API.
Per fare solo uno tra migliaia di esempi, considerato obsoleto. È stato deprecato dal rilascio di Java 1.2 nel dicembre 1998. Sono passati 22 anni da quando è stato deprecato.
Ma il mio codice attuale in produzione sta ancora uccidendo i thread ogni giorno. Pensi davvero che sia una cosa buona? Assolutamente! Voglio dire, ovviamente, se dovessi riscrivere il codice oggi, lo implementerei diversamente. Ma il codice del mio gioco, che ha reso felici centinaia di migliaia di persone negli ultimi due decenni, è scritto con una funzione per chiudere i thread che restano bloccati troppo a lungo, e io non ho mai dovuto cambiarlo. Conosco il mio sistema meglio di chiunque altro, ho letteralmente 25 anni di esperienza di lavoro con esso in produzione e posso dirlo con certezza: nel mio caso, chiudere questi thread di lavoro specifici è completamente senza valore. Non vale la pena dedicare tempo e fatica a riscrivere questo codice e ringrazio Larry Ellison (probabilmente) che Oracle non mi abbia costretto a riscriverlo.
Probabilmente Oracle capisce anche le piattaforme. Chi lo sa.
Le prove possono essere trovate in tutte le principali API Java, che sono piene di ondate di obsolescenza, come le linee di un ghiacciaio in un canyon. Puoi facilmente trovare cinque o sei diversi gestori di navigazione da tastiera (KeyboardFocusManager) nella libreria Java Swing. In realtà è difficile trovare un'API Java che non sia deprecata. Ma funzionano ancora! Penso che il team Java rimuoverà veramente un'API solo se l'interfaccia pone un evidente problema di sicurezza.
Il punto è questo, gente: noi sviluppatori di software siamo tutti molto impegnati e in ogni area del software ci troviamo di fronte ad alternative concorrenti. In ogni momento, i programmatori nella lingua X considerano la lingua Y come un possibile sostituto. Oh, non mi credi? Vuoi chiamarlo Swift? Ad esempio, tutti stanno migrando a Swift e nessuno lo abbandona, giusto? Wow, quanto poco sai. Le aziende stanno contando i costi dei doppi team di sviluppo mobile (iOS e Android) e stanno iniziando a rendersi conto che quei sistemi di sviluppo multipiattaforma con nomi divertenti come Flutter e React Native funzionano davvero e possono essere utilizzati per ridurre le dimensioni dei loro team. team mobili due volte o, al contrario, renderli due volte più produttivi. Ci sono soldi veri in gioco. Sì, ci sono dei compromessi, ma d'altra parte ci sono i soldi.
Supponiamo ipoteticamente che Apple abbia stupidamente preso spunto da Guido van Rossum e abbia dichiarato che Swift 6.0 è retrocompatibile con Swift 5.0, proprio come Python 3 è incompatibile con Python 2.
Probabilmente ho raccontato questa storia circa dieci anni fa, ma circa quindici anni fa andai al Foo Camp di O'Reilly con Guido, sedetti in una tenda con Paul Graham e un gruppo di pezzi grossi. Ci siamo seduti nel caldo soffocante aspettando che Larry Page volasse via con il suo elicottero personale mentre Guido parlava di "Python 3000", a cui ha dato il nome dal numero di anni che ci sarebbero voluti prima che tutti migrassero lì. Continuavamo a chiedergli perché stava interrompendo la compatibilità e lui ha risposto: "Unicode". E ci siamo chiesti, se dovessimo riscrivere il nostro codice, quali altri vantaggi vedremmo? E lui ha risposto: "Yoooooooooooooooouuuuuuniiiiiiicoooooooode".
Se installi l'SDK di Google Cloud Platform ("gcloud"), riceverai la seguente notifica:
Gentile destinatario,
Vorremmo ricordarti che il supporto per Python 2 è stato deprecato, quindi vaffanculo
… e così via. Cerchio della vita.
Ma il punto è che ogni sviluppatore ha una scelta. E se li costringi a riscrivere il codice abbastanza spesso, potrebbero pensarci altro opzioni. Non sono i tuoi ostaggi, non importa quanto potresti desiderare che lo siano. Sono i tuoi ospiti. Python è ancora un linguaggio di programmazione molto popolare, ma dannazione, Python 3(000) ha creato un tale caos in sé, nelle sue comunità e tra gli utenti delle sue comunità, che le conseguenze non sono state chiarite per quindici anni.
Quanti programmi Python sono stati riscritti in Go (o Ruby, o qualche altra alternativa) a causa di questa incompatibilità con le versioni precedenti? Quanto nuovo software è stato scritto in qualcosa di diverso da Python, sebbene esso potrebbe essere scritto in Python, se Guido non avesse bruciato l'intero villaggio? È difficile da dire, ma Python ha chiaramente sofferto. È un gran pasticcio e tutti perdono.
Quindi diciamo che Apple prende spunto da Guido e interrompe la compatibilità. Cosa pensi che succederà dopo? Ebbene, forse l'80-90% degli sviluppatori riscriverà il proprio software, se possibile. In altre parole, il 10-20% della base utenti passa automaticamente a qualche linguaggio concorrente, come Flutter.
Fallo più volte e perderai metà della tua base utenti. Proprio come nello sport, anche nel mondo della programmazione conta la forma attuale. tutto. Chiunque perde la metà dei propri utenti in cinque anni sarà considerato un Big Fat Loser. Devi essere trendy nel mondo delle piattaforme. Ma è qui che il mancato supporto delle versioni precedenti ti rovinerà nel tempo. Perché ogni volta che ti sbarazzi di alcuni sviluppatori, (a) li perdi per sempre perché sono arrabbiati con te per aver infranto il contratto e (b) li dai via ai tuoi concorrenti.
Ironicamente, ho anche aiutato Google a diventare una prima donna che ignora la compatibilità con le versioni precedenti quando ho creato Grok, un sistema di analisi e comprensione del codice sorgente che semplifica l'automazione e la strumentazione del codice stesso - simile a un IDE, ma qui il servizio cloud memorizza rappresentazioni materializzate di tutti i miliardi di righe del codice sorgente di Google in un grande data warehouse.
Grok ha fornito ai Googler un potente framework per eseguire refactoring automatizzati sull'intera base di codice (letteralmente su Google). Il sistema calcola non solo le tue dipendenze a monte (da cui dipendi), ma anche a valle (che dipende da te) quindi quando cambi le API conosci tutti quelli che stai rompendo! In questo modo, quando apporti modifiche, puoi verificare che ogni consumer della tua API sia aggiornato alla nuova versione, e in realtà, spesso con il tool che hanno scritto Rosie, puoi automatizzare completamente il processo.
Ciò consente al codice base di Google di essere internamente pulito in modo quasi soprannaturale, poiché hanno questi servitori robotici che corrono per la casa e ripuliscono automaticamente tutto se rinominano SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName perché qualcuno ha deciso che era un brutto nipote e aveva bisogno di essere messo a dormire.
E francamente, funziona piuttosto bene per Google... internamente. Voglio dire, sì, la comunità Go di Google si diverte molto con la comunità Java di Google a causa della loro abitudine al refactoring continuo. Se ricominci qualcosa N volte, significa che non solo hai sbagliato tutto N-1 volte, ma dopo un po' diventa abbastanza chiaro che probabilmente hai sbagliato anche tu all'ennesimo tentativo. Ma, nel complesso, restano al di sopra di tutto questo trambusto e mantengono il codice “pulito”.
Il problema inizia quando cercano di imporre questo atteggiamento ai loro client cloud e agli utenti di altre API.
Ti ho presentato un po' Emacs, Android e Java; diamo un'occhiata all'ultima piattaforma di successo e di lunga durata: il Web stesso. Riesci a immaginare quante iterazioni ha attraversato HTTP dal 1995, quando abbiamo utilizzato i tag lampeggianti? e le icone "In costruzione" sulle pagine web.
Ma funziona ancora! E queste pagine funzionano ancora! Sì, ragazzi, i browser sono i campioni del mondo in termini di compatibilità con le versioni precedenti. Chrome è un altro esempio della rara piattaforma Google che ha le teste avvitate correttamente e, come avrai intuito, Chrome opera effettivamente come un'azienda sandbox separata dal resto di Google.
Voglio anche ringraziare i nostri amici sviluppatori di sistemi operativi: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, ecc., per aver fatto un ottimo lavoro di retrocompatibilità sulle loro piattaforme di successo (Apple ottiene al massimo una C con The lo svantaggio è che rompono tutto continuamente senza una buona ragione, ma in qualche modo la comunità riesce ad aggirare il problema con ogni versione, e i contenitori OS X non sono ancora del tutto obsoleti... ancora).
Ma aspetta, dici. Non stiamo forse paragonando le mele alle arance: sistemi software autonomi su una singola macchina come Emacs/JDK/Android/Chrome rispetto a sistemi multi-server e API come i servizi cloud?
Bene, ne ho twittato ieri, ma nello stile di Larry Wall (creatore del linguaggio di programmazione Perl - ca. per.) ho cercato la parola "fa schifo/regole" deprecato sui siti degli sviluppatori di Google e Amazon. E sebbene AWS lo abbia centinaia di volte più offerte di servizi rispetto a GCP, la documentazione per gli sviluppatori di Google menziona la deprecazione circa sette volte più spesso.
Se qualcuno in Google sta leggendo questo articolo, probabilmente è pronto a tirare fuori grafici in stile Donald Trump dimostrando che in realtà stanno facendo tutto bene e che non dovrei fare paragoni ingiusti come "numero di menzioni della parola deprecata rispetto a numero di servizi" "
Ma dopo tutti questi anni, Google Cloud è ancora il servizio n. 3 (non ho mai scritto un articolo sul tentativo fallito di diventare il servizio n. 2), ma se si vuole credere agli addetti ai lavori, ci sono alcune preoccupazioni che potrebbero presto cadere in secondo piano. N. 4.
Non ho argomenti convincenti per "dimostrare" la mia tesi. Tutto quello che ho sono gli esempi colorati che ho accumulato in 30 anni come sviluppatore. Ho già menzionato la natura profondamente filosofica di questo problema; in un certo senso è politicizzato nelle comunità di sviluppatori. Alcuni lo credono creatori le piattaforme dovrebbero preoccuparsi della compatibilità, mentre altri pensano che questa sia una preoccupazione gli utenti (gli stessi sviluppatori). Uno su due. In effetti, non è forse una questione politica decidere chi debba sostenere i costi dei problemi comuni?
Quindi questa è politica. E probabilmente ci saranno risposte rabbiose al mio discorso.
Come utente Google Cloud Platform e come utente AWS per due anni (mentre lavoravo per Grab), posso dire che c'è un'enorme differenza tra la filosofia di Amazon e quella di Google quando si tratta di priorità. Non sviluppo attivamente su AWS, quindi non so molto bene quanto spesso rimuovono le vecchie API. Ma c'è il sospetto che ciò non avvenga così spesso come in Google. E credo davvero che questa fonte di continue controversie e frustrazioni in GCP sia uno dei maggiori fattori che frenano lo sviluppo della piattaforma.
So di non aver citato esempi specifici di sistemi GCP che non sono più supportati. Posso dire che quasi tutto quello che ho utilizzato, dalle reti (dalle più vecchie al VPC) allo storage (Cloud SQL v1-v2), Firebase (ora Firestore con un'API completamente diversa), App Engine (non cominciamo nemmeno) , endpoint cloud Cloud Endpoint e fino a... non so - assolutamente tutto questo ti hanno costretto a riscrivere il codice dopo un massimo di 2-3 anni e non hanno mai automatizzato la migrazione per te, e 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. Loro hanno bisogno покупатели. Capisci la differenza? Lasciatemi spiegare.
Google Cloud ha , dove le persone propongono le loro soluzioni software e, per evitare l'effetto ristorante vuoto, avevano bisogno di riempirlo con alcune proposte, quindi hanno stipulato un contratto con una società chiamata Bitnami per creare una serie di soluzioni che vengono implementate con "un clic", o dovrebbero Lo scrivo io stesso “soluzioni”, perché queste non risolvono un bel niente. Esistono semplicemente come caselle di controllo, come riempitivi di marketing, e a Google non è mai importato se qualcuno degli strumenti funziona effettivamente. Conosco product manager che sono stati al posto di guida e posso assicurarti che a queste persone non importa.
Prendiamo, ad esempio, una soluzione di distribuzione apparentemente “con un clic”. . Ero stufo da morire degli imbrogli di Google Cloud SQL, quindi ho iniziato a cercare di creare il mio cluster Percona come alternativa. E questa volta Google sembrava aver fatto un buon lavoro, mi avrebbero fatto risparmiare tempo e fatica con un semplice clic!
Bene, fantastico, andiamo. Seguiamo il collegamento e facciamo clic su questo pulsante. Seleziona "Sì" per accettare tutte le impostazioni predefinite e distribuire il cluster nel tuo progetto Google Cloud. Ahah, non funziona. Niente di tutto questo funziona. Lo strumento non è mai stato testato e ha iniziato a marcire dal primo minuto, e non mi sorprenderebbe se più della metà delle "soluzioni" fossero implementazioni con un clic (ora capiamo perché le virgolette) affatto non funziona. Questa è un'oscurità assolutamente senza speranza, dove è meglio non entrare.
Ma Google ha ragione призывает di usarli. Vogliono che tu lo faccia comprato. Per loro è una transazione. Non vogliono niente per 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 servizi per la gente comune sempre erano spietati , che non soddisfa gli standard di redditività anche se ha milioni di utenti.
E questo rappresenta una vera sfida per GCP perché questo è il DNA dietro tutte le offerte cloud. Non stanno cercando di supportare nulla; È noto che si rifiutano di ospitare (come servizio gestito) qualsiasi software di terze parti fino a, finché AWS non farà lo stesso e non creerà un business di successo attorno ad esso, e finché i clienti non chiederanno letteralmente la stessa cosa. Tuttavia, ci vuole un certo sforzo per convincere Google a supportare qualcosa.
Questa mancanza di cultura del supporto, unita alla mentalità del "rompiamolo per renderlo più bello", allontana gli sviluppatori.
E questa non è una buona cosa se vuoi costruire una piattaforma di lunga durata.
Google, svegliati, dannazione. È il 2020 adesso. Stai ancora perdendo. È tempo di guardarti allo specchio e chiederti se vuoi davvero rimanere nel business del cloud.
Se vuoi restare, allora smettila di rompere tutto. Ragazzi, siete ricchi. Noi sviluppatori no. Quindi, quando si tratta di chi si assumerà l’onere della compatibilità, devi prendertelo su te stesso. Non per noi.
Perché ci sono almeno altre tre nuvole davvero buone. Fanno cenno.
E ora passerò a riparare tutti i miei sistemi guasti. Eh.
Fino alla prossima volta!
PS Aggiornamento dopo aver letto alcune delle discussioni su questo articolo (le discussioni sono fantastiche, tra l'altro). Il supporto Firebase non è stato interrotto e non ci sono piani di cui sono a conoscenza. Tuttavia, hanno un brutto bug di streaming che causa lo stallo del client Java in App Engine. Uno dei loro ingegneri mi ha aiutato a risolvere questo problema, quando lavoravo in Google, ma in realtà non hanno mai risolto il bug, quindi ho una soluzione scadente che consiste nel dover riavviare l'app GAE ogni giorno. E così è da quattro anni! Ora hanno Firestore. Ci vorrà molto lavoro per migrarlo poiché è un sistema completamente diverso e il bug di Firebase non verrà mai risolto. Quale conclusione si può trarre? Puoi ottenere aiuto se lavori in un'azienda. Probabilmente sono l'unico a utilizzare Firebase su GAE perché registro meno di 100 chiavi in un'app nativa al 100% e smette di funzionare ogni paio di giorni a causa di un bug noto. Cosa posso dire se non usarlo a proprio rischio e pericolo? Sto passando a Redis.
Ho anche visto alcuni utenti AWS più esperti affermare che AWS di solito non smette mai di supportare alcun servizio e SimpleDB è un ottimo esempio. Le mie ipotesi secondo cui AWS non ha la stessa malattia di fine supporto di Google sembrano essere giustificate.
Inoltre, ho notato che 20 giorni fa il team di Google App Engine ha interrotto l'hosting di una libreria Go critica, chiudendo un'applicazione GAE di uno degli sviluppatori Go principali. È stato davvero stupido.
Infine, ho sentito i Googler già discutere di questo problema e in generale essere d'accordo con me (vi adoro ragazzi!). Ma sembrano pensare che il problema sia 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 discutere dell'esperienza assolutamente straordinaria che ho avuto lavorando con gli ingegneri AWS mentre lavoravo presso Grab. Un giorno in futuro, spero!
E sì, nel 2005 avevano diversi tipi di carne di squalo nel buffet gigante dell'edificio 43, e la mia preferita era la carne di squalo martello. Tuttavia, nel 2006, Larry e Sergei si sono sbarazzati di tutti gli snack malsani. Quindi durante la storia di Bigtable nel 2007 non c'erano davvero gli squali e ti ho ingannato.
Quando ho guardato Cloud Bigtable quattro anni fa (più o meno), è qui che stava il costo. Sembra che ora sia diminuito un po', ma è ancora troppo per un data warehouse vuoto, soprattutto perché la mia prima storia mostra quanto sia irrilevante una grande tabella vuota sulla loro scala.
Ci scusiamo per aver offeso la comunità Apple e non aver detto nulla di carino su Microsoft, ecc. Stai bene, apprezzo davvero tutta la discussione che questo articolo ha generato! Ma a volte è necessario fare un po' di scalpore per avviare una discussione, sai?
Grazie per aver letto.
Aggiornamento 2, 19.08.2020/XNUMX/XNUMX. Banda !
Aggiornamento 3, 31.08.2020/2/2. Sono stato contattato da un ingegnere di Google presso Cloud Marketplace che si è rivelato essere un mio vecchio amico. Voleva capire perché CXNUMXD non funzionava e alla fine abbiamo capito che era perché avevo costruito la mia rete anni fa e CXNUMXD non funzionava su reti legacy perché nei loro modelli mancava il parametro della sottorete. Penso che sia meglio per i potenziali utenti GCP assicurarsi di conoscere un numero sufficiente di ingegneri di Google...
Fonte: habr.com