Verdomde Google, ik wilde niet meer bloggen. Ik heb zoveel te doen. Bloggen kost tijd, energie en creativiteit, die ik goed zou kunnen gebruiken: mijn boeken, , mijn spel enzovoort. Maar je hebt me zo kwaad gemaakt dat ik dit moet schrijven.
Dus laten we dit achter de rug hebben.
Laat ik beginnen met een kort maar leerzaam verhaal van toen ik voor het eerst bij Google begon te werken. Ik weet dat ik de laatste tijd veel slechte dingen over Google heb gezegd, maar het maakt me van streek als mijn eigen bedrijf regelmatig incompetente zakelijke beslissingen neemt. Tegelijkertijd moeten we het waarmaken: de interne infrastructuur van Google is werkelijk buitengewoon, het is veilig om te zeggen dat er vandaag de dag niets beters is. De oprichters van Google waren veel betere ingenieurs dan ik ooit zal zijn, en dit verhaal bevestigt dat feit alleen maar.
Eerst wat achtergrondinformatie: Google heeft een technologie voor gegevensopslag genoemd . Het was een opmerkelijke technische prestatie, een van de eerste (zo niet de eerste) ‘oneindig schaalbare’ sleutelwaardeopslag (K/V): in wezen het begin van NoSQL. Tegenwoordig doet Bigtable het nog steeds goed in de nogal drukke K/V-opslagruimte, maar destijds (2005) was het verbazingwekkend cool.
Het grappige aan Bigtable is dat ze objecten op het interne controlevlak hadden (als onderdeel van de implementatie), genaamd tabletservers, met grote indexen, en op een gegeven moment werden ze een knelpunt bij het schalen van het systeem. Bigtable-ingenieurs vroegen zich af hoe ze schaalbaarheid moesten implementeren en realiseerden zich plotseling dat ze tabletservers konden vervangen door andere Bigtable-opslag. Bigtable is dus onderdeel van de Bigtable-implementatie. Deze opslagfaciliteiten zijn er op alle niveaus.
Een ander interessant detail is dat Bigtable een tijdje populair en alomtegenwoordig werd binnen Google, waarbij elk team zijn eigen repository had. Dus tijdens een van de vrijdagbijeenkomsten vroeg Larry Page terloops: “Waarom hebben we meer dan één Bigtable? Waarom niet slechts één?” In theorie zou één opslagruimte voldoende moeten zijn voor alle opslagbehoeften van Google. Natuurlijk gingen ze nooit naar slechts één om praktische ontwikkelingsredenen (zoals de gevolgen van een mogelijke mislukking), maar de theorie was interessant. Eén opslagplaats voor het hele universum (Weet iemand trouwens of Amazon dit met hun Sable heeft gedaan?)
Hoe dan ook, hier is mijn verhaal.
Ik werkte toen iets meer dan twee jaar bij Google en op een dag ontving ik een e-mail van het technische team van Bigtable die ongeveer zo luidde:
Beste Steve,
Hallo namens het Bigtable-team. We willen u graag laten weten dat u bij [datacenternaam] een heel, heel oud Bigtable-binair bestand gebruikt. Deze versie wordt niet langer ondersteund en we willen u helpen bij het upgraden naar de nieuwste versie.
Laat het me weten als u tijd kunt vrijmaken om samen aan dit onderwerp te werken.
Al het beste,
Bigtable-team
Op Google krijg je veel mail, dus op het eerste gezicht lees ik zoiets als dit:
Beste ontvanger,
Hallo namens een team. Wij willen dat bla-bla-bla-bla-bla communiceren. Bla, bla, bla, bla, bla, en meteen bla, bla.
Laat het ons weten als u wat van uw kostbare tijd kunt inplannen voor bla bla bla.
Al het beste,
Een soort commando
Ik had het bijna meteen verwijderd, maar aan de rand van mijn bewustzijn voelde ik een pijnlijk, zeurderig gevoel dat het het was niet echt ziet er echter uit als een formele brief очевидно, dat de ontvanger zich heeft vergist omdat ik Bigtable niet heb gebruikt.
Maar het was vreemd.
De rest van de dag bracht ik afwisselend door met nadenken over werk en wat voor soort haaienvlees ik moest proberen in de microkeuken, waarvan er minstens drie dichtbij genoeg waren om met een welgemikte worp van een koekje vanuit mijn stoel te slaan, maar de De gedachte aan schrijven heeft me nooit met een groeiend gevoel van milde angst achtergelaten.
Ze zeiden duidelijk mijn naam. En de e-mail is naar mijn e-mailadres verzonden, niet naar dat van iemand anders, en het is niet cc: of bcc:. De toon is heel persoonlijk en helder. Misschien is dit een soort vergissing?
Uiteindelijk kreeg de nieuwsgierigheid de overhand en ging ik naar de Borg-console kijken in het datacenter dat ze noemden.
En natuurlijk had ik BigTable-opslag in beheer. Het spijt me, wat? Ik keek naar de inhoud en wauw! Het kwam uit de Codelab-incubator waarin ik zat tijdens mijn eerste week bij Google in juni 2005. Codelab dwong je om Bigtable uit te voeren om daar enkele waarden te schrijven, en ik heb de opslag daarna blijkbaar nooit gesloten. Het werkte nog steeds, ook al waren er meer dan twee jaar verstreken.
Er zijn een aantal opmerkelijke aspecten aan dit verhaal. Ten eerste was het werk van Bigtable zo onbeduidend op de schaal van Google dat slechts twee jaar later iemand de extra opslagruimte opmerkte, en alleen omdat de versie van het binaire bestand verouderd was. Ter vergelijking: ik heb ooit overwogen om te gebruiken voor mijn online spel. Destijds kostte deze service ongeveer $ 16 per jaar. leeg Bigtable op GCP. Ik zeg niet dat ze je oplichten, maar naar mijn persoonlijke mening is dat veel geld voor een lege database.
Een ander opmerkelijk aspect is dat de opslag werkt na twee jaar nog steeds. WTF? Datacenters komen en gaan; ze hebben te maken met storingen, ze ondergaan gepland onderhoud en ze veranderen voortdurend. Hardware wordt bijgewerkt, schakelaars worden verwisseld, alles wordt voortdurend verbeterd. Hoe konden ze in godsnaam mijn programma twee jaar lang draaiende houden met al deze veranderingen? In 2020 lijkt dit misschien een bescheiden prestatie, maar in 2005-2007 was het behoorlijk indrukwekkend.
En het mooiste aspect is dat een extern technisch team in een andere staat mij benadert, de eigenaar van een klein, bijna leeg exemplaar van Bigtable, die nul verkeer van de afgelopen twee jaar - en bieden hulp om deze bij te werken.
Ik bedankte ze, verwijderde de opslag en het leven ging verder zoals gewoonlijk. Maar dertien jaar later denk ik nog steeds aan die brief. Omdat ik soms soortgelijke e-mails ontvang van Google Cloud. Ze zien er zo uit:
Beste Google Cloud-gebruiker,
Ter herinnering: we zullen de service [essentiële service die u gebruikt] vanaf augustus 2020 stopzetten, waarna u uw instances niet meer kunt upgraden. We raden aan om met onze vriendelijke hulp te upgraden naar de nieuwste versie, die zich in bètatest bevindt, geen documentatie heeft, geen migratiepad heeft en al eerder verouderd is.
We willen ervoor zorgen dat deze wijziging een minimale impact heeft op alle gebruikers van het Google Cloud-platform.
Beste vrienden voor altijd,
Google Cloudplatform
Maar ik lees zulke brieven bijna nooit, want wat ze eigenlijk zeggen is:
Beste ontvanger,
Loop naar de hel. Fuck jou, fuck jij, fuck jij. Laat alles vallen wat je doet, want het doet er niet toe. Wat telt is onze tijd. We verspillen tijd en geld met het onderhouden van onze onzin en we zijn het beu, dus we zullen het niet meer steunen. Dus stop met je verdomde plannen en begin met het doorzoeken van onze waardeloze documentatie, smeken om restjes op de forums, en trouwens, onze nieuwe shit is compleet anders dan de oude shit, omdat we dit ontwerp behoorlijk verprutst hebben, heh, maar dat is jouw probleem, niet het onze.
Wij blijven ons inspannen om ervoor te zorgen dat al uw ontwikkelingen binnen een jaar onbruikbaar worden.
Rot alsjeblieft op
Google Cloudplatform
En het feit is dat ik dergelijke brieven ongeveer één keer per maand ontvang. Dit gebeurt zo vaak en zo constant dat het onvermijdelijk is weggeduwd mij van GCP naar het anti-cloudkamp. Ik ben het er niet langer mee eens om afhankelijk te zijn van hun propriëtaire ontwikkelingen, omdat het in feite gemakkelijker is voor ontwikkelaars om een open source-systeem op een kale virtuele machine te onderhouden dan te proberen Google bij te houden met zijn beleid om ‘verouderde’ producten te sluiten.
Voordat ik terugga naar Google Cloud omdat ik zelfs dichtbij We zijn nog niet klaar met het bekritiseren ervan. Laten we eens kijken naar de prestaties van het bedrijf op een aantal andere gebieden. Google-ingenieurs zijn trots op hun software-engineeringdiscipline, en dit is wat feitelijk problemen veroorzaakt. Trots is een valkuil voor onoplettenden en heeft ertoe geleid dat veel Google-werknemers denken dat hun beslissingen altijd juist zijn en dat gelijk hebben (volgens een vage, vage definitie) belangrijker is dan zorgen voor klanten.
Ik zal enkele willekeurige voorbeelden geven van andere grote projecten buiten Google, maar ik hoop dat je dit patroon overal tegenkomt. Het is als volgt: achterwaartse compatibiliteit houdt systemen tientallen jaren levend en up-to-date.
Achterwaartse compatibiliteit is het ontwerpdoel van alle succesvolle systemen waarvoor ze zijn ontworpen open gebruik, dat wil zeggen geïmplementeerd met open source code en/of open standaarden. Ik heb het gevoel dat ik iets te voor de hand liggend zeg, waardoor iedereen zich zelfs ongemakkelijk voelt, maar nee. Dit is een politieke kwestie, dus er zijn voorbeelden nodig.
Het eerste systeem dat ik zal kiezen is het oudste: GNU Emacs, een soort hybride tussen Windows Notepad, de OS-kernel en het International Space Station. Het is een beetje moeilijk uit te leggen, maar in een notendop is Emacs een platform dat in 1976 (ja, bijna een halve eeuw geleden) werd gecreëerd voor programmeren om je productiever te maken, maar dat zich voordoet als een teksteditor.
Ik gebruik Emacs elke dag. Ja, ik gebruik IntelliJ ook elke dag, het is op zichzelf uitgegroeid tot een krachtig toolingplatform. Maar het schrijven van extensies voor IntelliJ is een veel ambitieuzere en complexere taak dan het schrijven van extensies voor Emacs. En nog belangrijker: alles dat voor Emacs is geschreven, blijft behouden eeuwig.
Ik gebruik nog steeds de software die ik in 1995 voor Emacs schreef. En ik weet zeker dat iemand modules gebruikt die halverwege de jaren 80 voor Emacs zijn geschreven, zo niet eerder. Het kan zijn dat ze af en toe een beetje moeten worden aangepast, maar dit is echt vrij zeldzaam. Ik ken niets dat ik ooit voor Emacs heb geschreven (en ik heb er veel geschreven) waarvoor een nieuwe architectuur nodig was.
Emacs heeft een functie genaamd make-obsolete voor verouderde entiteiten. De terminologie van Emacs voor fundamentele computerconcepten (zoals wat een "venster" is) verschilt vaak van de industriële conventies, omdat Emacs deze lang geleden introduceerde. Dit is een typisch gevaar voor degenen die hun tijd vooruit zijn: al uw termen zijn onjuist. Maar Emacs heeft wel een concept van afschrijving, dat in hun jargon heet veroudering.
Maar in de Emacs-wereld lijkt er een andere werkdefinitie te bestaan. Een andere onderliggende filosofie, zo je wilt.
In de wereld van Emacs (en op veel andere gebieden, die we hieronder zullen bespreken) betekent de verouderde API-status feitelijk: "Je zou deze aanpak eigenlijk niet moeten gebruiken, want hoewel het werkt, lijdt het aan verschillende tekortkomingen die we zullen tegenkomen lijst hier. Maar uiteindelijk is het jouw keuze."
In de wereld van Google betekent verouderd zijn: "We schenden onze belofte aan u." Dit is waar. Dit is wat het in wezen betekent. Dit betekent dat ze je zullen dwingen op regelmatige basis wat werk doen, misschien veel werk, als straf voor het geloven in hen : Wij hebben de beste software. De snelste! Je doet alles volgens de instructies, start je applicatie of dienst, en dan bam, na een jaar of twee gaat hij kapot.
Het is alsof je een gebruikte auto verkoopt die na 1500 km definitief kapot gaat.
Dit zijn twee totaal verschillende filosofische definities van ‘veroudering’. Google's definitie van geur . Ik geloof dit niet in feite geplande veroudering in dezelfde zin als Apple. Maar Google is zeker van plan om uw programma's via een omweg kapot te maken. Ik weet dit omdat ik daar ruim twaalf jaar als software engineer heb gewerkt. Ze hebben vage interne richtlijnen over hoeveel achterwaartse compatibiliteit moet worden gevolgd, maar het is uiteindelijk aan elk individueel team of elke dienst. Er zijn geen aanbevelingen op ondernemings- of technisch niveau, en de stoutmoedigste aanbeveling in termen van verouderingscycli is “probeer klanten zes tot twaalf maanden de tijd te geven om te upgraden voordat ze hun hele systeem kapot maken.”
Het probleem is veel groter dan ze denken, en het zal nog jaren voortduren omdat klantenservice niet in hun DNA zit. Meer hierover hieronder.
Op dit punt ga ik een gewaagde verklaring afleggen dat Emacs in grote mate en zelfs succesvol is in principe omdat ze achterwaartse compatibiliteit zo serieus nemen. Eigenlijk is dit de stelling van ons artikel. Succesvolle, langlevende open systemen danken hun succes aan de microgemeenschappen die er al tientallen jaren omheen leven extensies/plug-ins. Dit is het ecosysteem. Ik heb het al gehad over de aard van platforms en hoe belangrijk ze zijn, en hoe Google in zijn hele bedrijfsgeschiedenis nooit heeft begrepen wat er komt kijken bij het creëren van een succesvol open platform buiten Android of Chrome.
Eigenlijk zou ik Android kort moeten noemen, omdat je er waarschijnlijk over nadenkt.
Enerzijds de Android is geen Google. Ze hebben vrijwel niets met elkaar gemeen. Android is een bedrijf dat in juli 2005 door Google is gekocht, het bedrijf mocht min of meer autonoom opereren en is in de tussenliggende jaren feitelijk grotendeels onaangeroerd gebleven. Android is een beruchte tech-stack en een even beruchte stekelige organisatie. Zoals een Googler het verwoordde: “Je kunt niet zomaar inloggen op Android.”
In een vorig artikel besprak ik hoe slecht sommige vroege ontwerpbeslissingen van Android waren. Heck, toen ik dat artikel schreef, waren ze bezig met het uitrollen van onzin genaamd "instant apps", die nu (verrassing!) , en ik heb medelijden met het feit dat je zo stom was om naar Google te luisteren en je inhoud naar deze instant-apps te verplaatsen.
Maar er is hier een verschil, een significant verschil, namelijk dat Android-mensen echt begrijpen hoe belangrijk platforms zijn, ze doen hun best om oude Android-apps werkend te houden. In feite zijn hun inspanningen om achterwaartse compatibiliteit te behouden zo extreem dat zelfs ik, tijdens mijn korte periode bij de Android-divisie een paar jaar geleden, merkte dat ik hen probeerde te overtuigen de ondersteuning voor enkele van de oudste apparaten en API's stop te zetten (ik had het mis , zoals met veel andere dingen uit heden en verleden. Sorry Android-jongens! Nu ik in Indonesië ben geweest, begrijp ik waarom we ze nodig hebben).
De Android-mensen pushen achterwaartse compatibiliteit tot bijna onvoorstelbare extremen, waardoor enorme hoeveelheden verouderde technische schulden in hun systemen en toolchains worden opgestapeld. Oh mijn god, je zou enkele van de gekke dingen moeten zien die ze in hun bouwsysteem moeten doen, allemaal in naam van compatibiliteit.
Hiervoor beloon ik Android met de felbegeerde onderscheiding 'Je bent geen Google'. Ze willen echt geen Google worden, dat geen duurzame platforms weet te creëren, maar Android weet, hoe je dat doet. En dus is Google in één opzicht heel slim: mensen de dingen op hun eigen manier laten doen op Android.
Instant-apps voor Android waren echter een behoorlijk dom idee. En weet je waarom? Omdat ze het eisten herschrijf en herontwerp uw applicatie! Het is alsof mensen simpelweg twee miljoen applicaties zullen herschrijven. Ik vermoed dat Instant Apps een idee van een Googler was.
Maar er is een verschil. Achterwaartse compatibiliteit brengt hoge kosten met zich mee. Android draagt zelf de last van deze kosten, terwijl Google erop aandringt dat de last wordt gedragen вы, betalende klant.
Je kunt de toewijding van Android aan achterwaartse compatibiliteit zien in zijn API's. Als je vier of vijf verschillende subsystemen hebt die letterlijk hetzelfde doen, is dat een duidelijk teken dat achterwaartse compatibiliteit centraal staat. Wat in de wereld van platforms synoniem staat voor betrokkenheid bij je klanten en je markt.
Het grootste probleem van Google hier is hun trots op hun technische hygiëne. Ze houden er niet van als er veel verschillende manieren zijn om hetzelfde te doen, waarbij de oude, minder wenselijke manieren naast de nieuwe, mooiere manieren staan. Het verhoogt de leercurve voor degenen die nieuw zijn in het systeem, het verhoogt de last van het onderhouden van oudere API's, het vertraagt de snelheid van nieuwe functies, en de hoofdzonde is dat het niet mooi is. Google - zoals Lady Ascot uit Tim Burton's Alice in Wonderland:
Dame Ascot:
- Alice, weet je waar ik het meest bang voor ben?
- Het verval van de aristocratie?
- Ik was bang dat ik dat zou doen lelijke kleinkinderen.
Laten we, om de afweging tussen mooi en praktisch te begrijpen, eens kijken naar het derde succesvolle platform (na Emacs en Android) en zien hoe het werkt: Java zelf.
Java heeft veel verouderde API's. Beëindiging is erg populair onder Java-programmeurs, zelfs populairder dan in de meeste programmeertalen. Java zelf, de kerntaal en de bibliotheken zijn voortdurend bezig met het afschaffen van API's.
Om maar een van de duizenden voorbeelden te noemen: als verouderd beschouwd. Het is verouderd sinds de release van Java 1.2 in december 1998. Het is 22 jaar geleden dat dit werd afgeschaft.
Maar mijn daadwerkelijke code in productie doodt nog steeds threads каждый день. Vind je dat echt goed? Absoluut! Ik bedoel, als ik de code vandaag zou herschrijven, zou ik hem natuurlijk anders implementeren. Maar de code voor mijn spel, dat de afgelopen twintig jaar honderdduizenden mensen blij heeft gemaakt, is geschreven met een functie om discussies te sluiten die te lang blijven hangen, en ik heb het nooit hoeven veranderen. Ik ken mijn systeem beter dan wie dan ook, ik heb letterlijk 25 jaar ervaring met het werken ermee in de productie, en ik kan met zekerheid zeggen: in mijn geval is het sluiten van deze specifieke werkthreads volkomen onschadelijk. Het is de tijd en moeite niet waard om deze code te herschrijven, en bedank Larry Ellison (waarschijnlijk) dat Oracle mij niet heeft gedwongen om het te herschrijven.
Oracle begrijpt waarschijnlijk ook platforms. Wie weet.
Bewijs is te vinden in de belangrijkste Java-API's, die doordrenkt zijn met golven van veroudering, zoals de lijnen van een gletsjer in een kloof. U kunt eenvoudig vijf of zes verschillende toetsenbordnavigatiemanagers (KeyboardFocusManager) vinden in de Java Swing-bibliotheek. Het is eigenlijk moeilijk om een Java API te vinden die niet verouderd is. Maar ze werken nog steeds! Ik denk dat het Java-team een API pas echt zal verwijderen als de interface een flagrant beveiligingsprobleem oplevert.
Het punt is, mensen: wij softwareontwikkelaars hebben het allemaal erg druk, en op elk softwaregebied worden we geconfronteerd met concurrerende alternatieven. Op elk gegeven moment overwegen programmeurs in taal X taal Y als een mogelijke vervanging. Geloof je mij niet? Wil je het Swift noemen? Iedereen migreert bijvoorbeeld naar Swift en niemand laat het in de steek, toch? Wauw, wat weet je weinig. Bedrijven rekenen de kosten van twee mobiele ontwikkelingsteams (iOS en Android) door - en ze beginnen zich te realiseren dat die platformonafhankelijke ontwikkelingssystemen met grappige namen als Flutter en React Native echt werken en gebruikt kunnen worden om de omvang van hun teams te verkleinen. mobiele teams twee keer of, omgekeerd, ze twee keer zo productief maken. Er staat echt geld op het spel. Ja, er zijn compromissen, maar aan de andere kant is er geld.
Laten we hypothetisch aannemen dat Apple dwaas het signaal van Guido van Rossum heeft overgenomen en heeft verklaard dat Swift 6.0 achterwaarts incompatibel is met Swift 5.0, net zoals Python 3 incompatibel is met Python 2.
Ik heb dit verhaal waarschijnlijk tien jaar geleden verteld, maar ongeveer vijftien jaar geleden ging ik met Guido naar O'Reilly's Foo Camp, zat in een tent met Paul Graham en een stel grote jongens. We zaten in de zinderende hitte te wachten tot Larry Page zou wegvliegen in zijn persoonlijke helikopter, terwijl Guido doorzeurde over ‘Python 3000’, die hij vernoemde naar het aantal jaren dat het zou duren voordat iedereen daarheen zou migreren. We bleven hem vragen waarom hij de compatibiliteit verbrak, en hij antwoordde: “Unicode.” En we vroegen ons af: als we onze code moesten herschrijven, welke andere voordelen zouden we dan zien? En hij antwoordde: "Yooooooooooooouuuuuuuniiiiiiicoooooooode."
Als u de Google Cloud Platform SDK (“gcloud”) installeert, ontvangt u de volgende melding:
Beste ontvanger,
We willen je eraan herinneren dat de ondersteuning voor Python 2 is beëindigd, dus fuck you
… enzovoort. Cirkel van het leven.
Maar het punt is dat elke ontwikkelaar een keuze heeft. En als je ze dwingt de code vaak genoeg te herschrijven, zullen ze er misschien over nadenken ander opties. Het zijn niet jouw gijzelaars, hoe graag je dat ook zou willen. Het zijn jouw gasten. Python is nog steeds een zeer populaire programmeertaal, maar verdomd, Python 3(000) heeft op zichzelf, in zijn gemeenschappen en onder de gebruikers van zijn gemeenschappen zo'n puinhoop gecreëerd dat de gevolgen al vijftien jaar niet zijn opgehelderd.
Hoeveel Python-programma's zijn herschreven in Go (of Ruby, of een ander alternatief) vanwege deze achterwaartse incompatibiliteit? Hoeveel nieuwe software is er in iets anders dan Python geschreven, hoewel dat wel het geval is zou kunnen geschreven in Python, als Guido niet het hele dorp had platgebrand? Het is moeilijk te zeggen, maar Python heeft duidelijk geleden. Het is een enorme puinhoop en iedereen verliest.
Laten we dus zeggen dat Apple een signaal van Guido overneemt en de compatibiliteit verbreekt. Wat denk je dat er hierna zal gebeuren? Nou ja, misschien zal 80-90% van de ontwikkelaars hun software herschrijven als dat mogelijk is. Met andere woorden: 10-20% van het gebruikersbestand gaat automatisch naar een concurrerende taal, zoals Flutter.
Als u dit meerdere keren doet, verliest u de helft van uw gebruikersbestand. Net als in de sport is ook in de programmeerwereld de huidige vorm van belang. всё. Iedereen die binnen vijf jaar de helft van zijn gebruikers verliest, wordt beschouwd als een Big Fat Loser. Je moet trendy zijn in de wereld van platforms. Maar dit is waar het niet ondersteunen van oudere versies je na verloop van tijd zal ruïneren. Omdat elke keer dat je een aantal ontwikkelaars wegdoet, je (a) ze voor altijd kwijtraakt omdat ze boos op je zijn omdat je het contract hebt verbroken, en (b) ze weggeeft aan je concurrenten.
Ironisch genoeg heb ik Google ook geholpen zo'n prima donna te worden die achterwaartse compatibiliteit negeert toen ik Grok creëerde, een broncode-analyse- en begripssysteem dat het gemakkelijk maakt om de code zelf te automatiseren en te instrumenteren - vergelijkbaar met een IDE, maar hier slaat de cloudservice op gematerialiseerde representaties van alle miljarden regels Google-broncode in een groot datawarehouse.
Grok voorzag Googlers van een krachtig raamwerk voor het uitvoeren van geautomatiseerde refactorings in hun gehele codebase (letterlijk overal in Google). Het systeem berekent niet alleen uw upstream-afhankelijkheden (waarvan u afhankelijk bent), maar ook stroomafwaarts (die is aan jou), dus als je API's wijzigt, weet je iedereen die je kapot maakt! Op deze manier kunt u, wanneer u wijzigingen aanbrengt, verifiëren dat elke gebruiker van uw API is bijgewerkt naar de nieuwe versie, en in werkelijkheid kunt u, vaak met de Rosie-tool die zij hebben geschreven, het proces volledig automatiseren.
Hierdoor kan de codebase van Google intern bijna bovennatuurlijk schoon zijn, omdat deze robotbedienden door het huis rennen en alles automatisch opruimen als ze de naam SomeDespicablyLongFunctionName hernoemen naar SomeDespicablyLongMethodName, omdat iemand heeft besloten dat het een lelijk kleinkind is en dat hij in slaap moet worden gebracht.
En eerlijk gezegd werkt het redelijk goed voor Google... intern. Ik bedoel, ja, de Go-gemeenschap bij Google lacht goed met de Java-gemeenschap bij Google vanwege hun gewoonte van voortdurende refactoring. Als je iets N keer opnieuw opstart, betekent dit dat je het niet alleen N-1 keer verprutst hebt, maar na een tijdje wordt het vrij duidelijk dat je het waarschijnlijk ook bij de N-de poging verprutst hebt. Maar over het algemeen blijven ze boven al deze ophef en houden ze de code ‘schoon’.
Het probleem begint wanneer ze deze houding proberen op te leggen aan hun cloudclients en gebruikers van andere API’s.
Ik heb je een beetje kennis laten maken met Emacs, Android en Java; laten we eens kijken naar het nieuwste succesvolle platform met een lange levensduur: het web zelf. Kunt u zich voorstellen hoeveel iteraties HTTP heeft doorlopen sinds 1995, toen we knipperende tags gebruikten? en 'Under Construction'-pictogrammen op webpagina's.
Maar het werkt nog steeds! En deze pagina's werken nog steeds! Ja jongens, browsers zijn de wereldkampioenen op het gebied van achterwaartse compatibiliteit. Chrome is een ander voorbeeld van het zeldzame Google-platform waarvan de koppen correct zijn vastgeschroefd, en zoals je misschien al geraden had, opereert Chrome feitelijk als een sandbox-bedrijf, los van de rest van Google.
Ik wil ook onze vrienden in de ontwikkelaars van besturingssystemen bedanken: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., voor hun geweldige werk op het gebied van achterwaartse compatibiliteit op hun succesvolle platforms (Apple krijgt op zijn best een C met The Het nadeel is dat ze de hele tijd alles kapot maken zonder goede reden, maar op de een of andere manier komt de gemeenschap er bij elke release omheen, en OS X-containers zijn nog steeds niet helemaal verouderd... nog steeds).
Maar wacht, zegt u. Vergelijken we geen appels met peren: zelfstandige softwaresystemen op één machine zoals Emacs/JDK/Android/Chrome versus systemen met meerdere servers en API's zoals cloudservices?
Nou, ik heb hier gisteren over getweet, maar in de stijl van Larry Wall (maker van de programmeertaal Perl - ongeveer per.) op basis van het principe van "sucks/rules" heb ik het woord opgezocht deprecated op de ontwikkelaarssites van Google en Amazon. En hoewel AWS dat wel heeft gedaan honderden keer meer serviceaanbiedingen dan GCP, vermeldt de ontwikkelaarsdocumentatie van Google ongeveer zeven keer vaker beëindiging.
Als iemand bij Google dit leest, zijn ze waarschijnlijk klaar om grafieken in Donald Trump-stijl tevoorschijn te halen die laten zien dat ze eigenlijk alles goed doen, en dat ik geen oneerlijke vergelijkingen mag maken zoals "het aantal vermeldingen van het woord verouderd versus aantal diensten" "
Maar na al die jaren is Google Cloud nog steeds de nummer 3-service (ik heb nooit een artikel geschreven over de mislukte poging om nummer 2 te worden), maar als we insiders mogen geloven, zijn er enkele zorgen waar ze binnenkort naar toe zouden kunnen gaan. Nummer 4.
Ik heb geen overtuigende argumenten om mijn stelling te ‘bewijzen’. Het enige dat ik heb zijn de kleurrijke voorbeelden die ik in de afgelopen dertig jaar als ontwikkelaar heb verzameld. Ik heb de diepgaande filosofische aard van dit probleem al genoemd; in sommige opzichten is het gepolitiseerd in ontwikkelaarsgemeenschappen. Sommigen geloven dat makers platforms zouden zich zorgen moeten maken over compatibiliteit, terwijl anderen denken dat dit een probleem is gebruikers (de ontwikkelaars zelf). Een van de twee. Is het niet een politieke kwestie als we beslissen wie de kosten van gemeenschappelijke problemen moet dragen?
Dit is dus politiek. En er zullen waarschijnlijk boze reacties komen op mijn toespraak.
Als gebruiker Google Cloud Platform, en als AWS-gebruiker gedurende twee jaar (terwijl ik voor Grab werkte), kan ik zeggen dat er een enorm verschil is tussen de filosofieën van Amazon en Google als het gaat om prioriteiten. Ik ontwikkel niet actief op AWS, dus ik weet niet zo goed hoe vaak ze oude API's verwijderen. Maar het vermoeden bestaat dat dit lang niet zo vaak gebeurt als bij Google. En ik geloof echt dat deze bron van voortdurende controverse en frustratie bij GCP een van de grootste factoren is die de ontwikkeling van het platform tegenhouden.
Ik weet dat ik geen specifieke voorbeelden heb genoemd van GCP-systemen die niet langer worden ondersteund. Ik kan zeggen dat bijna alles wat ik heb gebruikt, van netwerken (van de oudste tot VPC) tot opslag (Cloud SQL v1-v2), Firebase (nu Firestore met een compleet andere API), App Engine (laten we niet eens beginnen) , cloud-eindpunten Cloud-eindpunt en tot... Ik weet het niet - absoluut dit allemaal dwongen je om de code na maximaal 2-3 jaar te herschrijven, en ze hebben de migratie nooit voor je geautomatiseerd, en vaak . Alsof het zo zou moeten zijn.
En elke keer als ik naar AWS kijk, vraag ik mezelf af waarom ik in vredesnaam nog steeds op GCP zit. Ze hebben duidelijk geen klanten nodig. Zij hebben nodig покупатели. Begrijp je het verschil? Laat het me uitleggen.
Google Cloud heeft , waar mensen hun softwareoplossingen voorstellen, en om het lege restauranteffect te voorkomen, moesten ze het vullen met een aantal voorstellen, dus gingen ze een contract aan met een bedrijf genaamd Bitnami om een aantal oplossingen te creëren die met “één klik” kunnen worden ingezet, of zouden moeten Ik schrijf het zelf ‘oplossingen’, omdat deze niets oplossen. Ze bestaan eenvoudigweg als selectievakjes, als marketingvuller, en het heeft Google nooit kunnen schelen of een van de tools ook daadwerkelijk werkt. Ik ken productmanagers die aan het stuur hebben gezeten, en ik kan je verzekeren dat het deze mensen niets kan schelen.
Neem bijvoorbeeld een zogenaamd ‘één-klik’-implementatieoplossing. . Ik was doodziek van Google Cloud SQL-shenanigans, dus begon ik te kijken naar het bouwen van mijn eigen Percona-cluster als alternatief. En deze keer leek Google het goed te hebben gedaan; ze gingen me met één klik op de knop wat tijd en moeite besparen!
Nou, geweldig, laten we gaan. Laten we de link volgen en op deze knop klikken. Selecteer “Ja” om akkoord te gaan met alle standaardinstellingen en het cluster in uw Google-cloudproject te implementeren. Haha, het werkt niet. Niets van deze onzin werkt. De tool is nooit getest en begon vanaf de eerste minuut te rotten, en het zou mij niet verbazen als meer dan de helft van de "oplossingen" implementaties met één klik zijn (nu begrijpen we waarom de aanhalingstekens) in het algemeen werkt niet. Dit is absoluut hopeloze duisternis, waar het beter is om niet binnen te gaan.
Maar Google heeft gelijk driften jij om ze te gebruiken. Ze willen dat je dat doet kocht. Voor hen is het een transactie. Ze willen niets ondersteuning. Het maakt geen deel uit van het DNA van Google. Ja, engineers ondersteunen elkaar, zoals blijkt uit mijn verhaal met Bigtable. Maar in producten en diensten voor gewone mensen wel altijd waren meedogenloos in , dat niet voldoet aan de lat voor winstgevendheid, ook al heeft het miljoenen gebruikers.
En dit vormt een echte uitdaging voor GCP, omdat dit het DNA is achter alle cloudaanbiedingen. Ze proberen niets te steunen; Het is bekend dat ze weigeren software van derden te hosten (als beheerde service). tot, totdat AWS hetzelfde doet en er een succesvol bedrijf omheen bouwt, en wanneer klanten letterlijk hetzelfde eisen. Het kost echter wel wat moeite om Google iets te laten ondersteunen.
Dit gebrek aan ondersteuningscultuur, in combinatie met de 'laten we het breken om het mooier te maken'-mentaliteit, vervreemdt ontwikkelaars.
En dat is geen goede zaak als je een platform met een lange levensduur wilt bouwen.
Google, word wakker, verdomme. Het is nu 2020. Je verliest nog steeds. Het is tijd om eens goed in de spiegel te kijken en te beslissen of u echt in de cloud wilt blijven werken.
Als je dan wilt blijven hou op met alles kapot te maken. Jongens, jullie zijn rijk. Wij ontwikkelaars niet. Dus als het erom gaat wie de last van compatibiliteit op zich neemt, moet u de taak op zich nemen. Niet voor ons.
Omdat er nog minstens drie echt goede wolken zijn. Ze wenken.
En nu ga ik verder met het repareren van al mijn kapotte systemen. Eh.
Tot de volgende keer!
PS Update na het lezen van enkele discussies over dit artikel (de discussies zijn trouwens geweldig). Firebase-ondersteuning is niet stopgezet en er zijn voor zover ik op de hoogte ben geen plannen. Ze hebben echter een vervelende streamingbug die ervoor zorgt dat de Java-client vastloopt in App Engine. Een van hun ingenieurs heeft me geholpen dit probleem op te lossen, toen ik bij Google werkte, maar ze hebben de bug nooit echt opgelost, dus ik heb een waardeloze oplossing: ik moet de GAE-app elke dag opnieuw opstarten. En dat is al vier jaar zo! Ze hebben nu Firestore. Het zal veel werk vergen om ernaar te migreren, omdat het een heel ander systeem is en de Firebase-bug nooit zal worden opgelost. Welke conclusie kan worden getrokken? Je kunt hulp krijgen als je in een bedrijf werkt. Ik ben waarschijnlijk de enige die Firebase op GAE gebruikt, omdat ik minder dan 100 sleutels log in een 100% native app en deze stopt om de paar dagen met werken vanwege een bekende bug. Wat kan ik anders zeggen dan het gebruiken op eigen risico. Ik stap over naar Redis.
Ik heb ook enkele meer ervaren AWS-gebruikers zien zeggen dat AWS meestal nooit stopt met het ondersteunen van services, en SimpleDB is een goed voorbeeld. Mijn veronderstellingen dat AWS niet dezelfde end-of-support-ziekte heeft als Google lijken gerechtvaardigd.
Bovendien merkte ik dat het Google App Engine-team twintig dagen geleden de hosting van een cruciale Go-bibliotheek verbrak, waardoor een GAE-applicatie van een van de belangrijkste Go-ontwikkelaars werd afgesloten. Het was echt dom.
Ten slotte heb ik Googlers dit onderwerp al horen bespreken en het in het algemeen met mij eens zijn (ik hou van jullie!). Maar ze lijken te denken dat het probleem onoplosbaar is, omdat de cultuur van Google nooit de juiste stimuleringsstructuur heeft gehad. Ik dacht dat het goed zou zijn om wat tijd te nemen om de absoluut geweldige ervaring te bespreken die ik had tijdens het werken met AWS-ingenieurs tijdens mijn werk bij Grab. Ooit in de toekomst, hoop ik!
En ja, in 2005 hadden ze verschillende soorten haaienvlees op het gigantische buffet in gebouw 43, en mijn favoriet was het hamerhaaienvlees. In 2006 waren Larry en Sergei echter van alle ongezonde snacks af. Dus tijdens het Bigtable-verhaal in 2007 waren er echt geen haaien en ik heb je bedrogen.
Toen ik vier jaar geleden naar cloud Bigtable keek (geven of nemen), waren dit de kosten. Het lijkt nu iets te zijn gedaald, maar dat is nog steeds heel veel voor een leeg datawarehouse, vooral omdat mijn eerste verhaal laat zien hoe onbelangrijk een lege grote tafel op deze schaal is.
Sorry dat ik de Apple-gemeenschap heb beledigd en dat ik niets aardigs heb gezegd over Microsoft enz. Het gaat goed met je, ik waardeer alle discussie die dit artikel heeft veroorzaakt enorm! Maar soms moet je een beetje opschudding veroorzaken om een discussie op gang te brengen, weet je?
Bedankt voor het lezen.
Update 2, 19.08.2020/XNUMX/XNUMX. Streep !
Update 3, 31.08.2020/2/2. Er werd contact met mij opgenomen door een Google-ingenieur bij Cloud Marketplace, die een oude vriend van mij bleek te zijn. Hij wilde uitzoeken waarom CXNUMXD niet werkte, en uiteindelijk kwamen we erachter dat dit kwam doordat ik mijn netwerk jaren geleden had gebouwd, en CXNUMXD niet werkte op oudere netwerken omdat de subnetparameter ontbrak in hun sjablonen. Ik denk dat het voor potentiële GCP-gebruikers het beste is om ervoor te zorgen dat ze voldoende technici bij Google kennen...
Bron: www.habr.com