Kära Google Cloud, avskaffandet av bakåtkompatibilitet dödar dig

Herregud, Google, jag ville inte blogga igen. Jag har så mycket att göra. Att blogga kräver tid, energi och kreativitet som jag skulle kunna använda till något nyttigt: mina böcker, musik, mitt spel och så vidare. Men du har gjort mig tillräckligt arg, så jag måste skriva detta.

Så låt oss avsluta detta.

Jag börjar med en liten, men lärorik historia från de dagar då jag just hade börjat jobba på Google. Jag vet att jag har sagt mycket dåligt om Google på sistone, men det frustrerar mig när mitt egna företag regelbundet fattar dåliga affärsbeslut. Samtidigt måste man ge dem kredit: Googles interna infrastruktur är verkligen extraordinär, man kan tryggt hävda att det idag inte finns något bättre. Googles grundare var mycket bättre ingenjörer än jag någonsin kommer att bli, och denna historia bekräftar just det.

Först lite bakgrund: Google har en datalagringsteknik som kallas Bigtable. Det var en fantastisk teknisk prestation, en av de första (om inte den första) ”oändligt skalbara” lagringslösningarna för nyckel-värde-par (key-value store, K/V): i praktiken, början på NoSQL. Idag klarar sig Bigtable fortfarande bra i en ganska mättad K/V-lagringsmarknad, men vid den tiden (2005) var det otroligt imponerande.

En rolig detalj med Bigtable är att de hade interna kontrollplaneobjekt (som en del av implementeringen) kallade tablet-servrar, med stora index, och vid något tillfälle blev de en flaskhals när systemet skulle skalas. Ingenjörerna på Bigtable funderade på hur man skulle uppnå skalbarhet och insåg plötsligt att de kunde ersätta tablet-servrar med andra Bigtable-lagringar. Så Bigtable är en del av Bigtable-implementationen. Dessa lagringar finns på alla nivåer.

En annan intressant detalj är att Bigtable blev populära och allestädes närvarande inom Google under en tid, och varje team hade sitt eget lagringsutrymme. Så på ett av fredagsmötena frågade Larry Page nonchalant: "Varför har vi mer än en Bigtable? Varför nöja oss med bara en?" Teoretiskt sett skulle en enda lagring räcka för alla Googles lagringsbehov. Självklart övergick de aldrig till bara en av praktiska skäl relaterade till utveckling (t.ex. konsekvenserna av ett potentiellt fel), men teorin var intressant. Ett lagringsutrymme för hela universum (förresten, vet någon om Amazon gjorde så med sin Sable?)

Hur som helst, här är min historia.

Vid den tiden hade jag arbetat på Google i lite mer än två år, och en dag fick jag ett e-postmeddelande från ingenjörsteamet för Bigtable med ungefär följande innehåll:

Kära Steve,

Hälsningar från Bigtable-teamet. Vi vill informera dig om att ni i datacentret [datacenterets namn] använder en mycket, mycket gammal binärfil av Bigtable. Den här versionen stöds inte längre, och vi vill hjälpa er att uppgradera till den senaste versionen.

Låt oss veta om ni kan schemalägga lite tid för att arbeta tillsammans med det här problemet.

Allt gott,
Bigtable-teamet

På Google får man mycket e-post, så vid första ögonkastet läste jag det ungefär så här:

Kära mottagare,

Hälsningar från något team. Vi vill informera er om att bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, och bla-bla-bla omedelbart.

Låt oss veta om ni kan schemalägga en del av er dyrbara tid för bla-bla-bla.

Allt gott,
Något team

Jag höll nästan på att radera det direkt, men i medvetandets gräns kände jag en tryckande, molande känsla av att det här inte riktigt kändes som ett formellt brev, även om det uppenbarligenvar klart att de hade fel adressat eftersom jag inte använde Bigtable.

Men det var konstigt.

Resten av dagen tänkte jag växelvis på arbetet och vilken typ av hajkött jag skulle prova i mikro-köket, där åtminstone tre var tillräckligt nära för att träffa med ett välriktat kexkast från min plats, men tanken på brevet lämnade mig med en växande känsla av lätt oro.

De namngav tydligt mitt namn. Och brevet skickades till min e-postadress, inte någon annans, och det är inte cc: eller bcc:. Tonen är mycket personlig och tydlig. Kan det vara ett misstag?

