Sakra, Google, nechcel som znovu písať blog. Mám toho toľko na práci. Vedenie blogu si vyžaduje čas, energiu a kreativitu, ktoré by som mohol využiť efektívnejšie: na svoje knihy, , svoju hru a podobne. Ale dosť si ma naštval, takže to musím napísať.
Takže poďme na to.
Začnem malým, ale poučným príbehom z čias, keď som len začínal pracovať v Google. Viem, že v poslednej dobe som o Google hovoril veľa zlého, ale je mi to nepríjemné, keď moja rodná spoločnosť pravidelne prijíma nekompetentné obchodné rozhodnutia. Na druhej strane, treba priznať: vnútorná infraštruktúra Google je skutočne výnimočná, dá sa s istotou povedať, že dnes neexistuje nič lepšie. Zakladatelia Google boli omnoho lepší inžinieri, ako kým kedy budem ja, a tento príbeh to len potvrdzuje.
Najprv trochu pozadia: Google má technológiu ukladania dát s názvom . To bol úžasný technický pokrok, jeden z prvých (ak nie prvý) 'nekonečne škálovateľných' úložísk párov 'kľúč-hodnota' (key-value store, K/V): v podstate začiatok NoSQL. Dnes je Bigtable stále v dobrej kondícii v pomerne preplnenom priestore K/V úložísk, ale vtedy (v roku 2005) to bolo ohromne cool.
Zaujímavý detail o Bigtable je, že mali vnútorné objekty riadiacej roviny (ako súčasť implementácie) nazývané tablet-servery, s veľkými indexmi, a v istom momente sa stali úzkym miestom pri škálovaní systému. Inžinieri Bigtable si lámali hlavy, ako dosiahnuť škálovateľnosť, a zrazu si uvedomili, že môžu nahradiť tablet-servery inými úložiskami Bigtable. Takže Bigtable je súčasť implementácie Bigtable. Tieto úložiská sú prítomné na všetkých úrovniach.
Ešte jedna zaujímavá skutočnosť je, že na nejaký čas sa Bigtable stali populárnymi a všadeprítomnými v Google, pričom každé tím malo vlastné úložisko. Preto sa na jednom z piatkových stretnutí Larry Page letmo opýtal: „Prečo máme viac ako jeden Bigtable? Prečo sa nemôžeme obísť len s jedným?“ Teoreticky by jedno úložisko malo stačiť na všetky potreby ukladania Googlu. Samozrejme, nikdy neprešli len na jedno z praktických dôvodov vývoja (napríklad potenciálne následky zlyhania), ale teória bola zaujímavá. Jedno úložisko pre celý vesmír (mimochodom, vie niekto, čo spravil Amazon so svojím Sable?)
Tak, alebo onak, tu je môj príbeh.
V tom čase som pracoval v Google niečo viac ako dva roky a raz som dostal email od inžinierskeho tímu Bigtable, ktorý znel asi takto:
Vážený Steve,
Ahoj od tímu Bigtable. Chceme vás informovať, že v dátovom centre [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 chceme vám pomôcť prejsť na najnovšiu verziu.
Prosím, dajte nám vedieť, ak môžete naplánovať nejaký čas na spoluprácu na tejto záležitosti.
Všetko najlepšie,
Tím Bigtable
V Google prichádza veľa emailov, takže na prvý pohľad som to prečítal asi takto:
Vážený príjemca,
Ahoj od nejakej skupiny. Chceme vás informovať, že bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla a bla-bla-bla okamžite.
Prosím, dajte nám vedieť, ak môžete naplánovať čas na bla-bla-bla.
Všetko najlepšie,
Nejaká skupina
Takmer som to okamžite vymazal, ale na pokraji vedomia som cítil ťaživý, ale bolesť v srdci, že to nie je úplne ako formálny list, hoci je zjavné, že sa adresát pomýlil, pretože som nepoužíval Bigtable.
Ale bolo to zvláštne.
Zvyšok dňa som striedavo myslel na prácu a na to, aký druh žraločieho mäsa vyskúšať v mikro-kuchyni, z ktorých boli aspoň tri dosť blízko, aby som do nich mohol z môjho miesta presne hodiť sušienku, ale myšlienka na email ma neopúšťala s rastúcim pocitom ľahkej úzkosti.
Jasne, že mi spomenuli meno. A list bol zaslaný na moju e-mailovú adresu, nie na niekoho iného, a nejde o cc: alebo bcc:. Tón je veľmi osobný a jasný. Možno je to nejaká chyba?
Nakoniec zvíťazila zvedavosť a išiel som sa pozrieť na konzolu Borg v dátovom centre, o ktorom hovorili.
A samozrejme, mal som na starosti úložisko BigTable. Čože? Pozrel som sa na jeho obsah a – je to vôbec možné! Bolo to z inkubátora Codelab, v ktorom som bol počas prvého týždňa práce v Googli v júni 2005. Codelab vás prinútil spustiť Bigtable, aby ste tam zapísali niektoré hodnoty, a zjavne som úložisko po tom neuzavrel. Stále fungovalo, hoci od toho prešli viac ako dva roky.
V tomto príbehu je niekoľko pozoruhodných aspektov. Po prvé, fungovanie Bigtable bolo také nevýznamné v rozsahu Googlu, že len o dva roky neskôr si niekto všimol nadbytočné úložisko, a to len preto, že verzia binárneho súboru bola zastaraná. Pre porovnanie, kedysi som uvažoval o použití pre moju online hru. V tej dobe stálo toto služba asi 16 000 dolárov ročne za prázdne Bigtable na GCP. Nehovorím, že vás klamú, ale podľa môjho osobného názoru sú to veľké peniaze za prázdnu francúzsku databázu.
Ďalším pozoruhodným aspektom je, že úložisko stále fungovalo aj po dvoch rokoch. WTF? Dátové centrá prichádzajú a odchádzajú; prechádzajú výpadkami, podstupujú plánovanú údržbu, neustále sa menia. Hardvér je obnovovaný, prepínače sa presúvajú, všetko sa neustále zlepšuje. Ako, do pekla, sa im podarilo udržať môj program spustený dve roky za všetkých týchto zmien? Môže sa to zdať skromným úspechom v roku 2020, ale v rokoch 2005-2007 to bolo veľmi pôsobivé.
A najúžasnejším aspektom je, že externý inžiniersky tím z nejakého iného štátu sa obracia na mňa, vlastníka nejakého malého, prakticky prázdneho príkladu Bigtable, ktorý má nulový traffic počas posledných dvoch rokov – a ponúkajú pomoc pri jeho aktualizácii.
Poďakoval som im, vymazal úložisko a život išiel ďalej. Ale o trinásť rokov neskôr stále myslím na tento list. Pretože niekedy dostávam podobné listy od Google Cloud. Vyzerajú takto:
Vážený používateľ Google Cloud,
Pripomíname, že saugse sme ukončili poskytovanie služby [dôležitá služba, ktorú používate] od augusta 2020, po čom už nebudete môcť aktualizovať svoje inštancie. Odporúčame prejsť na najnovšiu verziu, ktorá prechádza beta testovaním, nemá žiadnu dokumentáciu, žiadny migračný plán a už bola zastaraná s našou láskyplnou pomocou.
Usilujeme sa o to, aby táto zmena mala minimálny dopad na všetkých používateľov platformy Google Cloud.
Najlepší priatelia navždy,
Oblačná platforma Google
Ale skoro vôbec nečítam takéto maily, pretože v nich vlastne ide o toto:
Vážený príjemca,
Choď do čerta. Choď, choď, choď. Zahoď všetko, čo robíš, pretože to nie je dôležité. Čo je dôležité, je náš čas. Trávime čas a peniaze na udržiavanie našich sračiek a sme z toho unavení, preto už nebudeme udržiavať. Takže hod svoje zasrané plány a začni prekopávať našu zasranú dokumentáciu, vymáhajúc zbytky na fórach, a mimochodom, naše nové sračky sú úplne odlišné od starých sračiek, pretože sme ten dizajn dosť pokazili, heh, ale to je tvoja starosť, nie naša.
Stále sa snažíme zabezpečiť, aby všetky tvoje vývojové projekty boli nefunkčné do jedného roka.
Prosím, choď do hája,
Oblačná platforma Google
A o to ide, že takéto maily dostávam zhruba raz za mesiac. Stáva sa to tak často a tak pravidelne, že nevyhnutne odradili ma od GCP k táboru protivníkov cloudu. Už sa nechcem spoliehať na ich proprietárne vývojové nástroje, pretože je v skutočnosti pre devops oveľa jednoduchšie udržiavať systém s otvoreným zdrojovým kódom na holých virtuálkach, než sa snažiť stíhať Google s jeho politikou uzatvárania 'zastaralých' produktov.
Predtým, ako sa vrátim k Google Cloud, pretože ja ani zďaleka nenechal ich kritizovať, poďme sa pozrieť na prácu spoločnosti v niektorých iných oblastiach. Inžinieri Google sú hrdí na svoju disciplínu vývoja softvéru a to je presne to, čo spôsobuje problémy. Hrdosť je pasca pre nepozorných, donútila mnohých zamestnancov Google myslieť si, že ich rozhodnutia sú vždy správne a že správnosť (podľa nejakej nejasnej definície) je dôležitejšia ako starostlivosť o zákazníkov.
Uvediem niekoľko náhodných príkladov z iných veľkých projektov mimo Google, ale dúfam, že tento vzor uvidíte všade. Spočíva v nasledovnom: spätná kompatibilita udržuje životaschopnosť a aktuálnosť systémov počas desaťročí.
Spätná kompatibilita je cieľom navrhovania všetkých úspešných systémov určených na otvorené používanie, teda realizovaných s otvoreným zdrojovým kódom a/alebo na otvorených štandardoch. Mám pocit, že hovorím niečo príliš očividné, čo by všetkým mohlo byť nepríjemné, ale nie. Je to politická otázka, preto sú potrebné príklady.
Prvý systém, ktorý si vyberiem, najstarší: GNU Emacs, to je akýsi hybrid medzi Poznámkovým blokom Windows, jadrom operačného systému a Medzinárodnou vesmírnou stanicou. Je to trochu zložité vysvetliť, ale v dvoch slovách, Emacs je platforma, vytvorená v roku 1976 (áno, pred takmer polstoročím) na programovanie, aby zvýšila vašu produktivitu, ale maskuje sa ako textový editor.
Používam Emacs každý deň. Áno, používam aj IntelliJ každý deň, ona sama sa už stala mocnou nástrojovou platformou. Ale písanie rozšírení pre IntelliJ je oveľa ambicióznejšia a zložitejšia úloha ako písanie rozšírení pre Emacs. A čo je ešte dôležitejšie, všetko, čo je napísané pre Emacs, sa uchováva navždy.
Stále používam softvér, ktorý som napísal pre Emacs ešte v roku 1995. A som presvedčený, že niekto používa moduly napísané pre Emacs v polovici 80. rokov, ak nie skôr. Občas môžu vyžadovať drobné úpravy, ale to je naozaj dosť zriedkavé. Neviem o ničom, čo by som kedy napísal pre Emacs (a napísal som veľa), čo by si muselo prestavať architektúru.
V Emacse existuje funkcia s názvom make-obsolete pre zastarané entity. Terminológia Emacsu pre základné počítačové koncepty (napríklad čo je to „okno“) často odlišuje od priemyselných konvencií, pretože Emacs ich zaviedol už dávno. Toto je typické nebezpečenstvo pre tých, ktorí predbehli svoj čas: všetky vaše termíny sú nesprávne. Ale v Emacse naozaj existuje koncepcia zastarania, ktorá sa v ich žargóne nazýva obsolescence.
Ale vo svete Emacsu sa zdá, že existuje iná pracovná definícia. Iná základná filozofia, ak chcete.
Vo svete Emacsu (a v mnohých ďalších oblastiach, ktoré si neskôr prejdeme) status zastaraných API väčšinou znamená: „Naozaj by ste nemali používať tento prístup, pretože, hoci funguje, má rôzne nedostatky, ktoré tu uvedieme. Ale nakoniec, je to na vás.“
Vo svete Googlu status zastaraného produktu znamená: „Porušujeme naše záväzky voči vám.“ To naozaj tak je. Tým sa vlastne myslí, že vás pritláčajú k tomu, pravidelne vykonávať určitú prácu, možno veľkú prácu, ako trest za to, že ste uverili v ich : máme najlepšie softvérové riešenie. To najrýchlejšie! Robíte všetko podľa pokynov, spúšťate svoju aplikáciu alebo službu a potom — bum, za rok alebo dva sa to pokazí.
Je to ako predávať ojazdené auto, ktoré sa určite skazí po 1500 km.
Toto sú dve úplne rôzne filozofické definície „zastarania“. Definícia Googlu smrdí . Neverím, že ide o v skutočnosti plánované zastaranie v rovnakom zmysle ako u spoločnosti Apple. Ale Google určite plánuje pokaziť vaše programy, obchádzajúc. Viem to, pretože som tam pracoval ako programátor viac ako 12 rokov. Majú nejasné interné odporúčania, do akej miery dodržiavať spätnú kompatibilitu, ale nakoniec záleží na každom jednotlivom tíme alebo službe. Neexistujú žiadne odporúčania na firemnej alebo inžinierskej úrovni a najodvážnejšie odporúčanie, pokiaľ ide o cykly zastarania, je „skúste dať klientom 6-12 mesiacov na aktualizáciu predtým, ako im úplne zlomíte systém“.
Problém je oveľa vážnejší, než si myslia, a potrvá ešte dlhé roky, pretože starostlivosť o zákazníkov nie je v ich DNA. Viac informácií nájdete nižšie.
V súčasnosti mám v úmysle urobiť odvážne tvrdenie, že Emacs je úspešný do značnej miery a dokonca predovšetkým kvôli tomu, že sa veľmi vážne zaoberajú spätne kompatibilitou. Toto je vlastne téza našich článkov. Úspešné a dlhodobé otvorené systémy vďačia za svoj úspech mikrospoločenstvám, ktoré desaťročia žijú okolo rozšírení/podporách. To je ekosystém. Už som hovoril o podstate platforiem a o tom, aké sú dôležité, a o tom, že Google nikdy za celú svoju firemnú históriu nepochopil, čo znamená vytvoriť úspešnú otvorenú platformu, okrem Androidu alebo Chrome.
V skutočnosti by som mal stručne spomenúť Android, pretože ste si to pravdepodobne pomysleli.
Po prvé, Android nie je Google. Takmer nemajú nič spoločné. Android je spoločnosť, ktorú Google kúpil v júli 2005, tejto spoločnosti bolo umožnené pracovať viac či menej autonómne a prakticky zostala v značnej miere nedotknutá po celé roky. Android je známy technický stack a rovnako známa roztrhnutá organizácia. Ako povedal jeden zamestnanec Googlu, "nie je možné len tak vziať a vstúpiť do Androidu."
V jednom z predchádzajúcich článkov som už hovoril, ako zlými boli niektoré z počiatočných dizajnérskych rozhodnutí Androidu. Človeče, keď som písal ten článok, zaoberali sa nasadením niečoho, čo sa nazýva "okamžité aplikácie", ktoré teraz (prekvapenie!) , a súcitim s vami, ak ste boli dostatočne hlúpi, aby ste poslúchli Google a presunuli svoj obsah do týchto okamžitých aplikácií.
Ale je tu rozdiel, podstatný rozdiel, ktorý spočíva v tom, že ľudia z Androidu naozaj chápu, aké dôležité sú platformy, a usilovne sa snažia zachovať fungovanie starých android aplikácií. V skutočnosti sú ich snahy o zachovanie spätnej kompatibility tak extrémne, že aj ja, počas svojho krátkeho pôsobenia v android divízii pred niekoľkými rokmi, som zistil, že sa snažím presvedčiť ich, aby sa vzdali podpory niektorých z najstarších zariadení a API (mýlil som sa, ako aj v mnohých iných veciach minulosti a prítomnosti. Prepáčte, chlapci z Androidu! Teraz, keď som bol v Indonézii, chápem, prečo ich potrebujeme).
Ľudia z Androidu udržiavajú spätnú kompatibilitu do takmer nepredstaviteľných extrémov, čo hromadí obrovské množstvo zastaraného technického dlhu v ich systémoch a nástrojových reťazcoch. Och, videli by ste nejaké šialené veci, ktoré musia robiť v svojom systéme zostavovania, a to všetko v mene kompatibility.
Za to udeľujem Androidu cennú cenu „Ty nie si Google“. Naozaj nechcú byť Google, ktorý nevie vytvárať trvácne platformy, ale Android vie, ako to robiť. A preto sa Google správa veľmi rozumne v jednej veci: umožňuje ľuďom v Androide robiť všetko po svojom.
Ale okamžité aplikácie pre Android boli dosť hlúpy nápad. A viete prečo? Pretože si vyžadovali prepisovanie a preprojektovanie vašej aplikácie! Akoby si ľudia len tak vzali a prepísali dva milióny aplikácií. Predpokladám, že okamžité aplikácie boli nápadom nejakého googleru.
Ale tu je rozdiel. Spätná kompatibilita so sebou nesie veľké náklady. Android sám nesie bremeno týchto nákladov, zatiaľ čo Google trvá na tom, aby toto bremeno niesli vy, platený klient.
Vidíte oddanosť Androidu spätnej kompatibilite v jeho API. Keď máte štyri alebo päť rôznych podsystémov na dosiahnutie doslova toho istého, je to jasný znak, že za tým je oddanosť spätnej kompatibilite. Čo je v svete platforiem synonymom oddanosti vašim klientom a vášmu trhu.
Hlavný problém Google spočíva v ich pýche na inžiniersku hygienu. Nepáči sa im, keď existuje veľa rôznych spôsobov, ako robiť to isté, pričom staršie, menej žiaduce metódy sú vedľa novších, zaujímavejších metód. To zvyšuje krivku učenia pre nováčikov v systéme, zvyšuje záťaž pri podpore zastaraných API, spomaľuje rýchlosť nových funkcií a najväčší hriech – je to neestetické. Google je ako Lady Escot z Timovej Burtonovej „Alenky v ríši divov“:
Lady Escot:
— Alenka, vieš, čoho sa najviac obávam?
— Úpadku aristokracie?
— Obávala som sa, že budem mať nepekných vnukov.
Aby sme pochopili kompromis medzi krásnym a praktickým, pozrime sa na tretiu úspešnú platformu (po Emacs a Android) a na to, ako funguje: samotná Java.
V Jave je množstvo zastaraných API. Zastaralosť je medzi java programátormi veľmi populárna, dokonca populárnejšia než v väčšine programovacích jazykov. V samotnej Jave, základnom jazyku a knižniciach, neustále prebieha zastaranosť API.
Ak si vezmeme len jeden z tisícich príkladov, sa považuje za zastarané. Zastaralo od vydania Javy 1.2 v decembri 1998. Uplynulo 22 rokov od jeho zastarania.
Ale môj skutočný kód v produkcii stále zabíja vlákna každý deň. Je to dobre? Absolútne! Mám na mysli, samozrejme, keby som dnes prepisoval kód, implementoval by som to inak. Ale kód mojej hry, ktorá šťastnými urobila stovky tisícov ľudí za posledné dve desaťročia, je napísaný s funkciou uzatvárania vláken, ktoré visia príliš dlho, a ja som ho nikdy nemusel meniť. Poznám svoj systém lepšie ako ktokoľvek iný, mám doslova 25-ročné skúsenosti s ním v produkcii a môžem presne povedať: v mojom prípade uzatváranie týchto konkrétnych pracovných vlákien je úplne bezpečné. Nestojí za to strácať čas a energiu prepisovaním tohto kódu, a chvála Larrymu Ellisonovi (pravdepodobne), že Oracle ma nenútil to prepisovať.
Pravdepodobne aj Oracle rozumie platformám. Kto vie.
Dôkazy môžete nájsť vo všetkých kľúčových Java API, ktoré sú presiaknuté vlnami zastarania, podobne ako ľadovcové línie v rokline. V knižnici Java Swing sa dajú ľahko nájsť päť alebo šesť rôznych manažérov klávesovej navigácie (KeyboardFocusManager). V skutočnosti je ťažké nájsť Java API, ktoré nie je zastarané. Ale stále fungujú! Myslím, že tím Java skutočne odstráni API iba vtedy, ak rozhranie spôsobí zjavný problém so zabezpečením.
O toto ide, chalani: my, vývojári softvéru, sme všetci veľmi zaneprázdnení a v každej oblasti softvéru sa stretávame s konkurenčnými alternatívami. V každom okamihu programátori v jazyku X zvažujú jazyk Y ako možnú náhradu. Ach, neveríte mi? Chcete spomenúť Swift? Znie to tak, ako keby všetci migrovali na Swift a nikto sa ho nevzdáva, je to tak? Wau, koľko toho neviete. Spoločnosti zohľadňujú náklady na dvojité tímy mobilného vývoja (iOS a Android) - a začínajú si uvedomovať, že tieto multiplatformové systémy vývoja s vtipnými názvami, ako sú Flutter a React Native, skutočne fungujú a s ich pomocou môžu zredukovať veľkosť svojich mobilných tímov na polovicu alebo, naopak, zvýšiť ich produktivitu dvojnásobne. Na hre sú skutočné peniaze. Áno, sú tam kompromisy, ale na druhej strane, pe-ene-zi.
Predpokladajme hypoteticky, že Apple z hlúposti vzal príklad od Guida van Rossuma a vyhlásil, že Swift 6.0 je spätne nekompatibilný so Swift 5.0, tak ako je Python 3 nekompatibilný s Python 2.
Asi som túto príhodu rozprával pred desiatimi rokmi, ale pred pätnástimi rokmi som na O'Reillyho Foo Campe sedel s Guidom, sedel som v stane s Paulom Grahamom a hromadou ďalších veľkých mien. Sedeli sme v úmornej horúčave a čakali, kým Larry Page priletí svojim súkromným vrtuľníkom, a Guido monotónne mumlal o 'Pythone 3000', ktorý nazval podľa počtu rokov, ktoré potrebujeme na migráciu. Stále sme sa ho pýtali, prečo porušuje kompatibilitu, a on odpovedal: „Unicode“. A pýtali sme sa, ak musíme prepísať náš kód, aké ďalšie výhody uvidíme? A on odpovedal „Yoooooooooooooouuuuuuuniiiiiiicoooooooode“.
Ak nainštalujete Google Cloud Platform SDK („gcloud“), dostanete nasledujúce upozornenie:
Vážený príjemca,
Radi by sme vám pripomenuli, že podpora Pythonu 2 bola ukončená, takže si môžete povedať, čo chcete.
… a tak ďalej. Kolobeh života.
Ale je pravda, že každý vývojár má na výber. A ak ich nútite prepisovať kód dostatočne často, môžu zvážiť aj ďalších alternatívy. Nie sú vašimi rukojemníkmi, aj keď by ste si to želali. Sú vašimi hosťami. Python je stále veľmi populárny programovací jazyk, ale, sakra, Python 3(000) vytvoril taký chaos vo svojich komunitách a medzi používateľmi svojich komunít, že následky sa nedajú upratať už pätnásť rokov.
Koľko programov v Pythone bolo preprogramovaných na Go (alebo Ruby, alebo nejakú inú alternatívu) kvôli tejto spätné nekompatibilite? Koľko nového softvéru bolo napísaného v niečom inom ako v Pythone, hoci to mohlo byť napísané v Pythone, keby Guido nespálil celú dedinu? Ťažko povedať, ale Python zjavne utrpel. Je to obrovský chaos, a všetci na tom strácajú.
Predpokladajme, že Apple berie príklad od Guida a porušuje kompatibilitu. Čo si myslíte, čo sa stane ďalej? Nuž, možno 80-90% vývojárov preprogramuje svoj softvér, ak to bude možné. Inými slovami, 10-20% používateľskej základne automaticky prejde na nejaký konkurenčný jazyk, napríklad Flutter.
Urobte to niekoľkokrát — a stratíte polovicu svojej používateľskej základne. Rovnako ako v športe, aj vo svete programovania je aktuálna forma tiež veľmi dôležitá. Všetko. Kto len tak stratí polovicu používateľov za päť rokov, bude považovaný za obrovského neúspešného hráča. Musíte byť trendy vo svete platforiem. Ale presne tu vás zanechanie podpory starších verzií časom zruinuje. Pretože zakaždým, keď sa zbavíte časti vývojárov, (a) ich navždy stratíte, pretože sú nahnevaní na vás za porušenie zmluvy, a (b) prenecháte ich svojim konkurentom.
Ironicky, aj ja som pomohol Googlu stať sa takým primadonou, ktorá ignoruje spätnú kompatibilitu, keď som vytvoril Grok, systém analýzy a porozumenia zdrojovému kódu, ktorý uľahčuje automatizáciu a vybavenie nástrojmi na základe samotného kódu — vyzerá to ako IDE, ale tu cloudová služba uchováva materializované pohľady všetkých miliárd riadkov zdrojového kódu Googlu vo veľkom úložisku dát.
Grok poskytol Googlerom silný základ pre automatizované refaktorovanie naprieč celou kódovou základňou (doslova v celom Googli). Systém vypočítava nielen vaše vzostupné závislosti (na ktorých ste závislí), ale aj zostupné (ktoré sú na vás závislé), takže pri zmene API viete, koho rozbíjate! Takto môžete pri vykonávaní zmien skontrolovať, či sa každý používateľ vášho API aktualizoval na novú verziu, a v skutočnosti často pomocou nástroja Rosie, ktorý napísali, môžete proces úplne automatizovať.
To umožňuje kódovej základni Googlu byť vnútorne takmer nadprirodzene „čistou“, pretože majú týchto robotizovaných sluhov, ktorí sa potulujú po dome a automaticky všetko upratujú, ak premenovali SomeDespicablyLongFunctionName na SomeDespicablyLongMethodName, pretože niekto sa rozhodol, že to je škaredý vnuk a treba ho uspať.
A úprimne, funguje to pre Google… vnútorné. Mám na mysli, áno, komunita Go v Googli sa naozaj priateľsky smeje komunite Java v Googli kvôli ich návyku na nepretržité refaktorovanie. Ak niečo reštartujete N-krát, znamená to, že ste to pokazili N-1-krát, ale po istom čase sa úplne jasne ukáže, že ste to pravdepodobne pokazili aj pri N-tom pokuse. Ale vo veľkom to ostáva nad touto rozruchom a udržuje kód „čistým“.
Problémy začínajú, keď sa pokúšajú vnucovať takýto prístup svojim cloudovým klientom a používateľom iných API.
Trochu som vás zoznámil s Emacs, Androidom a Javou; poďme sa pozrieť na poslednú úspešnú, dlhodobú platformu: samotný Web. Dokážete si predstaviť, koľko iterácií prešiel HTTP od roku 1995, keď sme používali blikajúce tagy a ikony „V prebiehaní“ na webových stránkach.
Ale stále to funguje! A tieto stránky stále fungujú! Áno, chalani, prehliadače sú majstri sveta v spätnej kompatibilite. Chrome je ďalším príkladom zriedkavej platformy Googlu, kde sú hlavy pripevnené správne, a ako ste už uhádli, Chrome efektívne funguje ako izolovaná spoločnosť od zvyšku Googlu.
Rád by som tiež poďakoval našim priateľom medzi vývojármi operačných systémov: Windows, Linux, NIE APPLE POŠLA ŤA APPLE, FreeBSD a tak ďalej, za to, že odviedli takú veľkú prácu na spätnej kompatibilite na svojich úspešných platformách (Apple dostáva v najlepšom prípade trojku s mínusom, pretože neustále všetko rozbíjajú bez akéhokoľvek dôvodu, ale nejako sa komunita s týmto vyrovnáva v každej verzii, a doteraz sú kontajnery s OS X stále relevantné… zatiaľ).
Ale počkajte, poviete vy. Neprirovnávame predsa jablká k pomarančom — autonómne softvérové systémy na jednom stroji, ako Emacs/JDK/Android/Chrome, k viacserverovým systémom a API, ako v oblakových službách?
Napísal som o tom včera na Twitteri, ale v štýle Larryho Walla (tvorcu programovacieho jazyka Perl — pozn. prekl.) na princípe „odpadky/úžasné“ som hľadal slovo deprecated na stránkach pre vývojárov Google a Amazon. A hoci má AWS stokrát viac ponúk služieb ako GCP, dokumentácia vývojárov Google spomína zastaranosť približne sedemkrát častejšie.
Ak niekto z Google toto číta, určite sú pripravení vytiahnuť diagramy, ukazujúc štýl Donalda Trumpa, že v skutočnosti všetko robia správne, a že by som nemal robiť nespravodlivé porovnania, ako „počet zmienok slova deprecated v závislosti od počtu služieb“.
Ale po toľkých rokoch zostáva Google Cloud stále službou č. 3 (napsal som článok o neúspešnom pokuse stať sa č. 2), ale ak veríte insiderom, existujú určité obavy, že môžu čoskoro klesnúť na č. 4.
Nemám pádne argumenty, aby som „dokázal“ svoju teóriu. Všetko, čo mám, sú pôsobivé príklady, ktoré som nazbieral za 30 rokov práce ako vývojár. Už som spomínal hĺbkové filozofické povahy tohto problému; v istom zmysle je to politizované v komunitách vývojárov. Niektorí si myslia, že tvorcovia platforiem by sa mali zaujímať o kompatibilitu, a iní si myslia, že je to starosť užívateľov (samotných vývojárov). Jedno alebo druhé. A naozaj, nie je to politická otázka, keď sa rozhodujeme, kto by mal niesť náklady na spoločné problémy?
Takže je to politika. A určite budú rozhorčené odpovede na moje vystúpenie.
Ako používateľ ako používateľ cloudovej platformy Google a AWS už dva roky (práca v spoločnosti Grab), môžem povedať, že medzi filozofiami Amazonu a Google existuje obrovský rozdiel, pokiaľ ide o priority. Nezameriavam sa na aktívny vývoj na AWS, preto neviem presne, ako často odstraňujú staré API. Mám však podozrenie, že sa to nestáva tak často ako v Google. Úprimne verím, že tento zdroj neustálych sporov a sklamaní na GCP je jedným z najväčších faktorov, ktoré brzdia rozvoj platformy.
Vieme, že som nespomenul konkrétne príklady systémov GCP, ktorých podpora bola ukončená. Môžem povedať, že takmer všetko, čo som použil, 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 (o tom ani nezačínajme), cloudových koncových bodov Cloud Endpoint a až po… neviem — absolútne všetko toto ma nútilo prepisovať kód maximálne každé 2-3 roky, a nikdy pre vás automaticky nemigrovali, a často . Ako keby to tak malo byť.
A zakaždým, keď sa pozriem na AWS, pýtam sa, prečo na svete som ešte na GCP. Zjavne ich klienti nezaujímajú. Potrebujú kupujúcich. Chápete ten rozdiel? Nechajte ma to vysvetliť.
Google Cloud má , kde ľudia ponúkajú svoje softvérové riešenia, a aby sa predišlo efektu prázdnej reštaurácie, bolo potrebné ju zaplniť niektorými ponukami, a preto uzavreli zmluvu so spoločnosťou Bitnami, aby vytvorila množstvo riešení, ktoré sú nasadzované „jedným kliknutím myši“, alebo musím sám napísať „riešenia“, pretože tieto naozaj nič nerobia. Iba existujú ako checkboxy, ako marketingový vypĺňač, a Google nikdy nezaujímalo, či niektorý z nástrojov skutočne funguje. Poznám produktových manažérov, ktorí to riadili, a môžem vás uistiť, že týmto ľuďom je to jedno.
Povedzme si príklad so zdanlivo „jedným kliknutím myši“ nasadením . Urobilo ma do extrému unavený trikmi Google Cloud SQL, takže som začal zvažovať vytvorenie vlastného clusteru Percona ako alternatívy. A tentoraz sa zdalo, že Google urobil dobrý krok, mali mi ušetriť trochu času a úsilia jedným kliknutím!
No, skvele, poďme. Prejdeme na odkaz a stlačíme toto tlačidlo. Vyberáme „Áno“, aby sme súhlasili so všetkými predvolenými parametrami a rozšírili klaster vo svojom oblačnom projekte Google. Haha, nefunguje to. Nič z toho nefunguje. Nástroj nikdy nebol testovaný a začal hniť od prvej minúty, a neprekvapí ma, ak viac ako polovica „riešení“ na nasadenie jedným kliknutím myši (teraz chápeme, prečo sú úvodzovky) nefunguje. vôbec nefungujú. Je to absolútna beznádejná temnota, do ktorej je lepšie nevstupovať.
Ale Google priamo vyzýva vás, aby ste ich používali. Chcú, aby ste ich kúpili. Pre nich je to transakcia. Nechcú nič podporovať. To nie je časť DNA Google. Áno, inžinieri si navzájom pomáhajú, čo potvrdzuje moja skúsenosť s Bigtable. Ale v produktoch a službách pre bežných používateľov sú vždy neúprosní v , ktorý nespĺňa štandard ziskovosti, aj keď má milióny používateľov.
A to predstavuje reálny problém pre GCP, pretože táto DNA je základom všetkých oblačných ponúk. Nesnažia sa nič podporovať; je dobre známe, že odmietajú hosťovať (ako riadenú službu) akýkoľvek tretí softvér kým AWS neurobí to isté a nevybuduje okolo toho úspešný biznis, a keď zákazníci doslova nebudú požadovať to isté. Avšak je potrebné vynaložiť určité úsilie, aby sa Google donútil niečo podporovať.Táto absencia kultúry podpory, v kombinácii s princípom „poďme rozbiť, aby sme to urobili krásnejším“, odrádza od nich vývojárov.
A to nie je veľmi dobré, ak chcete vybudovať dlhodobú platformu.
Google, prebudi sa, sakra. Teraz je rok 2020. Stále prehrávaš. Je čas sa pozrieť do zrkadla a odpovedať si, naozaj chceš zostať v oblačnom biznise.
Ak chceš zostať, tak
prestaň všetko rozbíjať . Chlapci, veď ste bohatí. My, vývojári, nie sme. Takže, keď príde na to, kto ponesie bremeno kompatibility, musíte to vziať na seba. Nie nás.Pretože existujú ešte aspoň tri naozaj dobré cloudové riešenia. Láka nás to k sebe.
A teraz pôjdem ďalej opravovať všetky moje zlomené systémy. Ach.
Do ďalšieho razy!
Do ďalšieho raz!
P. S. Aktualizácia po prečítaní niektorých diskusií k tomuto článku (diskusie sú mimochodom skvelé). Podpora Firebase nebola ukončená a nemám informácie o žiadnych plánoch na jej ukončenie. Napriek tomu majú nepríjemnú chybu streamovania, ktorá spôsobuje, že Java klient zamŕza na App Engine. Jeden z ich inžinierov mi pomohol vyriešiť tento problém, keď som pracoval v Google, ale nikdy naozaj neopravili túto chybu, takže mám nedokonalé obchádzanie, musím každý deň reštartovať aplikáciu GAE. Takto to ide už štyri roky! Teraz majú Firestore. Bude to vyžadovať veľa práce na migráciu, pretože ide o úplne iný systém a chyba Firebase nikdy nebude opravená. Aký je záver? Môžete získať pomoc, ak pracujete v spoločnosti. Asi som jediný, kto používa Firebase na GAE, pretože zapisujem menej ako 100 kľúčov do natívnej aplikácie na 100% a prestáva fungovať každé pár dní kvôli známej chybe. Čo sa dá povedať, ak nie, že to používate na vlastné riziko. Prechádzam na Redis.
Taktiež som videl, že niektorí skúsenejší používatelia AWS hovorili, že AWS zvyčajne nikdy neukončuje podporu žiadnych služieb a SimpleDB je skvelým príkladom. Moje predpoklady, že v AWS nie je také zlo, ako je ukončenie podpory, ako v Google, sa zdajú byť oprávnené.
Okrem toho som si všimol, že pred 20 dňami tím Google App Engine zrušil hosting kritickej knižnice Go, zatvorením aplikácie GAE od jedného z hlavných vývojárov Go. Naozaj sa to ukázalo ako hlúpe.
Nakoniec, počul som, že googleri už diskutujú o tomto probléme a vo všeobecnosti so mnou súhlasia (mám vás rád, chlapci!). Ale zdá sa, že považujú problém za neriešiteľný, pretože v kultúre Google nikdy neexistovala správna štruktúra stimulov. Myslím, že by bolo dobré nájsť si čas na diskusiu o úplne úžasnej skúsenosti práce s inžiniermi AWS, keď som pracoval v spoločnosti Grab. Dúfam, že sa k tomu dostanem niekedy v budúcnosti!
A áno, v roku 2005 mali skutočne rôzne druhy žraločieho mäsa na obrovskom švédskom stole v budove 43, a mne najviac chutnalo mäso mletých žralokov. Avšak do roku 2006 Larry a Sergey zbavili všetky nezdravé občerstvenia. Takže počas príbehu o Bigtable v roku 2007 už naozaj nebolo žiadnych žralokov a podlato som vás oklamal.
Keď som pred štyrmi rokmi (plus mínus) pozeral na cloudovú Bigtable, cena bola presne takáto. Zdá sa, že teraz trochu klesla, ale stále je to hrozne veľa za prázdne úložisko dát, najmä keď moja prvá história ukazuje, ako nepodstatná je prázdna veľká tabuľka v ich meradle.
Prepáčte, že som urazil komunitu Apple a že som nepovedal nič dobré o Microsofte a tak ďalej. Máte pravdu, veľmi si vážim všetky diskusie, ktoré tento článok vyvolal! Ale niekedy je potrebné trochu rozprúdiť debatu, rozumiete?
Ďakujem za čítanie.
Aktualizácia 2, 19.08.2020. Stripe !
Aktualizácia 3, 31.08.2020. Skontaktoval sa so mnou inžinier Google z Cloud Marketplace, ktorý sa ukázal byť mojím starým priateľom. Chcel zistiť, prečo C2D nefunguje, a nakoniec sme zistili: dôvod je ten, že som svoju sieť vytvoril pred pár rokmi, a C2D nefunguje vo zastaraných sieťach kvôli chýbajúcemu parametru podsiete v ich šablónach. Myslím, že potenciálni používatelia GCP by sa mali uistiť, že majú dostatočne známych inžinierov v Googli...
Zdroj: habr.com
