For poking fun, Google, I didn't want to write a blog post again. I have so much to do. Blogging requires time, energy, and creativity that I could use more productively: my books, , my games, and so on. But you've annoyed me enough that I have to write this.
So let's get this over with.
I'll begin with a small but insightful story from the time when I first started working at Google. I know I’ve said a lot of negative things about Google lately, but I get frustrated when my own company regularly makes incompetent business decisions. That said, it’s important to acknowledge that Google's internal infrastructure is truly extraordinary; it can confidently be claimed that nothing better exists today. The founders of Google were far better engineers than I will ever be, and this story only reinforces that fact.
A bit of background first: Google has a data storage technology called . It was a remarkable technical achievement, one of the first (if not the first) "infinitely scalable" key-value stores: essentially, the beginning of NoSQL. Nowadays, Bigtable still performs well in a rather crowded K/V storage space, but back then (2005) it was incredibly cool.
One amusing detail about Bigtable is that they had internal control plane objects (as part of the implementation) called tablet servers, with large indices, and at some point, they became a bottleneck when scaling the system. The Bigtable engineers racked their brains over how to implement scalability, and suddenly realized they could replace tablet servers with other Bigtable stores. So Bigtable is part of the implementation of Bigtable. These stores exist at all levels.
En interessant detalje er, at Bigtable i en periode blev populære og udbredte inden for Google, og hver team havde deres eget lager. Så på et af fredagsmøderne spurgte Larry Page nonchalant: "Hvorfor har vi mere end én Bigtable? Hvorfor kan vi ikke nøjes med én?" Teoretisk set burde et lager være tilstrækkeligt til Googles alle lagringsbehov. Selvfølgelig gik de aldrig kun over til ét af praktiske udviklingsårsager (f.eks. konsekvenserne af et potentielt nedbrud), men teorien var interessant. Én lager for hele universet.Forresten, ved nogen, om Amazon har gjort det samme med deres Sable?)
Under alle omstændigheder, her er min historie.
På det tidspunkt havde jeg arbejdet i Google i lidt over to år, og en dag fik jeg en mail fra ingeniørteamet for Bigtable, som omtrent lød sådan her:
Kære Steve,
Hej fra Bigtable-teamet. Vi vil gerne informere dig om, at i datacentret [datacenterets navn] bruger du en meget, meget gammel Bigtable-binærfil. Denne version understøttes ikke længere, og vi vil gerne hjælpe dig med at opgradere til den nyeste version.
Lad os venligst vide, om du kan planlægge lidt tid til at arbejde sammen på dette spørgsmål.
Alt det bedste,
Bigtable-teamet
I Google får du mange mails, så ved første blik læste jeg det omtrent sådan her:
Kære modtager,
Hej fra et eller andet team. Vi vil gerne informere dig om, at bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, og bla-bla-bla straks.
Lad os venligst vide, om du kan planlægge en del af din dyrebare tid til bla-bla-bla.
Alt det bedste,
Et eller andet team
Jeg var næsten på vej til at slette det med det samme, men på grænsen af bevidstheden følte jeg en tung, nagende fornemmelse af, at det ikke helt lignede et formelt brev, selvom det var tydeligt,at de havde taget fejl med modtageren, for jeg brugte ikke Bigtable.
Men det var underligt.
Resten af dagen skiftede jeg mellem at tænke på arbejde og hvilken slags hajkød, jeg skulle prøve i mikro-køkkenet, hvoraf mindst tre var tæt nok på, til at jeg kunne ramme dem med et præcist kast af en småkage, men tanken på brevet blev ved med at plage mig med en stigende følelse af let angst.
De nævnte tydeligt mit navn. Og brevet blev sendt til min e-mailadresse, ikke nogen andens, og det var ikke cc: eller bcc:. Tonen er meget personlig og klar. Måske er det en fejl?
Til sidst tog nysgerrigheden overhånd, og jeg gik for at kigge på Borg-konsollen i det datacenter, de nævnte.
Og selvfølgelig havde jeg BigTable-lageret under mit ansvar. Hvad? Jeg kiggede på indholdet, og — for pokker! Det var fra Codelab-inkubator, hvor jeg sad den første uge af mit arbejde i Google i juni 2005. Codelab fik dig til at køre Bigtable, så du kunne skrive nogle værdier der, og åbenbart havde jeg ikke lukket lageret efter det. Det kørte stadig, selvom der var gået mere end to år.
Der er flere bemærkelsesværdige aspekter ved denne historie. For det første var arbejdet med Bigtable så uvæsentligt i Googles store setup, at det kun to år senere blev bemærket af nogen, og det kun fordi binærversionen var forældet. Til sammenligning overvejede jeg en gang at bruge til mit online-spil. På det tidspunkt kostede tjenesten omkring $16.000 om året for et tomt Bigtable på GCP. Jeg siger ikke, at de snyder dig, men efter min personlige mening er det mange penge for en tom, skide database.
Endnu et bemærkelsesværdigt aspekt er, at lageret fortsat fungerede efter to år.. Hvad pokker? Datacentre kommer og går; de oplever nedbrud, de gennemgår planlagt vedligeholdelse, de ændrer sig hele tiden. Hardwaren opgraderes, switchene skiftes ud, alt forbedres konstant. Hvordan i alverden kunne de holde mit program kørende i to år med alle disse ændringer? Det kan synes som en beskeden præstation i 2020, men i 2005-2007 var det ret imponerende.
Og den mest bemærkelsesværdige del er, at et ekstern ingeniørteam fra en anden stat kontakter mig, ejeren af en lille, næsten tom instans af Bigtable, der har nul trafik i de sidste to år — og tilbyder hjælp til at opgradere den.
Jeg takkede dem, slettede lageret, og livet fortsatte. Men tretten år senere tænker jeg stadig på dette brev. Fordi nogle gange modtager jeg lignende breve fra Google Cloud. De ser sådan ud:
Kære Google Cloud-bruger,
Vi minder om, at vi stopper med at understøtte tjenesten [vigtig tjeneste, som du bruger] fra august 2020, hvorefter du ikke vil kunne opdatere dine instanser. Vi anbefaler, at du skifter til den nyeste version, som er i beta-test, uden nogen dokumentation, ingen migrationsvejledning og som allerede er forældet med vores venlige hjælp.
Vi stræber efter, at denne ændring får minimal indvirkning på alle brugere af Google Cloud-platformen.
Bedste venner for altid,
Google Cloud-platformen
Men jeg læser næsten ikke sådanne breve, fordi de i virkeligheden siger følgende:
Kære modtager,
Gå helvede til. Gå, gå, gå. Giv alt, hvad du gør, op, for det betyder intet. Det, der betyder noget, er vores tid. Vi bruger tid og penge på at holde vores lort kørende, og vi er trætte af det, så vi vil ikke længere understøtte det. Så drop dine forbandede planer og begynd at rode i vores dårlige dokumentation, og tigger om madrester på foraene, og forresten, vores nye lort er helt anderledes end det gamle lort, fordi vi har virkelig ødelagt dette design, hehe, men det er dit problem, ikke vores.
Vi fortsætter med at arbejde på, at alle dine udviklinger bliver ubrugelige inden for et år.
Vær sød at forlade,
Google Cloud-platformen
Og sagen er, at jeg får sådanne breve cirka en gang om måneden. Det sker så ofte og så regelmæssigt, at de uundgåeligt skubbede mig væk fra GCP til modstandernes lejr mod cloud. Jeg er ikke længere enig i at være afhængig af deres proprietære udviklinger, fordi det i virkeligheden er lettere for devOps at vedligeholde et system med open source på en rå virtuel maskine end at forsøge at følge med Google med deres politik for at lukke «forældede» produkter.
Før jeg vender tilbage til Google Cloud, fordi jeg overhovedet ikke er tæt på Jeg er ikke færdig med at kritisere dem, lad os se på virksomhedens arbejde inden for nogle andre områder. Ingeniører hos Google er stolte af deres softwareudviklingsdisciplin, og det er netop det, der skaber problemer. Stolthed er en fælde for de uforsigtige, den har fået mange Google-ansatte til at tro, at deres løsninger altid er rigtige og at korrekthed (ifølge en eller anden vag og uspecificeret definition) er vigtigere end at tage sig af kunderne.
Lad mig give nogle vilkårlige eksempler fra andre store projekter uden for Google, men jeg håber, at I vil se denne skabelon overalt. Den handler om følgende: bagudkompatibilitet understøtter overlevelsen og relevansen af systemer i årtier..
Bagudkompatibilitet er et designmål for alle succesfulde systemer, der er tænkt til åben brug, det vil sige implementeret med open source og/eller på åbne standarder. Jeg føler, jeg siger noget for indlysende, som alle kan finde det ubehageligt, men nej. Det er et politisk spørgsmål, så der skal bruges eksempler.
Det første system, jeg vælger, er det ældste: GNU Emacs, det er en slags hybrid mellem Windows Notesblok, OS-kernen og Den Internationale Rumstation. Det er lidt svært at forklare, men kort sagt er Emacs en platform, der blev skabt i 1976 (ja, næsten for fem årtier siden) til programmering for at øge din produktivitet, men som camouflerer sig som en teksteditor.
Jeg bruger Emacs hver eneste dag. Ja, jeg bruger også IntelliJ hver dag, den er allerede blevet en kraftfuld værktøjsplatform i sig selv. Men at skrive udvidelser til IntelliJ er en meget mere ambitiøs og kompleks opgave end at skrive udvidelser til Emacs. Og endnu vigtigere, alt hvad der er skrevet til Emacs bevares for evigt..
Jeg bruger stadig software, som jeg skrev til Emacs tilbage i 1995. Og jeg er sikker på, at nogen stadig bruger moduler, der blev skrevet til Emacs i midten af 80'erne, hvis ikke tidligere. Af og til kan de kræve en mindre tilpasning, men det er virkelig ret sjældent. Jeg ved ikke noget af det, jeg nogensinde har skrevet til Emacs (og jeg har skrevet meget), som skulle have ombygget arkitekturen.
I Emacs findes der en funktion kaldet make-obsolete til forældede enheder. Terminologien i Emacs for grundlæggende computerkoncepter (for eksempel hvad et "vindue" er) adskiller sig ofte fra branchekonventionerne, fordi Emacs indførte dem for længe siden. Dette er en typisk fare for dem, der ligger foran deres tid: alle jeres udtryk er forkerte. Men i Emacs er der faktisk et koncept for forældelse, som i deres jargon kaldes forældelse.
Men i Emacs ser det ud til at være en anden arbejdsmæssig definition. En anden grundlæggende filosofi, hvis du vil.
I Emacs' verden (og i mange andre områder, vi vil dække nedenfor) betyder status for forældede API'er hovedsageligt: "Du bør virkelig ikke bruge denne tilgang, fordi selvom den fungerer, lider den under forskellige mangler, som vi vil opregne her. Men i sidste ende er det dit valg."
I Googles verden betyder status for et forældet produkt: "Vi bryder vores forpligtelser over for dig." Det er faktisk sådan. Det, dette i bund og grund betyder, er, at de vil tvinge dig til regelmæssigt at udføre noget arbejde, muligvis meget arbejde, som straf for at du troede på deres : vi har den bedste software. Den hurtigste! Du følger alle instruktionerne, starter din applikation eller tjeneste, og så—bam, om et år eller to går den ned.
Det svarer til at sælge en brugt bil, der helt sikkert går i stykker efter 1500 km.
Dette er to helt forskellige filosofiske definitioner af "forældelse". Googles definition lugter af . Jeg tror ikke, det er har vi virkelig planlagt forældelse i samme forstand som hos Apple. Men Google planlægger bestemt at knække dine programmer indirekte. Jeg ved det, fordi jeg har arbejdet der som softwareingeniør i over 12 år. De har uklare interne retningslinjer for, hvor meget man skal overholde bagudkompatibilitet, men i sidste ende afhænger det af hver enkelt team eller afdeling. Der er ingen anbefalinger på selskabs- eller ingeniørniveau, og den mest dristige anbefaling i forhold til forældelsescykler er "prøv at give kunderne 6-12 måneder til at opdatere, før du ødelægger hele deres system."
Problemet er langt mere alvorligt, end de tror, og det vil fortsætte i mange år, fordi kundeservice ikke er en del af deres DNA. Læs mere om dette nedenfor.
I øjeblikket vil jeg komme med en dristig påstand, at Emacs er i høj grad succesfuld, og endda hovedsageligt fordi de tager tilbagemeldinger om bagudkompatibilitet så alvorligt. Det er faktisk hovedpunkterne i vores artikel. Succesfulde, langvarige åbne systemer skylder deres succes til mikrosamfund, som har eksisteret i årtier omkring udvidelser/plugins.Det er økosystemet. Jeg har tidligere talt om essensen af platforme, hvor vigtige de er, og at Google aldrig i hele sin virksomhedshistorie har forstået, hvad der kræves for at skabe en succesfuld åben platform, bortset fra Android eller Chrome.
Faktisk bør jeg kort nævne Android, fordi du sikkert tænkte på det.
For det første, Android er ikke Google.De har næsten intet til fælles. Android er et firma, der blev købt af Google i juli 2005, og dette firma blev tilladt at operere mere eller mindre autonomt og har i virkeligheden været næsten uudviklet i de forgangne år. Android er en berygtet teknologisk stak og lige så berygtet en tornet organisation. Som en Google-medarbejder sagde, "man kan ikke bare gå ind i Android."
I en af mine tidligere artikler har jeg allerede diskuteret, hvor dårlige nogle af de tidlige designbeslutninger i Android var. Hold da op, da jeg skrev den artikel, havde de travlt med at implementere noget skidt kaldet "øjeblikkelige apps", som nu (overraskelse!) , og jeg beklager, hvis du var så dum at følge Googles råd og flytte dit indhold til disse øjeblikkelige apps.
Men der er en forskel, en væsentlig forskel, som er, at folk fra Android virkelig forstår, hvor vigtige platforme er, og de kæmper for at opretholde funktionaliteten af de gamle Android-apps. Faktisk er deres bestræbelser på at bevare bagudkompatibilitet så ekstreme, at jeg, under mit korte ophold i Android-afdelingen for et par år siden, fandt mig selv overbevise dem om at opgive støtte til nogle af de ældste enheder og API'er (jeg tog fejl, ligesom i mange andre ting fra fortid og nutid. Beklager, folk fra Android! Nu, hvor jeg har været i Indonesien, forstår jeg hvorfor de er nødvendige for os).
Folk fra Android opretholder bagudkompatibilitet til næsten uhåndterlige grænser, hvilket medfører en enorm mængde teknologisk gæld i deres systemer og værktøjskæder. Åh Gud, du skulle have set nogle af de skøre ting, de er nødt til at gøre i deres byggesystem, alt sammen i navnet kompatibilitet.
For dette tildeler jeg Android den eftertragtede pris "Du er ikke Google". De ønsker faktisk ikke at blive Google, som ikke kan skabe holdbare platforme, men Android kender, hvordan man gør det. Og derfor handler Google rigtig klogt på én måde: de lader folk i Android gøre det på deres egen måde.
Men instant apps til Android var en ret dum idé. Og ved du hvorfor? Fordi de krævede at omskrive og redesigne din app! Som om folk bare ville tage og omskrive to millioner apps. Jeg formoder, at instant apps var idéen fra en eller anden Googler.
Men her er forskellen. Bagudkompatibilitet medfører store omkostninger. Android selv bærer byrden af disse omkostninger, mens Google insisterer på, at det er dig, den betalende kunde.
Du kan se Androids engagement til bagudkompatibilitet i dens API-interfaces. Når du har fire eller fem forskellige undersystemer til at udføre stort set det samme, er det et sikkert tegn på, at der ligger et engagement i bagudkompatibilitet. Hvilket i platformverdenen er lig med engagement til dine kunder og dit marked.
Hovedproblemet for Google her er deres stolthed over deres ingeniørhygiejne. De kan ikke lide, når der er mange forskellige måder at gøre det samme på, hvor de gamle, mindre ønskværdige metoder sidder side om side med de nye, mere fantasifulde måder. Dette øger indlæringskurven for nybegyndere i systemet, det øger byrden ved at støtte forældede API'er, det bremser hastigheden af nye funktioner, og den største synd - det ser grimt ud. Google minder om Lady Escot fra Tim Burtons 'Alice in Wonderland':
Lady Escot:
— Alice, ved du, hvad jeg frygter mest?
— Faldet af aristokratiet?
— Jeg frygtede, at jeg ville få grimme børnebørn.
For at forstå kompromiset mellem smukt og praktisk, lad os se på den tredje succesfulde platform (efter Emacs og Android) og se, hvordan den fungerer: selve Java.
Der er masser af forældede API'er i Java. Forældelse er meget populært blandt Java-programmører, endda mere populært end i de fleste programmeringssprog. I selve Java, grundsproget og bibliotekerne, foregår der konstant forældelse af API'er.
Hvis vi kun ser på et af de tusinde eksempler, betragtes som forældet. Det har været forældet siden udgivelsen af Java 1.2 i december 1998. Der er gået 22 år, siden det blev forældet.
Men min reelle kode i produktionen dræber stadig tråde hver dag. Er det godt? Absolut! Jeg mener, selvfølgelig, hvis jeg skulle omskrive koden i dag, ville jeg gøre det anderledes. Men koden til mit spil, som de sidste to årtier har gjort hundredtusinder af mennesker glade, er skrevet med funktionen til at lukke tråde, som hænger for længe, og jeg har aldrig været nødt til at ændre det. Jeg kender mit system bedre end nogen, jeg har bogstaveligt talt 25 års erfaring med det i produktion, og jeg kan sige med sikkerhed: i mit tilfælde er det at lukke disse specifikke arbejdstråde helt harmløst. Det er ikke værd at spilde tid og ressourcer på at omskrive denne kode, og tak til Larry Ellison (måske), fordi Oracle ikke har tvunget mig til at omskrive det.
Måske forstår Oracle også platforme. Hvem ved.
Beviser kan findes i alle de nøgle Java API'er, der er gennemsyret af forældelsen, ligesom islinjerne i en kløft. I Java Swing-biblioteket kan man hurtigt finde fem eller seks forskellige tastaturnavigationschefer (KeyboardFocusManager). Det er faktisk svært at finde et Java API, der ikke er forældet. Men de fungerer stadig! Jeg tror, at Java-teamet kun vil fjerne API'er, hvis et interface skaber en åbenbar sikkerhedsproblematik.
Her er sagen, folkens: Vi, softwareudviklere, har alle meget travlt, og i hvert softwareområde står vi over for konkurrerende alternativer. På ethvert tidspunkt overvejer programmører i sprog X sprog Y som en potentiel erstatning. Åh, tror du ikke mig? Vil du nævne Swift? Som om alle migrerer til Swift og ingen giver det op, ikke? Wow, hvor lidt du ved. Virksomheder overvejer omkostningerne ved dobbelte mobile udviklingsteams (iOS og Android) - og de begynder at forstå, at disse tværplatformssystemer med sjove navne, såsom Flutter og React Native, virkelig virker, og at de kan halvere størrelsen af deres mobile teams eller derimod gøre dem dobbelt så produktive. Rigtige penge er på spil. Ja, der er kompromiser, men på den anden side, penge.
Lad os hypotetisk antage, at Apple i sin dumhed tog inspiration fra Guido van Rossum og erklærede, at Swift 6.0 ikke er bagudkompatibelt med Swift 5.0, ligesom Python 3 ikke er kompatibelt med Python 2.
Jeg har sikkert fortalt denne historie for ti år siden, men for femten år siden var jeg til O'Reilly's Foo Camp med Guido, sad i et telt med Paul Graham og en masse store navne. Vi sad i den kvælende varme og ventede på, at Larry Page skulle komme flyvende i sin private helikopter, mens Guido monoton mumlede om 'Python 3000', som han kaldte det, fordi det ville tage alle år at migrere dertil. Vi spurgte ham hele tiden, hvorfor han brød kompatibiliteten, og han svarede: 'Unicode'. Og vi spurgte, hvis vi skulle omskrive vores kode, hvilke andre fordele vi ville se? Og han svarede 'Yoooooooooooooouuuuuuuniiiiiiicoooooooode'.
Hvis du installerer Google Cloud Platform SDK ('gcloud'), vil du modtage følgende meddelelse:
Kære modtager,
Vi vil gerne minde dig om, at supporten til Python 2 er udgået, så gå dog blåbær!
… og så videre. Livets cyklus.
Men sagen er, at hver udvikler har et valg. Og hvis du får dem til at omskrive deres kode for ofte, kan de også overveje andre muligheder. De er ikke dine fanger, uanset hvor meget du ønsker det. De er dine gæster. Python er stadig et meget populært programmeringssprog, men, for pokker, Python 3(000) har skabt sådan et rod i sine fællesskaber og hos brugerne af disse fællesskaber, at konsekvenserne ikke kan rydde op i de sidste femten år.
Hvor mange Python-programmer er blevet omskrevet til Go (eller Ruby, eller et andet alternativ) på grund af denne bagudkompatibilitet? Hvor mange nye softwareløsninger er blevet skrevet på noget andet end Python, selvom det kunne have været skrevet i Python, hvis Guido ikke havde brændt hele landsbyen ned? Det er svært at sige, men Python har bestemt lidt. Det er et kæmpe rod, og alle taber.
Så lad os sige, at Apple følger Guids eksempel og bryder kompatibiliteten. Hvad tror du, der vil ske? Nå, måske 80-90% af udviklerne vil omskrive deres software, hvis det er muligt. Med andre ord, 10-20% af brugerbasen vælger automatisk et konkurrerende sprog, for eksempel Flutter.
Gør dette et par gange – og så mister du halvdelen af din brugerbase. Ligesom i sport betyder nuværende form også alt. Enhver, der mister halvdelen af brugerne på fem år, vil blive betragtet som en stor fed fiaskos. Du skal være på spidsen i platformenes verden. Men netop her vil manglende support til gamle versioner på sigt ødelægge dig. For hver gang du fjerner en del udviklere, (a) mister du dem for altid, fordi de er vrede på dig for at bryde kontrakten, og (b) giver dem til dine konkurrenter.
Ironisk nok hjalp jeg også Google med at blive sådan en diva, der ignorerer bagudkompatibilitet, når jeg skabte Grok, et system til analyse og forståelse af kildekode, der letter automatisering og udstyr baseret på selve koden – det ligner en IDE, men her opbevarer cloudtjenesten materialiserede visninger af alle milliarder linjer kildekode fra Google i et stort datalager.
Grok har givet Google-folkene en stærk basis for at udføre automatiseret refactoring på tværs af hele kodebasen (bogstaveligt talt i hele Google). Systemet beregner ikke kun dine opadgående afhængigheder (som du er afhængig af), men også nedadgående (som er afhængige af dig), så når API'et ændres, ved du, hvem du bryder! På den måde kan du ved ændringer tjekke, at hver forbruger af dit API er opdateret til den nye version, og faktisk kan du ofte fuldautomatisere processen med værktøjet Rosie, som de har lavet.
Dette gør, at Google-kodebasen indeni er næsten overnaturligt "ren", da de har disse robotter, der suser rundt i huset og automatisk rydder op, hvis de omdøber SomeDespicablyLongFunctionName til SomeDespicablyLongMethodName, fordi nogen besluttede, at det var et grimt barnebarn, der skulle aflive.
Og, ærligt talt, det fungerer ret godt for Google... internt. Jeg mener, ja, Go-samfundet i Google har virkelig en venlig latter på bekostning af Java-samfundet i Google på grund af deres vane til konstant refactoring. Hvis du genstarter noget N gange, så betyder det, at du ikke kun har ødelagt det N-1 gange, men efter et stykke tid bliver det helt klart, at du sandsynligvis også har ødelagt det med den N-te gang. Men i det store hele forbliver de over denne nedbrydning og holder koden "ren".
Problemerne begynder, når de forsøger at påtvinge en sådan tilgang til deres cloud-kunder og brugere af andre API'er.
Jeg har givet dig en smule introduktion til Emacs, Android og Java; lad os se på den seneste succesfulde, langtidsholdbare platform: selve webben. Kan du forestille dig, hvor mange iterationer HTTP har været igennem siden 1995, da vi brugte blinkende tags og "Under udvikling" ikoner på websider.
Men det virker stadig! Og disse sider fungerer stadig! Ja, folkens, browsere er verdensmestre i bagudkompatibilitet. Chrome er endnu et eksempel på en sjælden Google-platform, hvor hovederne er skruet korrekt på, og som du gættede, fungerer Chrome effektivt som et isoleret selskab adskilt fra resten af Google.
Jeg vil også gerne takke vores venner blandt operativsystemudviklerne: Windows, Linux, IKKE APPLE GÅ DIT APPLE, FreeBSD osv. for det store arbejde, de har gjort med tilbagekompatibilitet på deres succesfulde platforme (Apple får i bedste fald en tre med minus, da de konstant ødelægger alt uden nogen respektable grunde, men på en eller anden måde klarer fællesskabet dette i hver udgivelse, og indtil videre er containere med OS X stadig ikke helt forældede… endnu).
Men vent lidt, siger du. Sammenligner vi ikke æbler med appelsiner - autonome software-systemer på én maskine, såsom Emacs/JDK/Android/Chrome, med multiserver-systemer og API'er ligesom i cloud-tjenester?
Nå, jeg skrev om dette i går på Twitter, men i stil med Larry Wall (skaberen af programmeringssproget Perl - bemærkningen til oversætteren) med princippet "lort/rul", så jeg søgte efter ordet deprecated på udviklerwebstederne hos Google og Amazon. Og selvom AWS har hundrede gange flere tilbud end GCP, nævner Google-developer-dokumentationen forældelse omkring syv gange oftere.
Hvis nogen fra Google læser dette, så er de sikkert klar til at trække diagrammer op, der viser i Donald Trumps stil, at de faktisk gør alt rigtigt, og at jeg ikke skal lave uretfærdige sammenligninger som "antallet af omtaler af ordet deprecated i forhold til antallet af tjenester."
Men efter så mange år forbliver Google Cloud stadig service nr. 3 (jeg har ikke fået skrevet artiklen om det mislykkede forsøg på at blive nr. 2), men hvis man skal tro på insidere, er der nogle bekymringer om, at de måske snart kan falde til nr. 4.
Jeg har ikke stærke argumenter til at "bevise" min påstand. Alt, hvad jeg har, er farverige eksempler, som jeg har samlet over 30 års arbejde som udvikler. Jeg har allerede nævnt den dybt filosofiske natur af dette problem; på en måde er det politiseret i udviklersamfundene. Nogle mener, at platformskaberne skal tage sig af kompatibiliteten, mens andre mener, at det er brugernes ansvar (selv udviklerne). Enten det ene eller det andet. Og i virkeligheden, er det ikke et politisk spørgsmål, når vi beslutter, hvem der skal bære omkostningerne ved fælles problemer?
Så det er politik. Og der vil uden tvivl komme vrede svar på mit indlæg.
siger bruger Som bruger af AWS i to år (mens jeg arbejdede hos Grab) og med erfaring fra Google Cloud-platformen, kan jeg sige, at der er en kæmpe forskel mellem Amazon og Googles filosofi, når det kommer til prioriteter. Jeg er ikke aktivt udvikler på AWS, så jeg ved ikke, hvor ofte de fjerner gamle API'er. Men jeg har en mistanke om, at det ikke sker så ofte som hos Google. Jeg tror oprigtigt, at denne kilde til konstant debat og frustration i GCP er en af de største faktorer, der hæmmer platformens udvikling.
Jeg ved, at jeg ikke har nævnt konkrete eksempler på systemer i GCP, hvis støtte er blevet ophørt. Jeg kan sige, at stort set alt, hvad jeg har brugt, fra netværk (fra de ældste til VPC) til lagringsløsninger (Cloud SQL v1-v2), Firebase (nu Firestore med en helt anden API), App Engine (lad os ikke engang komme ind på det), Cloud Endpoint og... jeg ved ikke — absolut alt dette tvang mig til at omskrive koden senest hvert 2-3 år, og de har aldrig automatiseret migreringen for dig, og ofte . Som om det var meningen.
Hver gang jeg ser på AWS, spørger jeg mig selv, hvad i alverden jeg stadig laver på GCP. De har åbenlyst ikke brug for kunder. De har brug for købere. Forstår du forskellen? Lad mig forklare.
Google Cloud har en , hvor folk tilbyder deres softwareløsninger, og for at undgå effekten af en tom restaurant var de nødt til at fylde det med nogle tilbud, så de indgik kontrakt med Bitnami for at skabe en masse løsninger, der kan implementeres "med et enkelt klik", eller også skal jeg selv skrive "løsninger", fordi de her slet ikke løser noget. De eksisterer bare som markører, som marketingfyld, og Google har aldrig bekymret sig om, hvorvidt nogen af værktøjerne rent faktisk fungerer. Jeg kender produktchefer, der har været ved roret, og jeg kan forsikre dig, at disse mennesker ikke giver en dyt.
Lad os tage et eksempel med en løsning, der angiveligt kan implementeres "med et enkelt klik" . Jeg er dødtræt af Google Cloud SQL's narrestreger, så jeg begyndte at overveje at opbygge mit eget Percona-kluster som alternativ. Og denne gang gjorde Google tilsyneladende noget godt, de havde tænkt sig at spare mig lidt tid og kræfter med et enkelt klik!
Nå godt, lad os komme i gang. Vi går videre til linket og trykker på denne knap. Vi vælger "Ja" for at acceptere alle standardindstillinger og implementere klyngen i vores Google Cloud-projekt. Ha-ha, det virker ikke. Intet af dette skrammel fungerer. Værktøjet er aldrig blevet testet, og det begyndte at rådne fra første minut, og jeg ville ikke blive overrasket, hvis mere end halvdelen af "løsningerne" til kørsel med ét klik (nu forstår vi, hvorfor der er citationstegn) overhovedet ikke fungerer. Det er et fuldstændigt dystert sted, man hellere ikke skal træde ind i.
Men Google opfordrer direkte dig til at bruge dem. De ønsker, at du skal købe. For dem er det en transaktion. De ønsker ikke at supportere. Det er ikke en del af Googles DNA. Ja, ingeniørerne støtter hinanden, som min historie med Bigtable viser. Men i produkter og tjenester til almindelige mennesker har de altid været nådesløse i , der ikke lever op til profit-kriterierne, selvom den har millioner af brugere.
Og dette udgør et reelt problem for GCP, fordi denne DNA ligger bag alle cloud-tilbud. De stræber ikke efter at supportere noget; det er velkendt, at de nægter at hoste (som en administreret tjeneste) enhver tredjeparts software indtil, at AWS gør det samme og bygger omkring en succesfuld forretning, og når kunderne bogstaveligt talt kræver det samme. Men der skal gøres en indsats for at få Google til at supportere noget.
Denne mangel på supportkultur, kombineret med princippet "lad os bryde det for at gøre det smukkere," fremmedgør udviklere fra dem.
Og det er ikke særlig godt, hvis du vil bygge en langtidsholdbar platform.
Google, vågn op, for fanden. Det er 2020 nu. Du taber stadig. Det er tid til at se nøje i spejlet og svare, om du virkelig ønsker at forblive i cloud-forretningen.
Hvis du vil forblive, så stop med at ødelægge alt.Folkens, I er rige. Vi, udviklerne - ikke. Så når det kommer til, hvem der skal bære byrden for kompatibilitet, er det jer, I skal tage ansvar for. Ikke os.
For der er stadig mindst tre virkelig gode cloud-løsninger. De tiltrækker folk.
Og nu vil jeg gå videre med at reparere alle mine ødelagte systemer. Sejt.
Indtil næste gang!
P. S. Opdatering efter at have læst nogle af diskussionerne omkring denne artikel (diskussionerne er fantastiske, for øvrigt). Supporten for Firebase er ikke blevet afbrudt, og der er ingen planer, som jeg kender til. Dog har de et uheldigt fejl i streaming, som får Java-klienten til at stoppe på App Engine. En af deres ingeniører hjalp mig med at løse det problem, da jeg arbejdede hos Google, men de har aldrig reelt løst fejlen, så jeg har en temmelig klodset workaround, hvor jeg skal genstarte GAE-applikationen hver dag. Og det har stået på i fire år! Nu har de Firestore. Det vil kræve meget arbejde at migrere til det, da det er et helt andet system, og Firebase-fejlen vil aldrig blive rettet. Hvad kan vi konkludere? Du kan få hjælp, hvis du arbejder i et firma. Jeg er nok den eneste, der bruger Firebase på GAE, fordi jeg registrerer mindre end 100 nøgler i en 100 % indfødte applikation, og den stopper med at fungere hver anden dag på grund af den kendte fejl. Hvad kan man sige andet end at bruge det på egen risiko. Jeg skifter til Redis.
Jeg har også set, at nogle mere erfarne AWS-brugere siger, at AWS normalt aldrig stopper understøttelsen af nogen tjenester, og SimpleDB er et glimrende eksempel. Mine antagelser om, at der ikke er den samme risiko for at miste support i AWS som hos Google, ser ud til at være berettigede.
Derudover har jeg bemærket, at for 20 dage siden brød Google App Engine-teamet hosting af et kritisk Go-bibliotek ved at lukke GAE-applikationen fra en af de primære Go-udviklere. Det er virkelig dumt.
Endelig har jeg hørt, at Googlerne allerede diskuterer dette spørgsmål og generelt er enige med mig (jeg elsker jer, folk!). Men det ser ud til, at de betragter problemet som uløseligt, fordi der i Googles kultur aldrig har været en ordentlig struktur for incitamenter. Jeg synes, det ville være godt at finde tid til at diskutere den helt fantastiske oplevelse, jeg havde med AWS-ingeniører, da jeg arbejdede i firmaet Grab. Måske en dag i fremtiden, håber jeg!
Ja, i 2005 var der faktisk forskellige slags hajkød på den kæmpemæssige buffet i bygning 43, og jeg kunne bedst lide kød fra hammerhajer. Men i 2006 fjernede Larry og Sergey alle usunde snacks. Så der var virkelig ingen hajer under historien om Bigtable i 2007, og jeg har svigtet dig.
Da jeg kiggede på den cloud-baserede Bigtable for omkring fire år siden (plus/minus), var prisen lige sådan. Det ser ud til, at den nu er faldet en smule, men det er stadig alt for meget for tom datalagring, især når min første historie viser, hvor ubetydelig en tom stor tabel er i deres målestok.
Undskyld, hvis jeg har såret Apple-fællesskabet og ikke har sagt noget godt om Microsoft osv. I er alle ret, jeg værdsætter virkelig alle diskussioner, som denne artikel har givet anledning til! Men nogle gange skal man røre lidt i gryden for at starte en diskussion, forstår I hvad jeg mener?
Tak for læsningen.
Opdatering 2, 19.08.2020. Stripe !
Opdatering 3, 31.08.2020. En Google-ingeniør fra Cloud Marketplace kontaktede mig, og han viste sig at være min gamle ven. Han ville finde ud af, hvorfor C2D ikke virkede, og til sidst fandt vi ud af, at årsagen var, at jeg havde oprettet mit netværk for flere år siden, og C2D fungerer ikke på forældede netværk på grund af manglende subnetparameter i deres skabeloner. Jeg tror, at potentielle GCP-brugere bedre bør sikre sig, at de har tilstrækkeligt bekendte ingeniører hos Google ...
Kilde: habr.com