Till slut tog nyfikenheten över och jag gick för att titta på Borg-konsolen i datacentret som de nämnde.

Och självklart hade jag ett BigTable-lager under min kontroll. Vad? Jag tittade på dess innehåll, och - tja! Det var från Codelab-inkubatorn där jag satt den första veckan av mitt arbete på Google i juni 2005. Codelab fick dig att köra Bigtable för att du skulle mata in vissa värden, och jag verkar inte ha stängt lagret efter det. Det fungerade fortfarande, trots att det hade gått mer än två år.

Det finns några anmärkningsvärda aspekter av denna historia. För det första var Bigtables funktion så obetydlig i Googles perspektiv att det tog två år innan någon märkte det överflödiga lagret, och det berodde endast på att binärversionen var föråldrad. Som jämförelse övervägde jag någon gång att använda Bigtable i Google Cloud för mitt online-spel. Vid den tiden kostade tjänsten cirka 16 000 dollar om året för ett tomt Bigtable i GCP. Jag säger inte att de lurar dig, men enligt min personliga åsikt är det mycket pengar för en helt värdelös databas.

En annan anmärkningsvärd aspekt är att lagret fortfarande fungerade två år senare. WTF? Datacentraler kommer och går; de upplever avbrott, de genomgår planerat underhåll, de förändras hela tiden. Hårdvara uppgraderas, switchar byts ut, allt förbättras ständigt. Hur i helvete lyckades de hålla min applikation igång i två år med alla dessa förändringar? Det kan tyckas vara en blygsam prestation 2020, men mellan 2005 och 2007 var det ganska imponerande.

Och den mest fantastiska aspekten är att ett utomstående ingenjörsteam i en annan delstat kontaktar mig, ägaren av en nästan tom Bigtable-instans, som har noll trafik under de senaste två åren - och erbjuder sin hjälp för att uppdatera den.

Jag tackade dem, tog bort lagret, och livet fortsatte som vanligt. Men tretton år senare tänker jag fortfarande på det brevet. För ibland får jag liknande brev från Google Cloud. De ser ut så här:

Kära Google Cloud-användare,

Vi påminner om att vi stoppar tjänsten [viktig tjänst som du använder] från och med augusti 2020, efter vilket du inte längre kommer att kunna uppdatera dina instanser. Vi rekommenderar att du uppgraderar till den senaste versionen som för närvarande är i betatest, som saknar dokumentation och migrationsväg, och som är föråldrad med vår vänliga hjälp.

Vi strävar efter att denna förändring ska påverka alla användare av Google Cloud-plattformen så lite som möjligt.

Bästa vänner för alltid,
Google Cloud-plattformen

Men jag läser nästan aldrig sådana här mejl, för det som faktiskt står i dem är följande:

Kära mottagare,

Dra åt helvete. Dra åt helvete, dra åt helvete, dra åt helvete. Sluta med allt du gör, för det spelar ingen roll. Det som betyder något är vår tid. Vi lägger tid och pengar på att underhålla vårt skräp, och vi är trötta på det, så vi kommer inte att stödja det längre. Så släpp dina förbenade planer och börja gräva i vår skräp-dokumentation, där du tigger om rester på forum, och förresten är vårt nya skräp helt annorlunda än det gamla skräpet, för vi har förstört designen ganska mycket, hehe, men det är ditt problem, inte vårt.

Vi fortsätter att arbeta för att dina utvecklingar ska bli obrukbara inom ett år.

Vänligen gå till helvete,
Google Cloud-plattformen

Och saken är att jag får sådana här mejl ungefär en gång i månaden. Det händer så ofta och så regelbundet att de oundvikligen stöter bort mig från GCP till motståndarlägret mot moln. Jag vill inte längre vara beroende av deras proprietära lösningar, för det är faktiskt mycket lättare för en devops att underhålla ett system med öppen källkod på en ren virtuell maskin än att försöka hänga med Google i deras politik att stänga ner "föråldrade" produkter.

Innan jag återvänder till Google Cloud, för jag är inte ens nära Han slutade inte kritisera dem, låt oss titta på företagets arbete inom några andra områden. Googles ingenjörer är stolta över sin mjukvaruutvecklingsdisciplin, och det är faktiskt detta som skapar problem. Stolthet är en fälla för de oförsiktiga; den har fått många anställda på Google att tro att deras beslut alltid är rätt och att riktighet (enligt något oklart och diffust kriterium) är viktigare än att bry sig om kunderna.

