Damne Guglo, mi ne volis blogi denove. Mi havas tiom da por fari. Blogado bezonas tempon, energion kaj kreemon, kiujn mi povus bone utiligi: miajn librojn, , mia ludo kaj tiel plu. Sed vi sufiĉe kolerigis min, ke mi devas skribi ĉi tion.
Do ni finigu ĉi tion.
Mi komencu kun mallonga sed instrua rakonto de kiam mi unue eklaboris ĉe Guglo. Mi scias, ke mi diras multajn malbonajn aferojn pri Guglo lastatempe, sed ĉagrenas min kiam mia propra kompanio regule faras nekompetentajn komercajn decidojn. Samtempe, ni devas doni al ĝi sian meriton: la interna infrastrukturo de Guglo estas vere eksterordinara, estas sekure diri ke ekzistas nenio pli bona hodiaŭ. La fondintoj de Guglo estis multe pli bonaj inĝenieroj ol mi iam estos, kaj ĉi tiu rakonto nur konfirmas tiun fakton.
Unue, iom da fono: Google havas datuman stokan teknologion nomitan . Ĝi estis rimarkinda teknika atingo, unu el la unuaj (se ne la unua) "senfine skalebla" ŝlosilvalora vendejo (K/V): esence la komenco de NoSQL. Nuntempe Bigtable ankoraŭ fartas bone en la sufiĉe homplena K/V-stoka spaco, sed tiutempe (2005) ĝi estis mirinde malvarmeta.
Unu amuza afero pri Bigtable estas, ke ili havis internajn kontrolajn aviadilobjektojn (kiel parto de la efektivigo) nomitajn tabulserviloj, kun grandaj indeksoj, kaj iam ili iĝis proplempunkto dum skalado de la sistemo. Bigtable-inĝenieroj konfuziĝis pri kiel efektivigi skaleblon, kaj subite ekkomprenis ke ili povas anstataŭigi tabulservilojn per alia Bigtable-stokado. Do Bigtable estas parto de la efektivigo de Bigtable. Ĉi tiuj stokejoj estas tie sur ĉiuj niveloj.
Alia interesa detalo estas, ke dum iom da tempo Bigtable iĝis populara kaj ĉiea ene de Guglo, kie ĉiu teamo havas sian propran deponejon. Do ĉe unu el la vendredaj renkontiĝoj, Larry Page hazarde demandis preterpase: "Kial ni havas pli ol unu Bigtable? Kial ne nur unu?” En teorio, unu stokado devus sufiĉi por ĉiuj stokadbezonoj de Guglo. Kompreneble, ili neniam iris al nur unu pro praktikaj evoluaj kialoj (kiel la sekvoj de ebla fiasko), sed la teorio estis interesa. Unu deponejo por la tuta Universo (Cetere, ĉu iu scias ĉu Amazon faris tion per sia Zibelo?)
Ĉiuokaze, jen mia rakonto.
Tiutempe mi laboris ĉe Google dum iom pli ol du jaroj, kaj iun tagon mi ricevis retmesaĝon de la inĝenieristikteamo de Bigtable, kiu iris tiel:
Kara Steve,
Saluton de la Bigtable-teamo. Ni ŝatus informi vin, ke ĉe [datumcentronomo] vi uzas tre, tre malnovan Bigtable-binaron. Ĉi tiu versio ne plu estas subtenata kaj ni volas helpi vin ĝisdatigi al la plej nova versio.
Bonvolu sciigi min ĉu vi povas plani tempon por kunlabori pri ĉi tiu afero.
Ĉion bonan,
Bigtable Teamo
En Guglo vi ricevas multe da poŝto, do unuavide mi legas ion tian:
Kara Ricevanto,
Saluton de iu teamo. Ni volas komuniki tion bla bla bla bla bla. Bla bla bla bla bla bla, kaj bla bla bla tuj.
Bonvolu sciigi nin ĉu vi povas plani iom da via altvalora tempo por bla bla bla.
Ĉion bonan,
Ia komando
Mi preskaŭ forigis ĝin tuj, sed ĉe la rando de mia konscio mi sentis doloran, ĉagrenan senton, ke ĝi ne tute tamen aspektas kiel formala letero evidente, ke la ricevanto eraris ĉar mi ne uzis Bigtable.
Sed estis strange.
Mi pasigis la reston de la tago alterne pensante pri laboro kaj kian ŝarkan viandon provi en la mikrokuirejo, el kiuj almenaŭ tri estis sufiĉe proksimaj por bati de mia seĝo per bone celita ĵeto de biskvito, sed la penso pri skribado neniam lasis min kun kreskanta sento de milda angoro.
Ili klare diris mian nomon. Kaj la retpoŝto estis sendita al mia retadreso, ne al alies, kaj ĝi ne estas cc: aŭ bcc:. La tono estas tre persona kaj klara. Eble ĉi tio estas ia eraro?
Fine, scivolemo venkis min kaj mi iris rigardi la Borg-konzolon en la datumcentro, kiun ili menciis.
Kaj kompreneble, mi havis BigTable-stokadon sub administrado. Pardonu, kio? Mi rigardis ĝian enhavon, kaj ve! Ĝi estis de la Codelab-inkubatoro, en kiu mi sidis dum mia unua semajno ĉe Guglo en junio 2005. Codelab devigis vin ruli Bigtable por skribi iujn valorojn tie, kaj mi ŝajne neniam fermis la stokadon post tio. Ĝi ankoraŭ funkciis kvankam pasis pli ol du jaroj.
Estas pluraj rimarkindaj aspektoj en ĉi tiu rakonto. Unue, la laboro de Bigtable estis tiel sensignifa en la skalo de Guglo, ke nur du jarojn poste iu rimarkis la ekstran stokadon, kaj nur ĉar la versio de la binaro estis malaktuala. Por komparo, mi iam pripensis uzi por mia interreta ludo. Tiutempe ĉi tiu servo kostis proksimume $16 jare. malplena Bigtable sur GCP. Mi ne diras, ke ili trompas vin, sed laŭ mia persona opinio, tio estas multe da mono por malplena fika datumbazo.
Alia rimarkinda aspekto estas, ke la stokado ankoraŭ laboras post du jaroj. WTF? Datumcentroj venas kaj iras; ili spertas malfunkciojn, ili spertas planitan prizorgadon, ili ŝanĝiĝas la tutan tempon. Aparataro estas ĝisdatigita, ŝaltiloj estas interŝanĝitaj, ĉio estas konstante plibonigata. Kiel diable ili povis teni mian programon funkcianta dum du jaroj kun ĉiuj ĉi tiuj ŝanĝoj? Ĉi tio povas ŝajni modesta atingo en 2020, sed en 2005-2007 ĝi estis sufiĉe impona.
Kaj la plej mirinda aspekto estas, ke ekstera inĝenieristikteamo en iu alia ŝtato kontaktas min, la posedanto de iu eta, preskaŭ malplena ekzemplo de Bigtable, kiu havas nula trafiko dum la lastaj du jaroj - kaj proponas helpon por ĝisdatigi ĝin.
Mi dankis ilin, forigis la stokadon, kaj la vivo daŭris kiel kutime. Sed dek tri jarojn poste, mi ankoraŭ pensas pri tiu letero. Ĉar foje mi ricevas similajn retmesaĝojn de Google Cloud. Ili aspektas jene:
Kara Uzanto de Google Cloud,
Kiel memorigilo, ni ĉesigos la [esencan servon, kiun vi uzas]-servon ekde aŭgusto 2020, post kio vi ne povos ĝisdatigi viajn okazojn. Ni rekomendas ĝisdatigi al la plej nova versio, kiu estas en beta-testado, havas neniun dokumentadon, neniun migradvojon kaj estas antaŭe malmoderna kun nia afabla helpo.
Ni kompromitas certigi, ke ĉi tiu ŝanĝo havas minimuman efikon al ĉiuj uzantoj de la platformo Google Cloud.
Bonaj amikoj por ĉiam,
Google Cloud Platform
Sed mi preskaŭ neniam legas tiajn leterojn, ĉar tio, kion ili fakte diras, estas:
Kara Ricevanto,
Iru al infero. Fiku vin, fiku vin, fiku vin. Forlasu ĉion, kion vi faras, ĉar ĝi ne gravas. Gravas nia tempo. Ni malŝparas tempon kaj monon konservante nian aĉaĵon kaj ni estas lacaj de ĝi, do ni ne plu subtenos ĝin. Do forlasu viajn fiajn planojn kaj komencu trafosi nian aĉan dokumentaron, petegante pecetojn sur la forumoj, kaj cetere, nia nova merdo estas tute malsama ol la malnova merdo, ĉar ni malbonigis ĉi tiun dezajnon sufiĉe malbone, he, sed tio estas via. problemo, ne nia.
Ni daŭre klopodas por certigi, ke ĉiuj viaj evoluoj fariĝu neuzeblaj ene de unu jaro.
Bonvolu fiki
Google Cloud Platform
Kaj la fakto estas, ke mi ricevas tiajn leterojn proksimume unufoje monate. Ĉi tio okazas tiel ofte kaj tiel konstante ke ili neeviteble forpuŝita mi de GCP al la kontraŭnuba tendaro. Mi ne plu konsentas dependi de iliaj proprietaj evoluoj, ĉar fakte estas pli facile por devopoj konservi malfermfontan sistemon sur nuda virtuala maŝino ol provi daŭrigi kun Guglo kun ĝia politiko fermi "malmodernajn" produktojn.
Antaŭ ol mi revenas al Google Cloud ĉar mi eĉ ne proksime ne finite kritiki ilin, ni rigardu la agadon de la kompanio en iuj aliaj areoj. Guglo-inĝenieroj fieras pri sia programaro-inĝenieristiko, kaj ĉi tio efektive kaŭzas problemojn. Fiero estas kaptilo por neprudentaj, kaj ĝi igis multajn Guglo-dungitojn pensi, ke iliaj decidoj ĉiam pravas kaj ke pravi (laŭ neklara difino) pli gravas ol zorgi pri klientoj.
Mi donos kelkajn hazardajn ekzemplojn de aliaj grandaj projektoj ekster Guglo, sed mi esperas, ke vi vidos ĉi tiun ŝablonon ĉie. Ĝi estas kiel sekvas: retrokongruo tenas sistemojn vivaj kaj ĝisdatigitaj dum jardekoj.
Malantaŭa kongruo estas la projektcelo de ĉiuj sukcesaj sistemoj projektitaj por malfermita uzo, tio estas, efektivigita per malferma fontkodo kaj/aŭ malfermaj normoj. Mi sentas, ke mi diras ion tro evidentan, ke ĉiuj eĉ estas malkomfortaj, sed ne. Ĉi tio estas politika afero, do necesas ekzemploj.
La unua sistemo, kiun mi elektos, estas la plej malnova: GNU Emakso, kiu estas ia hibrido inter Windows Notepad, la OS-kerno, kaj la Internacia Kosmostacio. Estas iom malfacile klarigi, sed resume, Emakso estas platformo kreita en 1976 (jes, antaŭ preskaŭ duonjarcento) por programado por igi vin pli produktiva, sed maskanta kiel tekstredaktilo.
Mi uzas Emakson ĉiutage. Jes, mi ankaŭ uzas IntelliJ ĉiutage, ĝi fariĝis potenca ila platformo per si mem. Sed skribi etendaĵojn por IntelliJ estas multe pli ambicia kaj kompleksa tasko ol skribi etendaĵojn por Emakso. Kaj pli grave, ĉio skribita por Emakso estas konservita eterne.
Mi ankoraŭ uzas la programaron, kiun mi skribis por Emakso en 1995. Kaj mi certas, ke iu uzas modulojn skribitajn por Emakso meze de la 80-aj jaroj, se ne pli frue. Ili eble postulas iom da tajlado de tempo al tempo, sed ĉi tio estas vere sufiĉe malofta. Mi ne scias pri io ajn, kion mi iam verkis por Emakso (kaj mi verkis multe), kio postulis re-arkitekturon.
Emakso havas funkcion nomatan far-malaktuala por malnoviĝintaj estaĵoj. Emaksa terminologio por fundamentaj komputilaj konceptoj (kiel ekzemple kio estas "fenestro") ofte diferencas de industriaj konvencioj ĉar Emakso enkondukis ilin antaŭ longe. Ĉi tio estas tipa danĝero por tiuj, kiuj antaŭvidas sian tempon: ĉiuj viaj kondiĉoj estas malĝustaj. Sed Emakso ja havas koncepton pri malrekomendiĝo, kiu en ilia ĵargono nomiĝas malnoviĝo.
Sed en la Emaksa mondo ŝajnas esti alia labordifino. Malsama subesta filozofio, se vi volas.
En la mondo de Emakso (kaj en multaj aliaj areoj, kiujn ni traktos malsupre), malrekomendita API-statuso esence signifas: "Vi vere ne devus uzi ĉi tiun aliron, ĉar dum ĝi funkcias, ĝi suferas diversajn mankojn, kiujn ni faros. listigu ĉi tie. Sed fine de la tago, ĝi estas via elekto."
En la mondo de Google, esti malnoviĝinta signifas, "Ni malobservas nian sindevontigon al vi." Ĉi tio estas vera. Jen kion ĝi esence signifas. Ĉi tio signifas, ke ili devigos vin regule faru iom da laboro, eble multe da laboro, kiel puno por kredi je ili : Ni havas la plej bonan programaron. La plej rapida! Vi faras ĉion laŭ la instrukcioj, lanĉas vian aplikaĵon aŭ servon, kaj poste bam, post unu aŭ du jaroj ĝi rompiĝas.
Estas kiel vendi uzitan aŭton, kiu certe paneos post 1500 km.
Ĉi tiuj estas du tute malsamaj filozofiaj difinoj de "malnoviĝo". La difino de Guglo pri odoro . Mi ne kredas ĉi tion fakte planita malnoviĝo en la sama signifo kiel Apple. Sed Guglo certe planas rompi viajn programojn, en ronda maniero. Mi scias ĉi tion ĉar mi laboris tie kiel programaro-inĝeniero dum pli ol 12 jaroj. Ili havas neklarajn internajn gvidliniojn pri kiom malantaŭen kongruo devas esti sekvita, sed finfine dependas de ĉiu individua teamo aŭ servo. Ne ekzistas entreprenaj aŭ inĝenieraj nivelaj rekomendoj, kaj la plej aŭdaca rekomendo pri malnoviĝo-cikloj estas "provi doni al klientoj 6-12 monatojn por ĝisdatigi antaŭ ol rompi ilian tutan sistemon."
La problemo estas multe pli granda ol ili pensas, kaj ĝi daŭros dum venontaj jaroj ĉar klientprizorgo ne estas en ilia DNA. Pli pri ĉi tio sube.
Je ĉi tiu punkto mi faros aŭdacan deklaron ke Emakso estas sukcesa grandparte kaj eĉ esence ĉar ili prenas malantaŭen kongruecon tiel serioze. Efektive, ĉi tio estas la tezo de nia artikolo. Sukcesaj, longvivaj malfermaj sistemoj ŝuldas sian sukceson al la mikrokomunumoj, kiuj vivis ĉirkaŭ ili dum jardekoj. etendaĵoj/kromaĵoj. Ĉi tio estas la ekosistemo. Mi jam parolis pri la naturo de platformoj kaj kiom gravaj ili estas, kaj kiel Guglo neniam en sia tuta kompania historio komprenis kio okazas en kreado de sukcesa malferma platformo ekster Android aŭ Chrome.
Efektive, mi devus mencii Android mallonge ĉar vi verŝajne pensas pri ĝi.
Antaŭ ĉio, Android ne estas Guglo. Ili havas preskaŭ nenion komunan unu kun la alia. Android estas firmao, kiu estis aĉetita de Guglo en julio 2005, la firmao rajtis funkcii pli-malpli aŭtonome kaj fakte restis plejparte netuŝita en la mezaj jaroj. Androido estas fifama teknika stako kaj same fifama pika organizo. Kiel unu Googler diris, "Vi ne povas simple ensaluti en Android."
En antaŭa artikolo, mi diskutis kiom malbonaj estis kelkaj el la fruaj projektaj decidoj de Android. Heck, kiam mi skribis tiun artikolon, ili eligis aĉaĵojn nomatajn "tujajn programojn", kiuj nun estas (surprizo!) , kaj mi simpatias, se vi estus sufiĉe stulta por aŭskulti Guglon kaj movi vian enhavon al ĉi tiuj tujaj programoj.
Sed estas diferenco ĉi tie, grava diferenco, kiu estas, ke la Android-uloj vere komprenas kiom gravaj platformoj estas, ili provas sian eblon por ke malnovaj Android-aplikoj funkcias. Fakte, iliaj klopodoj konservi malantaŭan kongruecon estas tiom ekstremaj, ke eĉ mi, dum mia mallonga deĵoro ĉe la Android-dividado antaŭ kelkaj jaroj, trovis min provi konvinki ilin forigi subtenon por iuj el la plej malnovaj aparatoj kaj API-oj (mi eraris , kiel estis en multaj aliaj aferoj pasintaj kaj nunaj. Pardonu Android-uloj! Nun kiam mi estis en Indonezio, mi komprenas kial ni bezonas ilin).
La Android-homoj puŝas malantaŭen kongruon al preskaŭ neimageblaj ekstremoj, amasigante amasajn kvantojn da heredaĵa teknika ŝuldo en siaj sistemoj kaj ilĉenoj. Ho mia dio, vi devus vidi kelkajn el la frenezaj aferoj, kiujn ili devas fari en sia konstrusistemo, ĉio en la nomo de kongruo.
Pro tio, mi donas al Android la aviditan premion "Vi ne estas Guglo". Ili vere ne volas fariĝi Guglo, kiu ne scias kiel krei daŭrajn platformojn, sed Android scias, kiel fari ĝin. Kaj do Guglo estas tre inteligenta en unu rilato: permesi homojn fari aferojn siamaniere en Android.
Tamen, tujaj programoj por Android estis sufiĉe stulta ideo. Kaj ĉu vi scias kial? Ĉar ili postulis reverki kaj restrukturi vian aplikaĵon! Estas kvazaŭ homoj simple reverkos du milionojn da aplikoj. Mi supozas, ke Instant Apps estis ideo de iu Googler.
Sed estas diferenco. Malantaŭa kongruo havas altan koston. Android mem portas la ŝarĝon de ĉi tiuj kostoj, dum Guglo insistas, ke la ŝarĝo estu portita vi estas, paganta kliento.
Vi povas vidi la engaĝiĝon de Android al retrokongruo en ĝiaj APIoj. Kiam vi havas kvar aŭ kvin malsamajn subsistemojn farantaj laŭvorte la saman aferon, ĝi estas certa signo, ke ekzistas engaĝiĝo al retrokongruo ĉe la kerno. Kio en la mondo de platformoj estas sinonimo de engaĝiĝo al viaj klientoj kaj via merkato.
La ĉefa problemo de Guglo ĉi tie estas ilia fiero pri ilia inĝenieristika higieno. Ili ne ŝatas tion, kiam ekzistas multaj malsamaj manieroj fari la saman aferon, kun la malnovaj, malpli dezirindaj manieroj sidantaj apud la novaj, pli ŝatataj manieroj. Ĝi pliigas la lernkurbon por tiuj novaj en la sistemo, ĝi pliigas la ŝarĝon de konservado de heredaj API-oj, ĝi malrapidigas la rapidecon de novaj funkcioj, kaj la ĉefa peko estas, ke ĝi ne estas bela. Guglo - kiel Lady Ascot el Alico en Mirlando de Tim Burton:
Sinjorino Ascot:
- Alicio, ĉu vi scias, kion mi plej timas?
- La malkresko de la aristokrataro?
- Mi timis, ke mi havus malbelaj genepoj.
Por kompreni la kompromison inter bela kaj praktika, ni rigardu la trian sukcesan platformon (post Emakso kaj Android) kaj vidu kiel ĝi funkcias: Java mem.
Java havas multajn malmodernajn APIojn. Malrekomendiĝo estas tre populara inter Java-programistoj, eĉ pli populara ol en la plej multaj programlingvoj. Java mem, la kernlingvo, kaj la bibliotekoj konstante malrekomendas APIojn.
Por preni nur unu el miloj da ekzemploj, konsiderata malnoviĝinta. Ĝi estis malrekomendita ekde la liberigo de Java 1.2 en decembro 1998. Pasis 22 jaroj de kiam tio estis malrekomendita.
Sed mia reala kodo en produktado ankoraŭ mortigas fadenojn ĉiutage. Ĉu vi vere opinias, ke tio estas bona? Absolute! Mi volas diri, kompreneble, se mi reverkus la kodon hodiaŭ, mi efektivigus ĝin alimaniere. Sed la kodo por mia ludo, kiu feliĉigis centojn da miloj da homoj dum la lastaj du jardekoj, estas skribita kun funkcio por fermi fadenojn kiuj pendas tro longe, kaj mi neniam devis ŝanĝi ĝin. Mi konas mian sistemon pli bone ol iu ajn, mi havas laŭvorte 25 jarojn da sperto laboranta kun ĝi en produktado, kaj mi povas diri certe: en mia kazo, fermi ĉi tiujn specifajn laborfadenojn estas tute. sendanĝera. Ne valoras la tempon kaj penon reverki ĉi tiun kodon, kaj danki Larry Ellison (verŝajne) ke Orakolo ne devigis min reverki ĝin.
Oracle verŝajne ankaŭ komprenas platformojn. Kiu scias.
Indico povas esti trovita ĉie en la kernaj Java APIoj, kiuj estas truitaj per ondoj de malnoviĝo, kiel la linioj de glaĉero en kanjono. Vi povas facile trovi kvin aŭ ses malsamajn klavarajn navigaciajn administrantojn (KeyboardFocusManager) en la biblioteko de Java Swing. Estas fakte malfacile trovi Java API kiu ne estas malrekomendita. Sed ili ankoraŭ funkcias! Mi pensas, ke la Java teamo nur vere forigos API se la interfaco prezentas evidentan sekurecan problemon.
Jen la afero, homoj: ni programistoj estas ĉiuj tre okupataj, kaj en ĉiu areo de programaro ni alfrontas konkurantajn alternativojn. En ajna momento, programistoj en lingvo X konsideras lingvon Y kiel ebla anstataŭaĵo. Ho, vi ne kredas min? Ĉu vi volas nomi ĝin Swift? Kiel, ĉiuj migras al Swift kaj neniu forlasas ĝin, ĉu ne? Ve, kiom malmulte vi scias. Firmaoj kalkulas la kostojn de duoblaj poŝtelefonaj evoluteamoj (iOS kaj Android) - kaj ili ekkomprenas, ke tiuj transplatformaj evolusistemoj kun amuzaj nomoj kiel Flutter kaj React Native efektive funkcias kaj povas esti uzataj por redukti la grandecon de siaj. moveblaj teamoj dufoje aŭ, male, igas ilin duoble pli produktivaj. Estas reala mono en ludo. Jes, estas kompromisoj, sed, aliflanke, mono.
Ni supozu hipoteze, ke Apple stulte prenis signalon de Guido van Rossum kaj deklaris, ke Swift 6.0 estas malantaŭen nekongrua kun Swift 5.0, same kiel Python 3 estas nekongrua kun Python 2.
Mi verŝajne rakontis ĉi tiun historion antaŭ proksimume dek jaroj, sed antaŭ proksimume dek kvin jaroj mi iris al Foo Camp de O'Reilly kun Guido, sidis en tendo kun Paul Graham kaj amaso da grandaj pafoj. Ni sidis en la sufoka varmego atendante ke Larry Page elflugus en sia persona helikoptero dum Guido dronis pri "Python 3000", kiun li nomis laŭ la nombro da jaroj necesas por ĉiuj migri tien. Ni daŭre demandis lin kial li rompis kongruecon, kaj li respondis: "Unikodo." Kaj ni demandis, se ni devus reverki nian kodon, kiajn aliajn avantaĝojn ni vidus? Kaj li respondis "Yooooooooooooooouuuuuuuniiiiiiicoooooooode."
Se vi instalas la SDK de Google Cloud Platform ("gcloud"), vi ricevos la jenan sciigon:
Kara Ricevanto,
Ni ŝatus memorigi al vi, ke subteno por Python 2 estas malrekomendita, do fiku vin
… kaj tiel plu. Rondo de vivo.
Sed la afero estas, ke ĉiu programisto havas elekton. Kaj se vi devigas ilin reverki kodon sufiĉe ofte, ili eble pripensos aliaj opcioj. Ili ne estas viaj ostaĝoj, kiom ajn vi eble volas, ke ili estu. Ili estas viaj gastoj. Python estas ankoraŭ tre populara programlingvo, sed damne, Python 3(000) kreis tian ĥaoson en si mem, en siaj komunumoj kaj inter la uzantoj de ĝiaj komunumoj, ke la sekvoj ne estas klarigitaj dum dek kvin jaroj.
Kiom da Python-programoj estis reverkitaj en Go (aŭ Ruby, aŭ iu alia alternativo) pro ĉi tiu malantaŭa nekongruo? Kiom da nova programaro estis skribita en io alia ol Python, kvankam ĝi povus esti skribita en Python, se Guido ne estus forbruligis la tutan vilaĝon? Estas malfacile diri, sed Python klare suferis. Estas grandega malordo kaj ĉiuj perdas.
Do ni diru, ke Apple prenas signalon de Guido kaj rompas kongruon. Kion vi pensas okazos poste? Nu, eble 80-90% de programistoj reverkos sian programaron se eble. Alivorte, 10-20% de la uzantbazo aŭtomate iras al iu konkuranta lingvo, kiel Flutter.
Faru tion plurfoje kaj vi perdos duonon de via uzantbazo. Same kiel en sporto, en la mondo de programado gravas ankaŭ aktuala formo. ĉio. Ĉiu, kiu perdas duonon de siaj uzantoj en kvin jaroj, estos konsiderata Granda Grasa Perdanto. Vi devas esti laŭmoda en la mondo de platformoj. Sed ĉi tie ne subteni pli malnovajn versiojn ruinigos vin kun la tempo. Ĉar ĉiufoje kiam vi forigas iujn programistojn, vi (a) perdas ilin por ĉiam, ĉar ili koleras kontraŭ vi pro tio, ke vi rompis la kontrakton, kaj (b) fordonas ilin al viaj konkurantoj.
Ironie, mi ankaŭ helpis Guglon fariĝi tia primadono, kiu ignoras malantaŭan kongruecon, kiam mi kreis Grok, fontkodan analizon kaj komprensistemon, kiu faciligas aŭtomatigi kaj instrumentigi la kodon mem - simile al IDE, sed ĉi tie la nuba servo butikoj. materiigis reprezentadojn de ĉiuj miliardoj da linioj de Guglo fontkodo en granda datumstokejo.
Grok provizis Googlers per potenca kadro por plenumi aŭtomatigitaj refactorings tra ilia tuta kodbazo (laŭvorte ĉie en Guglo). La sistemo kalkulas ne nur viajn kontraŭfluajn dependecojn (de kiuj vi dependas), sed ankaŭ malsupreniranta (kiuj dependas de vi) do kiam vi ŝanĝas API-ojn, vi konas ĉiujn, kiujn vi rompas! Tiel, kiam vi faras ŝanĝojn, vi povas kontroli, ke ĉiu konsumanto de via API ĝisdatigis al la nova versio, kaj fakte, ofte per la Rosie-ilo, kiun ili skribis, vi povas tute aŭtomatigi la procezon.
Ĉi tio ebligas al la kodbazo de Guglo esti interne preskaŭ supernature pura, ĉar ili havas ĉi tiujn robotajn servistojn kuregante ĉirkaŭ la domo kaj aŭtomate purigi ĉion, se ili renomis SomeDespicablyLongFunctionName al SomeDespicablyLongMethodName ĉar iu decidis, ke ĝi estas malbela nepo kaj liaj bezonoj esti endormigitaj.
Kaj sincere, ĝi funkcias sufiĉe bone por Guglo... interne. Mi volas diri, jes, la Go-komunumo ĉe Google ja bone ridas kun la Java-komunumo ĉe Guglo pro sia kutimo de kontinua refaktorado. Se vi rekomencas ion N-foje, tio signifas, ke vi ne nur malŝraŭbis ĝin N-1 fojojn, sed post iom da tempo evidentiĝas, ke vi verŝajne fuŝis ĝin ankaŭ je la N-a provo. Sed, ĝenerale, ili restas antaŭ ĉio ĉi tiu tumulto kaj tenas la kodon "pura".
La problemo komenciĝas kiam ili provas trudi ĉi tiun sintenon al siaj nubaj klientoj kaj uzantoj de aliaj API-oj.
Mi iomete konigis al vi Emakson, Androidon kaj Java; ni rigardu la plej novan sukcesan longvivan platformon: la Reto mem. Ĉu vi povas imagi kiom da ripetoj HTTP trapasis ekde 1995 kiam ni uzis fulmajn etikedojn? kaj "Konstruo" ikonoj sur retpaĝoj.
Sed ĝi ankoraŭ funkcias! Kaj ĉi tiuj paĝoj ankoraŭ funkcias! Jes, infanoj, retumiloj estas la mondĉampionoj en retrokongruo. Chrome estas alia ekzemplo de la malofta Google-platformo, kiu havas siajn kapojn ĝuste ŝraŭbitaj, kaj kiel vi eble divenis, Chrome efike funkcias kiel sablokesita firmao aparta de la resto de Guglo.
Mi ankaŭ volas danki niajn amikojn en la programistoj de operaciumoj: Vindozo, Linukso, NOT APPLE FUCK YOU APPLE, FreeBSD, ktp., pro tio, ke ili faris tiel bonegan laboron de retrokongruo en iliaj sukcesaj platformoj (Apple ricevas C en la plej bona kazo kun The malavantaĝo estas, ke ili rompas ĉion la tutan tempon sen bona kialo, sed iel la komunumo ĉirkaŭiras ĝin kun ĉiu eldono, kaj OS X-ujo ankoraŭ ne estas tute malnoviĝintaj... ankoraŭ).
Sed atendu, vi diras. Ĉu ni ne komparas pomojn kun oranĝoj - memstaraj programaj sistemoj sur ununura maŝino kiel Emakso/JDK/Android/Chrome kontraŭ plur-servilaj sistemoj kaj API-oj kiel nubaj servoj?
Nu, pri tio mi tutis hieraŭ, sed laŭ la stilo de Larry Wall (kreinto de la programlingvo Perl - ĉ. po.) laŭ la principo "suĉas/reguloj" mi serĉis la vorton. senkulpigita en la retejoj por programistoj de Google kaj Amazon. Kaj kvankam AWS havas centoj oble pli da servofertoj ol GCP, la dokumentaro pri programisto de Guglo mencias malrekomendiĝon proksimume sep fojojn pli ofte.
Se iu ĉe Guglo legas ĉi tion, ili verŝajne pretas eltiri Donald Trump-stilan diagramojn montrante ke ili efektive faras ĉion ĝuste, kaj ke mi ne devus fari maljustajn komparojn kiel "nombro da mencioj de la vorto malrekomendita kontraŭ nombro da servoj" "
Sed post ĉiuj ĉi tiuj jaroj, Google Cloud daŭre estas la numero 3-servo (mi neniam skribis artikolon pri la malsukcesa provo fariĝi numero 2), sed se kredindas al internuloj, estas iuj zorgoj, ke ili baldaŭ povus fali al. n-ro 4.
Mi ne havas konvinkajn argumentojn por "pruvi" mian tezon. Ĉio, kion mi havas, estas la buntaj ekzemploj, kiujn mi amasigis dum 30 jaroj kiel programisto. Mi jam menciis la profunde filozofian naturon de tiu ĉi problemo; iel ĝi estas politikigita en programkomunumoj. Iuj kredas tion kreintoj platformoj devus zorgi pri kongruo, dum aliaj opinias, ke tio estas zorgo uzantoj (la programistoj mem). Unu el du. Efektive, ĉu ne estas politika afero, kiam ni decidas, kiu devas pagi la kostojn de komunaj problemoj?
Do ĉi tio estas politiko. Kaj verŝajne estos koleraj respondoj al mia parolado.
Kiel la uzanto Google Cloud Platform, kaj kiel AWS-uzanto dum du jaroj (dum laboro por Grab), mi povas diri, ke estas grandega diferenco inter Amazon kaj la filozofioj de Google kiam temas pri prioritatoj. Mi ne aktive evoluas ĉe AWS, do mi ne tre bone scias kiom ofte ili forigas malnovajn APIojn. Sed ekzistas suspekto, ke ĉi tio ne okazas preskaŭ tiel ofte kiel ĉe Guglo. Kaj mi vere kredas, ke ĉi tiu fonto de konstanta diskutado kaj frustriĝo en GCP estas unu el la plej grandaj faktoroj bremsantaj la disvolviĝon de la platformo.
Mi scias, ke mi ne nomis specifajn ekzemplojn de GCP-sistemoj, kiuj ne plu estas subtenataj. Mi povas diri, ke preskaŭ ĉio, kion mi uzis, de retoj (de la plej malnova ĝis VPC) ĝis stokado (Cloud SQL v1-v2), Firebase (nun Firestore kun tute malsama API), App Engine (ni eĉ ne komencu) , nubaj finpunktoj Cloud Endpoint kaj ĝis... mi ne scias - absolute ĉio ĉi devigis vin reverki la kodon post maksimume 2-3 jaroj, kaj ili neniam aŭtomatigis la migradon por vi, kaj ofte . Kvazaŭ ĝi devus esti tiel.
Kaj ĉiufoje kiam mi rigardas AWS, mi demandas min kial diable mi ankoraŭ estas sur GCP. Ili klare ne bezonas klientojn. Ili bezonas aĉetantoj. Ĉu vi komprenas la diferencon? Lasu min klarigi.
Google Cloud havas , kie homoj proponas siajn softvarsolvojn, kaj por eviti la malplenan restoracio-efekton, ili bezonis plenigi ĝin per kelkaj proponoj, do ili kontraktis kun firmao nomita Bitnami por krei aron da solvoj kiuj estas deplojitaj per "unu klako", aŭ devus. Mi skribas ĝin mem "solvoj", ĉar ĉi tiuj ne solvas malbenitan aferon. Ili simple ekzistas kiel markobutonoj, kiel merkatiga plenigaĵo, kaj Guglo neniam zorgis ĉu iu el la iloj efektive funkcias. Mi konas produktmanaĝerojn, kiuj estis en la ŝoforo, kaj mi povas certigi vin, ke ĉi tiuj homoj ne zorgas.
Prenu, ekzemple, supozeble "unu-klaka" disfalda solvo. . Mi estis malsana al morto de Google Cloud SQL-ŝelaĵoj, do mi komencis rigardi konstrui mian propran Percona areton kiel alternativon. Kaj ĉi-foje Guglo ŝajnis fari bonan laboron, ili ŝparos al mi iom da tempo kaj peno per la klako de butono!
Nu bonege, ni iru. Ni sekvu la ligilon kaj alklaku ĉi tiun butonon. Elektu "Jes" por konsenti pri ĉiuj defaŭltaj agordoj kaj disfaldi la areton en via Google-nuba projekto. Haha, ĝi ne funkcias. Neniu el ĉi tiu aĉaĵo funkcias. La ilo neniam estis provita kaj ĝi komencis putri de la unua minuto, kaj ne surprizus min se pli ol duono de la "solvoj" estas unu-klakaj deplojoj (nun ni komprenas kial la citaĵoj) ĝenerale ne funkcias. Ĉi tio estas absolute senespera mallumo, kie estas pli bone ne eniri.
Sed Guglo pravas kuraĝigas vi uzi ilin. Ili volas, ke vi aĉetis. Por ili ĝi estas transakcio. Ili volas nenion subteno. Ĝi ne estas parto de la DNA de Guglo. Jes, inĝenieroj subtenas unu la alian, kiel pruvas mia rakonto kun Bigtable. Sed en produktoj kaj servoj por ordinaraj homoj ili ĉiam estis senkompataj en , kiu ne renkontas la stangon por profiteco eĉ se ĝi havas milionojn da uzantoj.
Kaj ĉi tio prezentas veran defion por GCP ĉar ĉi tio estas la DNA malantaŭ ĉiuj nubaj proponoj. Ili ne provas subteni ion; Estas konate, ke ili rifuzas gastigi (kiel administrita servo) ajnan trian programon ĝis, ĝis AWS faras la samon kaj konstruas sukcesan komercon ĉirkaŭ ĝi, kaj kiam klientoj laŭvorte postulas la samon. Tamen necesas iom da penado por ke Google subtenu ion.
Ĉi tiu manko de subteno-kulturo, kunligita kun la "ni rompu ĝin por plibeligi ĝin", fremdigas programistojn.
Kaj tio ne estas bona afero, se vi volas konstrui longvivan platformon.
Guglo, vekiĝu, diablo. Estas 2020 nun. Vi ankoraŭ perdas. Estas tempo rigardi al la spegulo kaj respondi ĉu vi vere volas resti en la nuba komerco.
Se vi volas resti tiam ĉesu rompi ĉion. Knaboj, vi estas riĉaj. Ni programistoj ne faras. Do kiam temas pri kiu portos la ŝarĝon de kongruo, vi devas preni ĝin sur vin mem. Ne por ni.
Ĉar estas almenaŭ tri pliaj vere bonaj nuboj. Ili mansvingas.
Kaj nun mi daŭrigos ripari ĉiujn miajn rompitajn sistemojn. Eh.
Ĝis la venonta tempo!
PS Ĝisdatigo post legi kelkajn el la diskutoj pri ĉi tiu artikolo (la diskutoj estas bonegaj, btw). Firebase-subteno ne estis ĉesigita kaj ne ekzistas planoj pri kiuj mi konscias. Tamen, ili havas malbonan fluan cimon, kiu igas la Java-klienton ekhalti en App Engine. Unu el iliaj inĝenieroj helpis min solvi ĉi tiun problemon, kiam mi laboris ĉe Guglo, sed ili neniam efektive riparis la cimon, do mi havas aĉan solvon de devi rekomenci la GAE-apon ĉiutage. Kaj tiel estis dum kvar jaroj! Ili nun havas Firestore. Necesos multe da laboro por migri al ĝi ĉar ĝi estas tute malsama sistemo kaj la Firebase-cimo neniam estos riparita. Kian konkludon oni povas tiri? Vi povas ricevi helpon se vi laboras en firmao. Verŝajne mi estas la sola kiu uzas Firebase sur GAE ĉar mi ensalutas malpli ol 100 ŝlosilojn en 100% denaska aplikaĵo kaj ĝi ĉesas funkcii ĉiujn du tagojn pro konata cimo. Kion mi povas diri krom uzi ĝin je via propra risko. Mi ŝanĝas al Redis.
Mi ankaŭ vidis kelkajn pli spertajn uzantojn de AWS diri, ke AWS kutime neniam ĉesas subteni iujn ajn servojn, kaj SimpleDB estas bonega ekzemplo. Miaj supozoj, ke AWS ne havas la saman finon de subtenmalsano kiel Guglo ŝajnas esti pravigitaj.
Aldone, mi rimarkis, ke antaŭ 20 tagoj la teamo de Google App Engine rompis la gastigadon de kritika Go-biblioteko, fermante GAE-aplikaĵon de unu el la kernaj Go-programistoj. Ĝi estis vere stulta.
Fine, mi aŭdis, ke Guglantoj jam diskutis ĉi tiun aferon kaj ĝenerale konsentas kun mi (ami vin!). Sed ili ŝajnas pensi, ke la problemo estas nesolvebla ĉar la kulturo de Guglo neniam havis la ĝustan instigan strukturon. Mi pensis, ke estus bone preni iom da tempo por diskuti la absolute mirindan sperton, kiun mi havis laborante kun AWS-inĝenieroj dum mi laboris ĉe Grab. Iun tagon estonte, mi esperas!
Kaj jes, en 2005 ili ja havis malsamajn specojn de ŝarka viando sur la giganta bufedo en konstruaĵo 43, kaj mia plej ŝatata estis la martelkapa ŝarka viando. Tamen, antaŭ 2006, Larry kaj Sergei forigis ĉiujn nesanajn etmanĝaĵojn. Do dum la rakonto de Bigtable en 2007 vere ne estis ŝarkoj kaj mi trompis vin.
Kiam mi rigardis nubon Bigtable antaŭ kvar jaroj (donu aŭ prenu), ĉi tie estis la kosto. Ŝajnas, ke nun iom malpliiĝis, sed tio ankoraŭ estas terura multe por malplena datumstokejo, precipe ĉar mia unua rakonto montras kiom malgrava estas malplena granda tablo laŭ ilia skalo.
Pardonu pro ofendi la komunumon de Apple kaj ne diri ion belan pri Microsoft ktp. Vi estas en ordo, mi tre dankas la tutan diskuton, kiun ĉi tiu artikolo estigis! Sed foje oni bezonas iom ondodi por komenci diskuton, ĉu vi scias?
Dankon pro legado.
Ĝisdatigo 2, 19.08.2020/XNUMX/XNUMX. Strio !
Ĝisdatigo 3, 31.08.2020/2/2. Mi estis kontaktita de Google-inĝeniero ĉe Cloud Marketplace, kiu montriĝis esti malnova amiko mia. Li volis eltrovi kial CXNUMXD ne funkciis, kaj ni finfine eltrovis, ke ĝi estas ĉar mi konstruis mian reton antaŭ jaroj, kaj CXNUMXD ne laboris en heredaĵaj retoj ĉar la subreto-parametro mankis en iliaj ŝablonoj. Mi pensas, ke estas plej bone por eblaj GCP-uzantoj certigi, ke ili konas sufiĉe da inĝenieroj ĉe Guglo...
fonto: www.habr.com