Sakra, Google, nechtěl jsem znovu psát blog. Mám toho tolik na práci. Vedení blogu vyžaduje čas, energii a kreativitu, které bych mohl využít lépe: moje knihy, , moje hra a tak dále. Ale dost jsi mě naštval, a tak to musím napsat.
Tak pojďme na to.
Začnu malým, ale poučným příběhem z dob, kdy jsem začal pracovat v Googlu. Vím, že jsem v poslední době o Googlu hodně kritizoval, ale štve mě, když má vlastní společnost pravidelně přijímá neschopná obchodní rozhodnutí. Přitom je třeba uznat, že vnitřní infrastruktura Googlu je skutečně mimořádná, dá se s jistotou říci, že dnes neexistuje nic lepšího. Zakladatelé Googlu byli mnohem lepšími inženýry, než kdy já budu, a tento příběh jen potvrzuje tento fakt.
Nejprve trochu kontextu: Google má technologii pro ukládání dat zvanou . Bylo to úžasné technické dosažení, jedno z prvních (pokud ne první) "nekonečně škálovatelných" úložišť párů "klíč-hodnota" (key-value store, K/V): v podstatě začátek NoSQL. Dnes se Bigtable stále drží v poměrně přeplněném prostoru K/V úložišť, ale v té době (rok 2005) to bylo ohromně cool.
Jedním vtipným detailem Bigtable je, že měli vnitřní objekty řídicí roviny (jako součást implementace) zvané tablet 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 se lámali hlavu nad tím, jak realizovat škálovatelnost, a najednou si uvědomili, že mohou nahradit tablet servery jinými Bigtable úložišti. Takže Bigtable je část implementace Bigtable. Tato úložiště jsou tam na všech úrovních.
Další zajímavý detail je, že Bigtable se na nějakou dobu stali populárními a všudypřítomnými v Googlu, a každému týmu patřila vlastní databáze. Na jednom z pátečních setkání Larry Page náhodou řekl: „Proč máme více než jeden Bigtable? Proč se nemůžeme omezit na jeden?“ Teoreticky by jedna databáze měla stačit pro všechny potřeby ukládání dat Googlu. Samozřejmě, že nikdy nepřešli na jednu z praktických důvodů vývoje (např. potenciální důsledky selhání), ale teorie byla zajímavá. Jedna databáze pro celou Univerzitu (mimochodem, ví někdo, jestli něco podobného udělal Amazon se svým Sable?)
Tak či onak, to je můj příběh.
V té době jsem pracoval v Googlu něco přes dva roky, když mi přišel e-mail od inženýrského týmu Bigtable, který měl zhruba takový obsah:
Vážený Stevane,
Zdravíme vás od týmu Bigtable. Chceme vás informovat, že v datovém centru [název datového centra] používáte velmi, velmi starý binární soubor Bigtable. Tato verze již není podporována a rádi bychom vám pomohli přejít na nejnovější verzi.
Dejte nám, prosím, vědět, jestli můžete naplánovat čas na společnou práci na tomto problému.
S pozdravem,
Tým Bigtable
V Googlu dostáváte spoustu e-mailů, takže při prvním pohledu jsem to přečetl asi takto:
Vážený příjemce,
Zdravíme vás od nějakého týmu. Chceme vás informovat, že blablabla. Blablabla blablabla, a blablabla okamžitě.
Dejte nám, prosím, vědět, jestli můžete naplánovat část svého cenného času na blablabla.
S pozdravem,
Nějaký tým
Téměř jsem ho ihned smazal, ale na okraji vědomí jsem cítil tíživý, bolavý pocit, že to není úplně formální dopis, i když je zřejmé,že se adresát spletl, protože jsem Bigtable nepoužíval.
Ale bylo to divné.
Zbytek dne jsem se střídavě zamýšlel nad prací a tím, jaký druh žraločího masa vyzkoušet v mikro-kuchyni, z nichž alespoň tři byly dost blízko, aby se k mému místu dostal přesným hodem sušenky, ale myšlenka na dopis mě neopouštěla s rostoucím pocitem mírné úzkosti.
Oni jasně zmínili moje jméno. A dopis byl poslán na moji e-mailovou adresu, a ne na něčí jiný, a to není cc: nebo bcc:. Ton je velmi osobní a jasný. Možná je to nějaká chyba?
Nakonec zvědavost zvítězila a šel jsem se podívat na konzoli Borg v datacentru, které zmínili.
A samozřejmě jsem měl pod kontrolou úložiště BigTable. Cože? Podíval jsem se na jeho obsah a — no tedy! Bylo to z inkubátoru Codelab, kde jsem byl první týden po nástupu do Googlu v červnu 2005. Codelab vás donutil spustit Bigtable, abyste tam zapsali nějaké hodnoty, a já jsem evidentně úložiště po tom nezavřel. Stále fungovalo, i když uplynuly více než dva roky.
V této historii je několik pozoruhodných aspektů. Za prvé, provoz Bigtable byl v rámci Googlu tak nepodstatný, že si jej nikdo nevšiml, až po dvou letech, a to jen proto, že binární verze byla zastaralá. Pro srovnání, kdysi jsem zvažoval použití pro svou online hru. Tehdy tato služba stála přibližně 16 000 dolarů ročně za prázdné Bigtable na GCP. Neříkám, že vás klamou, ale podle mého osobního názoru, to jsou velké peníze za prázdnou zasranou databázi.
Další pozoruhodný aspekt je, že úložiště stále fungovalo po dvou letech.. Co to, proboha? Datacentra přicházejí a odcházejí; mají výpadky, probíhají plánované údržby, stále se mění. Hardware se aktualizuje, switche se přemisťují, vše se neustále zlepšuje. Jak, sakra, se jim podařilo udržet mou aplikaci spuštěnou dva roky navzdory všem těmto změnám? To se může zdát jako skromný výkon v roce 2020, ale v letech 2005-2007 to bylo skutečně působivé.
A nejúžasnější aspekt je, že cizí inženýrský tým v nějakém jiném státě se obrací na mě, majitele nějakého maličkého, téměř prázdného případu Bigtable, který má nulový provoz poslední dva roky — a nabízí pomoc, jak ho aktualizovat.
Poděkoval jsem jim, odstranil úložiště a život šel dál. Ale třináct let poté stále myslím na tento dopis. Protože občas dostávám podobné dopisy od Google Cloud. Vypadají takto:
Vážený uživateli Google Cloud,
Připomínáme, že od srpna 2020 přestáváme podporovat službu [důležitá služba, kterou používáte], po čemž nebudete moci aktualizovat své instance. Doporučujeme přejít na nejnovější verzi, která je v beta testování, nemá žádnou dokumentaci, žádnou migrační cestu a která byla předem zastaralá s naší laskavou pomocí.
Usilujeme o to, aby tato změna co nejméně ovlivnila všechny uživatele platformy Google Cloud.
Nejlepší přátelé navždy,
Obcloudová platforma Google
Ale téměř takové dopisy nečtu, protože ve skutečnosti obsahují následující:
Vážený příjemce,
Dej si pohov. Dej si, dej si, dej si. Odhoď všechno, co děláš, protože to není důležité. Co je důležité, je náš čas. Utrácíme čas a peníze na to, abychom udržovali náš bordel a už jsme z toho unavení, a proto ho nebudeme více udržovat. Takže odhoď své zatracené plány a začni se šťourat v naší hnusné dokumentaci, žádající o odpadky na fórech, a mimochodem, náš nový bordel je zcela odlišný od starého bordelu, protože jsme tento design dost pokazili, hehe, ale to je tvůj problém, ne náš.
Stále vyvíjíme úsilí, aby všechny tvé vývoje byly nekompatibilní během jednoho roku.
Prosím, jdi k čertu,
Obcloudová platforma Google
A jde o to, že takové dopisy dostávám zhruba jednou za měsíc. Děje se to tak často a tak pravidelně, že nevyhnutelně odradily mě od GCP do tábora odpůrců cloudu. Už se nechci spoléhat na jejich proprietární vývoj, protože vlastně je pro devops snazší udržovat systém s otevřeným zdrojovým kódem na holé virtuálce, než se pokoušet dohnat Google s její politikou uzavírání "zastaralých" produktů.
Předtím, než se vrátím k Google Cloud, protože já i zdaleka nenechal je kritizovat, podívejme se na práci společnosti v několika dalších oblastech. Inženýři Google se pyšní svou disciplínou při vývoji software, což ve skutečnosti vyvolává problémy. Pýcha je pastí pro neopatrné, přiměla mnoho zaměstnanců Google věřit, že jejich rozhodnutí jsou vždy správná a že správnost (podle nějaké neurčité definice) je důležitější než péče o zákazníky.
Uvedu několik libovolných příkladů z jiných velkých projektů mimo Google, ale doufám, že tento vzor uvidíte všude. Spočívá v následujícím: zpětná kompatibilita udržuje životaschopnost a aktuálnost systémů po desetiletí.
Zpětná kompatibilita je cílem návrhu všech úspěšných systémů určených pro otevřený použití, tedy realizovaných s otevřeným zdrojovým kódem a/nebo na otevřených standardech. Mám pocit, že říkám něco příliš zřejmého, co je ostatním dokonce nepříjemné, ale není. Je to politická otázka, proto jsou potřeba příklady.
První systém, který si vyberu, je ten nejstarší: GNU Emacs, jakýsi hybrid mezi Notepadem, OS jádrem a Mezinárodní vesmírnou stanicí. Je to trochu složité vysvětlit, ale ve zkratce Emacs je platforma vytvořená v roce 1976 (ano, před téměř půl stoletím) pro programování, aby zvýšila vaši produktivitu, ale maskuje se jako textový editor.
Používám Emacs každý den. Ano, také používám IntelliJ každý den, už se sám stal mocnou nástrojovou platformou. 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 ještě 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 ještě v roce 1995. A jsem si jistý, že někdo používá moduly napsané pro Emacs v polovině 80. let, pokud ne dříve. Občas mohou vyžadovat drobné úpravy, ale to je opravdu dost vzácné. Nevím o ničem, co jsem kdy pro Emacs napsal (a napsal jsem toho hodně), co by vyžadovalo přepracování architektury.
V Emacsu existuje funkce nazvaná make-obsolete pro zastaralé entity. Terminologie Emacsu pro základní počítačové koncepty (například co je „okno“) se často liší od průmyslových standardů, protože Emacs je uvedl do praxe již dávno. To je typické nebezpečí pro ty, kteří byli před svým časem: všechny vaše termíny jsou nesprávné. Ale v Emacsu skutečně existuje koncept zastarávání, který se v jejich žargonu nazývá obsolence.
Ale ve světě Emacsu se zdá, že existuje jiné pracovní definice. Jiná základní filozofie, pokud chcete.
Ve světě Emacsu (a v mnoha dalších oblastech, které prozkoumáme níže) status zastaralého API většinou znamená: „Tento přístup byste opravdu neměli používat, protože i když funguje, trpí různými nedostatky, které zde vyjmenujeme. Nakonec je to ale vaše volba.“
Ve světě Google status zastaralého produktu znamená: „Porušujeme naše závazky vůči vám.“ Opravdu to tak je. To v podstatě znamená, že vás donutí pravidelně vykonávat nějakou práci, možná značnou práci, jako trest za to, že jste uvěřili jejich : máme nejlepší software. Ten nejrychlejší! Děláte vše podle pokynů, spouštíte svou aplikaci nebo službu, a pak – bum, za rok nebo dva se to rozbije.
Je to jako prodat ojeté auto, které se určitě rozbije po 1500 km.
To jsou dvě zcela odlišná filozofická definice „zastarání“. Definice Google má příchuť . Nevím, zda to je ve skutečnosti plánované zastarávání ve stejném smyslu jako u Apple. Ale Google rozhodně plánuje rozbít vaše programy, a to nepřímo. Vím to, protože jsem tam pracoval jako softwarový inženýr více než 12 let. Mají vágní interní pokyny, do jaké míry se má dodržovat zpětná kompatibilita, ale nakonec záleží na každém jednotlivém týmu nebo službě. Neexistují žádná doporučení na úrovni společnosti nebo inženýrství, a nejodvážnější doporučení, pokud jde o cykly zastarávání, je „zkuste dát zákazníkům 6–12 měsíců na aktualizaci, než jim rozbijete celý systém“.
Problém je mnohem vážnější, než si myslí, a potrvá ještě dlouhé roky, protože péče o zákazníky není součástí jejich DNA. Více o tom níže.
V tuto chvíli se chystám učinit odvážné tvrzení, že Emacs je do značné míry a dokonce zvláště úspěšný, protože se velmi vážně věnují zpětné kompatibilitě. To je vlastně teze našeho článku. Úspěšné dlouhověké otevřené systémy vděčí za svůj úspěch mikros společenstvím, která se kolem nich po desetiletí sdružují rozšíření / pluginů. To je ekosystém. Již jsem hovořil o podstatě platforem a o tom, jak jsou důležité, a že Google nikdy ve své korporátní historii nepochopil, co obnáší vytvoření úspěšné otevřené platformy, kromě Androidu nebo Chromu.
O Androidu bych měl vlastně stručně zmínit, protože si určitě pomyslíte na něj.
Za prvé, Android není Google. Nemají spolu téměř nic společného. Android je firma, kterou Google koupil v červenci 2005, této firmě bylo dovoleno pracovat více či méně autonomně a ve skutečnosti zůstala v podstatě nedotčena po uplynulých letech. Android je notoricky známý technologický stack a stejně tak notoricky známá ostrá organizace. Jak řekl jeden Googler, "není možné jen tak vstoupit do Androidu".
V jednom z předchozích článků jsem už hovořil o tom, jak špatná byla některá z raných designových rozhodnutí Androidu. Sakra, když jsem psal ten článek, zabývali se nasazováním sr*ček zvaných "okamžité aplikace", které nyní (překvapení!) , a omlouvám se, pokud jste byli dost hloupí, abyste poslechli Google a přenesli svůj obsah do těchto okamžitých aplikací.
Ale existuje zde rozdíl, zásadní rozdíl, který spočívá v tom, že lidé z Androidu skutečně chápou, jak důležité jsou platformy, a usilovně se snaží udržet funkčnost starých aplikací Android. Ve skutečnosti jsou jejich snahy o zachování zpětné kompatibility tak extrémní, že jsem dokonce během svého krátkého pobytu v Androidím oddělení před několika lety zjistil, že se snažím přesvědčit je, aby se vzdali podpory některých z nejstarších zařízení a API (byl jsem v omylu, jako u mnoha dalších věcí minulosti a přítomnosti. Omlouvám se, lidi z Androidu! Teď, když jsem byl v Indonésii, chápu, proč je potřebujeme).
Lidé z Androidu podporují zpětnou kompatibilitu až do téměř nepředstavitelných extrémů, což vytváří obrovské množství zastaralých technických závazků v jejich systémech a nástrojích. Ó bože, viděli byste některé bláznivé věci, které musí dělat ve svém systému sestavení, a to vše ve jménu kompatibility.
Za to uděluji Androidu cennou cenu „Ty nejsi Google“. Opravdu nechtějí být Googlem, který neumí vyvíjet trvalé platformy, a to je Android, zná,, jak to dělat. A proto se Google chová velmi moudře v jednom ohledu: umožňuje lidem v Androidu dělat všechny věci po svém.
Nicméně okamžité aplikace pro Android byly docela hloupý nápad. A víte proč? Protože vyžadovaly přepracovat a přeprojektovat vaši aplikaci! Jako by lidé jen tak vzali a přepsali dva miliony aplikací. Předpokládám, že okamžité aplikace byly nápadem nějakého googlera.
Ale existuje zde rozdíl. Zpětná kompatibilita je spojena s velkými náklady. Android nese toto břemeno sám, zatímco Google trvá na tom, že toto břemeno musí nést vy, placený klient.
Můžete vidět oddanost Androidu zpětné kompatibilitě v jejích API. Když máte čtyři nebo pět různých subsystémů pro doslova to samé, to je jasný znak toho, že za tímto stojí oddanost zpětné kompatibilitě. Což v světě platforem je synonymem oddanosti vašim zákazníkům a vašemu trhu.
Hlavním problémem Googlu zde je jejich hrdost na své inženýrské normy. Nelíbí se jim, když existuje mnoho různých způsobů, jak dělat to samé, přičemž starší, méně žádoucí způsoby stojí vedle novějších, propracovanějších metod. To zvyšuje křivku učení pro nováčky v systému, zvyšuje zátěž podpory zastaralých API, zpomaluje rychlost nových funkcí a hlavní hřích – je to nevzhledné. Google je jako Lady Escott z „Alenky v říši divů“ Tima Burtona:
Lady Escott:
– Alenko, víš, čeho se bojím nejvíc?
– Pád aristokracie?
– Obávala jsem se, že budu mít 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 zjistíme, jak to funguje: samotná Java.
V Javě je spousta zastaralých API. Zastarání je velmi populární mezi programátory Javy, dokonce populárnější než v mnoha programovacích jazycích. V samotné Javě, hlavním jazyce a knihovnách, dochází neustále k zastarávání API.
Pokud vezmeme jen jeden z tisíců příkladů, se považuje za zastaralé. Zastaralo to od vydání Javy 1.2 v prosinci 1998. Už uběhlo 22 let, co to bylo považováno za zastaralé.
Ale můj skutečný kód v produkci stále zabíjí vlákna každý den. Je to dobré? Rozhodně! Mám na mysli, samozřejmě, kdybych přepsal kód dnes, realizoval bych to jinak. Ale kód mé hry, která za poslední dvě dekády udělala šťastnými stovky tisíc lidí, byl napsán s funkcí uzavření vláken, která visela příliš dlouho, a já nikdy jsem ho nemusel měnit. Znám svůj systém lépe než kdokoliv jiný, mám doslova 25letou zkušenost s ním v produkci a mohu s přesností říct: v mém případě je uzavření těchto konkrétních pracovních vláken naprosto bezpečné. Není třeba trávit čas a úsilí přepisováním tohoto kódu, a sláva Larrymu Ellisonovi (asi), že mě Oracle nenutil přepisovat ho.
Asi se Oracle také vyzná v platformách. Kdo ví.
Důkazy můžete najít ve všech klíčových Java API, které jsou protkány vlnami zastaralosti, podobně jako linie ledovce v kaňonu. V knihovně Java Swing můžete snadno najít pět nebo šest různých správců klávesového zaměření (KeyboardFocusManager). Opravdu je obtížné najít Java API, které není zastaralé. Ale stále fungují! Myslím si, že tým Java skutečně odstraní API pouze v případě, že rozhraní vyvolá akutní bezpečnostní problém.
Co se děje, pánové: my, softwaroví vývojáři, jsme všichni velmi zaneprázdnění 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. O, nevěříte mi? Chcete zmínit Swift? Říkáte, že všichni migrují na Swift a nikdo se ho nevzdává, že? Wow, jak málo toho víte. Firmy začínají počítat náklady na dvojité týmy mobilního vývoje (iOS a Android) – a začínají si uvědomovat, že tyto multiplatformní vývojové systémy s vtipnými názvy, jako je Flutter a React Native, skutečně fungují a pomáhají snížit velikost jejich mobilních týmů na polovinu, nebo naopak je učinit dvakrát produkčnějšími. O skutečné peníze jde. Ano, jsou zde kompromisy, ale na druhé straně de-e-én-ě.
Představme si hypoteticky, že Apple z hlouposti vzal příklad z Guida van Rossuma a prohlásil, že Swift 6.0 je zpětně nekompatibilní se Swift 5.0, podobně jako Python 3 není kompatibilní s Python 2.
Možná jsem tuto historii vyprávěl před deseti lety, ale před patnácti lety jsem byl na táboře O’Reilly’s Foo Camp s Guidem, seděl jsem ve stanu s Paulem Grahamem a spoustou velkých šéfů. Byli jsme uprostřed úmorného vedra a čekali, až Larry Page přiletí ve svém soukromém vrtulníku, zatímco Guido monotónně mumlal o 'Pythonu 3000', který nazval kvůli počtu let, které bude trvat, než se všichni migrují. Neustále jsme se ho ptali, proč narušuje kompatibilitu, a on odpovídal: "Unicode". A my se ptali, pokud budeme muset přepsat náš kód, jaké další výhody uvidíme? A on odpovídal: "Yoooooooooooooouuuuuuuniiiiiiicoooooooode".
Pokud nainstalujete Google Cloud Platform SDK ("gcloud"), obdržíte následující oznámení:
Vážený příjemce,
Rádi bychom vám připomněli, že podpora Pythonu 2 skončila, takže si to prosím uvědomte.
… a tak dále. Kruh života.
Ale problém je, že každý vývojář má na výběr. A pokud je budete nutit přepisovat kód dost často, mohou začít přemýšlet i o dalších možnostech. Nemají být vašimi rukojmími, i když byste si to přáli. Jsou vašimi hosty. Python je stále velmi populární programovací jazyk, ale sakra, Python 3(000) vytvořil ve svých komunitách a mezi uživateli takový chaos, že důsledky nedokážou vyřešit už patnáct let.
Kolik programů v Pythonu bylo přepsáno do Go (nebo Ruby, nebo nějaké jiné alternativy) kvůli této nekompatibilitě? Kolik nového softwaru bylo napsáno na něčem jiném než na Pythonu, ačkoli to bylo možné napsat v Pythonu, kdyby Guido nezničil celou vesnici? Těžko říct, ale Python očividně trpěl. Je to obrovský chaos a všichni jsou v nevýhodě.
Tak si představme, že Apple se nechá inspirovat Guidem a poruší zpětnou kompatibilitu. Jak si myslíte, že to dopadne? No, možná 80-90 % vývojářů přepíše svůj software, pokud to bude možné. Jinými slovy, 10-20 % uživatelské základny automaticky přejde k nějakému konkurenčnímu jazyku, jako například Flutter.
Uděláte to několikrát a ztratíte polovinu své uživatelské základny. Stejně jako ve sportu, i ve světě programování je aktuální forma důležitá. všechno. Kdokoliv, kdo ztratí polovinu uživatelů za pět let, bude považován za Velkého Velkého Neúspěšného. Musíte být v trendu ve světě platforem. Ale právě tady vás nakonec zruinují odmítnutí starých verzí. Protože pokaždé, když se zbavíte části vývojářů, (a) je navždy ztratíte, protože jsou naštvaní na vás za porušení smlouvy, a (b) předáte je svým konkurentům.
Ironií osudu jsem také pomohl Googlu stát se takovou primadonou, která ignoruje zpětnou kompatibilitu, když jsem vytvořil Grok, systém analýzy a porozumění zdrojovému kódu, který usnadňuje automatizaci a vybavování nástroji na základě samotného kódu - připomíná to IDE, ale zde cloudová služba uchovává materializované pohledy všech miliard řádků zdrojového kódu Googlu ve velké datové infrastruktuře.
Grok poskytl Googlerům silný základ pro automatizované refaktoringy napříč celou kódovou základnou (doslova celým Googlem). Systém vypočítává nejen vaše vzestupné závislosti (na nichž závisíte), ale také sestupné (které na vás závisí), takže při změně API víte, koho rozbíjíte! Tímto způsobem, když provedete změny, můžete zkontrolovat, že každý uživatel vašeho API se aktualizoval na novou verzi, a ve skutečnosti často s pomocí nástroje Rosie, který napsali, můžete tento proces plně automatizovat.
To umožňuje kódové základně Google být prakticky nadpřirozeně „čisté“ interně, protože mají tyto robotizované služebníky, kteří pobíhají po domě a automaticky vše uklízejí, pokud přejmenovali SomeDespicablyLongFunctionName na SomeDespicablyLongMethodName, protože někdo se rozhodl, že je to ošklivý vnuk, a je třeba ho uspat.
A, upřímně, to docela dobře funguje pro Google... interně. Mám na mysli, ano, Go komunita v Googlu si opravdu dobrosrdečně dělá legraci z komunity Java v Googlu kvůli jejich zvyku na nekonečné refaktoringy. Pokud něco restartujete Nkrát, znamená to, že jste to nejen zkazili N-1krát, ale po nějaké době je zcela zřejmé, že jste to pravděpodobně zkazili i při N-té pokusu. Ale většinou zůstávají nad tímto shonem a udržují kód „čistý“.
Problémy začínají, když se snaží uplatnit takový přístup na své cloudové klienty a uživatele jiných API.
Trochu jsem vás seznámil s Emacsem, Androidem a Javou; pojďme se podívat na poslední úspěšnou dlouhověkou platformu: samotný Web. Dokážete si představit, kolik iterací prošel HTTP od roku 1995, kdy jsme používali blikající tagy a ikony „Ve vývoji“ na webových stránkách.
Ale stále to funguje! A ty stránky stále fungují! Ano, kluci, prohlížeče jsou světoví šampioni zpětné kompatibility. Chrome je dalším příkladem vzácné platformy Google, která má hlavy přišroubované správně, a, jak už jste asi uhodli, Chrome efektivně funguje jako izolovaná společnost odděleně od zbytku Google.
Chtěl bych také poděkovat našim přátelům mezi vývojáři operačních systémů: Windows, Linux, NE APPLE, FreeBSD a tak dále, za to, že odvedli skvělou práci na zpětné kompatibilitě svých úspěšných platforem (Apple dostává z mého pohledu maximálně trojku s mínusem, protože neustále něco rozbíjejí bez rozumného důvodu, ale nějakým způsobem se komunitě pokaždé podaří se s tím vypořádat, a kontejnery s OS X zatím ještě zcela nevyšly z módy… prozatím).
Ale počkejte, řeknete. Nehledáme snad jablka a pomeranče – samostatné software systémy na jednom stroji, jako jsou Emacs/JDK/Android/Chrome, ve srovnání s multi-serverovými systémy a API, jako v cloudových službách?
No, včera jsem o tom psal na Twitteru, ale ve stylu Larryho Walla (tvůrce programovacího jazyka Perl – pozn. překl.), přímo principem "fajn/hloupost" jsem hledal slovo deprecated na stránkách pro vývojáře Google a Amazon. Ačkoliv AWS má stokrát více nabídek služeb než GCP, dokumentace pro vývojáře Google zmiňuje zastaralost přibližně sedmkrát častěji.
Pokud to někdo z Google čte, určitě jsou připraveni vytáhnout diagramy v stylu Donalda Trumpa, aby ukázali, co dělají vše správně, a že bych neměl dělat neférové srovnání, jako je "počet zmínek o slově deprecated v závislosti na počtu služeb."
Ale po tolika letech Google Cloud stále zůstává službou č. 3 (ještě jsem nenapsal článek o neúspěšném pokusu dostat se na č. 2), ale pokud věřit insiderům, existují určité obavy, že by brzy mohli klesnout na č. 4.
Nemám silné argumenty, abych "dokázal" svůj názor. Všechno, co mám, jsou barevné příklady, které jsem nasbíral za 30 let práce jako vývojář. Už jsem zmiňoval hluboce filozofickou povahu tohoto problému; do určité míry je to zpolitizováno v komunitě vývojářů. Někteří věří, že tvůrci platforem by se měli starat o kompatibilitu, a jiní si myslí, že to je starost uživatelů (samotných vývojářů). Jedno z obou. A opravdu to není politická otázka, když se rozhodujeme, kdo by měl nést náklady za společné problémy?
Takže je to politika. A určitě budou rozhořčené reakce na moje vyjádření.
Jak uživateli jako uživatel cloudové platformy Google a také AWS po dobu dvou let (pracující ve společnosti Grab) mohu říci, že mezi filozofiemi Amazonu a Googlem existuje obrovský rozdíl, pokud jde o priority. Aktivně nevyvíjím na AWS, takže si nejsem úplně jistý, jak často odstraňují staré API. Mám však podezření, že se to děje daleko méně často než u Google. A upřímně věřím, že tento zdroj neustálých sporů a zklamání v GCP je jedním z největších faktorů, které brání rozvoji platformy.
Vím, že jsem nenazval konkrétní příklady systémů GCP, jejichž podpora byla ukončena. Mohu říci, že prakticky vše, co jsem použil, od sítí (od nejstarších po VPC) až po úložiště (Cloud SQL v1-v2), Firebase (nyní Firestore s úplně jiným API), App Engine (ani nezačínejme), cloudové koncové body Cloud Endpoint a až… nevím – absolutně všechno tohle nutilo přepisovat kód maximálně každé 2-3 roky a nikdy pro vás automatizovali migraci, často . Jako by to tak mělo být.
A pokaždé, když se dívám na AWS, ptám se sám sebe, proč jsem pořád na GCP. Zjevně nepotřebují zákazníky. Potřebují odběratele. Rozumíte rozdílu? Dovolte, abych to vysvětlil.
Google Cloud má , na kterém lidé nabízejí svá softwarová řešení, a aby se zabránilo efektu prázdné restaurace, muselo být vyplněno některými nabídkami, a proto uzavřeli smlouvu se společností Bitnami, aby vytvořili spoustu řešení, která se nasazují „jedním kliknutím myši“, nebo si sám musím napsat „řešení“, protože tyto nic neřeší. Jen existují jako zaškrtávací políčka, jako marketingový doplněk, a Google se nikdy nezajímal o to, zda nějaký z těchto nástrojů skutečně funguje. Známe produktové manažery, kteří byli u řízení, a mohu vás ujistit, že těmto lidem je to jedno.
Vezměme si například řešení s nasazením údajně „jedním kliknutím myši“ . Jsem už smrtelně unavený skopičinami Google Cloud SQL, takže jsem začal zvažovat jako alternativu vytvoření vlastního clusteru Percona. A tentokrát to Google vypadá, že to udělali dobře, chtěli mi ušetřit trochu času a úsilí jedním stisknutím tlačítka!
No dobrá, jdeme na to. Přejdeme na odkaz a klikneme na toto tlačítko. Vyberte „Ano“, abyste souhlasili se všemi výchozími parametry a rozbalili cluster ve svém cloudovém projektu Google. Haha, nefunguje to. Nic z této špatnosti nefunguje. Nástroj nebyl nikdy testován a začal se rozpadat od první minuty, a nebude mě překvapovat, pokud více než polovina „řešení“ pro nasazení jedním kliknutím myši (nyní chápeme, proč jsou v uvozovkách) vůbec nefungují. Je to absolutně beznadějná tma, do které je lepší nevstupovat.
Ale Google přímo vyzývá vás, abyste je používali. Chtějí, abyste je koupili. Pro ně je to transakce. Nechtějí nic udržovat. Není to součástí DNA Googlu. Ano, inženýři si pomáhají, o čemž svědčí můj příběh s Bigtable. Ale v produktech a službách pro běžné lidi byli vždy bezohlední v , která nesplňuje ziskovost, i když má miliony uživatelů.
A to představuje skutečný problém pro GCP, protože tato DNA stojí za všemi cloudovými nabídkami. Nesnaží se nic udržovat; je dobře známo, že odmítají hostit (jako spravovanou službu) jakýkoli software třetích stran dokud, než to AWS udělá a vybuduje kolem toho úspěšný byznys, a až když klienti doslova budou vyžadovat totéž. Nicméně je třeba vynaložit určité úsilí, aby Google něco udržoval.
Tato absence kultury podpory, v kombinaci s principem „pojďme to rozbít, abychom to učinili hezčí“, odrazuje vývojáře.
A to není moc dobře, pokud chcete vybudovat dlouhodobou platformu.
Google, probuď se, sakra. Je rok 2020. Pořád prohráváš. Je čas se důkladně podívat do zrcadla a odpovědět si, zda opravdu chceš zůstat v cloudovém byznysu.
Pokud chceš zůstat, tak přestaň všechno rozbíjet. Chlapi, vy jste přece bohatí. My, vývojáři, ne. Takže, když přijde na to, kdo ponese břemeno kompatibility, musíte to vzít na sebe. Ne my.
Protože je zde ještě alespoň tři opravdu dobré cloudy. Zajímají lidi.
A teď jdu dál opravovat všechny své rozbité systémy. Ach.
Do příště!
P. S. Aktualizace po přečtení některých diskuzí k tomuto článku (diskuze jsou mimochodem skvělé). Podpora Firebase nebyla ukončena a nemám žádné informace o plánech, které by to měnily. Nicméně mají nepříjemnou chybu streamování, která způsobuje, že Java klient zůstává viset na App Engine. Jeden z jejich inženýrů mi pomohl vyřešit tento problém, když jsem pracoval v Googlu, ale nikdy skutečně neopravili chybu, takže mám nouzové řešení, musím každý den restartovat aplikaci GAE. Tak je to už čtyři roky! Teď mají Firestore. Bude třeba hodně práce na migraci, protože to je zcela jiný systém a chyba Firebase nikdy nebude opravena. Jaký závěr z toho vyplývá? Můžete získat pomoc, pokud pracujete ve firmě. Asi jsem jediný, kdo používá Firebase na GAE, protože zápisuji méně než 100 klíčů v nativní aplikaci na 100 % a ta přestává fungovat každé dva dny kvůli známé chybě. Co k tomu říct, kromě použijte to na vlastní riziko. Přecházím na Redis.
Také jsem slyšel, jak někteří zkušenější uživatelé AWS říkali, že AWS obvykle nikdy neukončuje podporu žádných služeb, a SimpleDB je skvělým příkladem. Moje domněnky, že v AWS není taková nemoc s ukončováním podpory, jako u Googlu, se zdají být oprávněné.
Kromě toho jsem si všiml, že před 20 dny tým Google App Engine rozbil hosting kritické knihovny Go tím, že uzavřel aplikaci GAE od jednoho z hlavních vývojářů Go. Opravdu, to je hloupé.
Nakonec jsem slyšel, že Googlisté už tuto otázku diskutují a obecně se mnou souhlasí (mám vás rád, kluci!). Ale zdá se, že považují problém za neřešitelný, protože v kultuře Googlu nikdy nebyla správná struktura motivace. Myslím, že by stálo za to vyhradit si malou chvíli na diskusi o naprosto úžasných zkušenostech s inženýry AWS, když jsem pracoval ve firmě Grab. Doufám, že v budoucnu!
A ano, v roce 2005 měli skutečně různé druhy žraločího masa na obrovském švédském stole v budově 43, a nejvíce mi chutnalo maso žraloků s gilotinovou hlavou. Avšak v roce 2006 Larry a Sergey odstranili všechny nezdravé občerstvení. Takže během příběhu s Bigtable v roce 2007 už skutečně žádné žraloky nebyly a já jsem vás podvodně oklamal.
Když jsem se na cloudový Bigtable díval před čtyřmi lety (plus mínus), cena byla právě taková. Zdá se, že se nyní mírně snížila, ale stále je to hrozně moc za prázdné úložiště dat, zejména s ohledem na to, že můj první příběh ukazuje, jak nepodstatná je prázdná velká tabulka v jejich měřítku.
Omlouvám se, že jsem urazil komunitu Apple a že jsem neřekl nic dobrého o Microsoftu atd. Všichni máte pravdu, velmi si vážím všech diskusí, které tento článek vyvolal! Ale někdy je potřeba trochu rozbouřit vody, abychom začali diskusi, rozumíte?
Děkuji za přečtení.
Aktualizace 2, 19.08.2020. Stripe !
Aktualizace 3, 31.08.2020. Skontaktoval se se mnou inženýr Google z Cloud Marketplace, který se ukázal být mým starým přítelem. Chtěl zjistit, proč C2D nefunguje, a nakonec jsme zjistili: problém je v tom, že jsem si vytvořil svou síť před několika lety, a C2D nefunguje v zastaralých sítích kvůli chybějícímu parametru podsítě v jejich šablonách. Myslím, že potenciální uživatelé GCP by se měli ujistit, že mají dostatek znalých inženýrů v Googlu...
Zdroj: habr.com