Jag kommer att ge några slumpmässiga exempel från andra stora projekt utanför Google, men jag hoppas att ni kommer att se detta mönster överallt. Det handlar om följande: bakåtkompatibilitet upprätthåller hållbarhet och relevans för system under decennier.

Bakåtkompatibilitet är en designmål för alla framgångsrika system avsedda för öppen användning, det vill säga implementerade med öppen källkod och/eller i enlighet med öppna standarder. Jag känner att jag säger något för uppenbart, något som får alla att känna sig obekväma, men så är det inte. Det är en politisk fråga, därför behövs exempel.

Det första systemet jag väljer, det äldsta: GNU Emacs, är en slags hybrid mellan Notepad i Windows, operativsystemets kärna och den Internationella rymdstationen. Det är lite svårt att förklara, men i korthet är Emacs en plattform som skapades 1976 (ja, nästan fem decennier sedan) för programmering, för att öka din produktivitet, men som döljer sig som en textredigerare.

Jag använder Emacs varje dag. Ja, jag använder också IntelliJ varje dag; det har redan förvandlats till en kraftfull verktygsplattform. 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 som skrivs för Emacs bevaras för alltid..

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 från mitten av 80-talet, om inte tidigare. Då och då kan de behöva små justeringar, men detta är verkligen ganska sällsynt. Jag vet inget av det jag någonsin har skrivit för Emacs (och jag har skrivit mycket) som skulle behöva omstruktureras.

I Emacs finns det en funktion som heter make-obsolete för föråldrade entiteter. Emacs terminologi för grundläggande datorkoncept (till exempel vad ett "fönster" är) avviker ofta från branschkonventioner, eftersom Emacs introducerade dem för länge sedan. Detta är en typisk fara för dem som kom före sin tid: alla era termer är felaktiga. Men det finns faktiskt ett begrepp för föråldring i Emacs, vilket de kallar obsolescence.

Men i Emacs värld verkar det finnas en annan arbetsdefinition. En annan grundläggande filosofi, om ni vill.

I Emacs värld (och i många andra områden som vi kommer att täcka nedan) betyder status för föråldrade API:er huvudsakligen: "Du bör verkligen inte använda denna metod, för även om den fungerar, lider den av olika brister som vi kommer att lista här. Men i slutändan är det ditt val."

I Google värld betyder status för en föråldrad produkt: "Vi bryter våra åtaganden gentemot dig." Det är faktiskt sant. Det är vad det i stort sett innebär. Det betyder att de kommer att tvinga dig att regelbundet utföra en del arbete, kanske mycket arbete, som straff för att du trott på deras färgglada reklam: Vi har den bästa programvaran. Den snabbaste! Du följer bara instruktionerna, kör din applikation eller tjänst, och sedan — bam, efter ett år eller två fungerar den inte längre.

Det är som att sälja en begagnad bil som garanterat går sönder efter 1500 km.

Det här är två helt olika filosofiska definitioner av "föråldring". Googles definition luktar planerad föråldring. Jag tror inte att detta är som faktiskt planerad föråldring i samma mening som hos Apple. Men Google planerar definitivt att krossa dina program, på ett omvänt sätt. Jag vet detta, eftersom jag har arbetat där som programmeringsingenjör i mer än 12 år. De har vaga interna riktlinjer om i vilken utsträckning man bör upprätthålla bakåtkompatibilitet, men i slutändan beror det på varje enskilt team eller avdelning. Det finns inga riktlinjer på företags- eller ingenjörsnivå, och den djärvaste rekommendationen när det gäller föråldringscykler är "försök att ge kunderna 6-12 månader på sig att uppgradera innan du krossar hela deras system".

Problemet är mycket mer allvarligt än vad de tror, och det kommer att kvarstå i många år framöver, eftersom kundservice inte ingår i deras DNA. Läs mer om detta nedan.

Just nu tänker jag göra ett djärvt påstående att Emacs framgång till stor del beror på just det faktum att de tar bakåtkompatibilitet på så stort allvar. Det är egentligen vad vårt argument handlar om. Framgångsrika, långlivade öppna system är skyldiga sin framgång till mikrosamhällen som har funnits i flera decennier kring tillägg/plugins. Det är själva ekosystemet. Jag har redan diskuterat essensen av plattformar och hur viktiga de är, samt att Google under hela sin företagsverksamhet aldrig har förstått vad som krävs för att skapa en framgångsrik öppen plattform, förutom Android eller Chrome.

