Sakra Google, nechtěl jsem znovu blogovat. Mám toho tolik na práci. Blogování vyžaduje čas, energii a kreativitu, které bych mohl dobře využít: moje knihy, , moje hra a tak dále. Ale naštval jsi mě natolik, že to musím napsat.
Tak ať to máme za sebou.
Dovolte mi začít krátkým, ale poučným příběhem z doby, kdy jsem poprvé začal pracovat v Googlu. Vím, že v poslední době říkám o Googlu spoustu špatných věcí, ale rozčiluje mě, když moje vlastní společnost pravidelně dělá nekompetentní obchodní rozhodnutí. Zároveň musíme dát za pravdu: interní infrastruktura Google je skutečně mimořádná, s jistotou lze říci, že dnes není nic lepšího. Zakladatelé Googlu byli mnohem lepší inženýři, než kdy budu já, a tento příběh tuto skutečnost jen potvrzuje.
Nejprve malé pozadí: Google má technologii pro ukládání dat, tzv . Byl to pozoruhodný technický úspěch, jeden z prvních (ne-li první) „nekonečně škálovatelných“ úložišť klíč-hodnota (K/V): v podstatě začátek NoSQL. V těchto dnech si Bigtable stále vede dobře v poměrně přeplněném úložném prostoru K/V, ale v té době (2005) to bylo úžasně cool.
Jedna legrační věc na Bigtable je, že měli objekty vnitřní řídicí roviny (jako součást implementace) nazývané tabletové servery s velkými indexy a v určitém okamžiku se staly úzkým hrdlem při škálování systému. Inženýři Bigtable si lámali hlavu nad tím, jak implementovat škálovatelnost, a najednou si uvědomili, že by mohli nahradit tabletové servery jiným úložištěm Bigtable. Bigtable je tedy součástí implementace Bigtable. Tato skladovací zařízení jsou na všech úrovních.
Dalším zajímavým detailem je, že Bigtable se na chvíli stal populárním a všudypřítomným v rámci Googlu, přičemž každý tým má své vlastní úložiště. Na jednom z pátečních setkání se tedy Larry Page jen tak mimochodem zeptal: „Proč máme více než jeden Bigtable? Proč ne jen jeden?" Teoreticky by jedno úložiště mělo stačit pro všechny potřeby úložiště Google. Samozřejmě nikdy nešli jen do jednoho z praktických vývojových důvodů (jako důsledky případného selhání), ale teorie byla zajímavá. Jedno úložiště pro celý vesmír (Mimochodem, neví někdo, jestli to Amazon udělal se svým Sablem?)
Každopádně tady je můj příběh.
V té době jsem ve společnosti Google pracoval něco málo přes dva roky a jednoho dne jsem od inženýrského týmu Bigtable dostal e-mail, který vypadal asi takto:
milý Steve,
Zdravíme vás z týmu Bigtable. Rádi bychom vás informovali, že v [název datového centra] používáte velmi, velmi starou binárku Bigtable. Tato verze již není podporována a my vám chceme pomoci s upgradem na nejnovější verzi.
Dejte mi prosím vědět, zda si můžete naplánovat nějaký čas na společnou práci na tomto problému.
Vše nejlepší,
Bigtable tým
Na Google dostáváte spoustu pošty, takže na první pohled jsem četl něco takového:
Vážený příjemci,
Zdravím vás z nějakého týmu. Chceme sdělit, že bla bla bla bla bla. Bla bla bla bla bla bla a bla bla bla okamžitě.
Dejte nám prosím vědět, jestli si můžete naplánovat nějaký svůj drahocenný čas na bla bla bla.
Vše nejlepší,
Nějaký druh příkazu
Okamžitě jsem to málem vymazal, ale na okraji svého vědomí jsem cítil bolestivý, otravný pocit ne ve skutečnosti ale vypadá to jako formální dopis zjevně, že se příjemce spletl, protože jsem nepoužil Bigtable.
Ale bylo to zvláštní.
Zbytek dne jsem střídavě přemýšlel o práci a o tom, jaké žraločí maso zkusit v mikrokuchyni, z nichž minimálně tři byly tak blízko, abych trefil ze sedadla dobře mířeným hodem sušenky, ale myšlenka na psaní ve mně nikdy neopustila rostoucí pocit mírné úzkosti.
Jasně řekli mé jméno. A e-mail byl odeslán na moji e-mailovou adresu, ne na cizí, a není to kopie: ani skrytá kopie:. Tón je velmi osobní a jasný. Možná je to nějaká chyba?
Nakonec mě přemohla zvědavost a šel jsem se podívat na Borgskou konzoli v datovém centru, které zmiňovali.
A samozřejmě jsem měl pod správou úložiště BigTable. Omlouvám se, co? Podíval jsem se na jeho obsah a wow! Bylo to z inkubátoru Codelab, ve kterém jsem seděl během prvního týdne v Googlu v červnu 2005. Codelab vás donutil spustit Bigtable, abyste tam zapsali nějaké hodnoty, a poté jsem úložiště zřejmě nikdy nezavřel. Stále fungoval, i když uplynuly více než dva roky.
Tento příběh má několik pozoruhodných aspektů. Za prvé, práce Bigtable byla v měřítku Google tak bezvýznamná, že jen o dva roky později si někdo všiml dalšího úložiště, a to pouze proto, že verze binárního souboru byla zastaralá. Pro srovnání jsem kdysi uvažoval o použití pro mou online hru. V té době tato služba stála přibližně 16 000 $ ročně. prázdný Bigtable na GCP. Neříkám, že tě podvádějí, ale podle mého osobního názoru je to hodně peněz za prázdnou zkurvenou databázi.
Dalším pozoruhodným aspektem je úložiště funguje i po dvou letech. WTF? Datová centra přicházejí a odcházejí; mají výpadky, podstupují plánovanou údržbu, neustále se mění. Hardware je aktualizován, přepínače jsou prohozeny, vše se neustále vylepšuje. Jak sakra dokázali udržet můj program v chodu dva roky se všemi těmi změnami? V roce 2020 se to může zdát jako skromný úspěch, ale v letech 2005–2007 to bylo docela působivé.
A nejúžasnějším aspektem je, že se ke mně, majiteli nějaké maličké, téměř prázdné instance Bigtable, přiblíží externí inženýrský tým v nějakém jiném státě. nulový provoz za poslední dva roky – a nabízejí pomoc s jeho aktualizací.
Poděkoval jsem jim, vymazal úložiště a život pokračoval jako obvykle. Ale o třináct let později na ten dopis stále myslím. Protože někdy dostávám podobné e-maily z Google Cloud. Vypadají takto:
Vážený uživateli Google Cloud,
Připomínáme, že od srpna 2020 ukončíme službu [základní služba, kterou používáte], poté již nebudete moci upgradovat své instance. Doporučujeme upgradovat na nejnovější verzi, která je ve fázi beta testování, nemá žádnou dokumentaci, žádnou migrační cestu a s naší laskavou pomocí je již zastaralá.
Jsme odhodláni zajistit, aby tato změna měla minimální dopad na všechny uživatele platformy Google Cloud.
Nejlepší přátelé navždy,
Google Cloud Platform
Ale takové dopisy skoro nikdy nečtu, protože ve skutečnosti říkají:
Vážený příjemci,
Jdi do pekla. Do prdele, do prdele, do prdele. Zahoďte všechno, co děláte, protože na tom nezáleží. Důležitý je náš čas. Ztrácíme čas a peníze udržováním našich keců a už nás to nebaví, takže už to nebudeme podporovat. Tak přestaň se svými zasranými plány a začni se prohrabávat naší zasranou dokumentací, prosit o útržky na fórech, a mimochodem, naše nová sračka je úplně jiná než ta stará sračka, protože jsme tenhle design pěkně podělali, heh, ale to je tvoje problém, ne náš.
I nadále se snažíme zajistit, aby se všechny vaše vývojové prvky staly nepoužitelnými do jednoho roku.
Vypadni prosím
Google Cloud Platform
A je fakt, že takové dopisy dostávám tak jednou za měsíc. To se děje tak často a tak neustále, že nevyhnutelně odstrčený já z GCP do anti-cloudového tábora. Už nesouhlasím se spoléháním na jejich proprietární vývoj, protože ve skutečnosti je pro vývojáře snazší udržovat systém s otevřeným zdrojovým kódem na holém virtuálním stroji, než se snažit držet krok s Googlem s jeho politikou uzavírání „zastaralých“ produktů.
Než se vrátím ke službě Google Cloud, protože dokonce blízko ještě jsme je neskončili, podívejme se na výkonnost společnosti v některých jiných oblastech. Inženýři Google jsou hrdí na svou disciplínu softwarového inženýrství, a to je to, co ve skutečnosti způsobuje problémy. Pýcha je pastí pro neopatrné a mnoho zaměstnanců Google vedla k tomu, že si mysleli, že jejich rozhodnutí jsou vždy správná a že mít pravdu (podle nějaké vágní nejasné definice) je důležitější než péče o zákazníky.
Uvedu několik náhodných příkladů z jiných velkých projektů mimo Google, ale doufám, že tento vzor uvidíte všude. Je to takto: zpětná kompatibilita udržuje systémy živé a aktuální po celá desetiletí.
Zpětná kompatibilita je cílem návrhu všech úspěšných systémů navržených pro otevřít použití, to znamená implementované s otevřeným zdrojovým kódem a/nebo otevřenými standardy. Mám pocit, že říkám něco příliš samozřejmého, že je to všem dokonce nepříjemné, ale ne. Jde o politickou otázku, takže jsou potřeba příklady.
První systém, který vyberu, je nejstarší: GNU Emacs, což je jakýsi hybrid mezi Windows Notepadem, jádrem OS a Mezinárodní vesmírnou stanicí. Je to trochu těžké vysvětlit, ale v kostce, Emacs je platforma vytvořená v roce 1976 (ano, téměř před půl stoletím) pro programování, abyste byli produktivnější, ale maskující se jako textový editor.
Emacs používám každý den. Ano, IntelliJ také používám každý den, sám o sobě vyrostl ve výkonnou nástrojovou platformu. Ale psaní rozšíření pro IntelliJ je mnohem ambicióznější a složitější úkol než psaní rozšíření pro Emacs. A co je důležitější, vše napsané pro Emacs je zachováno navždy.
Stále používám software, který jsem napsal pro Emacs v roce 1995. A jsem si jistý, že někdo používá moduly napsané pro Emacs v polovině 80. let, ne-li dříve. Čas od času mohou vyžadovat drobné úpravy, ale to je opravdu velmi vzácné. Nevím o ničem, co jsem kdy napsal pro Emacs (a napsal jsem toho hodně), co by vyžadovalo re-architekturu.
Emacs má funkci nazvanou make-obsolete pro zastaralé entity. Terminologie Emacsu pro základní počítačové koncepty (např. co je to „okno“) se často liší od zvyklostí v oboru, protože je Emacs zavedl již před dlouhou dobou. Toto je typické nebezpečí pro ty, kteří předběhli dobu: všechny vaše podmínky jsou nesprávné. Ale Emacs má koncept zavržení, kterému se v jejich žargonu říká zastarávání.
Zdá se však, že ve světě Emacsu existuje jiná pracovní definice. Jiná základní filozofie, chcete-li.
Ve světě Emacsu (a mnoha dalších oblastech, kterým se budeme věnovat níže), zastaralý stav API v podstatě znamená: „Tento přístup byste opravdu neměli používat, protože i když funguje, trpí různými nedostatky, které zde uvedeme. Ale na konci dne je to vaše volba."
Ve světě Google znamená být zastaralý: „Porušujeme náš závazek vůči vám.“ To je pravda. To je to, co to v podstatě znamená. To znamená, že vás donutí pravidelně dělat nějakou práci, možná hodně práce, jako trest za to, že v ně věříte : Máme nejlepší software. Nejrychlejší! Uděláte vše podle návodu, spustíte svou aplikaci nebo službu a pak bum, po roce nebo dvou to praskne.
Je to jako prodávat ojeté auto, které se po 1500 km určitě rozbije.
Toto jsou dvě zcela odlišné filozofické definice „zastarání“. Definice vůně od Googlu . Tomu nevěřím ve skutečnosti plánované zastarávání ve stejném smyslu jako Apple. Google ale rozhodně plánuje rozbít vaše programy, a to kruhovým objezdem. Vím to, protože jsem tam pracoval jako softwarový inženýr přes 12 let. Mají vágní interní směrnice o tom, jak moc by se měla zpětná kompatibilita dodržovat, ale to je nakonec na každém jednotlivém týmu nebo službě. Neexistují žádná doporučení na podnikové nebo inženýrské úrovni a nejodvážnějším doporučením, pokud jde o cykly zastarávání, je „zkusit dát zákazníkům 6–12 měsíců na upgrade, než rozbijí celý jejich systém“.
Problém je mnohem větší, než si myslí, a bude přetrvávat v příštích letech, protože zákaznická péče není v jejich DNA. Více o tom níže.
V tomto bodě udělám odvážné prohlášení, že Emacs je do značné míry úspěšný a dokonce většinou protože berou zpětnou kompatibilitu tak vážně. To je vlastně teze našeho článku. Úspěšné otevřené systémy s dlouhou životností vděčí za svůj úspěch mikrokomunitám, které kolem nich žijí po celá desetiletí rozšíření/pluginy. Toto je ekosystém. Už jsem mluvil o povaze platforem a o tom, jak jsou důležité, a o tom, jak Google nikdy v celé své firemní historii nepochopil, co znamená vytvoření úspěšné otevřené platformy mimo Android nebo Chrome.
Vlastně bych se měl krátce zmínit o Androidu, protože o něm pravděpodobně přemýšlíte.
Za prvé, Android není Google. Nemají spolu téměř nic společného. Android je společnost, která byla koupena společností Google v červenci 2005, společnosti bylo povoleno fungovat víceméně autonomně a ve skutečnosti zůstala v uplynulých letech z velké části nedotčena. Android je notoricky známý technologický stack a stejně notoricky známá pichlavá organizace. Jak řekl jeden zaměstnanec společnosti Google: „Do Androidu se nemůžete jen tak přihlásit.“
V předchozím článku jsem diskutoval o tom, jak špatná byla některá z prvních návrhů Androidu. Sakra, když jsem psal ten článek, vypouštěli kecy zvané „okamžité aplikace“, které jsou nyní (překvapení!) a sympatizuji, pokud jste byli tak hloupí, abyste poslouchali Google a přesunuli svůj obsah do těchto okamžitých aplikací.
Ale je tu rozdíl, významný rozdíl, který spočívá v tom, že lidé s Androidem skutečně chápou, jak důležité jsou platformy, a snaží se, aby staré aplikace pro Android fungovaly. Ve skutečnosti je jejich úsilí o zachování zpětné kompatibility tak extrémní, že i já jsem se během svého krátkého působení v divizi Android před několika lety přistihl, že se je snažím přesvědčit, aby přestali podporovat některá z nejstarších zařízení a API (mýlil jsem se , stejně jako v mnoha jiných věcech minulých i současných. Promiňte, pánové Android! Teď, když jsem byl v Indonésii, chápu, proč je potřebujeme).
Lidé se systémem Android posouvají zpětnou kompatibilitu do téměř nepředstavitelných extrémů a hromadí obrovské množství starších technických dluhů ve svých systémech a řetězcích nástrojů. Ach můj bože, měli byste vidět některé z těch šílených věcí, které musí dělat ve svém systému sestavování, to vše ve jménu kompatibility.
Za to uděluji Androidu vytoužené ocenění „You're Not Google“. Opravdu se nechtějí stát Googlem, který neumí vytvářet odolné platformy, ale Androidem ví, jak to udělat. A tak je Google v jednom ohledu velmi chytrý: umožňuje lidem dělat věci na Androidu po svém.
Okamžité aplikace pro Android však byly docela hloupý nápad. A víte proč? Protože požadovali přepište a přepracujte svou aplikaci! Je to, jako by lidé jednoduše přepsali dva miliony aplikací. Hádám, že Instant Apps byl nápad nějakého zaměstnance společnosti Google.
Ale je tu rozdíl. Zpětná kompatibilita je spojena s vysokou cenou. Android sám nese břemeno těchto nákladů, zatímco Google trvá na tom, že toto břemeno nese vy, platícího klienta.
Závazek Androidu ke zpětné kompatibilitě můžete vidět v jeho API. Když máte čtyři nebo pět různých subsystémů, které dělají doslova totéž, je to neklamné znamení, že v jádru existuje závazek ke zpětné kompatibilitě. Což je ve světě platforem synonymem pro oddanost vašim zákazníkům a vašemu trhu.
Hlavním problémem Googlu je zde jejich hrdost na technickou hygienu. Nelíbí se jim, když existuje mnoho různých způsobů, jak dělat totéž, přičemž staré, méně žádoucí způsoby sedí vedle nových, vychytralejších způsobů. Prodlužuje to křivku učení pro ty, kdo jsou v systému noví, zvyšuje to zátěž na údržbu starších API, zpomaluje rychlost nových funkcí a hlavním hříchem je, že to není hezké. Google – jako Lady Ascot z Alenky v říši divů Tima Burtona:
Lady Ascotová:
- Alice, víš, čeho se nejvíc bojím?
- Úpadek aristokracie?
- Bál jsem se, že budu ošklivá vnoučata.
Abychom pochopili kompromis mezi krásným a praktickým, podívejme se na třetí úspěšnou platformu (po Emacsu a Androidu) a podívejme se, jak funguje: samotná Java.
Java má spoustu zastaralých API. Deprece je mezi programátory Java velmi populární, dokonce populárnější než ve většině programovacích jazyků. Samotná Java, základní jazyk a knihovny neustále zavrhují API.
Vezmeme-li jen jeden z tisíců příkladů, považovány za zastaralé. Od vydání Java 1.2 v prosinci 1998 je zastaralá. Je to 22 let, co byla tato podpora ukončena.
Ale můj skutečný kód ve výrobě stále zabíjí vlákna každý den. Opravdu si myslíš, že je to dobře? Absolutně! Myslím tím samozřejmě, že kdybych dnes přepisoval kód, implementoval bych ho jinak. Ale kód pro mou hru, která za poslední dvě desetiletí udělala radost stovkám tisíc lidí, je napsán pomocí funkce, která uzavírá vlákna, která visí příliš dlouho, a já nikdy to nemusel měnit. Znám svůj systém lépe než kdokoli jiný, mám doslova 25 let zkušeností s prací s ním ve výrobě a mohu s jistotou říci: v mém případě je uzavření těchto specifických pracovních vláken zcela neškodný. Nestojí za čas a námahu přepisovat tento kód a děkuji Larrymu Ellisonovi (pravděpodobně), že mě Oracle nenutil ho přepsat.
Oracle pravděpodobně rozumí i platformám. Kdo ví.
Důkazy lze nalézt v základních rozhraních Java API, která jsou protkaná vlnami zastaralosti, jako jsou čáry ledovce v kaňonu. V knihovně Java Swing můžete snadno najít pět nebo šest různých správců navigace pomocí klávesnice (KeyboardFocusManager). Ve skutečnosti je těžké najít Java API, které není zastaralé. Ale stále fungují! Myslím, že tým Java skutečně odstraní API pouze v případě, že rozhraní představuje závažný bezpečnostní problém.
Tady je věc, přátelé: My vývojáři softwaru jsme všichni velmi zaneprázdněni a v každé oblasti softwaru čelíme konkurenčním alternativám. V každém okamžiku programátoři v jazyce X zvažují jazyk Y jako možnou náhradu. Oh, ty mi nevěříš? Chcete tomu říkat Swift? Jako, všichni migrují na Swift a nikdo to neopouští, že? Páni, jak málo toho víš. Společnosti počítají náklady na dva mobilní vývojové týmy (iOS a Android) – a začínají si uvědomovat, že tyto multiplatformní vývojové systémy s vtipnými názvy jako Flutter a React Native skutečně fungují a lze je použít ke zmenšení velikosti jejich mobilní týmy dvakrát nebo naopak, aby byly dvakrát produktivnější. V sázce jsou skutečné peníze. Ano, existují kompromisy, ale na druhou stranu peníze.
Předpokládejme hypoteticky, že Apple si pošetile vzal návod od Guida van Rossuma a prohlásil, že Swift 6.0 je zpětně nekompatibilní se Swift 5.0, podobně jako je Python 3 nekompatibilní s Pythonem 2.
Pravděpodobně jsem tento příběh vyprávěl asi před deseti lety, ale asi před patnácti lety jsem šel s Guidem do O'Reillyho Foo Campu, seděl ve stanu s Paulem Grahamem a hromadil se velkých panáků. Seděli jsme v úmorném vedru a čekali, až Larry Page odletí ve své osobní helikoptéře, zatímco Guido hučel na „Python 3000“, který pojmenoval podle počtu let, které by každému trvalo, než by tam migroval. Stále jsme se ho ptali, proč porušuje kompatibilitu, a on odpověděl: "Unicode." A zeptali jsme se, kdybychom museli přepsat náš kód, jaké další výhody bychom viděli? A on odpověděl: "Joooooooooooooouuuuuuniiiiiiicoooooooode."
Pokud si nainstalujete Google Cloud Platform SDK („gcloud“), obdržíte následující upozornění:
Vážený příjemci,
Rádi bychom vám připomněli, že podpora pro Python 2 byla ukončena, tak se vyserte
… a tak dále. Kruh života.
Jde ale o to, že každý vývojář má na výběr. A pokud je dostatečně často donutíte přepisovat kód, mohli by o tom přemýšlet další možnosti. Nejsou to vaši rukojmí, bez ohledu na to, jak moc byste je chtěli mít. Jsou to vaši hosté. Python je stále velmi populární programovací jazyk, ale sakra, Python 3(000) vytvořil v sobě, ve svých komunitách a mezi uživateli svých komunit takový nepořádek, že následky nebyly odstraněny ani patnáct let.
Kolik programů Pythonu bylo přepsáno v Go (nebo Ruby nebo nějaké jiné alternativě) kvůli této zpětné nekompatibilitě? Kolik nového softwaru bylo napsáno v něčem jiném než v Pythonu, i když ano mohlo by být napsané v Pythonu, kdyby Guido nevypálil celou vesnici? Těžko říct, ale Python tím jednoznačně utrpěl. Je to obrovský nepořádek a všichni prohrávají.
Řekněme tedy, že si Apple vezme příklad od Guida a naruší kompatibilitu. Co myslíte, že se stane dál? No, možná 80-90% vývojářů přepíše svůj software, pokud je to možné. Jinými slovy, 10-20 % uživatelské základny automaticky přejde do nějakého konkurenčního jazyka, jako je Flutter.
Udělejte to několikrát a ztratíte polovinu své uživatelské základny. Stejně jako ve sportu i ve světě programování záleží také na aktuální formě. всё. Každý, kdo během pěti let ztratí polovinu uživatelů, bude považován za Big Fat Loser. Ve světě platforem musíte být trendy. Tady vás ale nepodporování starších verzí časem zruinuje. Protože pokaždé, když se zbavíte některých vývojářů, (a) je navždy ztratíte, protože se na vás zlobí za porušení smlouvy, a (b) je rozdáte svým konkurentům.
Je ironií, že jsem také pomohl Googlu stát se takovou primadonou, která ignoruje zpětnou kompatibilitu, když jsem vytvořil Grok, systém pro analýzu a pochopení zdrojového kódu, který usnadňuje automatizaci a instrumentaci samotného kódu – podobně jako IDE, ale zde se ukládají cloudové služby zhmotnila reprezentace všech miliard řádků zdrojového kódu Google ve velkém datovém skladu.
Grok poskytl zaměstnancům společnosti Google výkonný rámec pro provádění automatizovaných refaktoringů v celé jejich kódové základně (doslova v celém Googlu). Systém vypočítá nejen vaše upstream závislosti (na kterých jste závislí), ale také po proudu (což je na vás), takže když změníte API, budete vědět o každém, koho porušujete! Tímto způsobem, když provedete změny, můžete ověřit, že každý uživatel vašeho API aktualizoval na novou verzi, a ve skutečnosti, často pomocí nástroje Rosie, který napsali, můžete proces zcela automatizovat.
To umožňuje, aby kódová základna Googlu byla vnitřně téměř nadpřirozeně čistá, protože mají tyto robotické sluhy, kteří se potulují po domě a automaticky vše uklidí, pokud SomeDespicablyLongFunctionName přejmenovali na SomeDespicablyLongMethodName, protože někdo usoudil, že je to ošklivé vnouče a jeho potřeba uspat.
A upřímně řečeno, pro Google to funguje docela dobře... interně. Chci říct, ano, komunita Go ve společnosti Google se dobře směje s komunitou Java ve společnosti Google, protože mají ve zvyku neustále refaktorovat. Pokud něco restartujete N-krát, znamená to, že jste to nejen N-1krát podělali, ale po chvíli bude docela jasné, že jste to pravděpodobně podělali i na N-tý pokus. Ale celkově zůstávají nad vším tímto povykem a udržují kód „čistý“.
Problém začíná, když se pokusí vnutit tento postoj svým cloudovým klientům a uživatelům jiných API.
Trochu jsem vám představil Emacs, Android a Javu; podívejme se na nejnovější úspěšnou platformu s dlouhou životností: samotný web. Dokážete si představit, kolika iterací HTTP prošel od roku 1995, kdy jsme používali blikající značky? a ikony "Ve výstavbě" na webových stránkách.
Ale pořád to funguje! A tyto stránky stále fungují! Ano, pánové, prohlížeče jsou mistry světa ve zpětné kompatibilitě. Chrome je dalším příkladem vzácné platformy Google, která má správně našroubované hlavy, a jak jste možná uhodli, Chrome funguje jako izolovaná společnost oddělená od zbytku Googlu.
Také bych rád poděkoval našim přátelům v oblasti vývojářů operačního systému: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD atd., za odvedení tak skvělé práce se zpětnou kompatibilitou na jejich úspěšných platformách (Apple dostane C v nejlepším případě s The nevýhodou je, že bezdůvodně všechno neustále rozbíjejí, ale komunita to s každým vydáním nějak obejde a kontejnery OS X stále nejsou úplně zastaralé... zatím).
Ale počkej, říkáš si. Neporovnáváme jablka s pomeranči – samostatné softwarové systémy na jednom počítači, jako je Emacs/JDK/Android/Chrome, versus systémy s více servery a API, jako jsou cloudové služby?
No, včera jsem o tom tweetoval, ale ve stylu Larryho Walla (tvůrce programovacího jazyka Perl - cca per.) na principu "sucks/rules" jsem si vyhledal slovo zastaralé na vývojářských stránkách Google a Amazon. A přestože AWS má stovky více než GCP, vývojářská dokumentace Google zmiňuje ukončení podpory asi sedmkrát častěji.
Pokud to někdo z Googlu čte, pravděpodobně je připraven vytáhnout grafy ve stylu Donalda Trumpa, které ukazují, že vlastně všechno dělají správně a že bych neměl dělat nefér srovnání typu „počet zmínek o slově zastaralé versus počet služeb" "
Ale po všech těch letech je Google Cloud stále službou č. 3 (nikdy jsem nenapsal článek o neúspěšném pokusu stát se č. 2), ale pokud se má věřit zasvěceným, existují určité obavy, že by brzy mohli klesnout na č. 4.
Nemám žádné pádné argumenty, kterými bych svou tezi „doložil“. Vše, co mám, jsou barevné příklady, které jsem nashromáždil za 30 let jako vývojář. O hluboce filozofické povaze tohoto problému jsem se již zmínil; určitým způsobem je v komunitách vývojářů zpolitizována. Někteří tomu věří tvůrci platformy by se měly starat o kompatibilitu, zatímco jiní si myslí, že jde o problém uživatelé (samotní vývojáři). Jeden ze dvou. Opravdu, není to politická otázka, když rozhodujeme, kdo má nést náklady společných problémů?
Tak tohle je politika. A pravděpodobně budou na můj projev vzteklé reakce.
Jak uživatel Google Cloud Platform a jako uživatel AWS dva roky (při práci pro Grab) mohu říci, že mezi filozofií Amazonu a Google je obrovský rozdíl, pokud jde o priority. Na AWS aktivně nevyvíjím, takže moc dobře nevím, jak často odstraňují stará API. Existuje ale podezření, že se to neděje zdaleka tak často jako u Googlu. A skutečně věřím, že tento zdroj neustálých kontroverzí a frustrace v GCP je jedním z největších faktorů brzdících vývoj platformy.
Vím, že jsem nejmenoval konkrétní příklady systémů GCP, které již nejsou podporovány. Mohu říci, že téměř vše, co jsem používal, od sítí (od nejstarších po VPC) po úložiště (Cloud SQL v1-v2), Firebase (nyní Firestore s úplně jiným API), App Engine (to ani nezačínáme) , cloudové koncové body Cloud Endpoint a až... nevím - úplně tohle všechno nutili vás přepsat kód maximálně po 2-3 letech a migraci za vás nikdy nezautomatizovali a často . Jako by to tak mělo být.
A pokaždé, když se podívám na AWS, ptám se sám sebe, proč jsem sakra pořád na GCP. O klienty evidentně nepotřebují. Potřebují kupující. Chápeš ten rozdíl? Nech mě to vysvětlit.
Google Cloud má , kde lidé navrhují svá softwarová řešení, a aby se vyhnuli prázdnému restauračnímu efektu, potřebovali je naplnit nějakými návrhy, a tak uzavřeli smlouvu se společností Bitnami, aby vytvořila spoustu řešení, která se nasazují „jedním kliknutím“, nebo by měla Sám to píšu „řešení“, protože to zatracenou věc nevyřeší. Jednoduše existují jako zaškrtávací políčka, jako marketingová výplň a Google se nikdy nestaral o to, zda některý z nástrojů skutečně funguje. Znám produktové manažery, kteří seděli na místě řidiče, a mohu vás ujistit, že těmto lidem je to jedno.
Vezměme si například řešení nasazení „na jedno kliknutí“. . Byl jsem k smrti nemocný z vychytávek Google Cloud SQL, tak jsem se začal poohlížet po vytvoření vlastního clusteru Percona jako alternativy. A tentokrát se zdálo, že Google odvedl dobrou práci, kliknutím na tlačítko mi ušetří čas a námahu!
No super, jdeme na to. Sledujme odkaz a klikneme na toto tlačítko. Výběrem možnosti „Ano“ odsouhlasíte všechna výchozí nastavení a nasadíte cluster do svého cloudového projektu Google. Haha, to nejde. Nic z tohohle svinstva nefunguje. Nástroj nebyl nikdy testován a od první minuty začal hnít a nepřekvapilo by mě, kdyby více než polovina „řešení“ byla nasazení na jedno kliknutí (teď už chápeme, proč ty uvozovky) vůbec nefunguje. To je naprosto beznadějná tma, kam je lepší nevstupovat.
Ale Google má pravdu povzbuzuje abyste je používali. Oni to chtějí koupil. Pro ně je to transakce. Nic se jim nechce na podporu. Není součástí DNA společnosti Google. Ano, inženýři se navzájem podporují, což dokazuje můj příběh s Bigtable. Ale v produktech a službách pro obyčejné lidi ano vždy byli nemilosrdní v , která nesplňuje laťku ziskovosti, i když má miliony uživatelů.
A to představuje skutečnou výzvu pro GCP, protože toto je DNA za všemi cloudovými nabídkami. Nesnaží se nic podporovat; Je dobře známo, že odmítají hostovat (jako spravovanou službu) jakýkoli software třetích stran dokud, dokud AWS neudělá to samé a vybuduje kolem toho úspěšný byznys a až to budou zákazníci doslova vyžadovat. Přimět Google, aby něco podporoval, však vyžaduje určité úsilí.
Tento nedostatek kultury podpory spolu s mentalitou „rozbijme to, aby to bylo krásnější“ odcizuje vývojáře.
A to není dobrá věc, pokud chcete vybudovat platformu s dlouhou životností.
Google, probuď se, sakra. Teď je rok 2020. Pořád prohráváš. Je čas se pořádně podívat do zrcadla a odpovědět si, zda opravdu chcete zůstat v cloudovém byznysu.
Pokud tedy chcete zůstat přestaň všechno rušit. Kluci, jste bohatí. My vývojáři ne. Takže pokud jde o to, kdo ponese břemeno kompatibility, musíte to vzít na sebe. Ne pro nás.
Protože tam jsou minimálně tři další opravdu dobré mraky. lákají.
A teď přejdu k opravě všech mých nefunkčních systémů. Eh
Do příště!
PS Update po přečtení některých diskuzí k tomuto článku (diskuze jsou skvělé, btw). Podpora Firebase nebyla ukončena a nevím o žádných plánech. Mají však ošklivou chybu streamování, která způsobuje, že se Java klient zablokuje v App Engine. Jeden z jejich inženýrů mi pomohl vyřešit tento problém, když jsem pracoval v Googlu, ale ve skutečnosti nikdy neopravili chybu, takže mám mizerné řešení, že musím každý den restartovat aplikaci GAE. A tak to bylo už čtyři roky! Nyní mají Firestore. Migrace na něj bude vyžadovat hodně práce, protože se jedná o zcela odlišný systém a chyba Firebase nebude nikdy opravena. Jaký závěr lze vyvodit? Můžete získat pomoc pokud pracujete ve společnosti. Jsem pravděpodobně jediný, kdo používá Firebase na GAE, protože ve 100% nativní aplikaci přihlásím méně než 100 klíčů a každých pár dní přestane fungovat kvůli známé chybě. Co mohu říci jiného, než že jej používáte na vlastní nebezpečí. Přecházím na Redis.
Také jsem viděl, jak někteří zkušenější uživatelé AWS říkají, že AWS obvykle nikdy nepřestane podporovat žádné služby a SimpleDB je skvělý příklad. Moje domněnky, že AWS nemá stejný konec podpory jako Google, se zdají být oprávněné.
Navíc jsem si všiml, že před 20 dny tým Google App Engine přerušil hostování kritické knihovny Go a vypnul aplikaci GAE od jednoho z hlavních vývojářů Go. Bylo to opravdu hloupé.
Konečně jsem slyšel, že zaměstnanci společnosti Google již o tomto problému diskutují a obecně se mnou souhlasí (miluji vás!). Zdá se však, že si myslí, že problém je neřešitelný, protože kultura Googlu nikdy neměla správnou motivační strukturu. Myslel jsem, že by bylo dobré věnovat nějaký čas diskusi o naprosto úžasné zkušenosti, kterou jsem měl při práci s inženýry AWS při práci v Grabu. Jednou v budoucnu, doufám!
A ano, v roce 2005 měli v obřím bufetu v budově 43 různé druhy žraločího masa a moje oblíbené bylo maso žraloka kladivouna. V roce 2006 se však Larry a Sergei zbavili všech nezdravých svačin. Takže během příběhu Bigtable v roce 2007 opravdu žádní žraloci nebyli a oklamal jsem vás.
Když jsem se před čtyřmi lety díval na cloud Bigtable (dej nebo ber), tady byly náklady. Zdá se, že to teď trochu kleslo, ale na prázdný datový sklad je to pořád strašně moc, zvlášť když můj první příběh ukazuje, jak bezvýznamný je prázdný velký stůl v jejich měřítku.
Omlouvám se, že jsem urazil komunitu Apple a neřekl nic hezkého o Microsoftu atd. Máte pravdu, opravdu si vážím všech diskuzí, které tento článek vyvolal! Ale někdy je potřeba trochu zamávat, abys zahájil diskusi, víš?
Děkuji za přečtení.
Aktualizace 2, 19.08.2020. Proužek !
Aktualizace 3, 31.08.2020. Kontaktoval mě inženýr Google z Cloud Marketplace, který se ukázal jako můj starý přítel. Chtěl zjistit, proč C2D nefunguje, a nakonec jsme přišli na to, že to bylo proto, že jsem svou síť vybudoval před lety a C2D nefungovalo na starších sítích, protože v jejich šablonách chyběl parametr podsítě. Myslím, že pro potenciální uživatele GCP je nejlepší, aby se ujistili, že znají dostatek inženýrů ve společnosti Google...
Zdroj: www.habr.com