For fanden Google, jeg gad ikke blogge igen. Jeg har så meget at lave. Blogging tager tid, energi og kreativitet, som jeg godt kunne bruge: mine bøger, , mit spil og så videre. Men du har irriteret mig nok til, at jeg er nødt til at skrive dette.
Så lad os få det overstået.
Lad mig starte med en kort, men lærerig historie fra da jeg begyndte at arbejde hos Google. Jeg ved godt, at jeg har sagt mange dårlige ting om Google på det seneste, men det gør mig ked af det, når min egen virksomhed regelmæssigt træffer inkompetente forretningsbeslutninger. Samtidig må vi give det sin ret: Googles interne infrastruktur er virkelig ekstraordinær, man kan roligt sige, at der ikke er noget bedre i dag. Grundlæggerne af Google var meget bedre ingeniører, end jeg nogensinde vil være, og denne historie bekræfter kun det faktum.
Først en lille baggrund: Google har en datalagringsteknologi kaldet . Det var en bemærkelsesværdig teknisk præstation, en af de første (hvis ikke den første) "uendeligt skalerbare" nøgleværdilager (K/V): i det væsentlige begyndelsen af NoSQL. I disse dage klarer Bigtable sig stadig godt i den ret overfyldte K/V-lagerplads, men dengang (2005) var det fantastisk fedt.
En sjov ting ved Bigtable er, at de havde interne kontrolplanobjekter (som en del af implementeringen) kaldet tablet-servere, med store indekser, og på et tidspunkt blev de en flaskehals ved skalering af systemet. Bigtable-ingeniører undrede sig over, hvordan de skulle implementere skalerbarhed, og indså pludselig, at de kunne erstatte tablet-servere med anden Bigtable-lagring. Så Bigtable er en del af Bigtable-implementeringen. Disse lagerfaciliteter er der på alle niveauer.
En anden interessant detalje er, at Bigtable i et stykke tid blev populær og allestedsnærværende i Google, hvor hvert hold havde sit eget lager. Så ved et af fredagsmøderne spurgte Larry Page henkastet i forbifarten: "Hvorfor har vi mere end ét Bigtable? Hvorfor ikke kun én?” I teorien burde én lagerplads være nok til alle Googles lagerbehov. Selvfølgelig gik de aldrig til kun én af praktiske udviklingsmæssige årsager (som konsekvenserne af en potentiel fiasko), men teorien var interessant. Et lager for hele universet (Forresten, er der nogen, der ved, om Amazon gjorde dette med deres Sable?)
Anyway, her er min historie.
På det tidspunkt havde jeg arbejdet hos Google i lidt over to år, og en dag modtog jeg en e-mail fra Bigtable-ingeniørteamet, der lød sådan her:
Kære Steve,
Hej fra Bigtable-teamet. Vi vil gerne informere dig om, at du på [datacenternavn] bruger en meget, meget gammel Bigtable-binær. Denne version understøttes ikke længere, og vi vil gerne hjælpe dig med at opgradere til den nyeste version.
Fortæl mig venligst, hvis du kan planlægge lidt tid til at arbejde sammen om dette problem.
Alt det bedste,
Bigtable Team
På Google får man en masse mail, så ved første øjekast læser jeg noget som dette:
Kære modtager,
Hej fra et hold. Det vil vi gerne kommunikere bla bla bla bla bla. Bla bla bla bla bla bla, og bla bla bla med det samme.
Lad os venligst vide, hvis du kan planlægge noget af din dyrebare tid til bla bla bla.
Alt det bedste,
En slags kommando
Jeg slettede det næsten med det samme, men på kanten af min bevidsthed følte jeg en smertefuld, nagende følelse af, at det ikke rigtig ligner dog et formelt brev naturligvis, at modtageren tog fejl, fordi jeg ikke brugte Bigtable.
Men det var mærkeligt.
Jeg brugte resten af dagen på skiftevis 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å at slå fra min plads med et velrettet kast af en kiks, men Tanken på at skrive efterlod mig aldrig med en voksende følelse af mild angst.
De sagde tydeligt mit navn. Og e-mailen blev sendt til min e-mailadresse, ikke en andens, og det er ikke cc: eller bcc:. Tonen er meget personlig og klar. Måske er dette en form for fejl?
Endelig fik nysgerrigheden overhånd, og jeg gik for at se på Borg-konsollen i det datacenter, de nævnte.
Og selvfølgelig havde jeg BigTable-lagring under administration. Jeg er ked af det, hvad? Jeg kiggede på indholdet, og wow! Det var fra Codelab-inkubatoren, jeg sad i i løbet af min første uge hos Google i juni 2005. Codelab tvang dig til at køre Bigtable for at skrive nogle værdier der, og jeg lukkede tilsyneladende aldrig lageret efter det. Det virkede 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 Bigtables arbejde så ubetydeligt på Googles skala, at kun to år senere bemærkede nogen den ekstra lagerplads, og kun fordi versionen af den binære version var forældet. Til sammenligning overvejede jeg engang at bruge til mit online spil. På det tidspunkt kostede denne service cirka 16 USD om året. tom Bigtable på GCP. Jeg siger ikke, at de snyder dig, men efter min personlige mening er det mange penge for en tom forbandet database.
Et andet bemærkelsesværdigt aspekt er, at opbevaringen arbejder stadig efter to år. WTF? Datacentre kommer og går; de oplever udfald, de gennemgår planlagt vedligeholdelse, de skifter hele tiden. Hardware opdateres, switches byttes, alt bliver konstant forbedret. Hvordan fanden var de i stand til at holde mit program kørende i to år med alle disse ændringer? Dette kan virke som en beskeden præstation i 2020, men i 2005-2007 var det ganske imponerende.
Og det mest vidunderlige aspekt er, at et eksternt ingeniørteam i en anden stat henvender sig til mig, ejeren af en lille, næsten tom forekomst af Bigtable, som har nul trafik de seneste to år - og tilbyder hjælp til at opdatere den.
Jeg takkede dem, slettede lageret, og livet fortsatte som normalt. Men tretten år senere tænker jeg stadig på det brev. For nogle gange modtager jeg lignende e-mails fra Google Cloud. De ser sådan ud:
Kære Google Cloud-bruger
Som en påmindelse vil vi afbryde tjenesten [essentiel tjeneste, du bruger] fra august 2020, hvorefter du ikke vil være i stand til at opgradere dine forekomster. Vi anbefaler at opgradere til den seneste version, som er i beta-testning, har ingen dokumentation, ingen migrationssti og er tidligere forældet med vores venlige hjælp.
Vi er forpligtet til at sikre, at denne ændring har minimal indvirkning på alle brugere af Google Cloud-platformen.
Bedste venner for evigt,
Google Cloud Platform
Men jeg læser næsten aldrig sådanne breve, for hvad de faktisk siger er:
Kære modtager,
Gå ad helvede til. Fuck dig, fuck dig, fuck dig. Drop alt, hvad du gør, fordi det er ligegyldigt. Det, der betyder noget, er vores tid. Vi spilder tid og penge på at vedligeholde vores lort, og vi er trætte af det, så vi vil ikke støtte det længere. Så hold op med dine skide planer og begynd at grave igennem vores lorte dokumentation, tigge om stykker på foraene, og forresten, vores nye lort er helt anderledes end det gamle lort, fordi vi har ødelagt det her design ret dårligt, heh, men det er dit problem, ikke vores.
Vi bestræber os fortsat på at sikre, at alle dine udviklinger bliver ubrugelige inden for et år.
Vær venlig at kneppe af
Google Cloud Platform
Og faktum er, at jeg modtager sådanne breve cirka en gang om måneden. Dette sker så ofte og så konstant, at de uundgåeligt skubbet væk mig fra GCP til anti-sky-lejren. Jeg er ikke længere enig i at være afhængig af deres proprietære udvikling, for faktisk er det lettere for devops at vedligeholde et open source-system på en bar virtuel maskine end at forsøge at følge med Googles politik om at lukke "forældede" produkter.
Før jeg går tilbage til Google Cloud, fordi jeg ikke engang tæt på ikke færdig med at kritisere dem, lad os se på virksomhedens præstationer på nogle andre områder. Googles ingeniører er stolte af deres softwareingeniørdisciplin, og det er det, der faktisk forårsager problemer. Stolthed er en fælde for de uforsigtige, og det har fået mange Google-medarbejdere til at tro, at deres beslutninger altid er rigtige, og at det er vigtigere at have ret (af en eller anden vag uklar definition) end at bekymre sig om kunderne.
Jeg vil give nogle tilfældige eksempler fra andre store projekter uden for Google, men jeg håber, du ser dette mønster overalt. Det er som følger: bagudkompatibilitet holder systemerne i live og opdaterede i årtier.
Bagudkompatibilitet er designmålet for alle vellykkede systemer designet til åbent brug, det vil sige implementeret med åben kildekode og/eller åbne standarder. Jeg føler, at jeg siger noget for tydeligt, at alle er ubehagelige, men nej. Det er et politisk spørgsmål, så der er brug for eksempler.
Det første system, jeg vil vælge, er det ældste: GNU Emacs, som er en slags hybrid mellem Windows Notesblok, OS-kernen og den internationale rumstation. Det er lidt svært at forklare, men i en nøddeskal er Emacs en platform skabt i 1976 (ja, næsten et halvt århundrede siden) til programmering for at gøre dig mere produktiv, men forklædt som en teksteditor.
Jeg bruger Emacs hver eneste dag. Ja, jeg bruger også IntelliJ hver dag, det er vokset til 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 skrevet til Emacs er bevaret evigt.
Jeg bruger stadig den software, jeg skrev til Emacs tilbage i 1995. Og jeg er sikker på, at nogen bruger moduler skrevet til Emacs i midten af 80'erne, hvis ikke tidligere. De kan kræve lidt tweaking fra tid til anden, men dette er egentlig ret sjældent. Jeg kender ikke til noget, jeg nogensinde har skrevet til Emacs (og jeg har skrevet meget), som krævede en re-arkitektur.
Emacs har en funktion kaldet make-obsolete for forældede enheder. Emacs terminologi for grundlæggende computerkoncepter (såsom hvad et "vindue" er) adskiller sig ofte fra industrikonventioner, fordi Emacs introducerede dem for lang tid siden. Dette er en typisk fare for dem, der er forud for deres tid: alle dine udtryk er forkerte. Men Emacs har et begreb om deprecation, som i deres jargon kaldes forældelse.
Men i Emacs-verdenen synes der at være en anden arbejdsdefinition. En anden underliggende filosofi, om man vil.
I Emacs-verdenen (og på mange andre områder, som vi vil dække nedenfor), betyder forældet API-status dybest set: "Du bør virkelig ikke bruge denne tilgang, for mens den virker, lider den af forskellige mangler, som vi vil liste her. Men i sidste ende er det dit valg."
I Googles verden betyder det at være forældet: "Vi bryder vores forpligtelse over for dig." Det er rigtigt. Dette er, hvad det grundlæggende betyder. Det betyder, at de vil tvinge dig regelmæssigt gøre noget arbejde, måske meget arbejde, som straf for at tro på dem : Vi har den bedste software. Den hurtigste! Du gør alt i henhold til instruktionerne, starter din applikation eller tjeneste, og så går den i stykker efter et år eller to.
Det er som at sælge en brugt bil, der helt sikkert går i stykker efter 1500 km.
Disse er to helt forskellige filosofiske definitioner af "forældelse." Googles definition af lugt . Jeg tror ikke på det her faktisk planlagt forældelse i samme forstand som Apple. Men Google planlægger bestemt at bryde dine programmer på en omvej. Jeg ved det, fordi jeg arbejdede der som softwareingeniør i over 12 år. De har vage interne retningslinjer for, hvor meget bagudkompatibilitet der skal følges, men det er i sidste ende op til hvert enkelt team eller service. Der er ingen anbefalinger på virksomheds- eller ingeniørniveau, og den dristigeste anbefaling med hensyn til forældelsescyklusser er "prøv at give kunderne 6-12 måneder til at opgradere, før de ødelægger hele deres system."
Problemet er meget større, end de tror, og det vil vare ved i mange år fremover, fordi kundepleje ikke er i deres DNA. Mere om dette nedenfor.
På dette tidspunkt vil jeg komme med en dristig erklæring om, at Emacs har succes i vid udstrækning og endda dybest set fordi de tager bagudkompatibilitet så alvorligt. Faktisk er dette afhandlingen i vores artikel. Succesfulde åbne systemer med lang levetid skylder deres succes de mikrosamfund, der har levet omkring dem i årtier udvidelser/plugins. Dette er økosystemet. Jeg har allerede talt om karakteren af platforme, og hvor vigtige de er, og hvordan Google aldrig i hele sin virksomhedshistorie har forstået, hvad der ligger til grund for at skabe en vellykket åben platform uden for Android eller Chrome.
Faktisk bør jeg nævne Android kort, fordi du sikkert tænker på det.
For det første har Android er ikke Google. De har næsten intet til fælles med hinanden. Android er en virksomhed, der blev købt af Google i juli 2005, virksomheden fik lov til at operere mere eller mindre selvstændigt og har faktisk forblevet stort set urørt i de mellemliggende år. Android er en berygtet teknologisk stak og en lige så berygtet stikkende organisation. Som en Googler sagde det: "Du kan ikke bare logge ind på Android."
I en tidligere artikel diskuterede jeg, hvor dårlige nogle af Androids tidlige designbeslutninger var. For pokker, da jeg skrev den artikel, udrullede de lort kaldet "instant apps", som nu er (overraskelse!) , og jeg sympatiserer, hvis du var dum nok til at lytte til Google og flytte dit indhold til disse instant-apps.
Men der er en forskel her, en væsentlig forskel, som er, at Android-folkene virkelig forstår, hvor vigtige platforme er, de prøver deres bedste for at holde gamle Android-apps i gang. Faktisk er deres bestræbelser på at opretholde bagudkompatibilitet så ekstreme, at selv jeg, under mit korte ophold i Android-divisionen for et par år siden, fandt mig selv i at prøve at overbevise dem om at droppe støtten til nogle af de ældste enheder og API'er (jeg tog fejl , som det var i mange andre ting tidligere og nutid. Undskyld Android gutter! Nu hvor jeg har været i Indonesien, forstår jeg, hvorfor vi har brug for dem).
Android-folkene skubber baglæns kompatibilitet til næsten ufattelige yderpunkter og samler enorme mængder af ældre teknisk gæld op i deres systemer og værktøjskæder. Åh min gud, du burde se nogle af de skøre ting, de skal gøre i deres byggesystem, alt sammen i kompatibilitetens navn.
For dette tildeler jeg Android den eftertragtede "You're Not Google"-pris. De vil virkelig ikke blive Google, som ikke ved, hvordan man laver holdbare platforme, men Android kender, hvordan gør man det. Og så Google er meget smart i én henseende: at give folk mulighed for at gøre tingene på deres egen måde på Android.
Instant apps til Android var dog en ret dum idé. Og ved du hvorfor? Fordi de forlangte omskriv og redesign din ansøgning! Det er, som om folk blot vil omskrive to millioner ansøgninger. Jeg gætter på, at Instant Apps var en Googlers idé.
Men der er en forskel. Bagudkompatibilitet har en høj pris. Android bærer selv byrden af disse omkostninger, mens Google insisterer på, at byrden skal bæres du er, betalende kunde.
Du kan se Androids forpligtelse til bagudkompatibilitet i dets API'er. Når du har fire eller fem forskellige undersystemer, der bogstaveligt talt gør det samme, er det et sikkert tegn på, at der er en forpligtelse til bagudkompatibilitet i kernen. Hvilket i platformernes verden er synonymt med engagement i dine kunder og dit marked.
Googles største problem her er deres stolthed over deres tekniske hygiejne. De kan ikke lide det, når der er mange forskellige måder at gøre det samme på, hvor de gamle, mindre ønskværdige måder sidder ved siden af de nye, mere avancerede måder. Det øger indlæringskurven for dem, der er nye i systemet, det øger byrden ved at vedligeholde ældre API'er, det sænker hastigheden af nye funktioner, og hovedsynden er, at det ikke er kønt. Google - ligesom Lady Ascot fra Tim Burtons Alice in Wonderland:
Lady Ascot:
- Alice, ved du, hvad jeg er mest bange for?
- Aristokratiets forfald?
- Det var jeg bange for, at jeg ville have grimme børnebørn.
For at forstå afvejningen mellem smuk og praktisk, lad os tage et kig på den tredje succesrige platform (efter Emacs og Android) og se, hvordan den fungerer: Java selv.
Java har mange forældede API'er. Afskrivning er meget populær blandt Java-programmører, endda mere populær end i de fleste programmeringssprog. Java selv, kernesproget og bibliotekerne udfaser konstant API'er.
For blot at tage ét af tusindvis af eksempler, anses for forældet. Det er blevet forældet siden udgivelsen af Java 1.2 i december 1998. Det er 22 år siden, at dette blev forældet.
Men min egentlige kode i produktionen dræber stadig tråde hver dag. Synes du virkelig, det er godt? Absolut! Jeg mener selvfølgelig, at hvis jeg skulle omskrive koden i dag, ville jeg implementere den anderledes. Men koden til mit spil, som har gjort hundredtusindvis af mennesker glade i løbet af de sidste to årtier, er skrevet med en funktion til at lukke tråde, der hænger for længe, og jeg aldrig skulle ændre det. Jeg kender mit system bedre end nogen anden, jeg har bogstaveligt talt 25 års erfaring med at arbejde med det i produktionen, og jeg kan med sikkerhed sige: i mit tilfælde er det fuldstændigt at lukke disse specifikke arbejdstråde uskadelig. Det er ikke tiden og anstrengelserne værd at omskrive denne kode, og tak Larry Ellison (sandsynligvis), at Oracle ikke tvang mig til at omskrive den.
Oracle forstår sikkert også platforme. Hvem ved.
Beviser kan findes i hele Java-API'erne, som er fyldt med bølger af forældelse, som linjerne på en gletsjer i en canyon. Du kan nemt finde fem eller seks forskellige tastaturnavigationsmanagere (KeyboardFocusManager) i Java Swing-biblioteket. Det er faktisk svært at finde en Java API, der ikke er forældet. Men de virker stadig! Jeg tror, at Java-teamet kun virkelig vil fjerne en API, hvis grænsefladen udgør et grelt sikkerhedsproblem.
Her er sagen, folkens: Vi softwareudviklere har alle meget travlt, og på alle områder af software står vi over for konkurrerende alternativer. På ethvert givet tidspunkt overvejer programmører i sprog X sprog Y som en mulig erstatning. Åh, tror du mig ikke? Vil du kalde det Swift? Som om alle migrerer til Swift, og ingen forlader det, ikke? Wow, hvor ved du lidt. Virksomheder tæller omkostningerne ved dobbelte mobiludviklingsteams (iOS og Android) - og de er begyndt at indse, at disse udviklingssystemer på tværs af platforme med sjove navne som Flutter og React Native faktisk fungerer og kan bruges til at reducere størrelsen af deres mobile teams to gange eller omvendt gøre dem dobbelt så produktive. Der er rigtige penge på spil. Ja, der er kompromiser, men på den anden side penge.
Lad os hypotetisk antage, at Apple tåbeligt tog et signal fra Guido van Rossum og erklærede, at Swift 6.0 er bagudinkompatibel med Swift 5.0, ligesom Python 3 er inkompatibel med Python 2.
Jeg fortalte sikkert denne historie for omkring ti år siden, men for omkring femten år siden tog jeg til O'Reilly's Foo Camp med Guido, sad i et telt med Paul Graham og en masse store skud. Vi sad i den kvælende varme og ventede på, at Larry Page skulle flyve ud i sin personlige helikopter, mens Guido drønede videre omkring "Python 3000", som han navngav efter det antal år, det ville tage for alle at migrere dertil. Vi blev ved med at spørge ham, hvorfor han brød kompatibiliteten, og han svarede: "Unicode." Og vi spurgte, hvis vi skulle omskrive vores kode, hvilke andre fordele ville vi så se? Og han svarede "Yooooooooooooouuuuuuuniiiiiiiicooooooooode."
Hvis du installerer Google Cloud Platform SDK ("gcloud"), modtager du følgende meddelelse:
Kære modtager,
Vi vil gerne minde dig om, at support til Python 2 er blevet forældet, så fuck dig
… og så videre. Livets cirkel.
Men pointen er, at enhver udvikler har et valg. Og hvis du tvinger dem til at omskrive koden ofte nok, kan de måske tænke sig om andre muligheder. De er ikke dine gidsler, uanset hvor meget du ønsker, at de skal være. De er dine gæster. Python er stadig et meget populært programmeringssprog, men for fanden, Python 3(000) skabte så meget rod i sig selv, i dets fællesskaber og blandt brugerne af dets fællesskaber, at konsekvenserne ikke er blevet ryddet op i femten år.
Hvor mange Python-programmer er blevet omskrevet i Go (eller Ruby eller et andet alternativ) på grund af denne baglæns inkompatibilitet? Hvor meget ny software er der skrevet i noget andet end Python, selvom det kunne være skrevet i Python, hvis ikke Guido havde brændt hele landsbyen ned? Det er svært at sige, men Python har tydeligvis lidt. Det er et kæmpe rod, og alle taber.
Så lad os sige, at Apple tager et signal fra Guido og bryder kompatibiliteten. Hvad tror du vil ske næste gang? Nå, måske vil 80-90% af udviklerne omskrive deres software, hvis det er muligt. Med andre ord går 10-20% af brugerbasen automatisk til et eller andet konkurrerende sprog, såsom Flutter.
Gør dette flere gange, og du vil miste halvdelen af din brugerbase. Ligesom i sport, i programmeringsverdenen, betyder den nuværende form også noget. alle. Enhver, der mister halvdelen af deres brugere på fem år, vil blive betragtet som en Big Fat Loser. Du skal være trendy i platformens verden. Men det er her, at manglende understøttelse af ældre versioner vil ødelægge dig over tid. For hver gang du skiller dig af med nogle udviklere, (a) mister du dem for altid, fordi de er vrede på dig for at bryde kontrakten, og (b) giver dem væk til dine konkurrenter.
Ironisk nok hjalp jeg også Google med at blive sådan en primadonna, der ignorerer bagudkompatibilitet, da jeg skabte Grok, et kildekodeanalyse- og forståelsessystem, der gør det nemt at automatisere og instrumentere selve koden - svarende til en IDE, men her gemmer cloud-tjenesten materialiserede repræsentationer af alle milliarder af linjer med Google-kildekode i et stort datavarehus.
Grok gav Googlere en kraftfuld ramme til at udføre automatiserede refactorings på tværs af hele deres kodebase (bogstaveligt talt i hele Google). Systemet beregner ikke kun dine upstream-afhængigheder (som du er afhængig af), men også aftagende (som er op til dig), så når du ændrer API'er, kender du alle, du bryder! På denne måde, når du foretager ændringer, kan du verificere, at hver forbruger af din API har opdateret til den nye version, og i virkeligheden kan du, ofte med Rosie-værktøjet, de skrev, fuldstændig automatisere processen.
Dette gør det muligt for Googles kodebase at være internt næsten overnaturligt ren, da de har disse robottjenere, der suser rundt i huset og automatisk rydder alt op, hvis de omdøbte SomeDespicablyLongFunctionName til SomeDespicablyLongMethodName, fordi nogen besluttede, at det var et grimt barnebarn og hans behov for at blive lagt i søvn.
Og helt ærligt, det fungerer ret godt for Google... internt. Jeg mener, ja, Go-fællesskabet hos Google har et godt grin med Java-fællesskabet hos Google på grund af deres vane med kontinuerlig refaktorering. Hvis du genstarter noget N gange, betyder det, at du ikke kun har skruet det op N-1 gange, men efter et stykke tid bliver det ret tydeligt, at du sandsynligvis også har skruet det op i det N. forsøg. Men i det store og hele forbliver de frem for alt dette postyr og holder koden "ren".
Problemet starter, når de forsøger at påtvinge deres cloud-klienter og brugere af andre API'er denne holdning.
Jeg har introduceret dig lidt til Emacs, Android og Java; lad os se på den seneste succesrige langlivede platform: selve nettet. Kan du forestille dig, hvor mange iterationer HTTP har gennemgået siden 1995, da vi brugte blinkende tags? og "Under konstruktion" ikoner på websider.
Men det virker stadig! Og disse sider fungerer stadig! Ja, gutter, browsere er verdensmestrene i bagudkompatibilitet. Chrome er endnu et eksempel på den sjældne Google-platform, der har hovedet skruet korrekt på, og som du måske har gættet, fungerer Chrome effektivt som en sandkassevirksomhed adskilt fra resten af Google.
Jeg vil også gerne takke vores venner i operativsystemudviklerne: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD osv., for at have udført et så godt stykke arbejde med bagudkompatibilitet på deres succesrige platforme (Apple får i bedste fald et C med The Ulempen er, at de bryder alt hele tiden uden god grund, men på en eller anden måde kommer fællesskabet uden om det med hver udgivelse, og OS X-containere er stadig ikke helt forældede... endnu).
Men vent, siger du. Sammenligner vi ikke æbler med appelsiner - selvstændige softwaresystemer på en enkelt maskine som Emacs/JDK/Android/Chrome versus multi-server-systemer og API'er som cloud-tjenester?
Nå, jeg tweetede om dette i går, men i stil med Larry Wall (skaber af programmeringssproget Perl - ca. pr.) på princippet om "sutter/regler" slog jeg ordet op. forældet på Googles og Amazons udviklerwebsteder. Og selvom AWS har hundredvis af gange flere servicetilbud end GCP, nævner Googles udviklerdokumentation udfasning omkring syv gange oftere.
Hvis nogen hos Google læser dette, er de sandsynligvis klar til at trække Donald Trump-lignende diagrammer frem, der viser, at de faktisk gør alt rigtigt, og at jeg ikke bør lave uretfærdige sammenligninger som "antal omtaler af ordet forældet versus antal tjenester" "
Men efter alle disse år er Google Cloud stadig nr. 3-tjenesten (jeg har aldrig skrevet en artikel om det mislykkede forsøg på at blive nr. 2), men hvis man skal tro på insidere, er der nogle bekymringer om, at de snart kan falde til nr. 4.
Jeg har ingen overbevisende argumenter for at "bevise" min tese. Det eneste, jeg har, er de farverige eksempler, jeg har samlet over 30 år som udvikler. Jeg har allerede nævnt dette problems dybt filosofiske karakter; på nogle måder er det politiseret i udviklersamfund. Nogle tror det skabere platforme bør bekymre sig om kompatibilitet, mens andre mener, at dette er en bekymring brugere (udviklerne selv). En ud af to. Ja, er det ikke et politisk spørgsmål, når vi beslutter, hvem der skal bære omkostningerne ved fælles problemer?
Så det her er politik. Og der vil nok komme vrede svar på min tale.
Som bruger Google Cloud Platform, og som AWS-bruger i to år (mens jeg arbejdede for Grab), kan jeg sige, at der er en kæmpe forskel mellem Amazon og Googles filosofier, når det kommer til prioriteringer. Jeg udvikler ikke aktivt på AWS, så jeg ved ikke så godt, hvor ofte de fjerner gamle API'er. Men der er en mistanke om, at det ikke sker nær så ofte som hos Google. Og jeg tror virkelig, at denne kilde til konstant kontrovers og frustration i GCP er en af de største faktorer, der holder platformens udvikling tilbage.
Jeg ved, at jeg ikke nævnte specifikke eksempler på GCP-systemer, der ikke længere understøttes. Jeg kan sige, at næsten alt, hvad jeg har brugt, fra netværk (fra de ældste til VPC) til storage (Cloud SQL v1-v2), Firebase (nu Firestore med en helt anden API), App Engine (lad os ikke engang komme i gang) , cloud endpoints Cloud Endpoint og op til... Jeg ved det ikke - absolut alt dette tvang dig til at omskrive koden efter maksimalt 2-3 år, og de automatiserede aldrig migreringen for dig, og ofte . Som om det skulle være sådan.
Og hver gang jeg ser på AWS, spørger jeg mig selv, hvorfor fanden jeg stadig er på GCP. De har tydeligvis ikke brug for kunder. De har brug for покупатели. Forstår du forskellen? Lad mig forklare.
Google Cloud har , hvor folk foreslår deres softwareløsninger, og for at undgå den tomme restaurant-effekt, var de nødt til at fylde den med nogle forslag, så de indgik kontrakt med et firma kaldet Bitnami om at skabe en masse løsninger, der implementeres med "et klik", eller burde Jeg skriver det selv "løsninger", for disse løser ikke en pokkers ting. De eksisterer simpelthen som afkrydsningsfelter, som markedsføringsfylder, og Google har aldrig været ligeglad med, om nogen af værktøjerne rent faktisk virker. Jeg kender produktchefer, der har siddet i førersædet, og jeg kan forsikre dig om, at disse mennesker er ligeglade.
Tag for eksempel en formodet "et-klik" implementeringsløsning. . Jeg var dødsyg af Google Cloud SQL shenanigans, så jeg begyndte at se på at bygge min egen Percona-klynge som et alternativ. Og denne gang så det ud til, at Google havde gjort et godt stykke arbejde, de skulle spare mig for noget tid og kræfter med et klik på en knap!
Godt, lad os gå. Lad os følge linket og klikke på denne knap. Vælg "Ja" for at acceptere alle standardindstillinger og implementere klyngen i dit Google-skyprojekt. Haha, det virker ikke. Intet af det lort virker. Værktøjet blev aldrig testet, og det begyndte at rådne fra det første minut, og det ville ikke overraske mig, hvis mere end halvdelen af "løsningerne" er et-klik-implementeringer (nu forstår vi hvorfor citaterne) generelt virker ikke. Dette er et absolut håbløst mørke, hvor det er bedre ikke at komme ind.
Men Google har ret drifter dig til at bruge dem. De vil have dig til købt. For dem er det en transaktion. De vil ikke have noget support. Det er ikke en del af Googles DNA. Ja, ingeniører støtter hinanden, som det fremgår af min historie med Bigtable. Men i produkter og tjenester til almindelige mennesker de altid var hensynsløse i , som ikke opfylder grænsen for rentabilitet, selvom den har millioner af brugere.
Og dette udgør en reel udfordring for GCP, fordi dette er DNA'et bag alle cloud-tilbud. De forsøger ikke at støtte noget; Det er velkendt, at de nægter at hoste (som en administreret tjeneste) nogen tredjepartssoftware indtil, indtil AWS gør det samme og bygger en succesfuld forretning op omkring det, og når kunderne bogstaveligt talt efterspørger det samme. Det kræver dog en indsats at få Google til at understøtte noget.
Denne mangel på supportkultur kombineret med "lad os bryde det for at gøre det smukkere"-mentalitet fremmedgør udviklere.
Og det er ikke en god ting, hvis du vil bygge en langlivet platform.
Google, vågn op, for fanden. Det er 2020 nu. Du taber stadig. Det er tid til at tage et grundigt kig i spejlet og svare på, om du virkelig ønsker at blive i cloud-branchen.
Hvis du vil blive så stop med at bryde alt. Gutter, I er rige. Det gør vi udviklere ikke. Så når det kommer til, hvem der skal bære byrden af kompatibilitet, skal du tage det på dig selv. Ikke for os.
For der er mindst tre rigtig gode skyer mere. De vinker.
Og nu vil jeg gå videre med at reparere alle mine ødelagte systemer. Øh.
Indtil næste gang!
PS Opdater efter at have læst nogle af diskussionerne om denne artikel (diskussionerne er gode, btw). Firebase-support er ikke blevet afbrudt, og der er ingen planer, som jeg er bekendt med. De har dog en grim streaming-fejl, der får Java-klienten til at gå i stå i App Engine. En af deres ingeniører hjalp mig med at løse dette problem, da jeg arbejdede hos Google, men de har aldrig rettet fejlen, så jeg har en dårlig løsning med at skulle genstarte GAE-appen hver dag. Og sådan har det været i fire år! De har nu Firestore. Det vil tage meget arbejde at migrere til det, da det er et helt andet system, og Firebase-fejlen vil aldrig blive rettet. Hvilken konklusion kan man drage? Du kan få hjælp hvis du arbejder i en virksomhed. Jeg er sandsynligvis den eneste, der bruger Firebase på GAE, fordi jeg logger mindre end 100 nøgler i en 100 % indbygget app, og den holder op med at virke hvert par dage på grund af en kendt fejl. Hvad kan jeg sige andet end at bruge det på eget ansvar. Jeg skifter til Redis.
Jeg har også set nogle mere erfarne AWS-brugere sige, at AWS normalt aldrig stopper med at understøtte nogen tjenester, og SimpleDB er et godt eksempel. Mine antagelser om, at AWS ikke har den samme ende af støttesygdom, som Google synes at være berettiget.
Derudover bemærkede jeg, at for 20 dage siden brød Google App Engine-teamet hostingen af et kritisk Go-bibliotek, og lukkede en GAE-applikation fra en af de centrale Go-udviklere. Det var virkelig dumt.
Endelig har jeg hørt Googlere allerede diskutere dette problem og generelt være enige med mig (elsker jer!). Men de synes at tro, at problemet er uløseligt, fordi Googles kultur aldrig har haft den rigtige incitamentsstruktur. Jeg tænkte, at det ville være godt at tage lidt tid til at diskutere den helt fantastiske oplevelse, jeg havde arbejdet med AWS-ingeniører, mens jeg arbejdede hos Grab. En dag i fremtiden, håber jeg!
Og ja, i 2005 havde de forskellige typer hajkød på den gigantiske buffet i bygning 43, og min favorit var hammerhajkødet. Men i 2006 slap Larry og Sergei af med alle usunde snacks. Så under Bigtable-historien i 2007 var der virkelig ingen hajer, og jeg bedragede dig.
Da jeg så på cloud Bigtable for fire år siden (giv eller tag), var det her, prisen var. Det ser ud til at være faldet lidt nu, men det er stadig meget for et tomt datavarehus, især da min første historie viser, hvor ligegyldigt et tomt stort bord er i deres skala.
Beklager for at fornærme Apple-fællesskabet og ikke sige noget pænt om Microsoft osv. Du har det godt, jeg sætter virkelig pris på al den diskussion, denne artikel har skabt! Men nogle gange er du nødt til at lave bølger lidt for at starte en diskussion, ved du?
Tak fordi du læste med.
Opdatering 2, 19.08.2020/XNUMX/XNUMX. Stribe !
Opdatering 3, 31.08.2020/2/2. Jeg blev kontaktet af en Google-ingeniør på Cloud Marketplace, som viste sig at være en gammel ven af mig. Han ville finde ud af, hvorfor CXNUMXD ikke virkede, og vi fandt til sidst ud af, at det var, fordi jeg havde bygget mit netværk for mange år siden, og CXNUMXD ikke arbejdede på ældre netværk, fordi undernet-parameteren manglede i deres skabeloner. Jeg tror, det er bedst for potentielle GCP-brugere at sikre sig, at de kender nok ingeniører hos Google...
Kilde: www.habr.com