Egentligen bör jag kort nämna Android, eftersom du förmodligen har tänkt på det.

För det första, Android är inte Google. De har nästan inget gemensamt. Android är ett företag som köptes av Google i juli 2005, och företaget har fått arbeta mer eller mindre autonomt och har i stor utsträckning förblivit opåverkat under åren. Android är en beryktad teknisk stack och en lika beryktad krånglig organisation. Som en Googler uttryckte det, "man kan bara inte gå in i Android".

I en av mina tidigare artiklar har jag redan pratat om hur dåliga vissa av de tidiga designbesluten för Android var. Det var en dålig tid när jag skrev den artikeln, de sysslade med att rulla ut skräpet som kallades "öppna applikationer", vilka nu (överraskning!) är föråldrade, och jag beklagar om du varit tillräckligt dum för att lyssna på Google och flytta ditt innehåll till dessa öppna applikationer.

Men här finns en skillnad, en betydande skillnad, som handlar om att människorna bakom Android verkligen förstår hur viktiga plattformar är; de gör allt de kan för att hålla gamla Android-appar fungerande. Deras ansträngningar att bevara bakåtkompatibiliteten är så extrema att även jag, under min korta tid inom Android-avdelningen för några år sedan, upptäckte att jag försökte övertyga dem att släppa stödet för några av de äldsta enheterna och API:erna (jag hade fel, liksom i många andra avseenden både då och nu. Förlåt, Android-fantaster! Nu när jag har varit i Indonesien förstår jag varför de är viktiga).

Människorna bakom Android upprätthåller bakåtkompatibilitet till nästan osannolika nivåer, vilket resulterar i en enorm mängd teknisk skuld i deras system och verktygskedjor. Gud, ni skulle se vissa galna saker de måste göra i sitt byggsystem, allt i syfte att säkerställa kompatibilitet.

Därför tilldelar jag Android det åtråvärda priset "Du är inte Google". De vill verkligen inte bli som Google, som inte kan skapa hållbara plattformar, medan Android känner till, vet hur man gör det. Och därför agerar Google klokt på ett sätt: de låter människorna i Android göra saker på sitt sätt.

Men Android Instant Apps var en ganska dum idé. Och vet ni varför? För att de krävde att skriva om och designa om din app! Som om folk bara skulle ta och skriva om två miljoner appar. Jag antar att Instant Apps var en idé från någon i Google.

Men här finns en skillnad. Bakåtkompatibilitet medför stora kostnader. Android bär själv den kostnaden, medan Google insisterar på att denna kostnad ska bäras av du, betalande kunder.

Du kan se Androids engagemang för bakåtkompatibilitet i dess API:er. När du har fyra eller fem olika delsystem som utför bokstavligen samma sak, är det en tydlig indikation på att det hela grundar sig på ett engagemang för bakåtkompatibilitet. Vad som i plattformsvärlden är synonymt med engagemang för dina kunder och din marknad.

Google's main problem here is their pride in their engineering hygiene. They dislike having many different ways to accomplish the same thing, especially when old, less desirable methods sit alongside newer, fancier ones. This increases the learning curve for newcomers to the system, adds to the burden of maintaining outdated APIs, slows down the speed of new features, and the cardinal sin is that it looks unappealing. Google is like the Red Queen from Tim Burton's 'Alice in Wonderland':

The Red Queen:
— Alice, do you know what I fear the most?
— The decline of the aristocracy?
— I was worried that I would have ugly grandchildren..

To understand the compromise between beautiful and practical, let’s look at the third successful platform (after Emacs and Android) and see how it functions: Java itself.

Java has a lot of outdated APIs. Obsolescence is very popular among Java programmers, even more so than in most programming languages. In Java itself, the core language and libraries are constantly undergoing API obsolescence.

If we take just one of the thousands of examples, closing threads is deemed obsolete. It has been considered obsolete since the release of Java 1.2 in December 1998. It has been 22 years since it became obsolete.

But my actual production code still kills threads every day.. Is that good? Absolutely! I mean, sure, if I were to rewrite the code today, I would implement it differently. But the code for my game, which has brought joy to hundreds of thousands over the last two decades, was written using the thread-closing feature that hangs too long, and I have never had to change it.. I know my system better than anyone, I literally have 25 years of experience working with it in production, and I can confidently say: in my case, closing these specific worker threads is completely harmless.. There’s no need to waste time and effort rewriting this code, and praise be to Larry Ellison (probably), that Oracle hasn't forced me to rewrite it.

