Fan Google, jag ville inte blogga igen. Jag har så mycket att göra. Att blogga tar tid, energi och kreativitet, vilket jag skulle kunna använda: mina böcker, , mitt spel och så vidare. Men du har gjort mig så förbannad att jag måste skriva det här.
Så låt oss få det här över.
Låt mig börja med en kort men lärorik historia från när jag började jobba på Google. Jag vet att jag har sagt mycket dåliga saker om Google på sistone, men det gör mig upprörd när mitt eget företag regelbundet fattar inkompetenta affärsbeslut. Samtidigt måste vi ge det sin rätt: Googles interna infrastruktur är verkligen extraordinär, det är säkert att säga att det inte finns något bättre idag. Grundarna av Google var mycket bättre ingenjörer än jag någonsin kommer att vara, och den här historien bekräftar bara det faktum.
Först, lite bakgrund: Google har en datalagringsteknik som heter . Det var en anmärkningsvärd teknisk prestation, en av de första (om inte den första) "oändligt skalbara" nyckel-värdelagret (K/V): i huvudsak början på NoSQL. Nuförtiden klarar sig Bigtable fortfarande bra i det ganska trånga K/V-lagringsutrymmet, men på den tiden (2005) var det otroligt coolt.
En rolig sak med Bigtable är att de hade interna kontrollplansobjekt (som en del av implementeringen) kallade tabletservrar, med stora index, och vid något tillfälle blev de en flaskhals när de skulle skala systemet. Bigtable-ingenjörer funderade över hur de skulle implementera skalbarhet och insåg plötsligt att de kunde ersätta surfplattaservrar med annan Bigtable-lagring. Så Bigtable är en del av Bigtable-implementeringen. Dessa förvaringsmöjligheter finns på alla nivåer.
En annan intressant detalj är att Bigtable ett tag blev populärt och allmänt förekommande inom Google, där varje team hade sitt eget arkiv. Så vid ett av fredagsmötena frågade Larry Page slentrianmässigt i förbigående: "Varför har vi mer än ett Bigtable? Varför inte bara en?” I teorin borde ett lagringsutrymme räcka för alla Googles lagringsbehov. Naturligtvis gick de aldrig till bara en av praktiska utvecklingsskäl (som konsekvenserna av ett potentiellt misslyckande), men teorin var intressant. Ett förråd för hela universum (Förresten, är det någon som vet om Amazon gjorde detta med sin Sable?)
Hur som helst, här är min historia.
Vid den tiden hade jag jobbat på Google i drygt två år, och en dag fick jag ett e-postmeddelande från Bigtables ingenjörsteam som gick ungefär så här:
Kära Steve,
Hej från Bigtable-teamet. Vi skulle vilja informera dig om att du på [datacenternamn] använder en mycket, mycket gammal Bigtable-binär. Denna version stöds inte längre och vi vill hjälpa dig att uppgradera till den senaste versionen.
Meddela mig om du kan schemalägga lite tid för att arbeta tillsammans i det här problemet.
Med vänliga hälsningar,
Bigtable Team
På Google får man mycket mail, så vid första anblicken läser jag ungefär så här:
Kära mottagare,
Hej från något team. Det vill vi kommunicera bla bla bla bla bla. Bla bla bla bla bla bla, och bla bla bla direkt.
Låt oss veta om du kan schemalägga lite av din dyrbara tid för bla bla bla.
Med vänliga hälsningar,
Något slags kommando
Jag raderade nästan det direkt, men vid kanten av mitt medvetande kände jag en smärtsam, tjatande känsla av att den inte riktigt ser dock ut som ett formellt brev uppenbarligen, att mottagaren hade fel eftersom jag inte använde Bigtable.
Men det var konstigt.
Resten av dagen ägnade jag åt att omväxlande fundera på jobbet och vilken typ av hajkött jag skulle prova i mikroköket, varav minst tre var tillräckligt nära för att slå från min plats med ett välriktat kast av ett kex, men tänkte på att skriva lämnade mig aldrig med en växande känsla av mild ångest.
De sa tydligt mitt namn. Och mejlet skickades till min e-postadress, inte någon annans, och det är inte cc: eller hemlig kopia:. Tonen är väldigt personlig och tydlig. Kanske är detta något slags misstag?
Till slut tog nyfikenheten över mig och jag gick för att titta på Borg-konsolen i datacentret de nämnde.
Och naturligtvis hade jag BigTable-lagring under hantering. Jag är ledsen, vad? Jag tittade på innehållet, och wow! Det var från Codelab-inkubatorn jag satt i under min första vecka på Google i juni 2005. Codelab tvingade dig att köra Bigtable för att skriva några värden där, och jag stängde tydligen aldrig lagringen efter det. Det fungerade fortfarande trots att det hade gått mer än två år.
Det finns flera anmärkningsvärda aspekter av denna berättelse. För det första var Bigtables arbete så obetydligt i Googles skala att bara två år senare märkte någon den extra lagringen, och bara för att versionen av binären var föråldrad. Som jämförelse funderade jag en gång på att använda för mitt onlinespel. Då kostade den här tjänsten cirka 16 000 USD per år. tömma Bigtable på GCP. Jag säger inte att de lurar dig, men enligt min personliga åsikt är det mycket pengar för en tom jävla databas.
En annan anmärkningsvärd aspekt är att lagringen jobbar fortfarande efter två år. WTF? Datacenter kommer och går; de upplever avbrott, de genomgår planerat underhåll, de förändras hela tiden. Hårdvaran uppdateras, switchar byts ut, allt förbättras ständigt. Hur fan kunde de hålla mitt program igång i två år med alla dessa förändringar? Detta kan tyckas vara en blygsam prestation 2020, men 2005-2007 var det ganska imponerande.
Och den mest underbara aspekten är att ett externt ingenjörsteam i någon annan stat närmar sig mig, ägaren till en liten, nästan tom instans av Bigtable, som har noll trafik under de senaste två åren - och erbjuder hjälp att uppdatera den.
Jag tackade dem, tog bort lagringen och livet fortsatte som vanligt. Men tretton år senare tänker jag fortfarande på det brevet. För ibland får jag liknande e-postmeddelanden från Google Cloud. De ser ut så här:
Bästa Google Cloud-användare!
Som en påminnelse kommer vi att avbryta tjänsten [viktig tjänst du använder] från och med augusti 2020, varefter du inte kommer att kunna uppgradera dina instanser. Vi rekommenderar att du uppgraderar till den senaste versionen, som är i betatestning, har ingen dokumentation, ingen migreringsväg och är tidigare föråldrad med vår vänliga hjälp.
Vi är fast beslutna att se till att denna förändring har minimal inverkan på alla användare av Google Cloud-plattformen.
Bästa vänner för alltid,
Google Cloud Platform
Men jag läser nästan aldrig sådana brev, för vad de faktiskt säger är:
Kära mottagare,
Dra åt helvete. Fy fan, jävla, jävla. Släpp allt du gör för det spelar ingen roll. Det viktiga är vår tid. Vi slösar tid och pengar på att underhålla vår skit och vi är trötta på det så vi kommer inte att stödja det längre. Så sluta med dina jävla planer och börja gräva igenom vår taskiga dokumentation, tigga om klipp på forumen, och förresten, vår nya skit är helt annorlunda än den gamla skiten, för vi har skruvat ihop den här designen ganska dåligt, heh, men det är din problem, inte vårt.
Vi fortsätter att anstränga oss för att se till att alla dina utvecklingar blir oanvändbara inom ett år.
Snälla dra iväg
Google Cloud Platform
Och faktum är att jag får sådana brev ungefär en gång i månaden. Detta händer så ofta och så konstant att de oundvikligen bortstött mig från GCP till antimolnlägret. Jag går inte längre med på att vara beroende av deras egenutvecklade utveckling, eftersom det faktiskt är lättare för devops att upprätthålla ett system med öppen källkod på en naken virtuell maskin än att försöka hålla jämna steg med Google med dess policy att stänga "föråldrade" produkter.
Innan jag går tillbaka till Google Cloud eftersom jag till och med nära inte färdig med att kritisera dem, låt oss titta på företagets resultat på några andra områden. Googles ingenjörer är stolta över sin programvaruteknik, och det är detta som faktiskt orsakar problem. Stolthet är en fälla för de oförsiktiga, och det har fått många Google-anställda att tro att deras beslut alltid är rätt och att det är viktigare att ha rätt (enligt en vag suddig definition) än att bry sig om kunderna.
Jag ska ge några slumpmässiga exempel från andra stora projekt utanför Google, men jag hoppas att du ser det här mönstret överallt. Det är som följer: Bakåtkompatibilitet håller systemen levande och uppdaterade i årtionden.
Bakåtkompatibilitet är designmålet för alla framgångsrika system designade för öppen användning, det vill säga implementerad med öppen källkod och/eller öppna standarder. Jag känner att jag säger något för uppenbart att alla till och med är obekväma, men nej. Det här är en politisk fråga, så det behövs exempel.
Det första systemet jag kommer att välja är det äldsta: GNU Emacs, som är en sorts hybrid mellan Windows Notepad, OS-kärnan och den internationella rymdstationen. Det är lite svårt att förklara, men i ett nötskal är Emacs en plattform skapad 1976 (ja, nästan ett halvt sekel sedan) för programmering för att göra dig mer produktiv, men maskerad som en textredigerare.
Jag använder Emacs varje dag. Ja, jag använder också IntelliJ varje dag, det har vuxit till en kraftfull verktygsplattform i sig. Men att skriva tillägg för IntelliJ är en mycket mer ambitiös och komplex uppgift än att skriva tillägg för Emacs. Och ännu viktigare, allt skrivet för Emacs bevaras evigt.
Jag använder fortfarande programvaran jag skrev för Emacs redan 1995. Och jag är säker på att någon använder moduler skrivna för Emacs i mitten av 80-talet, om inte tidigare. De kan kräva lite justeringar då och då, men detta är egentligen ganska sällsynt. Jag vet inte om något jag någonsin har skrivit för Emacs (och jag har skrivit mycket) som krävde en omarkitektur.
Emacs har en funktion som kallas make-obsolete för föråldrade enheter. Emacs terminologi för grundläggande datorkoncept (som vad ett "fönster" är) skiljer sig ofta från industrikonventioner eftersom Emacs introducerade dem för länge sedan. Detta är en typisk fara för dem som är före sin tid: alla dina termer är felaktiga. Men Emacs har ett begrepp om deprecation, som på deras jargong kallas åldrande.
Men i Emacs-världen verkar det finnas en annan arbetsdefinition. En annan underliggande filosofi, om man så vill.
I Emacs-världen (och inom många andra områden, som vi kommer att täcka nedan), betyder utfasad API-status i princip: "Du borde verkligen inte använda det här tillvägagångssättet, för medan det fungerar, lider det av olika brister som vi kommer att lista här. Men i slutändan är det ditt val."
I Googles värld betyder att vara föråldrad "Vi bryter mot vårt åtagande gentemot dig." Detta är sant. Detta är vad det i huvudsak betyder. Det betyder att de kommer att tvinga dig regelbundet göra lite arbete, kanske mycket arbete, som straff för att du tror på dem : Vi har den bästa mjukvaran. Den snabbaste! Du gör allt enligt instruktionerna, startar din applikation eller tjänst och sedan bam, efter ett eller två år går det sönder.
Det är som att sälja en begagnad bil som definitivt går sönder efter 1500 mil.
Det här är två helt olika filosofiska definitioner av "föråldrad". Googles definition av lukt . Jag tror inte på det här faktiskt planerad inkurans i samma mening som Apple. Men Google planerar definitivt att bryta dina program, på ett omvägande sätt. Jag vet detta eftersom jag arbetade där som mjukvaruingenjör i över 12 år. De har vaga interna riktlinjer för hur mycket bakåtkompatibilitet som ska följas, men det är i slutändan upp till varje enskilt team eller tjänst. Det finns inga rekommendationer på företags- eller ingenjörsnivå, och den djärvaste rekommendationen när det gäller inkuranscykler är "försök att ge kunderna 6-12 månader på sig att uppgradera innan de förstör hela deras system."
Problemet är mycket större än de tror, och det kommer att bestå i många år framöver eftersom kundvård inte finns i deras DNA. Mer om detta nedan.
Vid det här laget kommer jag att göra ett djärvt uttalande att Emacs är framgångsrik i stor utsträckning och till och med till största del eftersom de tar bakåtkompatibilitet så allvarligt. Egentligen är detta avhandlingen i vår artikel. Framgångsrika, långlivade öppna system har sin framgång tack vare de mikrosamhällen som har levt runt dem i decennier tillägg/plugins. Detta är ekosystemet. Jag har redan pratat om plattformarnas natur och hur viktiga de är, och hur Google aldrig i hela sin företagshistoria har förstått vad som krävs för att skapa en framgångsrik öppen plattform utanför Android eller Chrome.
Egentligen borde jag nämna Android kort eftersom du förmodligen tänker på det.
Första, Android är inte Google. De har nästan ingenting gemensamt med varandra. Android är ett företag som köptes av Google i juli 2005, företaget fick verka mer eller mindre självständigt och har faktiskt legat i stort sett orört under de mellanliggande åren. Android är en ökänd teknikstack och en lika ökänd taggig organisation. Som en Googler uttryckte det, "Du kan inte bara logga in på Android."
I en tidigare artikel diskuterade jag hur dåliga vissa av Androids tidiga designbeslut var. Heck, när jag skrev den artikeln rullade de ut skit som heter "instant apps" som nu är (överraskning!) , och jag sympatiserar om du var dum nog att lyssna på Google och flytta ditt innehåll till dessa snabbappar.
Men det finns en skillnad här, en betydande skillnad, som är att Android-folket verkligen förstår hur viktiga plattformar är, de gör sitt bästa för att hålla gamla Android-appar fungerande. Faktum är att deras ansträngningar för att upprätthålla bakåtkompatibilitet är så extrema att till och med jag, under min korta vistelse på Android-divisionen för några år sedan, fann mig själv försöka övertyga dem om att sluta stödja några av de äldsta enheterna och API:erna (jag hade fel , som var i många andra saker förr och nu. Förlåt Android killar! Nu när jag har varit i Indonesien förstår jag varför vi behöver dem).
Android-folket pressar bakåtkompatibiliteten till nästan ofattbara ytterligheter och samlar upp enorma mängder äldre tekniska skulder i sina system och verktygskedjor. Herregud, du borde se några av de galna sakerna de måste göra i sitt byggsystem, allt i kompatibilitetens namn.
För detta tilldelar jag Android det eftertraktade priset "You're Not Google". De vill verkligen inte bli Google, som inte vet hur man skapar hållbara plattformar, utan Android vet, hur man gör det. Och så Google är väldigt smart i ett avseende: att låta människor göra saker på sitt eget sätt på Android.
Snabbappar för Android var dock en ganska dum idé. Och vet du varför? För att de krävde skriv om och designa om din applikation! Det är som om folk helt enkelt kommer att skriva om två miljoner ansökningar. Jag antar att Instant Apps var någon Googlers idé.
Men det finns en skillnad. Bakåtkompatibilitet kommer till en hög kostnad. Android själv bär bördan av dessa kostnader, medan Google insisterar på att bördan bärs du är, betalande kund.
Du kan se Androids engagemang för bakåtkompatibilitet i dess API:er. När du har fyra eller fem olika delsystem som bokstavligen gör samma sak, är det ett säkert tecken på att det finns ett engagemang för bakåtkompatibilitet i kärnan. Vilket i plattformarnas värld är synonymt med engagemang för dina kunder och din marknad.
Googles största problem här är deras stolthet över sin tekniska hygien. De gillar inte när det finns många olika sätt att göra samma sak, med de gamla, mindre önskvärda sätten som ligger bredvid de nya, mer raffinerade sätten. Det ökar inlärningskurvan för de som är nya i systemet, det ökar bördan för att underhålla äldre API:er, det saktar ner hastigheten på nya funktioner och huvudsynden är att det inte är snyggt. Google - som Lady Ascot från Tim Burtons Alice i Underlandet:
Lady Ascot:
- Alice, vet du vad jag är mest rädd för?
- Aristokratins förfall?
– Jag var rädd att jag skulle ha det fula barnbarn.
För att förstå avvägningen mellan vackert och praktiskt, låt oss ta en titt på den tredje framgångsrika plattformen (efter Emacs och Android) och se hur den fungerar: Java själv.
Java har många föråldrade API:er. Avskrivning är mycket populärt bland Java-programmerare, till och med mer populärt än i de flesta programmeringsspråk. Java självt, kärnspråket och biblioteken fasar ständigt ut API:er.
För att bara ta ett av tusentals exempel, anses föråldrad. Det har föråldrats sedan utgivningen av Java 1.2 i december 1998. Det har gått 22 år sedan detta avskaffades.
Men min faktiska kod i produktion dödar fortfarande trådar varje dag. Tycker du verkligen att det är bra? Absolut! Jag menar, naturligtvis, om jag skulle skriva om koden idag, skulle jag implementera den annorlunda. Men koden för mitt spel, som har gjort hundratusentals människor glada under de senaste två decennierna, är skriven med en funktion för att stänga trådar som hänger för länge, och jag aldrig behövt ändra det. Jag känner mitt system bättre än någon annan, jag har bokstavligen 25 års erfarenhet av att arbeta med det i produktionen, och jag kan med säkerhet säga: i mitt fall är det helt och hållet att stänga dessa specifika arbetartrådar värdelös. Det är inte värt tiden och ansträngningen att skriva om den här koden, och tack (förmodligen) Larry Ellison för att Oracle inte tvingade mig att skriva om den.
Oracle förstår förmodligen plattformar också. Vem vet.
Bevis kan hittas i hela Java API:er, som är fulla av vågor av föråldrad, som linjerna på en glaciär i en kanjon. Du kan enkelt hitta fem eller sex olika tangentbordsnavigeringshanterare (KeyboardFocusManager) i Java Swing-biblioteket. Det är faktiskt svårt att hitta ett Java API som inte är föråldrat. Men de fungerar fortfarande! Jag tror att Java-teamet bara verkligen kommer att ta bort ett API om gränssnittet utgör ett påfallande säkerhetsproblem.
Här är grejen, gott folk: Vi mjukvaruutvecklare är alla väldigt upptagna, och inom varje område av mjukvara ställs vi inför konkurrerande alternativ. Vid varje given tidpunkt överväger programmerare i språk X språk Y som en möjlig ersättning. Åh, tror du mig inte? Vill du kalla det Swift? Som att alla migrerar till Swift och ingen överger det, eller hur? Oj, vad lite du vet. Företag räknar kostnaderna för dubbla mobila utvecklingsteam (iOS och Android) – och de börjar inse att de där plattformsoberoende utvecklingssystemen med roliga namn som Flutter och React Native faktiskt fungerar och kan användas för att minska storleken på deras mobila team två gånger eller, omvänt, göra dem dubbelt så produktiva. Det står riktiga pengar på spel. Ja, det finns kompromisser, men å andra sidan pengar.
Låt oss hypotetiskt anta att Apple dåraktigt tog ett ledtråd från Guido van Rossum och förklarade att Swift 6.0 är bakåtkompatibelt med Swift 5.0, ungefär som Python 3 är inkompatibelt med Python 2.
Jag berättade förmodligen den här historien för ungefär tio år sedan, men för ungefär femton år sedan gick jag till O'Reilly's Foo Camp med Guido, satt i ett tält med Paul Graham och en massa stora skott. Vi satt i den svällande hettan och väntade på att Larry Page skulle flyga ut i sin personliga helikopter medan Guido drönade vidare om "Python 3000", som han döpte efter det antal år det skulle ta för alla att migrera dit. Vi frågade honom hela tiden varför han bröt kompatibiliteten, och han svarade: "Unicode." Och vi frågade, om vi var tvungna att skriva om vår kod, vilka andra fördelar skulle vi se? Och han svarade "Yooooooooooooouuuuuuuniiiiiiicooooooooode."
Om du installerar Google Cloud Platform SDK ("gcloud") får du följande meddelande:
Kära mottagare,
Vi vill påminna dig om att stödet för Python 2 har fasats ut, så fy fan
… och så vidare. Livets cirkel.
Men poängen är att varje utvecklare har ett val. Och om du tvingar dem att skriva om koden tillräckligt ofta, kanske de tänker efter andra alternativ. De är inte dina gisslan, hur mycket du än vill att de ska vara. De är dina gäster. Python är fortfarande ett väldigt populärt programmeringsspråk, men fan, Python 3(000) skapade en sådan röra i sig själv, i sina gemenskaper och bland användarna av dess gemenskaper att konsekvenserna inte har klarats ut på femton år.
Hur många Python-program har skrivits om i Go (eller Ruby, eller något annat alternativ) på grund av denna bakåtkompatibilitet? Hur mycket ny programvara har skrivits i något annat än Python, även om det kan vara skrivet i Python, om inte Guido hade bränt ner hela byn? Det är svårt att säga, men Python har helt klart lidit. Det är en enorm röra och alla förlorar.
Så låt oss säga att Apple tar ett ledtråd från Guido och bryter kompatibiliteten. Vad tror du kommer att hända härnäst? Tja, kanske 80-90% av utvecklarna kommer att skriva om sin programvara om möjligt. Med andra ord går 10-20% av användarbasen automatiskt till något konkurrerande språk, som Flutter.
Gör detta flera gånger och du kommer att förlora hälften av din användarbas. Precis som inom idrotten, i programmeringsvärlden, spelar den nuvarande formen också roll. allt. Alla som förlorar hälften av sina användare på fem år kommer att betraktas som en Big Fat Loser. Du måste vara trendig i plattformarnas värld. Men det är här som inte stödjer äldre versioner kommer att förstöra dig med tiden. För varje gång du blir av med vissa utvecklare, (a) förlorar du dem för alltid för att de är arga på dig för att du bryter kontraktet, och (b) ger bort dem till dina konkurrenter.
Ironiskt nog hjälpte jag även Google att bli en sådan primadonna som ignorerar bakåtkompatibilitet när jag skapade Grok, ett källkodsanalys- och förståelsesystem som gör det enkelt att automatisera och instrumentera själva koden – liknande en IDE, men här lagrar molntjänsten materialiserade representationer av alla miljarder rader med Googles källkod i ett stort datalager.
Grok försåg Googlers med ett kraftfullt ramverk för att utföra automatiserade refaktoreringar över hela deras kodbas (bokstavligen över hela Google). Systemet beräknar inte bara dina uppströmsberoenden (som du är beroende av), utan också nedåtgående (vilket är upp till dig) så när du ändrar API:er känner du alla du bryter! På så sätt, när du gör ändringar, kan du verifiera att varje konsument av ditt API har uppdaterat till den nya versionen, och i verkligheten, ofta med Rosie-verktyget de skrev, kan du helt automatisera processen.
Detta gör att Googles kodbas kan vara internt nästan övernaturligt ren, eftersom de har dessa robottjänare som springer runt i huset och automatiskt städar upp allt om de döpte om SomeDespicablyLongFunctionName till SomeDespicablyLongMethodName eftersom någon bestämde sig för att det var ett fult barnbarn och hans behov att sövas.
Och ärligt talat, det fungerar ganska bra för Google... internt. Jag menar, ja, Go-communityt på Google har ett gott skratt med Java-communityt på Google på grund av deras vana att kontinuerligt refaktorera. Om du startar om något N gånger betyder det att du inte bara skruvade ihop det N-1 gånger, utan efter ett tag blir det ganska tydligt att du förmodligen skruvade på det på N:te försöket också. Men i stort sett förblir de framför allt detta krångel och håller koden "ren".
Problemet börjar när de försöker påtvinga sina molnklienter och användare av andra API:er denna attityd.
Jag har introducerat dig lite till Emacs, Android och Java; låt oss titta på den senaste framgångsrika långlivade plattformen: själva webben. Kan du föreställa dig hur många iterationer HTTP har gått igenom sedan 1995 när vi använde blinkande taggar? och "Under Construction"-ikoner på webbsidor.
Men det funkar ändå! Och dessa sidor fungerar fortfarande! Ja, killar, webbläsare är världsmästare i bakåtkompatibilitet. Chrome är ett annat exempel på den sällsynta Google-plattformen som har sina huvuden ordentligt fastskruvade, och som du kanske har gissat fungerar Chrome effektivt som ett sandlådeföretag skilt från resten av Google.
Jag vill också tacka våra vänner inom operativsystemutvecklarna: Windows, Linux, INTE APPLE FUCK YOU APPLE, FreeBSD, etc., för att de har gjort ett så bra jobb med bakåtkompatibilitet på deras framgångsrika plattformar (Apple får i bästa fall ett C med The Nackdelen är att de bryter allt hela tiden utan goda skäl, men på något sätt kommer communityn runt det med varje release, och OS X-behållare är fortfarande inte helt föråldrade... ännu).
Men vänta, säger du. Jämför vi inte äpplen med apelsiner - fristående mjukvarusystem på en enda maskin som Emacs/JDK/Android/Chrome kontra multiserversystem och API:er som molntjänster?
Jo, jag twittrade om detta igår, men i stil med Larry Wall (skapare av programmeringsspråket Perl - ca per.) på principen "suger/regler" slog jag upp ordet fasats på Googles och Amazons utvecklarwebbplatser. Och även om AWS har hundratals gånger fler tjänsteerbjudanden än GCP, nämner Googles utvecklardokumentation utfasning ungefär sju gånger oftare.
Om någon på Google läser detta är de förmodligen redo att ta fram diagram i Donald Trump-stil som visar att de faktiskt gör allt rätt, och att jag inte borde göra orättvisa jämförelser som "antal omnämnanden av ordet utfasad kontra antal tjänster" "
Men efter alla dessa år är Google Cloud fortfarande nummer 3-tjänsten (jag skrev aldrig en artikel om det misslyckade försöket att bli nummer 2), men om man ska tro insiders finns det vissa farhågor om att de snart kan sjunka till Nr 4.
Jag har inga övertygande argument för att "bevisa" min tes. Allt jag har är de färgglada exemplen jag har samlat på mig under 30 år som utvecklare. Jag har redan nämnt detta problems djupt filosofiska natur; på något sätt är det politiserat i utvecklargemenskaper. Vissa tror det skapare plattformar bör bry sig om kompatibilitet, medan andra tycker att detta är ett problem användare (utvecklarna själva). En av två. Ja, är det inte en politisk fråga när vi bestämmer vem som ska bära kostnaderna för gemensamma problem?
Så detta är politik. Och det blir nog arga svar på mitt tal.
hur Användaren Google Cloud Platform, och som AWS-användare i två år (medan jag jobbade för Grab), kan jag säga att det är en enorm skillnad mellan Amazon och Googles filosofier när det kommer till prioriteringar. Jag utvecklar inte aktivt på AWS, så jag vet inte så väl hur ofta de tar bort gamla API:er. Men det finns en misstanke om att detta inte händer i närheten av lika ofta som hos Google. Och jag tror verkligen att denna källa till ständiga kontroverser och frustration i GCP är en av de största faktorerna som håller tillbaka plattformens utveckling.
Jag vet att jag inte nämnde specifika exempel på GCP-system som inte längre stöds. Jag kan säga att nästan allt jag har använt, från nätverk (från de äldsta till VPC) till lagring (Cloud SQL v1-v2), Firebase (nu Firestore med ett helt annat API), App Engine (låt oss inte ens komma igång) , cloud endpoints Cloud Endpoint och upp till... Jag vet inte - absolut allt detta tvingade dig att skriva om koden efter max 2-3 år, och de automatiserade aldrig migreringen åt dig, och ofta . Som om det skulle vara så.
Och varje gång jag tittar på AWS frågar jag mig själv varför jag fortfarande är på GCP. De behöver helt klart inte kunder. De behöver покупатели. Förstår du skillnaden? Låt mig förklara.
Google Cloud har , där människor föreslår sina mjukvarulösningar, och för att undvika den tomma restaurangeffekten, behövde de fylla den med några förslag, så de avtalade med ett företag som heter Bitnami för att skapa ett gäng lösningar som distribueras med "ett klick", eller borde Jag skriver det själv "lösningar", eftersom dessa inte löser en jäkla sak. De finns helt enkelt som kryssrutor, som marknadsföringsfyllare, och Google har aldrig brytt sig om något av verktygen faktiskt fungerar. Jag känner produktchefer som har suttit i förarsätet, och jag kan försäkra er att dessa människor inte bryr sig.
Ta till exempel en distributionslösning som påstås ha "ett klick". . Jag var dödssjuk av Google Cloud SQL shenanigans, så jag började titta på att bygga mitt eget Percona-kluster som ett alternativ. Och den här gången verkade Google ha gjort ett bra jobb, de skulle spara mig lite tid och ansträngning med en knapptryckning!
Bra, låt oss gå. Låt oss följa länken och klicka på den här knappen. Välj "Ja" för att godkänna alla standardinställningar och distribuera klustret i ditt Google-molnprojekt. Haha, det går inte. Inget av detta skit fungerar. Verktyget testades aldrig och det började ruttna från första minuten, och det skulle inte förvåna mig om mer än hälften av "lösningarna" är ett-klicks-installationer (nu förstår vi varför citaten) i allmänhet fungerar inte. Detta är absolut hopplöst mörker, där det är bättre att inte gå in.
Men Google har rätt drifter dig att använda dem. De vill att du ska köpt. För dem är det en transaktion. De vill inte ha någonting Stöd. Det är inte en del av Googles DNA. Ja, ingenjörer stödjer varandra, vilket framgår av min historia med Bigtable. Men i produkter och tjänster för vanliga människor de alltid var hänsynslösa i , som inte uppfyller ribban för lönsamhet även om den har miljontals användare.
Och detta utgör en verklig utmaning för GCP eftersom detta är DNA:t bakom alla molnerbjudanden. De försöker inte stödja någonting; Det är välkänt att de vägrar att vara värd (som en hanterad tjänst) någon programvara från tredje part fram tills, tills AWS gör samma sak och bygger ett framgångsrikt företag runt det, och när kunderna bokstavligen kräver detsamma. Det krävs dock lite ansträngning för att få Google att stödja något.
Denna brist på supportkultur, i kombination med "låt oss bryta det för att göra det vackrare"-mentalitet, alienerar utvecklare.
Och det är inte bra om du vill bygga en långlivad plattform.
Googla, vakna, fan. Det är 2020 nu. Du förlorar fortfarande. Det är dags att ta en ordentlig titt i spegeln och svara på om du verkligen vill stanna kvar i molnbranschen.
Om du vill stanna då sluta bryta allt. Killar, ni är rika. Det gör inte vi utvecklare. Så när det kommer till vem som ska bära bördan av kompatibilitet, måste du ta på dig det. Inte för oss.
För det finns minst tre riktigt bra moln till. De lockar.
Och nu ska jag gå vidare med att fixa alla mina trasiga system. Va.
Tills nästa gång!
PS Uppdatering efter att ha läst några av diskussionerna om den här artikeln (diskussionerna är bra, btw). Firebase-supporten har inte upphört och det finns inga planer som jag känner till. Däremot har de en otäck strömningsbugg som gör att Java-klienten stannar i App Engine. En av deras ingenjörer hjälpte mig att lösa det här problemet, när jag jobbade på Google, men de fixade aldrig felet, så jag har en skit lösning för att behöva starta om GAE-appen varje dag. Och så har det varit i fyra år! De har nu Firestore. Det kommer att ta mycket arbete att migrera till det eftersom det är ett helt annat system och Firebase-felet kommer aldrig att fixas. Vilken slutsats kan man dra? Du kan få hjälp om du arbetar på ett företag. Jag är förmodligen den enda som använder Firebase på GAE eftersom jag loggar mindre än 100 nycklar i en 100 % inbyggd app och den slutar fungera varannan dag på grund av en känd bugg. Vad kan jag säga annat än att använda den på egen risk. Jag byter till Redis.
Jag har också sett några mer erfarna AWS-användare säga att AWS vanligtvis aldrig slutar stödja några tjänster, och SimpleDB är ett bra exempel. Mina antaganden om att AWS inte har samma end of support disease som Google verkar vara motiverade.
Dessutom märkte jag att för 20 dagar sedan bröt Google App Engine-teamet värdskapet för ett kritiskt Go-bibliotek och stängde ner en GAE-applikation från en av de viktigaste Go-utvecklarna. Det var riktigt dumt.
Slutligen har jag hört att Google redan diskuterar den här frågan och håller med mig (älskar er!). Men de verkar tro att problemet är olösligt eftersom Googles kultur aldrig hade rätt incitamentstruktur. Jag tänkte att det skulle vara bra att ta lite tid att diskutera den helt fantastiska upplevelse jag hade att arbeta med AWS-ingenjörer när jag arbetade på Grab. Någon gång i framtiden, hoppas jag!
Och ja, 2005 hade de olika typer av hajkött på den gigantiska buffén i byggnad 43, och min favorit var hammarhajköttet. Men 2006 blev Larry och Sergei av med alla ohälsosamma mellanmål. Så under Bigtable-historien 2007 fanns det verkligen inga hajar och jag lurade dig.
När jag tittade på cloud Bigtable för fyra år sedan (ge eller ta) var det här kostnaden låg. Det verkar ha sjunkit lite nu, men det är fortfarande väldigt mycket för ett tomt datalager, särskilt eftersom min första berättelse visar hur oviktigt ett tomt stort bord är i deras skala.
Ursäkta för att jag förolämpade Apple-communityt och inte säger något snällt om Microsoft etc. Du är okej, jag uppskattar verkligen all diskussion som denna artikel har genererat! Men ibland måste man göra vågor lite för att få igång en diskussion, vet du?
Tack för att du läser.
Uppdatering 2, 19.08.2020/XNUMX/XNUMX. Rand !
Uppdatering 3, 31.08.2020/2/2. Jag blev kontaktad av en Google-ingenjör på Cloud Marketplace som visade sig vara en gammal vän till mig. Han ville ta reda på varför CXNUMXD inte fungerade, och så småningom kom vi på att det berodde på att jag byggde mitt nätverk för flera år sedan, och CXNUMXD fungerade inte på äldre nätverk eftersom subnätsparametern saknades i deras mallar. Jag tror att det är bäst för potentiella GCP-användare att se till att de känner tillräckligt många ingenjörer på Google...
Källa: will.com