Prekletstvo, Google, nisam želeo ponovo pisati blog. Imam toliko obaveza. Vođenje bloga zahteva vreme, energiju i kreativnost koje bih mogao bolje iskoristiti: moje knjige, , moja igra i tako dalje. Ali dovoljno si me iznervirao, moraću to napisati.
Dakle, da završimo s tim.
Počeću s malom, ali poučnom pričom iz vremena kada sam tek počeo raditi u Googleu. Znam da sam u poslednje vreme rekao mnogo loših stvari o Googleu, ali me frustrira kada moja kompanija redovno donosi nekvalitetne poslovne odluke. Ipak, treba priznati: unutrašnja infrastruktura Googlea zaista je izvanredna, i može se slobodno reći da danas nema bolje. Osnivači Googlea su bili mnogo bolji inženjeri nego što ću ikada postati, i ova priča to samo potvrđuje.
Prvo, malo pozadine: Google ima tehnologiju za skladištenje podataka nazvanu . To je bilo sjajno tehničko dostignuće, jedno od prvih (ako ne i prvo) "beskrajno skalabilno" skladište parova "ključ-vrednost" (key-value store, K/V): u suštini, početak NoSQL-a. Danas se Bigtable još uvek dobro snalazi u prilično zasićenom prostoru K/V skladišta, ali tada (2005. godine) bilo je neverovatno.
Jedna zanimljiva stvar o Bigtable-u je da su imali interne objekte kontrolne ravni (kao deo implementacije) nazvane tablet-serveri, s velikim indeksima, i u nekom trenutku su postali usko grlo pri skaliranju sistema. Inženjeri Bigtable-a su se mučili kako da implementiraju skalabilnost, i odjednom su shvatili da mogu zameniti tablet-servere drugim Bigtable skladištima. Tako da je Bigtable deo implementacije Bigtable-a. Ta skladišta su prisutna na svim nivoima.
Še ena zanimiva stvar je, da so bili Bigtable za nekaj časa priljubljeni in vseprisotni v Googlu, kjer je imela vsaka ekipa svoje skladišče. Zato je na enem izmed petkovnih sestankov Larry Page malomarno vprašal: "Zakaj imamo več kot en Bigtable? Zakaj ne uporabimo samo enega?" Teoretično bi moralo enega skladišča zadostovati za vse potrebe shranjevanja Googla. Seveda nikoli niso prešli na samo eno iz praktičnih razlogov razvoja (na primer, posledice morebitne okvare), a teorija je bila zanimiva. Eno skladišče za celo Univerzo (mimogrede, ali kdo ve, kaj je Amazon naredil s svojim Sable?)
Tako ali tako, tukaj je moja zgodba.
Takrat sem delal v Googlu že malo več kot dve leti, in enkrat sem prejel e-pošto od inženirske ekipe Bigtable, ki je bila približno takšna:
Spoštovani Steve,
Pozdrav od ekipe Bigtable. Želimo vas obvestiti, da v podatkovnem centru [ime podatkovnega centra] uporabljate zelo, zelo staro binarno datoteko Bigtable. Ta različica ni več podprta in želimo vam pomagati pri prehodu na najnovejšo različico.
Prosimo, sporočite nam, če lahko načrtujete nekaj časa za sodelovanje pri tej zadevi.
Vse najboljše,
Ekipa Bigtable
V Googlu prejmete veliko pošte, zato sem na prvi pogled to prebral približno tako:
Spoštovani prejemnik,
Pozdrav od neke ekipe. Želimo vas obvestiti, da bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla in bla-bla-bla takoj.
Prosimo, sporočite nam, ali lahko načrtujete del svojega dragocenega časa za bla-bla-bla.
Vse najboljše,
Neka ekipa
Skoraj sem ga takoj izbrisal, a sem na robu zavesti čutil breme, a hkrati neprijetno občutek, da to ni povsem videti kot formalno pismo, čeprav je očitno, da so se zmotili glede naslovnika, saj nisem uporabljal Bigtable.
Toda to je bilo nenavadno.
Preostanek dneva sem izmenično razmišljal o delu in o tem, katero vrsto morskega psa poskusiti v mikro kuhinji, od katerih so bile vsaj tri dovolj blizu, da jih lahko z natančnim metom piškota zadeneš s svojega mesta, vendar me misel na pismo ni zapustila s naraščajočim občutkom lahke tesnobe.
Oni so jasno navedli moje ime. In pismo je bilo poslano na moj elektronski naslov, ne pa na nekoga drugega, in to ni cc: ali bcc:. Ton je zelo oseben in jasen. Morda gre za napako?
Nazadnje je radovednost prevladala in šel sem pogledat konzolo Borg v podatkovnem centru, ki so ga omenili.
In seveda sem imel pod nadzorom skladišče BigTable. Kaj? Pogledal sem njegov sadržaj in - kakšno presenečenje! Bilo je iz inkubatorja Codelab, kjer sem bil v prvem tednu svojega dela pri Googlu junija 2005. Codelab je zahteval, da zaženete Bigtable, da ste vanj zapisali nekatere vrednosti, in očitno ga nisem zaprl po tem. Še vedno je delovalo, čeprav je minilo več kot dve leti.
V tej zgodbi je več opaznih vidikov. Prvič, dejavnost Bigtable je bila v obsegu Googla tako nepomembna, da je le dve leti kasneje nekdo opazil odvečno skladišče, in to le zato, ker je različica binarke zastarala. Za primerjavo, nekoč sem razmišljal o uporabi za svojo spletno igro. Takrat je ta storitev stala približno 16.000 $ letno za prazno Bigtable na GCP. Ne trdim, da vas zavajajo, vendar menim, da je to veliko denarja za prazno prekletredno bazo podatkov.
Še en opazen vidik je, da je skladišče še vedno delovalo po dveh letih. WTF? Podatkovni centri prihajajo in odhajajo; doživljajo motnje, podvrženi so načrtovanemu vzdrževanju, ves čas se spreminjajo. Strojna oprema se posodablja, stikala se premikajo, vse se nenehno izboljšuje. Kako, za vraga, so uspeli obdržati moje aplikacije delujoče dve leti ob vseh teh spremembah? To se morda zdi skromno dosežek leta 2020, vendar je bilo to med 2005 in 2007 zelo impresivno.
In najbolj neverjeten vidik je, da se na mene obrača ekipa inženirjev iz drugega državna in mi, lastniku nekega majhnega, praktično praznega primera Bigtable, ki ima ničelni promet v zadnjih dveh letih - in ponujajo pomoč pri njegovem posodabljanju.
Hvaležen sem jim, izbrisal sem skladišče in življenje je šlo naprej. Ampak trinajst let kasneje še vedno razmišljam o tem pismu. Ker kdaj pa kdaj dobim podobna pisma od Google Cloud. Izgledajo tako:
Spoštovani uporabnik Google Cloud,
Spominjamo vas, da prenehamo s podporo storitvi [važna storitev, ki jo uporabljate] od avgusta 2020, po čemer ne boste mogli posodobiti svojih inštanc. Priporočamo, da preidete na najnovejšo različico, ki je v beta testiranju, nima nobene dokumentacije, nikakršne možnosti migracije in je že vnaprej zastarela s našo prijazno pomočjo.
Trudimo se, da bi to spremembo čim manj vplivala na vse uporabnike platforme Google Cloud.
Najboljši prijatelji za vedno,
Oblačna platforma Google
Ampak takih sporočil skoraj ne berem, ker v njih dejansko piše naslednje:
Spoštovani prejemnik,
Pojdi hudiča. Pojdi, pojdi, pojdi. Odpusti vse, kar počneš, ker to ni pomembno. Kar je pomembno, je naš čas. Porabimo čas in denar, da vzdržujemo naše dreka, in tega smo siti, zato ga ne bomo več podpirali. Zato zavrzi svoje preklete načrte in začni preiskovati našo drečasto dokumentacijo, prosjačiti za drobtine na forumih, in mimogrede, naš nov dreka je popolnoma drugačen od starega dreka, ker smo močno pokvarili ta dizajn, heh, toda to je tvoja težava, ne naša.
Še vedno se trudimo, da vse tvoje razvite rešitve postanejo neuporabne v enem letu.
Prosim, pojdi v pekel,
Oblačna platforma Google
In dejstvo je, da taka sporočila prejemam približno enkrat na mesec. Dogaja se tako pogosto in tako stalno, da neizogibno odvrnilo me od GCP v tabor nasprotnikov oblakov. Ne strinjam se več, da bi bil odvisen od njihovih lastniških rešitev, ker je v resnici DevOpsu lažje vzdrževati sistem z odprto kodo na goli virtualki, kot pa poskušati držati korak z Googlovo politiko ukinjanja 'zastarelih' produktov.
Preden se vrnem k Google Cloud, ker sem tudi blizu Nisem prenehal kritizirati, poglejmo delo podjetja na nekaterih drugih področjih. Inženirji Googla so ponosni na svojo disciplino razvoja programske opreme, kar pravzaprav povzroča težave. Ponos je past za neprevidne, mnogi zaposleni v Googlu mislijo, da so njihove rešitve vedno pravilne in da je pravilnost (glede na nek nedefiniran, nejasen kriterij) pomembnejša od skrbi za stranke.
Navezal bom nekaj naključnih primerov iz drugih velikih projektov izven Googla, vendar upam, da boste ta vzorec videli povsod. Gre za naslednje: nazajšnja združljivost ohranja življenjsko dobo in aktualnost sistemov skozi desetletja.
Nazajšnja združljivost je ciljno načrtovanje vseh uspešnih sistemov, ki so zasnovani za odprto uporabo, torej realizirane z odprtokodno programsko opremo in/ali po odprtih standardih. Im feeling like I am stating something too obvious that is even uncomfortable for everyone, but it's not. This is a political issue, so examples are needed.
Prvi sistem, ki ga izberem, je najstarejši: GNU Emacs, to je nekakšen hibrid med Beležnico Windows, jedrom operacijskega sistema in Mednarodno vesoljsko postajo. Težko je to razložiti, a v dveh besedah je Emacs platforma, ustvarjena leta 1976 (da, skoraj pred petdesetimi leti) za programiranje, da bi povečala vašo produktivnost, a se pretvarja, da je besedilni urejevalnik.
Emacs uporabljam vsak dan. Da, vsak dan uporabljam tudi IntelliJ, ta se je že sama spremenila v močno orodno platformo. Vendar pa je pisanje razširitev za IntelliJ bistveno bolj ambiciozno in zahtevno nalogo, kot pisanje razširitev za Emacs. In kar je še pomembneje, vse, kar je zapisano za Emacs, se ohranja večno.
Še vedno uporabljam programsko opremo, ki sem jo napisal za Emacs že leta 1995. Prepričan sem, da nekdo uporablja module, napisane za Emacs v sredini 80. let, če ne celo prej. Občasno lahko zahtevajo drobne prilagoditve, vendar je to resnično precej redko. Ne vem za nič, kar sem kdaj napisal za Emacs (in napisal sem veliko), kar bi bilo treba ponovno zgraditi.
V Emacsu je funkcija z imenom make-obsolete za zastarele entitete. Terminologija Emacsa za temeljne računalniške koncepte (kot je "okno") se pogosto razlikuje od industrijskih konvencij, ker je Emacs te koncepte uvedel že zdavnaj. To je tipična nevarnost za tiste, ki so prehiteli svoj čas: vsi vaši izrazi so napačni. Ampak v Emacsu resnično obstaja koncept zastaranja, ki ga imenujejo zastaranje.
Toda v svetu Emacsa se zdi, da ima drugo delovno opredelitev. Druga temeljna filozofija, če želite.
V svetu Emacsa (in v mnogih drugih področjih, ki jih bomo obravnavali spodaj) status zastare API-jev predvsem pomeni: "Dejansko tega pristopa ne bi smeli uporabljati, ker, čeprav deluje, ima različne pomanjkljivosti, ki jih bomo tukaj našteli. A na koncu je to vaša izbira."
V svetu Googla status zastare proizvoda pomeni: "Krši se naše zaveze do vas." To je res. To v bistvu pomeni, da vas bodo prisilili redno opravljati neko delo, morda precejšnje delo, v kazen, ker ste verjeli v njihovo : imamo najboljšo programsko opremo. Najhitrejšo! Učite se sledi, zaženete svojo aplikacijo ali storitev in potem — bum, čez eno ali dve leti se pokvari.
To je enako, kot bi prodajali rabljen avto, ki se bo zagotovo pokvaril po 1500 km.
To sta povsem različni filozofski opredelitvi "zastaranja". Opredelitev Googla diši po . Ne verjamem, da je to v resnici načrtovano zastaranje v istem smislu kot pri Applu. Ampak Google zagotovo namerava pokvariti vaše programe po stranski poti. To vem, ker sem tam delal kot programer več kot 12 let. Imajo nejasne notranje smernice, v kolikšni meri bi morali ohranjati povratno združljivost, a na koncu je to odvisno od vsake posamezne ekipe ali službe. Ni nobenih priporočil na korporativni ali inženirski ravni in najbolj drzna priporočila glede ciklov zastaranja so: "Poskusite dati strankam 6-12 mesecev za posodobitev, preden jim pokvarite celoten sistem."
Problem je veliko ozbiljniji nego što misle i zadržaće se još dugo, jer briga o klijentima nije deo njihove DNK. Više informacija o tome u nastavku.
Trenutno nameravam da postavim hrabru tvrdnju da je Emacs uspešan u značajnoj meri i čak večinoma jer se ozbiljno bave unazadnom kompatibilnošću. U stvari, to je teza našeg članka. Uspešni dugovečni otvoreni sistemi duguju svoj uspeh mikrosvetovima koji decenijama postoje oko proširenja/pluginova. To je ekosistem. Razmišljao sam o suštini platformi i koliko su važne, kao i o tome da Google nikada tokom svoje korporativne istorije nije razumeo šta je potrebno za izgradnju uspešne otvorene platforme, osim Androida ili Chromea.
U stvari, trebalo bi ukratko da pomenem Android, jer ste verovatno pomislili na njega.
Najprej, Android nije Google. Oni nemaju gotovo ništa zajedničkog. Android je kompanija koju je Google kupio u julu 2005. godine, ovoj kompaniji je dozvoljeno da radi više-manje autonomno i zapravo je ostala u značajnoj meri netaknuta tokom godina. Android je poznati tehnički stog i podjednako poznata oštra organizacija. Kao što je rekao jedan
googler, "ne možete jednostavno ući u Android". U jednom od prethodnih članaka sam već razmišljao o tome koliko su loša bila neka od ranih dizajnerskih rešenja Androida. Prokletstvo, kada sam pisao taj članak, radili su na implementaciji smešnog dodeljenog
A vendar pa obstaja razlika, pomembna razlika, ki je v tem, da ljudje iz Androida resnično razumejo, kako pomembne so platforme, in se trudijo, da ohranijo delovanje starih Android aplikacij. V resnici so njihovi napori pri ohranjanju povratne združljivosti tako ekstremni, da sem tudi jaz, med svojim kratkim časom v Android oddelku pred nekaj leti, ugotovil, da jih skušam prepričati, da se odpovejo podpori nekaterih najstarejših naprav in API-jev (motil sem se, tako kot pri mnogih drugih stvareh iz preteklosti in sedanjosti. Opravičujem se, ekipa Android! Zdaj, ko sem obiskal Indonezijo, razumem, zakaj jih potrebujemo).
Ljudje iz Androida ohranjajo povratno združljivost do skoraj nevzdržnih skrajnosti, kar nalaga ogromno količino zastare tehničnih dolgov v njihovih sistemih in orodnih verigah. O, bog, videli bi nekatere nore stvari, ki jih morajo delati v svojem sistemu za gradnjo, in vse to v imenu združljivosti.
Zato podeljujem Androidu prestižno nagrado 'Nisi Google'. Res ne želijo postati Google, ki ne zna ustvarjati trajnih platform, toda Android zna. , in nihče drug nima nobenih informacij o tej vrednosti. V naslednjem razdelku bo potrebno, da za neko vnaprej določeno točko, kako to narediti. In zato se Google v enem pogledu obnaša zelo modro: dovoljuje ljudem v Androidu, da delajo po svoje.
Vendar so bile trenutne aplikacije za Android precej neumne ideje. In veste, zakaj? Ker so zahtevale prepisovanje in ponovno načrtovanje vaše aplikacije! Kot da bi ljudje kar vzeli in napisali dve milijoni aplikacij. Predvidevam, da so bile trenutne aplikacije ideja kakšnega Googlerja.
Toda obstaja razlika. Povratna združljivost prinaša velike stroške. Android sam nosi breme teh stroškov, medtem ko Google vztraja, da to breme nosijo vi, plačani stranki.
Lahko vidite zavezanost Androida povratni združljivosti v njegovih API-jih. Ko imate štiri ali pet različnih podsistemov, ki dobesedno izvajajo isto, je to zanesljiv znak, da je v ozadju zavezanost povratni združljivosti. Kar je v svetu platform sinonim za zavezanost vašim strankam in vašemu trgu.
Glavna težava Google-a leži v njihovi ponosu na inženirsko higieno. Ne marajo, da obstaja veliko različnih načinov za dosego istega, pri čemer stari, manj zaželeni načini stojijo ob strani novim, bolj zapletenim. To povečuje učno krivuljo za novince v sistemu, povečuje breme podpore zastarelih API-jev, počasni razvoj novih funkcij in glavni greh — to preprosto ne izgleda dobro. Google je kot gospa Escott iz 'Alise v čudežni deželi' Tima Burtona:
Gospa Escott:
— Alisa, veš, česa se najbolj bojim?
— Upada aristokracije?
— Bojim se, da bom imela grde vnuke.
Da bi razumeli kompromis med lepim in praktičnim, si oglejmo tretjo uspešno platformo (po Emacs in Android) in poglejmo, kako deluje: sama Java.
V Javi je veliko zastarelih API-jev. Zastarelost je zelo priljubljena med Java programerji, celo bolj kot v večini drugih programskih jezikov. V sami Javi, osnovnem jeziku in knjižnicah se nenehno dogajajo zastarele API-ji.
Če vzamemo samo enega izmed tisočih primerov, se šteje za zastarelo. Zastarelo je od izida Jave 1.2 decembra 1998. Minevali so 22 let od takrat, ko je to zastarelo.
Toda moj dejanski koda v produkciji še vedno ubija niti vsak dan. Je to dobro? Absolutno! Mislim, seveda, če bi danes prepisal kodo, bi to izvedel drugače. Toda koda moje igre, ki je zadnja dva desetletja osrečila na tisoče ljudi, je napisana z uporabo funkcije zapiranja niti, ki obstoji predolgo, in nikoli je nisem moral spremeniti. Poznam svoj sistem bolje kot kdorkoli, imam dosledno 25 let izkušenj z njim v produkciji, in lahko povem z gotovostjo: v mojem primeru je zapiranje teh specifičnih delovnih niti popolnoma neškodljivo. Ne bi smeli izgubljati časa in truda za prepisovanje te kode, in hvala Larryju Ellisonu (verjetno), da me Oracle ni prisilil, da jo prepišem.
Verjetno se Oracle tudi razume na platforme. Kdo ga ve.
Dokaze lahko srečate pri vseh ključnih Java API-jih, ki jih prežemajo valovi zastare, podobno kot linije ledenika v kanjonu. V knjižnici Java Swing lahko zlahka najdete pet ali šest različnih upravljalnikov za navigacijo s tipkovnico (KeyboardFocusManager). V resnici je težko najti Java API, ki ni zastarel. A še vedno delujejo! Mislim, da bo ekipa Java v resnici odstranila API le, če bo vmesnik povzročil očitne varnostne težave.
Tukaj je stvar, fantje: mi, razvijalci programske opreme, smo vsi zelo zasedeni, in v vsakem področju programske opreme se srečujemo s konkurenčnimi alternativami. Vsak trenutek programerji v jeziku X razmišljajo o jeziku Y kot možni zamenjavi. O, mi ne verjamete? Želite omeniti Swift? Kot da vsi prehajajo na Swift in nihče ne odstopa od njega, kajne? Ojoj, kako malo veste. Podjetja obravnavajo stroške dvostopenjskih ekip za mobilni razvoj (iOS in Android) — in začnejo spoznavati, da te cross-platform sisteme razvoja s smešnimi imeni, kot sta Flutter in React Native, dejansko delujejo, in s pomočjo njih lahko zmanjšajo število svojih mobilnih ekip na polovico ali, nasprotno, povečajo njihovo produktivnost za dvakrat. Na kocki so pravi denar. Da, obstajajo kompromisi, vendar, z druge strani, de-e-eni.
Predpostavimo hipotetično, da je Apple iz neumnosti vzel primer od Guida van Rossuma in oznanil, da je Swift 6.0 nazaj nezdružljiv s Swiftem 5.0, v veliki meri kot Python 3 ni združljiv s Pythonom 2.
Verjetno sem to zgodbo pripovedoval pred desetimi leti, toda pred petnajstimi leti sem šel na O'Reilly's Foo Camp s Guida, sedel v šotoru s Polom Grahamom in kupom velikih imen. Sedeli smo v izčrpavajoči vročini in čakali, da bo Larry Page priletel s svojim osebnim helikopterjem, Guido pa je monotono mumljal o 'Python 3000', ki ga je poimenoval po številu let, ki bo potrebno, da se vsi preselijo tja. Ves čas smo ga spraševali, zakaj krši združljivost, on pa je odgovarjal: 'Unicode'. In spraševali smo, če bomo morali prepisati svojo kodo, kakšne druge prednosti bomo videli? In on je odgovarjal: 'Yoooooooooooooouuuuuuuniiiiiiicoooooooode'.
Če namestite Google Cloud Platform SDK ('gcloud'), boste prejeli naslednje obvestilo:
Spoštovani prejemnik,
Radi bi vas spomnili, da je podpora za Python 2 zastarela, zato pa tečeš kot noro.
… in tako naprej. Krog življenja.
Toda dejstvo je, da ima vsak razvijalec izbiro. In če jih primorate, da pogosto prepisujejo kodo, bodo morda razmislili tudi o drugim opcije. Niso vaši sužnji, koliko želite. So vaši gostje. Python je še vedno zelo priljubljen programski jezik, vendar, hudiča, Python 3(000) je ustvaril takšno zmešnjavo v svojih skupnostih in pri uporabnikih teh skupnosti, da posledic ne morejo očistiti že petnajst let.
Koliko Python programov je bilo prepisanih v Go (ali Ruby, ali kakšno drugo alternativo) zaradi te neskladnosti? Koliko nove programske opreme je bilo napisanih v nečem drugem kot Python, čeprav bi lahko bilo narejeno v Pythonu, če ne bi Guido zažgal vasi? Težko je reči, a Python je očitno utrpel. To je ogromna zmeda in vsi so na slabšem.
Torej, recimo, da Apple sledi Guida in krši združljivost. Kaj mislite, da se bo zgodilo naprej? No, morda bo 80-90% razvijalcev prepisalo svojo programsko opremo, če bo mogoče. Drugimi besedami, 10-20% uporabniške baze se samodejno preseli na kakšen konkurenčni jezik, na primer, Flutter.
Naredite to večkrat – in izgubili boste polovico svoje uporabniške baze. Tako kot v športu, v svetu programiranja trenutna forma prav tako pomeni vse. Kdor koli izgubi polovico uporabnikov v petih letih, bo veljal za Velikega Debelookega Poraznika. Morate biti v trendu v svetu platform. Toda to je tukaj, ko vas opustitev podpore za stare različice sčasoma uniči. Kajti vsakokrat, ko se znebite dela razvijalcev, (a) jih izgubite za vedno, ker so jezni na vas zaradi kršitve pogodbe, in (b) jih predajate svojim konkurentom.
Ironično, tudi sam sem pomagal Googlu, da je postal takšna diva, ki ignorira nazaj kompatibilnost, ko sem ustvaril Grok, sistem za analizo in razumevanje izvorne kode, ki omogoča avtomatizacijo in opremljanje z orodji na podlagi same kode - kot IDE, vendar tukaj oblačna storitev hrani materializirane prikaze vseh milijard vrstic izvorne kode Googla v velikem podatkovnem skladišču.
Grok je zagotavljal močno osnovo za avtomatizirano prestrukturiranje celotne kode (dobesedno po vsej Google). Sistem izračuna ne le vaše naraščajoče odvisnosti (od katerih ste odvisni), temveč tudi padajoče (ki so odvisne od vas), zato ob spremembi API-ja veste, koga poškodujete! Tako lahko ob spremembah preverite, da je vsak uporabnik vašega API-ja posodobil na novo različico, v resnici pa pogosto s pomočjo orodja Rosie, ki so ga razvili, lahko popolnoma avtomatizirate ta postopek.
To omogoča, da je Google koda interno skoraj nadnaravno "čista", saj ti robotski služabniki prežijo po celotnem domu in samodejno popravijo vse, če so preimenovali SomeDespicablyLongFunctionName v SomeDespicablyLongMethodName, ker je nekdo odločil, da je to grdi vnuk in ga je treba uspavati.
In, iskreno, to za Google deluje precej dobro… interno. Mislim, da, skupnost Go v Googlu se resnično prijazno norčuje iz skupnosti Java v Googlu zaradi njihovega navdušenja nad nenehnim prestrukturiranjem. Če nekaj ponavljate N-krat, pomeni, da ste to N-1 krat pokvarili in po nekaj časa postane očitno, da ste to verjetno pokvarili tudi pri N-jem poskusu. A na splošno, ostajajo nad to zmešnjavo in ohranjajo kodo "čisto".
Težave se začnejo, ko poskušajo to mentaliteto vsiliti svojim oblačnim strankam in uporabnikom drugih API-jev.
Malce sem vas seznanil z Emacs, Android in Javo; poglejmo zadnjo uspešno dolgoživost platforme: samo Internet. Si lahko predstavljate, koliko iteracij je HTTP prešel od leta 1995, ko smo uporabljali utripajoče oznake in ikone »V razvoju« na spletnih straneh.
Toda še vedno deluje! In te strani še vedno delujejo! Da, fantje, brskalniki so svetovni prvaki v zagotavljanju nazadne združljivosti. Chrome je še en primer redke platforme Googla, ki ima glave zategnjene pravilno, in kot že verjetno uganite, Chrome učinkovito deluje kot izolirano podjetje ločeno od ostalega Googla.
Želim se zahvaliti našim prijateljima među razvijateljima operacijskih sustava: Windows, Linux, NE APPLE ŠTO ČINIŠ APPLE, FreeBSD i tako dalje, za sav trud oko unazadne kompatibilnosti na svojim uspješnim platformama (Apple zaslužuje najmanje trojku s minusom, jer konstantno sve ruši bez ikakvog objašnjenja, ali nekako zajednica se nosi s tim u svakoj verziji, a do sada kontejneri s OS X još nisu potpuno zastarjeli... za sad).
Ali pričekajte, reći ćete. Zar ne uspoređujemo jabuke i naranče — autonomne softverske sustave na jednom računalu, poput Emacs/JDK/Android/Chrome, s višeservernim sustavima i API-ima, kao što su u cloud uslugama?
Pa, to sam napisao jučer na Twitteru, ali u stilu Larryja Walla (stvoritelja programskog jezika Perl — napomena prevoditelja) zasad 'sotona/rules' potražio sam riječ deprecated na stranicama za razvijatelje Google i Amazon. I iako AWS ima sto puta više ponuda usluga nego GCP, dokumentacija za razvijatelje Google spominje zastarijevanje otprilike sedam puta češće.
Ako netko iz Googlea ovo čita, sigurno su spremni izvući dijagrame u stilu Donalda Trumpa, pokazujući da zapravo rade sve ispravno i da ne bih trebao raditi nepravedne usporedbe poput 'broj spominjanja riječi deprecated u odnosu na broj usluga'.
Ali nakon toliko godina Google Cloud još uvijek ostaje servis broj 3 (nisam još napisao članak o neuspješnoj pokušaju da postanu broj 2), ali prema izvorima, postoje neke brige da bi mogli uskoro pasti na broj 4.
Nemam čvrste argumente da 'dokažem' svoju tezu. Sve što imam su šareni primjeri koje sam prikupio tijekom 30 godina rada kao programer. Već sam spomenuo duboko filozofsku prirodu ovog problema; u nekom smislu je politički unutar zajednica programera. Neki smatraju da stvoritelji platformi trebaju brinuti o kompatibilnosti, dok drugi tvrde da je to briga uporabnikov (samih programera). Jedno od ta dva. I stvarno, zar nije ovo političko pitanje kad odlučujemo tko bi trebao snositi troškove zbog zajedničkih problema?
Dakle, ovo je politika. I sigurno će biti gnjevnih odgovora na moju izjavu.
Kako uporabnik kot Google Cloud, prav tako pa lahko kot uporabnik AWS v dveh letih (delal sem v podjetju Grab) rečem, da obstaja velika razlika med filozofijami Amazona in Googla, ko gre za prioritete. Aktivno ne razvijam na AWS, tako da ne vem točno, kako pogosto odstranjujejo stare API-je. Vendar pa imam občutek, da to ne poteka tako pogosto kot pri Googlu. In iskreno verjamem, da je ta vir nenehnih polemik in razočaranj v GCP eden največjih dejavnikov, ki omejuje razvoj platforme.
Vem, da nisem omenil konkretnih primerov sistemov GCP, katerih podpora je prenehala. Lahko pa rečem, da je skoraj vse, kar sem uporabljal, od omrežij (od najstarejših do VPC) do shranjevanja (Cloud SQL v1-v2), Firebase (zdaj Firestore z povsem drugim API-jem), App Engine (ne bi se celo lotil), oblačnih končnih točk Cloud Endpoint in ... ne vem - vse to je zahtevalo prepisovanje kode na največ vsakih 2-3 leta, in nikoli niso avtomatizirali migracije za vas, pogosto . Kot da je tako predvideno.
In vsakokrat, ko pogledam na AWS, se sprašujem, zakaj še vedno ostajam na GCP. Očitno ne potrebujejo strank. P potrebujejo kupce.Razumete razliko? Pustite mi, da razložim.
Google Cloud ima , na kateri ljudje ponujajo svoja programska sredstva, in da bi se izognili učinku praznega restavracije, so morali napolniti z nekaterimi ponudbami, zato so podpisali pogodbo s podjetjem Bitnami, da ustvarijo vrsto rešitev, ki se namestijo 'z enim klikom', ali pa moram sam napisati 'rešitve', ker te nič ne rešujejo. Preprosto obstajajo kot kljukice, kot tržni dodatek, Google pa nikoli ni skrbelo, ali kateri od teh orodij dejansko deluje. Poznam produktne vodje, ki so bili za volanom, in lahko vam zagotovim, da je tem ljudem vseeno.
Vzemimo na primer rešitev z domnevno 'namestitvijo z enim klikom' . Smrtno me je že zamorila potegavščina Google Cloud SQL, zato sem začel razmišljati o ustanovitvi svojega Percona klasterja. In tokrat se je Google očitno popravil, načrtovali so, da mi prihranijo malo časa in truda z enim pritiskom na gumb!
No, dobro, idemo. Kliknemo na ovu poveznicu i pritisnemo ovu tipku. Biramo 'Da' da se slažemo sa svim zadanim postavkama i implementiramo klaster u svom Google oblaku. Ha-ha, ne radi. Ništa od ove gluposti ne radi. Alat nikada nije testiran i počeo je trunuti od prve minute, i ne bi me iznenadilo da više od polovice 'rješenja' za implementaciju jednim klikom (sada razumijemo zašto su navodnici) ne funkcionira. uopće ne rade. To je apsolutna besmislica u koju je bolje ne ulaziti.
Ali Google otvoreno poziva vas da ih koristite. Žele da ih kupite. Za njih je to transakcija. Ne žele ništa podpira. To nije dio DNK Googlea. Da, inženjeri se međusobno podržavaju, što potvrđuje moja priča s Bigtableom. Ali u proizvodima i uslugama za obične ljude oni su vedno bili nemilosrdni u , koji ne ispunjava standard profitabilnosti, čak i ako ima milijune korisnika.
I to predstavlja pravi problem za GCP, jer ta DNK stoji iza svih oblačnih ponuda. Ne teže podržavanju nečega; dobro je poznato da odbijaju hostati (kao upravljanu uslugu) bilo koji softver treće strane sve dok AWS ne napravi isto i ne izgradi uspješan biznis oko toga, a kada klijenti doslovno budu zahtijevali isto. Međutim, potrebno je uložiti određeni trud da se natjera Google da nešto podrži.Ova nesposobnost podrške, u kombinaciji s principom 'razbijmo da bismo učinili ljepše', udaljava developere od njih.
I to nije baš dobro ako želite izgraditi dugotrajan vrijedan platformu.
Google, probudi se, dovraga. Sada je 2020. godina. Još uvijek gubiš. Vrijeme je da se ozbiljno pogledaš u ogledalo i odgovoriš, želiš li ostati u oblaku.
Ako želiš ostati, onda
prestani sve rušiti . Ljudi, vi ste bogati. Mi, developeri, nismo. Zato, kada je u pitanju tko će preuzeti teret kompatibilnosti, vi to morate preuzeti. Ne mi.Jer još uvijek postoje barem tri stvarno dobra oblaka. Mame se.
A sada ću krenuti dalje popraviti sve svoje pokvarene sustave. Eh.
Do sljedeći put!
До следующего раза!
P. S. Posodobitev po branju nekaterih razprav o tem članku (razprave so izjemne, mimogrede). Podpora za Firebase ni bila prekinjena in ne obstajajo nobeni načrti, o katerih vem. Kljub temu pa imajo nadležno napako pri prenosu, ki povzroča, da Java odjemalec ustavi delovanje v App Engine. Eden od njihovih inženirjev mi je pomagal rešiti ta problem, ko sem delal pri Googlu, vendar nikoli dejansko niso odpravili te napake, zato imam precej neprijeten obvod, kjer moram vsak dan znova zagnati aplikacijo GAE. Tako že štiri leta! Sedaj imajo Firestore. Migracija na to bo zahtevala veliko dela, saj je to povsem drugačen sistem, napaka Firebase pa nikoli ne bo odpravljena. Kakšen zaključek lahko potegnemo? Lahko dobite pomoč, če delate v podjetju. Verjetno sem edini, ki uporablja Firebase na GAE, ker beležim manj kot 100 ključev v 100% izvirni aplikaciji, in ta preneha delovati vsakih nekaj dni zaradi znane napake. Kaj naj rečem, razen da ga uporabljate na lastno odgovornost. Prehajam na Redis.
Tudi opazil sem, da so nekateri bolj izkušeni uporabniki AWS govorili, da AWS ponavadi nikoli ne preneha s podporo za nobene storitve, in SimpleDB je odličen primer. Moje predpostavke, da v AWS ni take bolezni s prenehanjem podpore, kot pri Googlu, se zdijo upravičene.
Poleg tega sem opazil, da je pred 20 dnevi ekipa Google App Engine pokvarila gostovanje kritične knjižnice Go, s čimer je preprečila dostop do aplikacije GAE od enega od glavnih razvijalcev Go. Res je, da je to nesmiselno.
Nazadnje, slišal sem, da se Googlerji že pogovarjajo o tem vprašanju in se na splošno strinjajo z mano (ljubim vas, fantje!). Vendar pa se zdi, da menijo, da je problem nerešljiv, ker v kulturi Googla nikoli ni bilo prave strukture spodbud. Mislim, da bi bilo dobro, da si vzamem malo časa, da razpravljam o neverjetnih izkušnjah dela z inženirji AWS, ko sem delal v podjetju Grab. Upam, da bo to kdaj v prihodnosti!
In 2005, they really did have various types of shark meat on a giant buffet in building 43, and I liked the meat of the hammerhead sharks the most. However, by 2006, Larry and Sergey got rid of all unhealthy snacks. So during the Bigtable story in 2007, there were indeed no sharks, and I deceived you shamefully.
When I looked at the cloud Bigtable about four years ago (plus or minus), the cost was exactly that. It seems to have decreased a bit now, but it’s still a horrendous amount for empty data storage, especially considering that my first story shows how insignificant an empty big table is at their scale.
I apologize for offending the Apple community and for not saying anything nice about Microsoft and so on. You are all right, I really appreciate all the discussions that this article has sparked! But sometimes you need to stir the waters a bit to start a conversation, you know?
Thank you for reading.
Update 2, 19.08.2020. Stripe !
Update 3, 31.08.2020. An engineer from Google in the Cloud Marketplace reached out to me who turned out to be an old friend. He wanted to figure out why C2D wasn’t working, and eventually, we discovered: the reason is that I created my network several years ago, and C2D doesn’t function in outdated networks due to a missing subnet parameter in their templates. I think potential GCP users should ensure they have enough familiar engineers at Google...
Izvor: habr.com