Oracle likely understands platforms too. Who knows?

Bevis kan hittas i alla viktiga Java API:er, som är genomträngda av föråldrade meddelanden, likt linjerna av glaciär i en ravin. I Java Swing-biblioteket kan man lätt hitta fem eller sex olika navigationshanterare för tangentbord (KeyboardFocusManager). Det är faktiskt svårt att hitta en Java API som inte är föråldrad. Men de fungerar fortfarande! Jag tror att Java-teamet verkligen kommer att ta bort API:er endast om gränssnittet orsakar en påtaglig säkerhetsrisk.

Här är saken, grabbar: vi mjukvaruutvecklare är alla mycket upptagna, och i varje område av programvara ställs vi inför konkurrerande alternativ. Vid varje given tidpunkt överväger programmerare i språk X språk Y som en potentiell ersättning. Åh, ni tror mig inte? Vill ni nämna Swift? Att alla migrerar till Swift och ingen avviker från det, eller hur? Wow, vad lite ni vet. Företag börjar räkna kostnaderna för dubbla mobila utvecklingsteam (iOS och Android) – och de börjar förstå att dessa plattformsövergripande utvecklingssystem med lustiga namn, som Flutter och React Native, faktiskt fungerar, och att de kan halvera storleken på sina mobila team eller å andra sidan göra dem dubbelt så produktiva. Riktiga pengar står på spel. Ja, det finns kompromisser, men å andra sidan, pengarna.

Anta hypotetiskt att Apple för dumt tog exempel av Guido van Rossum och meddelade att Swift 6.0 inte är bakåtkompatibelt med Swift 5.0, på ett sätt som Python 3 är inkompatibelt med Python 2.

Jag kanske berättade den här historien för tio år sedan, men för femton år sedan åkte jag till O’Reillys Foo Camp med Guido, satt i ett tält med Paul Graham och en massa stora fiskar. Vi satt i den kvävande hettan och väntade på att Larry Page skulle flyga in med sin privata helikopter, medan Guido monotont mumlade om "Python 3000", som han kallade det för 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 måste skriva om vår kod, vilka andra fördelar skulle vi se? Och han svarade “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.

Om du installerar Google Cloud Platform SDK (“gcloud”), kommer du att få följande meddelande:

Kära mottagare,

Vi vill påminna er om att stödet för Python 2 har upphört, så nu är det dags att gå vidare.

… och så vidare. Livets cykel.

Men saken är den att varje utvecklare har ett val. Och om man tvingar dem att skriva om koden tillräckligt ofta, kan de börja överväga andra andra alternativ. De är inte era fångar, oavsett hur mycket ni skulle vilja. De är era gäster. Python är fortfarande ett mycket populärt programmeringsspråk, men herregud, Python 3(000) har ställt till med sådan oreda bland sina samhällen och sina användare att konsekvenserna inte har kunnat rättas till på femton år.

Hur många Python-program har skrivits om till Go (eller Ruby, eller något annat alternativ) på grund av denna bristande bakåtkompatibilitet? Hur mycket ny mjukvara har skrivits på något annat än Python, trots att det kunde ha varit skrivet i Python, om Guido inte hade bränt hela byn? Det är svårt att säga, men Python har uppenbarligen lidit. Det är en stor oreda, och alla förlorar.

Så, låt oss anta att Apple tar ett exempel från Guido och bryter kompatibiliteten. Vad tror ni händer då? Tja, kanske 80-90% av utvecklarna kommer att skriva om sin mjukvara, om de kan. Med andra ord, 10-20% av användarbasen går automatiskt till något konkurrerande språk, som Flutter.

Gör detta några gånger så förlorar ni hälften av er användarbas. Precis som inom sport, så betyder nuvarande form också allt.Den som förlorar hälften av sina användare på fem år kommer att anses vara en stor misslyckad person. Ni måste hänga med i svängarna i plattformsvärlden. Men precis här kommer avståndet från att stödja gamla versioner med tiden att bli er undergång. För varje gång ni gör er av med en del av utvecklarna, (a) förlorar ni dem för alltid eftersom de är irriterade över att ni bryter kontraktet, och (b) ger ni dem till era konkurrenter.

