Preklet Google, nisem hotel več pisati bloga. Toliko dela imam. Pisanje bloga zahteva čas, energijo in ustvarjalnost, ki bi jih lahko dobro uporabil: moje knjige, , moja igra in tako naprej. Ampak dovolj si me razjezil, da moram to napisati.
Torej zaključimo s tem.
Naj začnem s kratko, a poučno zgodbo, ko sem začel delati pri Googlu. Vem, da zadnje čase govorim veliko slabega o Googlu, vendar me moti, ko moje podjetje redno sprejema nesposobne poslovne odločitve. Hkrati pa ji moramo dati priznanje: Googlova notranja infrastruktura je res izjemna, lahko rečemo, da danes ni nič boljše. Ustanovitelji Googla so bili veliko boljši inženirji, kot bom kdajkoli jaz, in ta zgodba to dejstvo samo potrjuje.
Najprej malo ozadja: Google ima tehnologijo za shranjevanje podatkov, imenovano . To je bil izjemen tehnični dosežek, ena prvih (če ne prva) »neskončno razširljiva« shramba ključ-vrednost (K/V): v bistvu začetek NoSQL. Te dni se Bigtable še vedno dobro znajde v precej natrpanem skladiščnem prostoru K/V, a takrat (2005) je bilo neverjetno kul.
Ena smešna stvar pri Bigtable je ta, da so imeli objekte notranje nadzorne ravnine (kot del izvedbe), imenovane tablični strežniki, z velikimi indeksi, in na neki točki so postali ozko grlo pri skaliranju sistema. Inženirji Bigtable so se spraševali, kako implementirati razširljivost, in nenadoma so ugotovili, da lahko tablične strežnike nadomestijo z drugimi shrambami Bigtable. Bigtable je torej del implementacije Bigtable. Ti skladiščni prostori so tam na vseh ravneh.
Druga zanimiva podrobnost je, da je Bigtable za nekaj časa postal priljubljen in vseprisoten v Googlu, pri čemer je imela vsaka ekipa svoje skladišče. Tako je Larry Page na enem izmed petkovih srečanj mimogrede vprašal: »Zakaj imamo več kot eno Bigtable? Zakaj ne samo enega?" Teoretično bi moral en prostor za shranjevanje zadostovati za vse Googlove potrebe po prostoru za shranjevanje. Seveda se nikoli niso odločili samo za enega zaradi praktičnih razvojnih razlogov (kot so posledice morebitnega neuspeha), vendar je bila teorija zanimiva. Eno skladišče za celotno vesolje (Mimogrede, ali kdo ve, ali je Amazon to naredil s svojim Sableom?)
Kakorkoli, tukaj je moja zgodba.
Takrat sem nekaj več kot dve leti delal pri Googlu in nekega dne sem od inženirske ekipe Bigtable prejel e-poštno sporočilo, ki je bilo nekako takole:
Dragi Steve,
Pozdrav iz ekipe Bigtable. Obveščamo vas, da v [ime podatkovnega centra] uporabljate zelo, zelo staro binarno datoteko Bigtable. Ta različica ni več podprta in želimo vam pomagati nadgraditi na najnovejšo različico.
Sporočite mi, če lahko načrtujete nekaj časa za skupno delo pri tej težavi.
Vse najboljše,
Ekipa Bigtable
Na Googlu dobiš veliko pošte, zato sem na prvi pogled prebral nekaj takega:
Spoštovani prejemnik,
Pozdrav od neke ekipe. Želimo sporočiti ta bla bla bla bla bla. Bla bla bla bla bla bla in bla bla bla takoj.
Prosimo, sporočite nam, če lahko namenite nekaj svojega dragocenega časa za bla bla bla.
Vse najboljše,
Nekakšen ukaz
Skoraj bi ga takoj izbrisal, a na robu zavesti sem začutil boleč, zoprn občutek, da ne čisto izgleda kot uradno pismo očitno, da se je prejemnik zmotil, ker nisem uporabil Bigtable.
Ampak bilo je čudno.
Preostanek dneva sem izmenično premišljeval o službi in o tem, kakšno meso morskega psa poskusiti v mikrokuhinji, od katere so bili vsaj trije dovolj blizu, da sem jih s sedeža zadel z dobro namerjenim metom piškota, a misel na pisanje me nikoli ni pustila z vedno večjim občutkom blage tesnobe.
Jasno so povedali moje ime. E-poštno sporočilo je bilo poslano na moj e-poštni naslov, ne na nekoga drugega, in ni cc: ali bcc:. Ton je zelo oseben in jasen. Mogoče je to kakšna napaka?
Končno me je premagala radovednost in sem šel pogledat konzolo Borg v podatkovni center, ki so ga omenili.
In seveda sem imel v upravljanju shrambo BigTable. Oprosti, kaj? Pogledal sem njegovo vsebino in vau! Bilo je iz inkubatorja Codelab, v katerem sem sedel v prvem tednu pri Googlu junija 2005. Codelab vas je prisilil, da zaženete Bigtable, da bi tja zapisali nekaj vrednosti, in očitno po tem nikoli nisem zaprl shrambe. Še vedno je deloval, čeprav sta minili že več kot dve leti.
V tej zgodbi je več omembe vrednih vidikov. Prvič, delo Bigtable je bilo v Googlovem merilu tako nepomembno, da je šele dve leti kasneje kdo opazil dodaten prostor za shranjevanje, in to samo zato, ker je bila različica binarne datoteke zastarela. Za primerjavo, enkrat sem razmišljal o uporabi za mojo spletno igro. Takrat je ta storitev stala približno 16 USD na leto. prazno Bigtable na GCP. Ne rečem, da te goljufajo, ampak po mojem osebnem mnenju je to veliko denarja za prazno bazo podatkov.
Drug omembe vreden vidik je shranjevanje po dveh letih še dela. WTF? Podatkovni centri prihajajo in gredo; doživljajo izpade, izvajajo redno vzdrževanje in se ves čas spreminjajo. Strojna oprema je posodobljena, stikala so zamenjana, vse se nenehno izboljšuje. Kako za vraga jim je z vsemi temi spremembami uspelo ohraniti moj program v teku dve leti? To se morda zdi skromen dosežek v letu 2020, v letih 2005–2007 pa je bil precej impresiven.
In najbolj čudovit vidik je, da se name obrne zunanja inženirska ekipa v neki drugi državi, lastnik nekega majhnega, skoraj praznega primerka Bigtable, ki ima nič prometa v zadnjih dveh letih – in ponujajo pomoč pri posodobitvi.
Zahvalil sem se jim, izbrisal shrambo in življenje je potekalo kot običajno. Toda trinajst let pozneje še vedno razmišljam o tem pismu. Ker včasih prejmem podobna e-poštna sporočila od Google Cloud. Izgledajo takole:
Spoštovani uporabnik storitve Google Cloud,
Naj vas spomnimo, da bomo od avgusta 2020 ukinili storitev [osnovna storitev, ki jo uporabljate], nato pa ne boste mogli nadgraditi svojih primerkov. Priporočamo nadgradnjo na najnovejšo različico, ki je v beta testiranju, nima dokumentacije, nima poti za selitev in je z našo prijazno pomočjo že prej zastarela.
Zavezani smo k temu, da ta sprememba čim manj vpliva na vse uporabnike platforme Google Cloud.
Najboljša prijatelja za vedno,
Google Cloud Platform
Toda takšnih pisem skoraj nikoli ne berem, ker pravzaprav pravijo:
Spoštovani prejemnik,
Pojdi k vragu. Jebi se, jebi se, jebi se. Opusti vse, kar počneš, ker ni pomembno. Pomemben je naš čas. Zapravljamo čas in denar z vzdrževanjem našega sranja in smo se ga naveličali, zato ga ne bomo več podpirali. Torej opusti svoje preklete načrte in začni brskati po naši usrani dokumentaciji, prosjačiti za zapiske na forumih in mimogrede, naše novo sranje je popolnoma drugačno od starega sranja, ker smo ta dizajn precej zajebali, heh, ampak to je tvoj problem, ne naš.
Še naprej si prizadevamo zagotoviti, da vsi vaši razvojni dogodki postanejo neuporabni v enem letu.
Odjebi prosim
Google Cloud Platform
In dejstvo je, da takšna pisma dobim približno enkrat na mesec. To se dogaja tako pogosto in tako nenehno, da neizogibno odrinil jaz iz GCP v tabor proti oblakom. Ne strinjam se več s tem, da bi bil odvisen od njihovega lastniškega razvoja, ker je devopsom dejansko lažje vzdrževati odprtokodni sistem na golem virtualnem stroju, kot pa poskušati slediti Googlu z njegovo politiko zapiranja »zastarelih« izdelkov.
Preden se vrnem v Google Cloud, ker sem niti blizu da jih ne kritiziramo, poglejmo uspešnost podjetja na nekaterih drugih področjih. Googlovi inženirji so ponosni na svojo disciplino programskega inženiringa in to je tisto, kar dejansko povzroča težave. Ponos je past za neprevidne in mnoge Googlove zaposlene je napeljal k misli, da so njihove odločitve vedno pravilne in da je imeti prav (po neki nejasni mehki definiciji) pomembnejše od skrbi za stranke.
Navedel bom nekaj naključnih primerov iz drugih velikih projektov zunaj Googla, vendar upam, da boste ta vzorec videli povsod. To je naslednje: združljivost za nazaj ohranja sisteme žive in posodobljene desetletja.
Povratna združljivost je cilj načrtovanja vseh uspešnih sistemov, namenjenih odprto uporabo, to je implementirano z odprtokodno kodo in/ali odprtimi standardi. Zdi se mi, kot da govorim nekaj preveč očitnega, da je vsem celo neprijetno, ampak ne. To je politično vprašanje, zato so potrebni primeri.
Prvi sistem, ki ga bom izbral, je najstarejši: GNU Emacs, ki je nekakšen hibrid med Windows Beležnico, jedrom OS in Mednarodno vesoljsko postajo. Malo težko je razložiti, toda na kratko, Emacs je platforma, ustvarjena leta 1976 (da, pred skoraj pol stoletja) za programiranje, ki vas naredi bolj produktivno, vendar pod masko urejevalnika besedil.
Emacs uporabljam vsak dan. Da, tudi IntelliJ uporabljam vsak dan, sam po sebi je zrasel v zmogljivo orodno platformo. Toda pisanje razširitev za IntelliJ je veliko bolj ambiciozna in zapletena naloga kot pisanje razširitev za Emacs. In kar je še pomembneje, ohranjeno je vse, kar je napisano za Emacs za vedno.
Še vedno uporabljam programsko opremo, ki sem jo leta 1995 napisal za Emacs. In prepričan sem, da nekdo uporablja module, napisane za Emacs sredi 80-ih, če ne prej. Občasno jih bo morda treba malo prilagoditi, vendar je to res zelo redko. Ne poznam ničesar, kar sem kdaj napisal za Emacs (in napisal sem veliko), kar bi zahtevalo prenovo arhitekture.
Emacs ima funkcijo, imenovano make-obsolete za zastarele entitete. Emacsova terminologija za temeljne računalniške koncepte (kot na primer, kaj je "okno") se pogosto razlikuje od industrijskih konvencij, ker jih je Emacs uvedel že zdavnaj. To je tipična nevarnost za tiste, ki so pred svojim časom: vsi vaši izrazi so napačni. Toda Emacs ima koncept opustitve, ki se v njihovem žargonu imenuje zastarelost.
Toda zdi se, da v svetu Emacsa obstaja drugačna delovna definicija. Drugačna temeljna filozofija, če hočete.
V svetu Emacsa (in na mnogih drugih področjih, ki jih bomo obravnavali spodaj) status zastarelega API-ja v bistvu pomeni: "Resnično ne bi smeli uporabljati tega pristopa, ker čeprav deluje, ima različne pomanjkljivosti, ki jih bomo seznam tukaj. Toda na koncu dneva je to vaša izbira."
V Googlovem svetu biti zastarel pomeni: "Kršimo našo zavezo do vas." To je resnica. To je tisto, kar v bistvu pomeni. To pomeni, da vas bodo prisilili redno opravite nekaj dela, morda veliko dela, kot kazen, ker verjamete vanje : Imamo najboljšo programsko opremo. Najhitrejši! Narediš vse po navodilih, zaženeš svojo aplikacijo ali storitev, potem pa bam, po letu ali dveh se pokvari.
Kot bi prodajal rabljen avto, ki se bo po 1500 km zagotovo pokvaril.
To sta dve popolnoma različni filozofski definiciji "zastarelosti". Googlova definicija vonja . tega ne verjamem v resnici načrtovano zastaranje v enakem smislu kot Apple. Toda Google zagotovo namerava zlomiti vaše programe, in sicer na zaokrožen način. To vem, ker sem tam delal kot programski inženir več kot 12 let. Imajo nejasne notranje smernice o tem, koliko združljivosti za nazaj je treba upoštevati, vendar je na koncu odvisno od vsake posamezne ekipe ali storitve. Ni priporočil na ravni podjetja ali inženiringa in najdrznejše priporočilo v smislu ciklov zastarelosti je "poskusite dati strankam 6-12 mesecev za nadgradnjo, preden zlomite njihov celoten sistem."
Težava je veliko večja, kot si mislijo, in bo vztrajala še leta, ker skrb za stranke ni v njihovem DNK. Več o tem spodaj.
Na tej točki bom podal drzno izjavo, da je Emacs uspešen v veliki meri in celo v bistvu ker tako resno jemljejo združljivost za nazaj. Pravzaprav je to teza našega članka. Uspešni, dolgoživi odprti sistemi dolgujejo svoj uspeh mikroskupnostim, ki že desetletja živijo okoli njih razširitve/vtičniki. To je ekosistem. Govoril sem že o naravi platform in o tem, kako pomembne so, in o tem, kako Google v svoji celotni zgodovini podjetja nikoli ni razumel, kaj je potrebno za ustvarjanje uspešne odprte platforme zunaj Androida ali Chroma.
Pravzaprav bi moral na kratko omeniti Android, ker verjetno razmišljate o njem.
Prvič, Android ni Google. Med seboj nimata skoraj nič skupnega. Android je podjetje, ki ga je julija 2005 kupil Google, podjetju je bilo dovoljeno delovati bolj ali manj avtonomno in je v vmesnih letih dejansko ostalo večinoma nedotaknjeno. Android je razvpit tehnološki sklad in prav tako razvpita bodičasta organizacija. Kot je rekel en zaposlen v Googlu: "Ne morete se kar prijaviti v Android."
V prejšnjem članku sem razpravljal o tem, kako slabe so bile nekatere zgodnje oblikovalske odločitve Androida. Hudiča, ko sem napisal ta članek, so uvajali sranje, imenovano "instant aplikacije", ki so zdaj (presenečenje!) , in sočustvujem, če ste bili tako neumni, da ste poslušali Google in svojo vsebino premaknili v te takojšnje aplikacije.
Toda tukaj je razlika, pomembna razlika, ki je, da ljudje z Androidom resnično razumejo, kako pomembne so platforme, in se trudijo po svojih najboljših močeh ohranjati delovanje starih aplikacij za Android. Pravzaprav so njihova prizadevanja za ohranitev združljivosti za nazaj tako izjemna, da sem se celo jaz med svojim kratkim delom v oddelku Android pred nekaj leti zalotil, da sem jih poskušal prepričati, naj opustijo podporo za nekatere najstarejše naprave in API-je (motil sem se , tako kot v mnogih drugih stvareh v preteklosti in sedanjosti. Oprostite, fantje Android! Zdaj, ko sem bil v Indoneziji, razumem, zakaj jih potrebujemo).
Ljudje, ki se ukvarjajo z Androidom, potisnejo združljivost nazaj do skoraj nepredstavljivih skrajnosti, s čimer si v svojih sistemih in verigah orodij nakopljejo ogromne količine starega tehničnega dolga. O moj bog, morali bi videti nekaj norih stvari, ki jih morajo narediti v svojem sistemu gradnje, vse v imenu združljivosti.
Za to podeljujem Androidu željno nagrado "Ti nisi Google". Res nočejo postati Google, ki ne zna ustvarjati vzdržljivih platform, ampak Android ve, kako narediti. In tako je Google zelo pameten v enem pogledu: ljudem dovoli, da v sistemu Android počnejo stvari po svoje.
Vendar so bile takojšnje aplikacije za Android precej neumna ideja. In veste zakaj? Ker so zahtevali prepišite in preoblikujte svojo aplikacijo! Kot da bi ljudje preprosto prepisali dva milijona vlog. Predvidevam, da so bile Instant Apps ideja nekoga Googlovega.
Vendar je razlika. Povratna združljivost ima visoke stroške. Android sam nosi breme teh stroškov, Google pa vztraja, da breme nosi vi, plačljiva stranka.
Androidovo zavezanost združljivosti za nazaj lahko vidite v njegovih API-jih. Če imate štiri ali pet različnih podsistemov, ki delajo dobesedno isto stvar, je to zanesljiv znak, da je v jedru zavezanost združljivosti za nazaj. Kar je v svetu platform sinonim za predanost vašim strankam in vašemu trgu.
Googlov glavni problem je njihov ponos na svojo inženirsko higieno. Ni jim všeč, ko obstaja veliko različnih načinov za isto stvar, pri čemer stari, manj zaželeni načini stojijo poleg novih, bolj domiselnih načinov. Poveča krivuljo učenja za tiste, ki so novi v sistemu, poveča breme vzdrževanja podedovanih API-jev, upočasni hitrost novih funkcij in kardinalni greh je, da ni lepo. Google – kot Lady Ascot iz Alice v čudežni deželi Tima Burtona:
Lady Ascot:
- Alice, veš česa se najbolj bojim?
- Zaton aristokracije?
- Bal sem se, da bom grdi vnuki.
Da bi razumeli kompromis med lepim in praktičnim, si oglejmo tretjo uspešno platformo (za Emacsom in Androidom) in poglejmo, kako deluje: samo Javo.
Java ima veliko zastarelih API-jev. Opustitev je zelo priljubljena med programerji Java, celo bolj priljubljena kot v večini programskih jezikov. Java sama, jedrni jezik in knjižnice nenehno opuščajo API-je.
Če vzamem samo enega od tisočih primerov, velja za zastarelo. Od izdaje Jave 1.2 decembra 1998 je bil zastarel. Minilo je 22 let, odkar je bilo to opuščeno.
Toda moja dejanska koda v proizvodnji še vedno ubija niti vsak dan. Se ti res zdi to dobro? Vsekakor! Mislim, seveda, če bi danes prepisal kodo, bi jo implementiral drugače. Toda koda za mojo igro, ki je v zadnjih dveh desetletjih osrečila na stotine tisoč ljudi, je napisana s funkcijo zapiranja niti, ki predolgo visijo, in jaz nikoli ga ni bilo treba spremeniti. Svoj sistem poznam bolje kot kdorkoli drug, imam dobesedno 25 let izkušenj dela z njim v proizvodnji in z gotovostjo lahko rečem: v mojem primeru je zapiranje teh specifičnih delovnih niti popolnoma neškodljiv. Ni vredno časa in truda, da bi ponovno napisali to kodo, in hvala Larryju Ellisonu (verjetno), da me Oracle ni prisilil, da je ponovno napišem.
Oracle verjetno razume tudi platforme. Kdo ve.
Dokaze je mogoče najti v vseh osnovnih API-jih Java, ki so prepredeni z valovi zastarelosti, kot so črte ledenika v kanjonu. V knjižnici Java Swing lahko preprosto najdete pet ali šest različnih upraviteljev navigacije s tipkovnico (KeyboardFocusManager). Pravzaprav je težko najti Java API, ki ni zastarel. Ampak še vedno delujejo! Mislim, da bo skupina Java zares odstranila API le, če vmesnik predstavlja očitno varnostno težavo.
Ljudje, razvijalci programske opreme smo vsi zelo zaposleni in na vsakem področju programske opreme se soočamo s konkurenčnimi alternativami. Programerji v jeziku X kadar koli razmišljajo o jeziku Y kot možni zamenjavi. Oh, mi ne verjameš? Ali ga želite imenovati Swift? Na primer, vsi migrirajo na Swift in nihče ga ne opusti, kajne? Joj, kako malo veš. Podjetja preštevajo stroške dvojnih mobilnih razvojnih skupin (iOS in Android) – in začenjajo se zavedati, da ti razvojni sistemi za več platform s smešnimi imeni, kot sta Flutter in React Native, dejansko delujejo in jih je mogoče uporabiti za zmanjšanje velikosti njihovih mobilne ekipe dvakrat ali, nasprotno, dvakrat bolj produktivne. V igri je pravi denar. Da, so kompromisi, a po drugi strani denar.
Hipotetično predpostavimo, da se je Apple nespametno zgledoval po Guidu van Rossumu in izjavil, da je Swift 6.0 za nazaj nezdružljiv s Swift 5.0, podobno kot je Python 3 nezdružljiv s Python 2.
Verjetno sem to zgodbo povedal pred približno desetimi leti, pred približno petnajstimi leti pa sem šel v O'Reillyjev Foo Camp z Guidom, sedel v šotoru s Paulom Grahamom in kupom velikih ljudi. Sedeli smo v vročini in čakali, da Larry Page odleti s svojim osebnim helikopterjem, medtem ko je Guido brnel o "Pythonu 3000", ki ga je poimenoval po številu let, ki bodo trajala, da se bodo vsi preselili tja. Ves čas smo ga spraševali, zakaj krši združljivost, in odgovoril je: "Unicode." In vprašali smo, če bi morali ponovno napisati našo kodo, kakšne druge koristi bi videli? In odgovoril je "Jooooooooooooooouuuuuuuniiiiiiicooooooooooooooo."
Če namestite Google Cloud Platform SDK (»gcloud«), boste prejeli naslednje obvestilo:
Spoštovani prejemnik,
Radi bi vas spomnili, da je podpora za Python 2 opuščena, zato se jebite
… in tako naprej. Krog življenja.
Bistvo pa je, da ima vsak razvijalec izbiro. In če jih prisilite, da dovolj pogosto prepisujejo kodo, se bodo morda zamislili drugo opcije. Niso vaši talci, ne glede na to, kako zelo si to želite. So vaši gostje. Python je še vedno zelo popularen programski jezik, a hudiča, Python 3(000) je v sebi, v svojih skupnostih in med uporabniki svojih skupnosti ustvaril takšno zmešnjavo, da posledice niso bile razčiščene že petnajst let.
Koliko programov Python je bilo prepisanih v Go (ali Ruby ali kateri drugi alternativi) zaradi te nezdružljivosti za nazaj? Koliko nove programske opreme je bilo napisanega v nečem drugem kot v Pythonu, čeprav je lahko bi bilo napisano v Pythonu, če ne bi Guido požgal cele vasi? Težko je reči, vendar je Python očitno trpel. To je velika zmešnjava in vsi izgubijo.
Recimo, da se Apple zgleduje po Guidu in prekine združljivost. Kaj mislite, da se bo zgodilo naslednje? No, morda bo 80-90 % razvijalcev prepisalo svojo programsko opremo, če bo to mogoče. Z drugimi besedami, 10–20 % uporabniške baze samodejno gre v neki konkurenčni jezik, kot je Flutter.
Naredite to večkrat in izgubili boste polovico uporabniške baze. Tako kot v športu je tudi v svetu programiranja pomembna trenutna forma. всё. Vsakdo, ki v petih letih izgubi polovico svojih uporabnikov, bo obravnavan kot Big Fat Loser. Morate biti v trendu v svetu platform. Toda tukaj vas bo nepodpora za starejše različice sčasoma uničila. Ker vsakič, ko se znebiš nekaterih razvijalcev, jih (a) za vedno izgubiš, ker so jezni nate, ker si prekinil pogodbo, in (b) jih daš svojim tekmecem.
Ironično, ko sem ustvaril Grok, sistem za analizo in razumevanje izvorne kode, ki olajša avtomatizacijo in instrumentacijo same kode – podobno kot IDE, vendar tukaj shranjuje storitev v oblaku, sem tudi pomagal Googlu postati taka primadona, ki ignorira združljivost za nazaj. materializirane predstavitve vseh milijard vrstic Googlove izvorne kode v velikem podatkovnem skladišču.
Grok je Googlovim zaposlenim zagotovil zmogljivo ogrodje za izvajanje avtomatiziranih preoblikovanj v njihovi celotni kodni bazi (dobesedno v celotnem Googlu). Sistem izračuna ne samo vaše odvisnosti navzgor (od katerih ste odvisni), ampak tudi dolvodno (kar je odvisno od vas), tako da, ko spremenite API-je, poznate vse, ki jih zlomite! Na ta način, ko naredite spremembe, lahko preverite, ali je vsak uporabnik vašega API-ja posodobljen na novo različico, v resnici pa lahko pogosto z orodjem Rosie, ki so ga napisali, popolnoma avtomatizirate postopek.
To omogoča, da je Googlova kodna zbirka interno skoraj nadnaravno čista, saj imajo te robotske služabnike, ki se sprehajajo po hiši in samodejno vse počistijo, če so SomeDespicablyLongFunctionName preimenovali v SomeDespicablyLongMethodName, ker se je nekdo odločil, da gre za grdega vnuka in da ga je treba uspavati.
In odkrito povedano, deluje zelo dobro za Google ... interno. Mislim, da, skupnost Go pri Googlu se res dobro smeji skupnosti Java pri Googlu zaradi njihove navade nenehnega preoblikovanja. Če nekaj znova zaženete N-krat, to pomeni, da niste le zajebali N-1-krat, ampak čez nekaj časa postane precej jasno, da ste verjetno zajebali tudi pri N-tem poskusu. Toda na splošno ostajajo nad vsem tem hrupom in ohranjajo kodo »čisto«.
Težava se začne, ko skušajo ta odnos vsiliti svojim odjemalcem v oblaku in uporabnikom drugih API-jev.
Malo sem vam predstavil Emacs, Android in Javo; poglejmo najnovejšo uspešno dolgoživo platformo: sam splet. Si lahko predstavljate, koliko iteracij je šel HTTP od leta 1995, ko smo uporabljali utripajoče oznake? in ikone "V izdelavi" na spletnih straneh.
Ampak še vedno deluje! In te strani še vedno delujejo! Da, fantje, brskalniki so svetovni prvaki v združljivosti za nazaj. Chrome je še en primer redke Googlove platforme, ki ima svoje glave pravilno, in kot ste morda uganili, Chrome dejansko deluje kot podjetje v peskovniku, ločeno od preostalega Googla.
Prav tako se želim zahvaliti našim prijateljem v razvijalcih operacijskega sistema: Windows, Linux, NE APPLE FUCK YOU APPLE, FreeBSD itd., za tako odlično delo povratne združljivosti na njihovih uspešnih platformah (Apple dobi C v najboljšem primeru z The Slaba stran je, da ves čas pokvarijo vse brez dobrega razloga, vendar se skupnost nekako izogne temu z vsako izdajo, vsebniki OS X pa še vedno niso popolnoma zastareli ... še).
Ampak počakaj, praviš. Ali ne primerjamo jabolk s pomarančami – samostojnih programskih sistemov na enem računalniku, kot je Emacs/JDK/Android/Chrome, v primerjavi z večstrežniškimi sistemi in API-ji, kot so storitve v oblaku?
No, o tem sem včeraj tvital, pa sem v stilu Larryja Walla (kreatorja programskega jezika Perl – cca. per.) po principu "zanič/pravila" izbrskal besedo zastarelo na spletnih mestih za razvijalce Google in Amazon. In čeprav ima AWS stotine раз больше предложений услуг, чем у GCP, документация разработчиков Google упоминает устаревание примерно в семь раз чаще.
Če kdo pri Googlu to bere, je verjetno pripravljen izvleči grafikone v slogu Donalda Trumpa, ki kažejo, da dejansko delajo vse prav in da ne bi smel delati nepoštenih primerjav, kot je "število omemb besede zastarela proti število storitev" "
Toda po vseh teh letih je Google Cloud še vedno storitev številka 3 (nikoli nisem napisal članka o neuspelem poskusu, da postanem številka 2), a če je verjeti poznavalcem, obstajajo nekateri pomisleki, da bi lahko kmalu padli na št. 4.
Nimam nobenih prepričljivih argumentov, s katerimi bi "dokazal" svojo tezo. Vse, kar imam, so barviti primeri, ki sem jih nabral v 30 letih kot razvijalec. Omenil sem že globoko filozofsko naravo tega problema; na nek način je spolitiziran v skupnostih razvijalcev. Nekateri menijo, da ustvarjalci platforme bi morale skrbeti za združljivost, medtem ko drugi menijo, da je to skrb uporabniki (razvijalci sami). Eden od dveh. Res, ali ni politično vprašanje, ko se odločamo, kdo naj nosi stroške skupnih težav?
To je torej politika. In verjetno bodo jezni odzivi na moj govor.
Kot Uporabnik Google Cloud Platform in kot dveletni uporabnik AWS (medtem ko sem delal za Grab) lahko rečem, da obstaja velika razlika med Amazonovo in Googlovo filozofijo, ko gre za prioritete. Ne razvijam aktivno na AWS, zato ne vem dobro, kako pogosto odstranijo stare API-je. Obstaja pa sum, da se to ne dogaja niti približno tako pogosto kot pri Googlu. In resnično verjamem, da je ta vir stalnih polemik in frustracij v GCP eden največjih dejavnikov, ki zavirajo razvoj platforme.
Vem, da nisem navedel konkretnih primerov sistemov GCP, ki niso več podprti. Lahko rečem, da skoraj vse, kar sem uporabil, od omrežij (od najstarejših do VPC) do shranjevanja (Cloud SQL v1-v2), Firebase (zdaj Firestore s popolnoma drugačnim API-jem), App Engine (da niti ne začnemo) , končne točke v oblaku Končna točka v oblaku in do ... Ne vem - absolutno vse to vas prisilili, da ponovno napišete kodo po največ 2-3 letih, migracije pa nikoli niso avtomatizirali namesto vas in pogosto . Kot da bi tako moralo biti.
In vsakič, ko pogledam AWS, se vprašam, zakaj za vraga sem še vedno na GCP. Strank očitno ne potrebujejo. Oni rabijo kupiteli. Ali razumete razliko? Naj pojasnim.
Google Cloud ima , kjer ljudje predlagajo svoje programske rešitve, in da bi se izognili učinku prazne restavracije, so jo morali napolniti z nekaj predlogi, zato so sklenili pogodbo s podjetjem z imenom Bitnami, da ustvarijo kup rešitev, ki se uvedejo z "enim klikom" ali bi morale Sam pišem "rešitve", ker te ne rešijo ničesar. Preprosto obstajajo kot potrditvena polja, kot marketinško polnilo in Googlu nikoli ni bilo mar, ali katero od orodij dejansko deluje. Poznam produktne menedžerje, ki so bili na voznikovem sedežu, in lahko vam zagotovim, da je tem ljudem vseeno.
Vzemimo za primer domnevno rešitev za uvedbo »z enim klikom«. . Na smrt sem se naveličal zvijač Google Cloud SQL, zato sem kot alternativo začel razmišljati o gradnji lastne gruče Percona. In tokrat se je zdelo, da je Google dobro opravil svoje delo, s klikom na gumb mi bodo prihranili nekaj časa in truda!
No super, gremo. Sledimo povezavi in kliknimo ta gumb. Izberite »Da«, da se strinjate z vsemi privzetimi nastavitvami in uvedete gručo v svojem projektu Google Cloud. Haha, ne gre. Nič od tega sranja ne deluje. Orodje ni bilo nikoli preizkušeno in je začelo gniti od prve minute, in ne bi me presenetilo, če je več kot polovica "rešitev" uvedb z enim klikom (zdaj razumemo, zakaj narekovaji) na splošno не работают. Это абсолютно беспросветная тьма, куда лучше не входить.
Toda Google ima prav poziva, da jih uporabite. Želijo, da kupil. Za njih je to transakcija. Nočejo ničesar podporo. Ni del Googlove DNK. Da, inženirji se podpirajo, kar dokazuje moja zgodba z Bigtable. Toda v izdelkih in storitvah za običajne ljudi vedno bili neusmiljeni v , ki ne dosega merila donosnosti, tudi če ima na milijone uporabnikov.
In to predstavlja pravi izziv za GCP, ker je to DNK za vsemi ponudbami v oblaku. Ne poskušajo podpirati ničesar; Dobro je znano, da zavračajo gostovanje (kot upravljane storitve) programske opreme tretjih oseb dokler, dokler AWS ne stori enako in okoli tega ne zgradi uspešnega podjetja in ko stranke dobesedno zahtevajo isto. Vendar se je treba nekaj potruditi, da Google nekaj podpre.
To pomanjkanje kulture podpore, skupaj z miselnostjo "razbijmo, da bo lepše", odtujuje razvijalce.
In to ni dobra stvar, če želite zgraditi dolgoživo platformo.
Google, zbudi se, prekleto. Zdaj je leto 2020. Še vedno izgubljaš. Čas je, da se dobro pogledate v ogledalo in odgovorite, ali res želite ostati v poslu v oblaku.
Če hočeš ostati potem nehaj vse razbijati. Fantje, bogati ste. Mi razvijalci ne. Torej, ko gre za to, kdo bo prevzel breme združljivosti, ga morate prevzeti sami. Ne za nas.
Ker obstajajo še vsaj trije res dobri oblaki. Vabijo.
In zdaj bom nadaljeval s popravljanjem vseh pokvarjenih sistemov. Eh.
Do naslednjič!
PS Posodobite po branju nekaterih razprav o tem članku (razprave so super, btw). Podpora za Firebase ni bila ukinjena in ni nobenih načrtov, za katere sem seznanjen. Vendar pa imajo grdo napako pri pretakanju, zaradi katere odjemalec Java zastane v App Engine. Eden od njihovih inženirjev mi je pomagal rešiti ta problem, ko sem delal pri Googlu, vendar nikoli niso odpravili napake, tako da imam bedno rešitev, da moram vsak dan znova zagnati aplikacijo GAE. In tako že štiri leta! Zdaj imajo Firestore. Prehod nanj bo zahteval veliko dela, saj gre za popolnoma drugačen sistem in napaka Firebase ne bo nikoli odpravljena. Kakšen zaključek je mogoče potegniti? Lahko dobite pomoč če delaš v podjetju. Verjetno sem edini, ki uporablja Firebase na GAE, ker zabeležim manj kot 100 ključev v 100-odstotno domačo aplikacijo in vsakih nekaj dni preneha delovati zaradi znane napake. Kaj naj rečem drugega, kot da ga uporabljate na lastno odgovornost. Prehajam na Redis.
Videl sem tudi, da nekateri bolj izkušeni uporabniki AWS pravijo, da AWS običajno nikoli ne preneha podpirati nobene storitve, in SimpleDB je odličen primer. Moje domneve, da AWS nima enake bolezni konca podpore kot Google, se zdijo upravičene.
Poleg tega sem opazil, da je pred 20 dnevi ekipa Google App Engine prekinila gostovanje kritične knjižnice Go in zaustavila aplikacijo GAE enega od osrednjih razvijalcev Go. Bilo je res neumno.
Končno sem slišal, da zaposleni pri Googlu že razpravljajo o tem vprašanju in se na splošno strinjajo z menoj (ljubim vas, fantje!). Vendar se zdi, da mislijo, da je problem nerešljiv, ker Googlova kultura nikoli ni imela prave strukture spodbud. Mislil sem, da bi bilo dobro, da si vzamem nekaj časa in razpravljam o popolnoma neverjetni izkušnji, ki sem jo imel pri delu z inženirji AWS med delom pri Grabu. Upam, da nekoč v prihodnosti!
In ja, leta 2005 so res imeli različne vrste mesa morskega psa v velikanskem bifeju v stavbi 43, meni najljubše pa je bilo meso morskega psa kladiva. Vendar sta se do leta 2006 Larry in Sergei znebila vseh nezdravih prigrizkov. Torej med zgodbo Bigtable leta 2007 res ni bilo morskih psov in sem vas prevaral.
Ko sem si pred štirimi leti ogledal oblak Bigtable (več ali manj), je bil tukaj strošek. Zdi se, da je zdaj nekoliko upadlo, vendar je to še vedno zelo veliko za prazno podatkovno skladišče, zlasti ker moja prva zgodba kaže, kako nepomembna je prazna velika tabela v njihovem obsegu.
Oprostite, ker sem užalil skupnost Apple in nisem rekel ničesar lepega o Microsoftu itd. Vse je v redu, resnično cenim vso razpravo, ki jo je sprožil ta članek! Ampak včasih moraš malo vznemiriti, da začneš razpravo, veš?
Hvala za branje.
Posodobitev 2, 19.08.2020. XNUMX. XNUMX. Stripe !
Posodobitev 3, 31.08.2020. 2. 2. Z mano je stopil v stik Googlov inženir v Cloud Marketplace, za katerega se je izkazalo, da je moj stari prijatelj. Želel je ugotoviti, zakaj CXNUMXD ne deluje, in sčasoma smo ugotovili, da je to zato, ker sem svoje omrežje zgradil pred leti, CXNUMXD pa ni deloval v podedovanih omrežjih, ker v njihovih predlogah manjka parameter podomrežja. Mislim, da je najbolje, da potencialni uporabniki GCP poskrbijo, da poznajo dovolj inženirjev v Googlu ...
Vir: www.habr.com