Sakra Google, nechcel som znova blogovať. Mám toho veľa na práci. Blogovanie si vyžaduje čas, energiu a kreativitu, ktoré by som mohol dobre využiť: moje knihy, , moja hra a podobne. Ale dosť si ma nasral, že to musím napísať.
Tak nech to máme za sebou.
Dovoľte mi začať krátkym, ale poučným príbehom z obdobia, keď som prvýkrát začal pracovať v Google. Viem, že v poslednej dobe hovorím o Google veľa zlých vecí, ale rozčuľuje ma, keď moja vlastná spoločnosť pravidelne robí nekompetentné obchodné rozhodnutia. Zároveň tomu musíme dať za pravdu: vnútorná infraštruktúra Google je skutočne výnimočná, s istotou sa dá povedať, že dnes neexistuje nič lepšie. Zakladatelia spoločnosti Google boli oveľa lepšími inžiniermi ako ja kedy budem a tento príbeh túto skutočnosť len potvrdzuje.
Najprv malé pozadie: Google má technológiu ukladania údajov tzv . Bol to pozoruhodný technický úspech, jeden z prvých (ak nie prvý) „nekonečne škálovateľný“ kľúč-hodnota (K/V): v podstate začiatok NoSQL. V týchto dňoch sa Bigtable stále darí v dosť preplnenom úložnom priestore K/V, ale v tom čase (2005) to bolo úžasne cool.
Jedna zábavná vec na Bigtable je, že mali vnútorné objekty riadiacej roviny (ako súčasť implementácie) nazývané tabletové servery s veľkými indexmi a v určitom bode sa stali prekážkou pri škálovaní systému. Inžinieri Bigtable si lámali hlavu nad tým, ako implementovať škálovateľnosť, a zrazu si uvedomili, že by mohli nahradiť tabletové servery iným úložiskom Bigtable. Bigtable je teda súčasťou implementácie Bigtable. Tieto skladovacie zariadenia sú na všetkých úrovniach.
Ďalším zaujímavým detailom je, že Bigtable sa na chvíľu stal populárnym a všadeprítomným v rámci Google, pričom každý tím má svoje vlastné úložisko. Na jednom z piatkových stretnutí sa teda Larry Page len tak mimochodom spýtal: „Prečo máme viac ako jeden Bigtable? Prečo nie len jeden?" Teoreticky by jedno úložisko malo stačiť na všetky úložné potreby Googlu. Samozrejme, nikdy nešli len do jedného z praktických dôvodov vývoja (ako dôsledky potenciálneho zlyhania), ale teória bola zaujímavá. Jedno úložisko pre celý vesmír (Mimochodom, vie niekto, či to Amazon urobil so svojím Sablem?)
Každopádne, tu je môj príbeh.
V tom čase som v Google pracoval niečo vyše dvoch rokov a jedného dňa som dostal e-mail od inžinierskeho tímu Bigtable, ktorý vyzeral takto:
drahý Steve,
Zdravíme vás z tímu Bigtable. Radi by sme vás informovali, že v [názov dátového centra] používate veľmi, veľmi starý binárny súbor Bigtable. Táto verzia už nie je podporovaná a my vám chceme pomôcť s inováciou na najnovšiu verziu.
Dajte mi vedieť, či si môžete naplánovať nejaký čas na spoločnú prácu na tomto probléme.
Všetko najlepšie,
Bigtable Team
Na Google dostávate veľa pošty, takže na prvý pohľad čítam niečo takéto:
Vážený príjemca,
Pozdrav z nejakého tímu. Chceme komunikovať, že bla bla bla bla bla. Bla bla bla bla bla bla a bla bla bla okamžite.
Prosím, dajte nám vedieť, či si môžete naplánovať nejaký svoj drahocenný čas na bla bla bla.
Všetko najlepšie,
Nejaký druh príkazu
Skoro som to hneď vymazal, ale na okraji môjho vedomia som cítil bolestivý, dotieravý pocit, že áno nie celkom vyzerá to ako formálny list samozrejme, že sa príjemca pomýlil, pretože som nepoužil Bigtable.
Ale bolo to zvláštne.
Zvyšok dňa som striedavo premýšľal o práci a o tom, aké žraločie mäso ochutnať v mikrokuchynke, z ktorých aspoň tri boli dosť blízko na to, aby som trafil zo sedadla dobre miereným hodom sušienky, no myšlienka na písanie vo mne nikdy neopustila rastúci pocit miernej úzkosti.
Jasne povedali moje meno. A e-mail bol odoslaný na moju e-mailovú adresu, nie na niekoho iného, a nie je to kópia: ani skrytá kópia:. Tón je veľmi osobný a jasný. Možno je to nejaký omyl?
Nakoniec ma premohla zvedavosť a išiel som sa pozrieť na konzolu Borg v dátovom centre, ktoré spomínali.
A samozrejme som mal pod správou úložisko BigTable. Prepáč, čo? Pozrel som sa na jeho obsah a wow! Bolo to z inkubátora Codelab, v ktorom som sedel počas prvého týždňa v Google v júni 2005. Codelab vás prinútil spustiť Bigtable, aby ste tam zapísali nejaké hodnoty, a zrejme som potom úložisko nikdy nezatvoril. Stále to fungovalo, aj keď prešli viac ako dva roky.
Tento príbeh má niekoľko pozoruhodných aspektov. Po prvé, práca Bigtable bola v meradle Google taká bezvýznamná, že len o dva roky neskôr si niekto všimol ďalšie úložisko, a to len preto, že verzia binárneho súboru bola zastaraná. Pre porovnanie som kedysi zvažoval použitie pre moju online hru. V tom čase stála táto služba približne 16 000 dolárov ročne. prázdny Bigtable na GCP. Nehovorím, že ťa podvádzajú, ale podľa môjho osobného názoru je to veľa peňazí za prázdnu posranú databázu.
Ďalším pozoruhodným aspektom je úložný priestor funguje aj po dvoch rokoch. WTF? Dátové centrá prichádzajú a odchádzajú; majú výpadky, podstupujú plánovanú údržbu, neustále sa menia. Aktualizuje sa hardvér, vymenia sa prepínače, všetko sa neustále vylepšuje. Ako do pekla dokázali udržať môj program v chode dva roky so všetkými týmito zmenami? V roku 2020 sa to môže zdať ako skromný úspech, ale v rokoch 2005 – 2007 to bolo celkom pôsobivé.
A najúžasnejším aspektom je, že sa ku mne, majiteľovi akejsi malej, takmer prázdnej inštancie Bigtable, približuje externý inžiniersky tím v nejakom inom štáte. nulová premávka za posledné dva roky – a ponúkajú pomoc pri jej aktualizácii.
Poďakoval som im, vymazal úložisko a život pokračoval ako zvyčajne. Ale o trinásť rokov neskôr stále myslím na ten list. Pretože niekedy dostávam podobné e-maily z Google Cloud. Vyzerajú takto:
Vážený používateľ služby Google Cloud,
Pripomíname, že od augusta 2020 ukončíme službu [základná služba, ktorú používate], po ktorej už nebudete môcť inovovať svoje inštancie. Odporúčame inovovať na najnovšiu verziu, ktorá je v beta testovaní, nemá žiadnu dokumentáciu, žiadnu migračnú cestu a s našou láskavou pomocou je už zastaraná.
Zaviazali sme sa zabezpečiť, že táto zmena bude mať minimálny vplyv na všetkých používateľov platformy Google Cloud.
Najlepší priatelia navždy,
Google Cloud Platform
Ale takmer nikdy nečítam takéto listy, pretože v skutočnosti hovoria:
Vážený príjemca,
Choď do pekla. Jebam ťa, jebem, jebnem. Zahoďte všetko, čo robíte, pretože na tom nezáleží. Dôležitý je náš čas. Strácame čas a peniaze udržiavaním našich svinstiev a sme z toho unavení, takže to už nebudeme podporovať. Tak prestaň s tými svojimi posratými plánmi a začni sa prehrabávať v našej posratej dokumentácii, žobrať o útržky na fórach, a mimochodom, naše nové sračky sú úplne iné ako tie staré sračky, pretože sme ten dizajn dosť pokazili, heh, ale to je tvoje problém, nie náš.
Naďalej sa snažíme zabezpečiť, aby sa všetky vaše riešenia stali nepoužiteľnými do jedného roka.
Prosím, vyser sa
Google Cloud Platform
A je fakt, že takéto listy dostávam tak raz za mesiac. Stáva sa to tak často a tak neustále, že nevyhnutne odstrčený ja z GCP do anti-cloudového tábora. Už viac nesúhlasím so závislosťou na ich vlastnom vývoji, pretože v skutočnosti je pre vývojárov jednoduchšie udržiavať systém s otvoreným zdrojovým kódom na holom virtuálnom stroji, ako sa snažiť držať krok s Google s jeho politikou uzatvárania „zastaraných“ produktov.
Než sa vrátim do služby Google Cloud, pretože som ani zďaleka keď sme ich kritizovali, pozrime sa na výkonnosť spoločnosti v niektorých iných oblastiach. Inžinieri Google sú hrdí na svoju disciplínu softvérového inžinierstva a práve to spôsobuje problémy. Pýcha je pasca pre neopatrných a mnohých zamestnancov Google viedla k tomu, že si mysleli, že ich rozhodnutia sú vždy správne a že mať pravdu (podľa nejakej nejasnej definície) je dôležitejšie ako starostlivosť o zákazníkov.
Uvediem niekoľko náhodných príkladov z iných veľkých projektov mimo spoločnosti Google, ale dúfam, že tento vzor uvidíte všade. Je to nasledovné: spätná kompatibilita udržuje systémy nažive a aktuálne po celé desaťročia.
Spätná kompatibilita je cieľom dizajnu všetkých úspešných systémov, pre ktoré sú navrhnuté otvorený použitie, to znamená implementované s otvoreným zdrojovým kódom a/alebo otvorenými štandardmi. Mám pocit, že hovorím niečo príliš zrejmé, čo je každému dokonca nepríjemné, ale nie. Ide o politickú otázku, preto sú potrebné príklady.
Prvý systém, ktorý si vyberiem, je najstarší: GNU Emacs, čo je akýsi hybrid medzi Windows Notepadom, jadrom OS a Medzinárodnou vesmírnou stanicou. Je to trochu ťažké vysvetliť, ale v skratke, Emacs je platforma vytvorená v roku 1976 (áno, takmer pred polstoročím) na programovanie, aby ste boli produktívnejší, no tváriac sa ako textový editor.
Emacs používam každý deň. Áno, aj ja používam IntelliJ každý deň, sám o sebe sa rozrástol na výkonnú platformu nástrojov. Ale písanie rozšírení pre IntelliJ je oveľa ambicióznejšia a komplexnejšia úloha ako písanie rozšírení pre Emacs. A čo je dôležitejšie, všetko napísané pre Emacs je zachované navždy.
Stále používam softvér, ktorý som napísal pre Emacs v roku 1995. A som si istý, že niekto používa moduly napísané pre Emacs v polovici 80. rokov, ak nie skôr. Z času na čas môžu vyžadovať malé úpravy, ale to je naozaj veľmi zriedkavé. Neviem o ničom, čo som kedy napísal pre Emacs (a napísal som toho veľa), čo by vyžadovalo re-architektúru.
Emacs má funkciu nazvanú make-obsolete pre zastarané entity. Terminológia Emacs pre základné počítačové koncepty (napríklad čo je to "okno") sa často líši od konvencií v odvetví, pretože Emacs ich zaviedol už dávno. Toto je typické nebezpečenstvo pre tých, ktorí predbehli dobu: všetky vaše podmienky sú nesprávne. Ale Emacs má koncept odmietnutia, ktorý sa v ich žargóne nazýva zastarávanie.
Zdá sa však, že vo svete Emacsu existuje iná pracovná definícia. Iná základná filozofia, ak chcete.
Vo svete Emacsu (a v mnohých ďalších oblastiach, ktorým sa budeme venovať nižšie) zastaraný stav API v podstate znamená: „Tento prístup by ste naozaj nemali používať, pretože aj keď funguje, trpí rôznymi nedostatkami, ktoré zoznam tu. Ale na konci dňa je to vaša voľba."
Vo svete Google znamená byť zastaraný: „Porušujeme náš záväzok voči vám.“ Toto je pravda. Toto v podstate znamená. To znamená, že vás budú nútiť pravidelne robiť nejakú prácu, možno veľa práce, ako trest za to, že v nich veríte : Máme najlepší softvér. Najrýchlejší! Urobíte všetko podľa návodu, spustíte svoju aplikáciu alebo službu a potom bum, po roku-dvoch sa to zlomí.
Je to ako predať ojazdené auto, ktoré sa po 1500 km určite pokazí.
Toto sú dve úplne odlišné filozofické definície „zastaranosti“. Definícia vône od Googlu . Tomu neverím v skutočnosti plánované zastarávanie v rovnakom zmysle ako Apple. Google však rozhodne plánuje prelomiť vaše programy, a to kruhovým objazdom. Viem to, pretože som tam pracoval ako softvérový inžinier viac ako 12 rokov. Majú nejasné interné smernice o tom, do akej miery by sa mala spätná kompatibilita dodržiavať, ale v konečnom dôsledku je to na každom jednotlivom tíme alebo službe. Neexistujú žiadne odporúčania na podnikovej alebo inžinierskej úrovni a najodvážnejším odporúčaním, pokiaľ ide o cykly zastarávania, je „pokúste sa dať zákazníkom 6 až 12 mesiacov na inováciu, kým sa im pokazí celý systém“.
Problém je oveľa väčší, ako si myslia, a bude pretrvávať aj v nasledujúcich rokoch, pretože starostlivosť o zákazníka nie je v ich DNA. Viac o tom nižšie.
V tomto bode urobím odvážne vyhlásenie, že Emacs je do značnej miery úspešný a dokonca väčšinou pretože spätnú kompatibilitu berú tak vážne. V skutočnosti je to téza nášho článku. Úspešné otvorené systémy s dlhou životnosťou vďačia za svoj úspech mikrokomunitám, ktoré okolo nich žili už desaťročia rozšírenia/doplnky. Toto je ekosystém. Už som hovoril o povahe platforiem a o tom, aké sú dôležité, a ako Google nikdy v celej svojej firemnej histórii nepochopil, čo znamená vytvorenie úspešnej otvorenej platformy mimo Android alebo Chrome.
Vlastne by som mal stručne spomenúť Android, pretože o ňom pravdepodobne uvažujete.
Po prvé, Android nie je Google. Nemajú spolu takmer nič spoločné. Android je spoločnosť, ktorú Google kúpil v júli 2005, spoločnosti bolo umožnené fungovať viac-menej autonómne a v skutočnosti zostala v priebehu rokov takmer nedotknutá. Android je notoricky známy technologický balík a rovnako notoricky známa pichľavá organizácia. Ako povedal jeden zamestnanec spoločnosti Google: „Do Androidu sa nemôžete len tak prihlásiť.“
V predchádzajúcom článku som diskutoval o tom, aké zlé boli niektoré rané rozhodnutia týkajúce sa dizajnu Androidu. Sakra, keď som písal ten článok, zavádzali kraviny nazývané „okamžité aplikácie“, ktoré sú teraz (prekvapenie!) a sympatizujem, ak ste boli dosť hlúpi na to, aby ste počúvali Google a presunuli svoj obsah do týchto okamžitých aplikácií.
Ale je tu rozdiel, významný rozdiel, ktorý spočíva v tom, že ľudia s Androidom skutočne chápu, aké dôležité sú platformy, a snažia sa, aby staré aplikácie pre Android fungovali. V skutočnosti je ich úsilie o udržanie spätnej kompatibility také extrémne, že aj ja som sa počas svojho krátkeho pôsobenia v divízii Android pred niekoľkými rokmi pristihol, že sa ich snažím presvedčiť, aby prestali podporovať niektoré z najstarších zariadení a API (mýlil som sa , ako to bolo v mnohých iných veciach v minulosti a súčasnosti. Ospravedlňujeme sa, páni Android! Teraz, keď som bol v Indonézii, chápem, prečo ich potrebujeme).
Ľudia so systémom Android posúvajú spätnú kompatibilitu do takmer nepredstaviteľných extrémov a hromadia obrovské množstvo starého technického dlhu vo svojich systémoch a reťazcoch nástrojov. Oh, môj bože, mali by ste vidieť niektoré zo šialených vecí, ktoré musia robiť vo svojom zostavovacom systéme, všetko v mene kompatibility.
Za to udeľujem Androidu vytúžené ocenenie „Nie ste Google“. Naozaj sa nechcú stať Google, ktorý nevie vytvárať odolné platformy, ale Androidom vie,, ako to spraviť. A tak je Google v jednom ohľade veľmi inteligentný: umožňuje ľuďom robiť veci na Androide po svojom.
Okamžité aplikácie pre Android však boli dosť hlúpy nápad. A viete prečo? Pretože požadovali prepíšte a prerobte svoju aplikáciu! Je to, ako keby ľudia jednoducho prepísali dva milióny aplikácií. Predpokladám, že Instant Apps bol nápad nejakého zamestnanca spoločnosti Google.
Ale je tu rozdiel. Spätná kompatibilita je drahá. Bremeno týchto nákladov znáša samotný Android, zatiaľ čo Google trvá na tom, že toto bremeno znáša vy, platiaci klient.
Záväzok Androidu k spätnej kompatibilite môžete vidieť v jeho API. Keď máte štyri alebo päť rôznych podsystémov, ktoré robia doslova to isté, je to neklamný znak toho, že v jadre je záväzok spätnej kompatibility. Čo je vo svete platforiem synonymom záväzku voči vašim zákazníkom a vášmu trhu.
Hlavným problémom spoločnosti Google je ich hrdosť na ich inžiniersku hygienu. Nepáči sa im, keď existuje veľa rôznych spôsobov, ako robiť to isté, pričom staré, menej žiaduce spôsoby sedia vedľa nových, luxusnejších spôsobov. Zvyšuje to krivku učenia pre tých, ktorí sú v systéme noví, zvyšuje to bremeno údržby starších API, spomaľuje rýchlosť nových funkcií a hlavným hriechom je, že to nie je pekné. Google – ako Lady Ascot z Alica v krajine zázrakov Tima Burtona:
Lady Ascotová:
- Alice, vieš čoho sa najviac bojím?
- Úpadok aristokracie?
- Bál som sa, že budem mať škaredé vnúčatá.
Aby sme pochopili kompromis medzi krásnym a praktickým, pozrime sa na tretiu úspešnú platformu (po Emacs a Androide) a uvidíme, ako funguje: samotná Java.
Java má veľa zastaraných API. Ukončenie podpory je medzi programátormi Java veľmi populárne, dokonca populárnejšie ako vo väčšine programovacích jazykov. Samotná Java, základný jazyk a knižnice neustále zavrhujú API.
Ak vezmeme len jeden z tisícok príkladov, považované za zastarané. Od vydania Java 1.2 v decembri 1998 je zastaraný. Od ukončenia podpory prešlo 22 rokov.
Ale môj skutočný kód vo výrobe stále zabíja vlákna každý deň. Naozaj si myslíš, že je to dobré? Absolútne! Samozrejme, ak by som mal prepísať kód dnes, implementoval by som ho inak. Ale kód pre moju hru, ktorá za posledné dve desaťročia urobila radosť státisícom ľudí, je napísaný pomocou funkcie uzatvárania vlákien, ktoré visia príliš dlho, a ja nikdy to nemusel meniť. Poznám svoj systém lepšie ako ktokoľvek iný, mám doslova 25-ročné skúsenosti s prácou s ním vo výrobe a môžem s istotou povedať: v mojom prípade je uzavretie týchto špecifických pracovných vlákien úplne neškodný. Nestojí to za čas a námahu prepísať tento kód a ďakujem Larrymu Ellisonovi (pravdepodobne), že ma Oracle nenútil ho prepísať.
Oracle zrejme rozumie aj platformám. Kto vie.
Dôkazy možno nájsť v základných rozhraniach Java API, ktoré sú prešpikované vlnami zastaranosti, ako sú čiary ľadovca v kaňone. V knižnici Java Swing ľahko nájdete päť alebo šesť rôznych manažérov navigácie na klávesnici (KeyboardFocusManager). V skutočnosti je ťažké nájsť Java API, ktoré nie je zastarané. Ale stále fungujú! Myslím si, že tím Java skutočne odstráni API iba vtedy, ak rozhranie predstavuje do očí bijúci bezpečnostný problém.
Tu je vec, priatelia: Všetci vývojári softvéru sme veľmi zaneprázdnení a v každej oblasti softvéru sa stretávame s konkurenčnými alternatívami. V danom čase programátori v jazyku X zvažujú jazyk Y ako možnú náhradu. Ach, ty mi neveríš? Chcete to nazvať Swift? Všetci migrujú na Swift a nikto to neopúšťa, však? Wow, ako málo vieš. Spoločnosti počítajú náklady na duálne mobilné vývojové tímy (iOS a Android) – a začínajú si uvedomovať, že tieto multiplatformové vývojové systémy s vtipnými názvami ako Flutter a React Native skutočne fungujú a možno ich použiť na zmenšenie ich veľkosti. mobilné tímy dvakrát alebo naopak, aby boli dvakrát produktívnejší. V hre sú skutočné peniaze. Áno, existujú kompromisy, ale na druhej strane peniaze.
Predpokladajme hypoteticky, že Apple si hlúpo vzal návod od Guida van Rossuma a vyhlásil, že Swift 6.0 je spätne nekompatibilný so Swift 5.0, podobne ako Python 3 je nekompatibilný s Pythonom 2.
Pravdepodobne som tento príbeh rozprával asi pred desiatimi rokmi, ale asi pred pätnástimi rokmi som išiel s Guidom do O'Reilly's Foo Camp, sedel som v stane s Paulom Grahamom a dával som veľa šotov. Sedeli sme v úmornej horúčave a čakali, kým Larry Page odletí vo svojej osobnej helikoptére, zatiaľ čo Guido hučí o „Python 3000“, ktorý pomenoval podľa počtu rokov, ktoré by každému trvalo, kým by tam migroval. Stále sme sa ho pýtali, prečo porušuje kompatibilitu, a on odpovedal: "Unicode." A spýtali sme sa, ak by sme museli prepísať náš kód, aké ďalšie výhody by sme videli? A on odpovedal: "Yoooooooooooooouuuuuuniiiiiiicoooooooode."
Ak si nainštalujete Google Cloud Platform SDK („gcloud“), dostanete nasledujúce upozornenie:
Vážený príjemca,
Radi by sme vám pripomenuli, že podpora pre Python 2 bola zastaraná, tak sa poserte
… a tak ďalej. Kruh života.
Ide však o to, že každý vývojár má na výber. A ak ich prinútite prepisovať kód dostatočne často, mohli by sa nad tým zamyslieť ďalšie možnosti. Nie sú vašimi rukojemníkmi, bez ohľadu na to, ako veľmi by ste ich chceli mať. Sú to vaši hostia. Python je stále veľmi populárny programovací jazyk, ale dočerta, Python 3(000) vytvoril v sebe, vo svojich komunitách a medzi používateľmi svojich komunít taký neporiadok, že následky neboli odstránené už pätnásť rokov.
Koľko programov Python bolo prepísaných v Go (alebo Ruby alebo inej alternatíve) kvôli tejto spätnej nekompatibilite? Koľko nového softvéru bolo napísané v niečom inom ako Python, hoci áno može byť napísané v Pythone, keby Guido nevypálil celú dedinu? Ťažko povedať, ale Python jednoznačne utrpel. Je to obrovský chaos a všetci prehrávajú.
Povedzme teda, že Apple si vezme pokyn od Guida a poruší kompatibilitu. Čo si myslíte, že sa stane ďalej? No, možno 80-90% vývojárov prepíše svoj softvér, ak je to možné. Inými slovami, 10 – 20 % používateľskej základne automaticky prejde do nejakého konkurenčného jazyka, ako je napríklad Flutter.
Urobte to viackrát a stratíte polovicu svojej používateľskej základne. Tak ako v športe, aj vo svete programovania záleží na aktuálnej forme. всё. Každý, kto stratí polovicu svojich užívateľov za päť rokov, bude považovaný za Big Fat Losera. Vo svete platforiem musíte byť trendy. Ale práve tu vás nepodporovanie starších verzií časom zruinuje. Pretože zakaždým, keď sa zbavíte niektorých vývojárov, (a) ich navždy stratíte, pretože sa na vás hnevajú, že ste porušili zmluvu, a (b) ich rozdáte svojim konkurentom.
Je iróniou, že som tiež pomohol spoločnosti Google stať sa takou primadonou, ktorá ignoruje spätnú kompatibilitu, keď som vytvoril Grok, systém na analýzu a pochopenie zdrojového kódu, ktorý uľahčuje automatizáciu a inštrumentáciu samotného kódu – podobne ako IDE, ale tu sa ukladajú cloudové služby zhmotnené reprezentácie všetkých miliárd riadkov zdrojového kódu Google vo veľkom dátovom sklade.
Grok poskytol zamestnancom spoločnosti Google výkonný rámec na vykonávanie automatizovaných refaktoringov v celej ich kódovej základni (doslova v celom Google). Systém vypočítava nielen vaše upstream závislosti (na ktorých ste závislí), ale aj po prúde (čo je na vás), takže keď zmeníte API, poznáte každého, koho porušujete! Týmto spôsobom, keď vykonáte zmeny, môžete si overiť, že každý spotrebiteľ vášho API aktualizoval na novú verziu a v skutočnosti, často s nástrojom Rosie, ktorý napísali, môžete proces úplne zautomatizovať.
To umožňuje, aby kódová základňa Googlu bola vnútorne takmer nadprirodzene čistá, pretože títo robotickí sluhovia sa potulujú po dome a automaticky všetko upratujú, ak SomeDespicablyLongFunctionName premenovali na SomeDespicablyLongMethodName, pretože sa niekto rozhodol, že ide o škaredé vnúča a jeho potrebu treba dať spať.
A úprimne povedané, pre Google to funguje celkom dobre... interne. Myslím, áno, komunita Go v spoločnosti Google sa dobre smeje s komunitou Java v spoločnosti Google kvôli ich zvyku neustáleho refaktorovania. Ak niečo reštartujete N-krát, znamená to, že ste to nielen pokazili N-1-krát, ale po chvíli bude celkom jasné, že ste to pravdepodobne pokazili aj pri N-tom pokuse. Vo všeobecnosti však zostávajú nad všetkým týmto rozruchom a udržiavajú kód „čistý“.
Problém začína, keď sa snažia vnútiť tento postoj svojim cloudovým klientom a používateľom iných rozhraní API.
Trochu som vám predstavil Emacs, Android a Java; pozrime sa na najnovšiu úspešnú platformu s dlhou životnosťou: samotný web. Viete si predstaviť, koľko iterácií prešiel HTTP od roku 1995, keď sme používali blikajúce značky? a ikony "Vo výstavbe" na webových stránkach.
Ale stále to funguje! A tieto stránky stále fungujú! Áno, chlapci, prehliadače sú majstrami sveta v spätnej kompatibilite. Chrome je ďalším príkladom vzácnej platformy Google, ktorá má správne naskrutkované hlavy, a ako ste možno uhádli, Chrome efektívne funguje ako izolovaná spoločnosť oddelená od zvyšku Google.
Chcem tiež poďakovať našim priateľom z oblasti vývojárov operačných systémov: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD atď., za to, že odviedli takú skvelú prácu so spätnou kompatibilitou na ich úspešných platformách (Apple dostane prinajlepšom C s The nevýhodou je, že všetko pokazia bez dobrého dôvodu, ale komunita to nejako obchádza s každým vydaním a kontajnery OS X stále nie sú úplne zastarané... zatiaľ).
Ale počkaj, povieš si. Neporovnávame jablká s pomarančmi – samostatné softvérové systémy na jednom počítači, ako je Emacs/JDK/Android/Chrome, verzus systémy s viacerými servermi a API, ako sú cloudové služby?
No o tomto som tweetoval už včera, ale v štýle Larryho Walla (tvorca programovacieho jazyka Perl - cca per.) na princípe "sucks/rules" som si vyhľadal slovo zastarané na vývojárskych stránkach Google a Amazon. A hoci AWS má stovky viackrát viac ponúk služieb ako GCP, dokumentácia pre vývojárov Google spomína ukončenie podpory asi sedemkrát častejšie.
Ak to niekto v Google číta, pravdepodobne je pripravený vytiahnuť tabuľky v štýle Donalda Trumpa, ktoré ukazujú, že v skutočnosti robia všetko správne a že by som nemal robiť neférové porovnania typu „počet zmienok o slove zastarané verzus počet služieb" "
Ale po všetkých tých rokoch je Google Cloud stále službou číslo 3 (nikdy som nenapísal článok o neúspešnom pokuse stať sa číslom 2), ale ak sa dá veriť zasväteným, existujú určité obavy, že by čoskoro mohli klesnúť na č. 4.
Nemám žiadne presvedčivé argumenty na "dokazovanie" mojej tézy. Všetko, čo mám, sú farebné príklady, ktoré som nazbieral za 30 rokov ako vývojár. Hlboko filozofický charakter tohto problému som už spomenul; istým spôsobom je v komunitách developerov spolitizovaná. Niektorí tomu veria tvorcovia platformy by sa mali starať o kompatibilitu, zatiaľ čo iní si myslia, že ide o problém Užívatelia (samotní vývojári). Jeden z dvoch. Naozaj, nie je to politická otázka, keď rozhodujeme, kto má znášať náklady na spoločné problémy?
Tak toto je politika. A na môj prejav budú zrejme nahnevané reakcie.
Ako užívateľ Google Cloud Platform a ako používateľ AWS dva roky (pri práci pre Grab) môžem povedať, že medzi filozofiou Amazonu a Google je obrovský rozdiel, pokiaľ ide o priority. Aktívne nevyvíjam na AWS, takže neviem, ako často odstraňujú staré API. Existuje však podozrenie, že sa to nestáva ani zďaleka tak často ako v Google. A skutočne verím, že tento zdroj neustálej kontroverzie a frustrácie v GCP je jedným z najväčších faktorov brzdiacich vývoj platformy.
Viem, že som nemenoval konkrétne príklady systémov GCP, ktoré už nie sú podporované. Môžem povedať, že takmer všetko, čo som používal, od sietí (od najstarších po VPC) až po úložiská (Cloud SQL v1-v2), Firebase (teraz Firestore s úplne iným API), App Engine (ani nezačíname) , cloudové koncové body Cloud Endpoint a až... neviem - úplne toto všetko donútili vás prepísať kód maximálne po 2-3 rokoch a migráciu za vás nikdy nezautomatizovali a často . Akoby to tak malo byť.
A vždy, keď sa pozriem na AWS, pýtam sa sám seba, prečo som sakra stále na GCP. Očividne nepotrebujú klientov. Potrebujú покупатели. Chápeš ten rozdiel? Nechaj ma vysvetliť.
Google Cloud má , kde ľudia navrhujú svoje softvérové riešenia, a aby sa vyhli efektu prázdnej reštaurácie, potrebovali ju naplniť nejakými návrhmi, a tak sa uzavreli so spoločnosťou Bitnami, aby vytvorili veľa riešení, ktoré sa nasadzujú „jedným kliknutím“ alebo by mali Píšem to sám „riešenia“, pretože tieto prekliate veci nevyriešia. Jednoducho existujú ako začiarkavacie políčka, ako marketingová výplň a Google sa nikdy nestaral o to, či niektorý z nástrojov skutočne funguje. Poznám produktových manažérov, ktorí sedeli na mieste vodiča, a môžem vás ubezpečiť, že týmto ľuďom je to jedno.
Vezmime si napríklad riešenie nasadenia údajne „jedným kliknutím“. . Bol som na smrť chorý z vychytávok Google Cloud SQL, tak som sa začal pozerať na vytvorenie vlastného klastra Percona ako alternatívu. A tentoraz sa zdalo, že Google odviedol dobrú prácu, kliknutím na tlačidlo mi ušetrí čas a námahu!
No super, poďme. Nasledujme odkaz a kliknite na toto tlačidlo. Ak chcete súhlasiť so všetkými predvolenými nastaveniami a nasadiť klaster vo svojom cloudovom projekte Google, vyberte možnosť „Áno“. Haha, nejde to. Nič z tohto svinstva nefunguje. Nástroj nebol nikdy testovaný a od prvej minúty začal hniť a neprekvapilo by ma, keby viac ako polovicu „riešení“ tvorili nasadenia na jeden klik (teraz už chápeme, prečo tie úvodzovky) vo všeobecnosti nefunguje. Toto je absolútne beznádejná tma, kam je lepšie nevstupovať.
Ale Google má pravdu nutkanie aby ste ich používali. Oni to chcú kúpil som. Pre nich je to transakcia. Nechcú nič podpora. Nie je súčasťou DNA spoločnosti Google. Áno, inžinieri sa navzájom podporujú, o čom svedčí aj môj príbeh s Bigtable. Ale v produktoch a službách pre bežných ľudí vždy boli bezohľadní v , ktorá nespĺňa latku ziskovosti, aj keď má milióny používateľov.
A to predstavuje skutočnú výzvu pre GCP, pretože toto je DNA za všetkými cloudovými ponukami. Nesnažia sa nič podporovať; Je dobre známe, že odmietajú hosťovať (ako riadenú službu) akýkoľvek softvér tretích strán kým, kým AWS neurobí to isté a nevybuduje okolo toho úspešnú firmu a keď to zákazníci doslova vyžadujú. Chce to však určité úsilie, aby Google niečo podporil.
Tento nedostatok kultúry podpory spolu s mentalitou „rozbime to, aby to bolo krajšie“ odcudzuje vývojárov.
A to nie je dobré, ak chcete vybudovať platformu s dlhou životnosťou.
Google, zobuď sa, sakra. Teraz je rok 2020. Stále prehrávaš. Je čas sa poriadne pozrieť do zrkadla a odpovedať si, či naozaj chcete zostať v cloudovom biznise.
Ak chceš zostať tak prestaň všetko rozbíjať. Chlapci, ste bohatí. My vývojári nie. Takže pokiaľ ide o to, kto ponesie bremeno kompatibility, musíte to vziať na seba. Nie pre nás.
Pretože tam sú ešte minimálne tri naozaj dobré mraky. Vábia.
A teraz prejdem k oprave všetkých mojich pokazených systémov. Eh
Dobudúcna!
PS Update po prečítaní niektorých diskusií k tomuto článku (diskusie sú skvelé, btw). Podpora Firebase nebola ukončená a neviem o žiadnych plánoch. Majú však nepríjemnú chybu streamovania, ktorá spôsobuje, že klient Java sa zastaví v App Engine. Jeden z ich inžinierov mi pomohol vyriešiť tento problém, keď som pracoval v Google, ale v skutočnosti nikdy neopravili chybu, takže mám mizerné riešenie, že musím každý deň reštartovať aplikáciu GAE. A tak je to už štyri roky! Teraz majú Firestore. Migrácia naň bude vyžadovať veľa práce, pretože ide o úplne iný systém a chyba Firebase nebude nikdy opravená. Aký záver možno vyvodiť? Môžete získať pomoc ak pracujete vo firme. Pravdepodobne som jediný, kto používa Firebase na GAE, pretože zaznamenávam menej ako 100 kľúčov v 100% natívnej aplikácii a každých pár dní prestane fungovať kvôli známej chybe. Čo môžem povedať okrem toho, že ho používate na vlastné riziko. Prechádzam na Redis.
Tiež som videl, ako niektorí skúsenejší používatelia AWS hovoria, že AWS zvyčajne nikdy neprestane podporovať žiadne služby a SimpleDB je skvelým príkladom. Moje predpoklady, že AWS nemá rovnaký koniec podpory ako Google, sa zdajú byť oprávnené.
Okrem toho som si všimol, že pred 20 dňami tím služby Google App Engine prerušil hosťovanie kritickej knižnice Go a odstavil aplikáciu GAE od jedného z hlavných vývojárov Go. Bolo to naozaj hlúpe.
Nakoniec som počul, že zamestnanci spoločnosti Google už diskutujú o tomto probléme a vo všeobecnosti so mnou súhlasia (milujem vás!). Zdá sa však, že si myslia, že problém je neriešiteľný, pretože kultúra Google nikdy nemala správnu štruktúru stimulov. Myslel som, že by bolo dobré venovať nejaký čas diskusii o úplne úžasnej skúsenosti, ktorú som mal pri práci s inžiniermi AWS počas práce v Grabe. Raz v budúcnosti, dúfam!
A áno, v roku 2005 mali v obrovskom bufete v budove 43 rôzne druhy žraločieho mäsa a moje obľúbené bolo mäso zo žraloka kladivohlavého. Do roku 2006 sa však Larry a Sergei zbavili všetkých nezdravých pochutín. Takže počas príbehu Bigtable v roku 2007 naozaj neboli žiadni žraloky a oklamal som vás.
Keď som sa pred štyrmi rokmi pozeral na cloud Bigtable (dať alebo vziať), tu boli náklady. Zdá sa, že teraz to trochu kleslo, ale stále je to strašne veľa na prázdny dátový sklad, najmä keď môj prvý príbeh ukazuje, aký bezvýznamný je prázdny veľký stôl v ich rozsahu.
Ospravedlňujem sa, že som urazil komunitu Apple a nepovedal nič pekné o Microsofte atď. Máte v poriadku, naozaj si vážim všetku diskusiu, ktorú tento článok vyvolal! Ale niekedy potrebujete trochu zamávať, aby ste začali diskusiu, viete?
Vďaka za prečítanie.
Aktualizácia 2, 19.08.2020. Stripe !
Aktualizácia 3, 31.08.2020. Kontaktoval ma inžinier Google z Cloud Marketplace, ktorý sa ukázal ako môj starý priateľ. Chcel zistiť, prečo C2D nefunguje, a nakoniec sme prišli na to, že to bolo preto, že som si svoju sieť vybudoval pred rokmi a C2D nefungovalo na starších sieťach, pretože v ich šablónach chýbal parameter podsiete. Myslím si, že pre potenciálnych používateľov GCP je najlepšie uistiť sa, že poznajú dostatok inžinierov v spoločnosti Google...
Zdroj: hab.com