Ironiskt nog hjälpte jag också Google att bli en sådan primadonna som ignorerar bakåtkompatibilitet när jag skapade Grok, ett analys- och förståelsessystem för källkod som underlättar automatisering och verktyg i basen av själva koden — liknande en IDE, men här lagrar en molntjänst materialiserade vyer av alla miljarder rader källkod från Google i ett stort datalager.

Grok har försett Googlarna med en kraftfull grund för att utföra automatiserad refaktorering över hela kodbasen (bokstavligen hela Google). Systemet beräknar inte bara dina uppåtgående beroenden (som du är beroende av) utan också nedåtgående (som är beroende av dig), så att när du ändrar API:et vet du alla som du bryter! På så sätt kan du vid ändringar kontrollera att varje användare av ditt API har uppdaterat till den nya versionen, och i verkligheten kan du ofta helt automatisera processen med hjälp av verktyget Rosie som de har skrivit.

Detta gör att Googles kodbas internt är nästan övermänskligt "ren", eftersom dessa robotar rör sig runt i huset och automatiskt städar upp om de har omdöpt SomeDespicablyLongFunctionName till SomeDespicablyLongMethodName, eftersom någon har bestämt att detta är ett fult barnbarn som behöver avlivas.

Och, ärligt talat, det fungerar ganska bra för Google… internt. Jag menar, ja, Go-communityt på Google skrattar verkligen vänligt åt Java-communityt på Google på grund av deras vana att ständigt refaktorera. Om du startar om något N gånger betyder det att du inte bara förstörde det N-1 gånger, utan efter ett tag blir det helt klart att du antagligen har förstört det även i N:e försöket. Men, överlag, håller de sig över denna oro och håller koden "ren".

Problemen börjar när de försöker påtvinga en sådan attityd på sina molnkunder och användare av andra API:er.

Jag har gett dig en kort introduktion till Emacs, Android och Java; låt oss titta på den senaste framgångsrika och långlivade plattformen: 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 utveckling"-ikoner på webbsidor.

Men det fungerar fortfarande! Och de sidorna fungerar fortfarande! Ja, killar, webbläsare är världens mästare i bakåtkompatibilitet. Chrome är ett annat exempel på en sällsynt Google-plattform som har huvuden skruvade på rätt sätt, och, som du redan gissat, fungerar Chrome effektivt som ett isolerat företag separat från resten av Google.

Jag vill också tacka våra vänner bland operativsystemutvecklarna: Windows, Linux, INTE APPLE VARFÖR APPLE, FreeBSD och så vidare, för att de har gjort ett så stort arbete med bakåtkompatibilitet på sina framgångsrika plattformar (Apple får högst en trea minus, eftersom de ständigt bryter allt utan någon respektabel anledning, men på något sätt klarar sig gemenskapen med detta i varje release, och fortfarande är behållarna med OS X inte helt föråldrade... än).

Men vänta, säger du. Jämför vi inte äpplen med apelsiner - fristående programvarusystem på en maskin, som Emacs/JDK/Android/Chrome, med fler-server-system och API:er, som i molntjänster?

Tja, jag skrev om detta igår på Twitter, men i stil med Larry Wall (skaparen av programmeringsspråket Perl - anm. red.) enligt principen "sopigt/bluff" letade jag efter ordet deprecated på utvecklarwebbplatserna för Google och Amazon. Och även om AWS har hundratals gånger fler tjänsteerbjudanden än GCP, nämner Googles utvecklardokumentation föråldring ungefär sju gånger oftare.

Om någon från Google läser detta, så är de säkert redo att dra diagram och visa i Donald Trump-stil, att de faktiskt gör allt rätt, och att jag inte borde göra orättvisa jämförelser, som "antalet omnämnanden av ordet deprecated i förhållande till antalet tjänster".

Men efter så många år förblir Google Cloud fortfarande tjänst nummer 3 (jag har fortfarande inte skrivit en artikel om det misslyckade försöket att bli nummer 2), men om man ska tro insider, finns det vissa farhågor att de snart kan falla till nummer 4.

Jag har inga starka argument för att "bevisa" mitt påstående. Det enda jag har är färgglada exempel som jag har samlat under 30 års arbete som utvecklare. Jag har redan nämnt den djupt filosofiska naturen av detta problem; på ett sätt är det politiserat i utvecklarsamhällena. Vissa anser att skaparna av plattformar bör ta ansvar för kompatibiliteten, medan andra anser att det är upp till användare (utvecklarna själva). Antingen eller. Och är det inte verkligen en politisk fråga när vi bestämmer vem som ska bära kostnaderna för gemensamma problem?

Så det här är politik. Och det kommer säkert att bli upprörda svar på min presentation.

Hur användare Som användare av Googles molnplattform, samt en AWS-användare under två år (när jag arbetade på företaget Grab), kan jag säga att det finns en enorm skillnad mellan Amazon och Googles filosofier när det kommer till prioriteringar. Jag är inte aktivt involverad i utvecklingen på AWS, så jag vet inte riktigt hur ofta de tar bort gamla API:er. Men jag har en misstanke om att detta inte sker lika ofta som på Google. Och jag är helt övertygad om att denna källa till ständiga konflikter och besvikelser inom GCP är en av de största faktorerna som hindrar plattformens utveckling.

Jag vet att jag inte angav specifika exempel på GCP-system vars stöd har upphört. Jag kan säga att i stort sett allt jag har använt, från nätverk (från de äldsta till VPC) till lagringslösningar (Cloud SQL v1-v2), Firebase (nu Firestore med helt annan API), App Engine (låt oss inte ens börja), molnslutpunkter Cloud Endpoint och till… jag vet inte — absolut allt detta tvingade mig att skriva om koden max var 2-3 år, och de har aldrig automatiserat migreringen för dig, och ofta fanns det ingen dokumenterad väg för migrering överhuvudtaget. Det är som om det är meningen.

Och varje gång jag tittar på AWS frågar jag mig själv, vad sjutton gör jag fortfarande på GCP. De verkar uppenbarligen inte behöva kunder. De behöver köpare. Förstår du skillnaden? Låt mig förklara.

Google Cloud har Marketplace, där människor erbjuder sina programlösningar, och för att undvika effekten av en tom restaurang behövde de fylla den med vissa erbjudanden, så de skrev kontrakt med företaget Bitnami för att skapa en uppsättning lösningar som kan implementeras "med ett klick", eller så måste jag själv skriva "lösningar", eftersom dessa inte gör ett dugg. De existerar bara som checkpunkter, som marknadsföringsfyllnad, och Google har aldrig brytt sig om huruvida något av verktygen faktiskt fungerar. Jag känner produktchefer som har varit i förarsätet, och jag kan försäkra dig att dessa personer inte bryr sig.

Låt oss ta ett exempel på en implementeringslösning som påstås vara "med ett klick" Percona. Jag är så trött på tricksen med Google Cloud SQL, så jag började överväga att skapa min egen Percona-kluster som alternativ. Och den här gången verkade Google ha gjort något bra, de var ute efter att spara mig lite tid och ansträngning med ett knapptryck!

Bra, låt oss gå. Vi går till länken och klickar på den här knappen. Välj 'Ja' för att acceptera alla standardinställningar och skapa en kluster i ditt Google-molnprojekt. Ha ha, det fungerar inte. Inget av det här skit fungerar. Verktyget har aldrig testats och har börjat ruttna från första minuten, och det skulle inte förvåna mig om mer än hälften av "lösningarna" för att implementera med ett klick (nu förstår vi varför det är inom citat) inte fungerar. verkligen inte fungerar. Det är helt och hållet en hopplös mörker, dit man inte borde gå.

Men Google uppmanar dig att använda dem. De vill att du ska köpa. För dem är det en transaktion. De vill inte ha något stöda. Det är inte en del av Googles DNA. Ja, ingenjörerna stödjer varandra, vilket bevisas av min historia med Bigtable. Men i produkter och tjänster för vanliga människor har de alltid varit obarmhärtiga i nedstängningen av varje tjänst, som inte möter lönsamhetskraven, även om den har miljontals användare.

Och det här utgör ett verkligt problem för GCP, för den här DNA:n ligger bakom alla molnerbjudanden. De strävar inte efter att stödja något; det är välkänt att de vägrar att vara värd för (som en hanterad tjänst) någon tredjepartsprogramvara så länge, tills AWS gör detsamma och bygger upp en framgångsrik verksamhet runt det, och när kunderna bokstavligen kräver detsamma. Men det krävs en ansträngning för att få Google att stödja något.

Denna brist på supportkultur, i kombination med princippet 'låt oss förstöra för att göra det snyggare', alienerar utvecklarna från dem.

Och det är inte bra om du vill bygga en långlivad plattform.

Google, vakna, helvetet. Nu är det år 2020. Du förlorar fortfarande. Det är dags att se djupt i spegeln och svara på om du verkligen vill vara kvar i molnverksamheten.

Om du vill vara kvar, så sluta förstöra allt.Killarna, ni är rika. Vi utvecklare är inte det. Så när det kommer till vem som ska ta på sig bördan av kompatibilitet, måste ni ta det ansvaret. Inte vi.

För det finns åtminstone tre riktigt bra moln kvar. De lockar till sig.

Och nu går jag vidare för att fixa alla mina trasiga system. Suck.

Tills nästa gång!

P. S. En uppdatering efter att ha läst några diskussioner kring denna artikel (diskussionerna är fantastiska, förresten). Stödet för Firebase har inte upphört, och det finns inga planer som jag känner till. Men de har en irriterande strömningsfel som gör att Java-klienten stannar i App Engine. En av deras ingenjörer hjälpte mig att hantera detta problem, när jag arbetade på Google, men de har aldrig verkligen åtgärdat buggen, så jag har en tråkig workaround, jag måste starta om GAE-applikationen varje dag. Och så har det varit i fyra år nu! Nu har de Firestore. Det kommer att krävas mycket arbete för att migrera till det, eftersom det är ett helt annat system, och Firebase-felet kommer aldrig att åtgärdas. Vad kan man dra för slutsats? Du kan få hjälp, om du arbetar på ett företag. Kanske är jag den enda som använder Firebase på GAE, eftersom jag registrerar mindre än 100 nycklar i en 100% inhemsk applikation, och den slutar fungera varannan dag på grund av den kända buggen. Vad kan man säga, annat än att använda det på egen risk. Jag går över till Redis.

Jag har också sett att vissa mer erfarna användare av AWS har sagt att AWS vanligtvis aldrig avslutar stödet för några tjänster, och SimpleDB är ett utmärkt exempel. Mina antaganden, att AWS inte har samma problem med att avsluta support som Google, verkar stämma.

Dessutom har jag lagt märke till att Googles App Engine-team för 20 dagar sedan bröt värdningen av ett kritiskt Go-bibliotek, vilket stängde av GAE-applikationen från en av de främsta Go-utvecklarna. Verkligen, det blev dumt.

Slutligen har jag hört att googlarna redan diskuterar detta och i stort sett är överens med mig (älskar er, grabbar!). Men det verkar som om de anser att problemet är olösbart, eftersom det aldrig har funnits en riktig struktur för incitament i Googles kultur. Jag tror att det skulle vara bra att ta lite tid för att diskutera den helt fantastiska erfarenheten av att arbeta med AWS-ingenjörer när jag arbetade på företaget Grab. Kanske i framtiden, hoppas jag!

Och ja, år 2005 hade de faktiskt olika typer av hajkött på den stora svenska buffén i byggnad 43, och jag gillade mest köttet från hammerhajar. Men till 2006 hade Larry och Sergey blivit av med alla ohälsosamma snacks. Så under historien om Bigtable 2007 fanns det verkligen inga hajar kvar, och jag lurade er elakt.

När jag tittade på den molnbaserade Bigtable för fyra år sedan (plus minus), var kostnaden just så. Det verkar som om det har minskat lite nu, men det är fortfarande förskräckligt mycket för ett tomt datalager, särskilt med tanke på att min första historia visar hur oväsentlig en tom stor tabell är i deras skala.

Jag ber om ursäkt för att jag förolämpade Apple-gemenskapen och för att jag inte sa något positivt om Microsoft och så vidare. Ni har alla rätt, jag uppskattar verkligen alla diskussioner som denna artikel har väckt! Men ibland behöver man skaka om lite för att få igång diskussionen, förstår ni?

Tack för att du läste.

Uppdatering 2, 19.08.2020. Stripe utför korrekt API-uppdatering!

Uppdatering 3, 31.08.2020. Jag blev kontaktad av en ingenjör på Google i Cloud Marketplace, som visade sig vara en gammal vän. Han ville ta reda på varför C2D inte fungerade, och till slut kom vi fram till att orsaken var att jag skapade mitt nätverk för flera år sedan, och C2D fungerar inte i föråldrade nätverk på grund av den saknade subnetparameter i deras mallar. Jag tror att potentiella GCP-användare bör se till att de har tillräckligt med bekanta ingenjörer på Google…

Källa: habr.com