Për hir të Zotit, Google, nuk doja të shkruaja përsëri në blog. Kam kaq shumë për të bërë. Të shkruash një blog kërkon kohë, energji dhe kreativitet që do t'i shfrytëzoja më mirë për: librat e mi, , lojën time dhe kështu me radhë. Por më theve mjaft nervat, dhe do të duhet ta shkruaj këtë.
Pra, le ta përfundojmë këtë.
Do të filloj me një histori të vogël, por mësuese nga koha kur fillova të punoj në Google. E di që kohët e fundit kam thënë shumë gjëra të këqija për Google, por më shqetëson kur kompania ime e dashur merr rregullisht vendime biznesi të papërgjegjshme. Sidoqoftë, duhet t'i jepet merita: infrastruktura e brendshme e Google është me të vërtetë ekzotike, mund të thuhet me siguri se sot nuk ka asgjë më të mirë. Themeluesit e Google ishin shumë inxhinierë më të mirë se sa do të bëhem ndonjëherë, dhe kjo histori vetëm e konfirmon këtë fakt.
Fillimisht pak histori: Google ka një teknologji ruhaje të dhënash të quajtur . Kjo ishte një arritje teknike e shkëlqyer, një nga të parat (nëse jo e para) ruajtje e "pa fund" e çifteve "çelës-vlerë" (key-value store, K/V): në thelb, fillimi i NoSQL. Në ditët e sotme Bigtable është ende shumë mirë në një hapësirë mjaft të mbushur me ruajtje K/V, por në atë kohë (viti 2005) ishte jashtëzakonisht e madhe.
Një detaj interesant për Bigtable është se ata kishin objekte të brendshme të planeve të menaxhimit (si pjesë e zbatimit) të quajtur serverë tablet, me indekse të konsiderueshme, dhe në një moment ata u bënë pika e ngushtë e shkallëzimit të sistemit. Inxhinierët e Bigtable po mërziteshin për mënyrën se si të realizonin shkallëzimin dhe papritmas kuptuan se mund të zëvendësonin serverët tablet me ruajtje të tjera Bigtable. Pra, Bigtable është një pjesë e zbatimit të Bigtable. Këto ruajtje janë atje në të gjitha nivelet.
një detaj tjetër interesant është se për një kohë Bigtable u bënë të njohura dhe të pranishme brenda Google, dhe çdo ekip kishte depo të tij. Prandaj, në një nga mbledhjet e së premtes, Larry Page e pyeti me pak kujdes: "Pse kemi më shumë se një Bigtable? Pse nuk mjafton vetëm një?" Teoretikisht, një depo do të mjaftonte për të gjitha nevojat e magazinimit të Google. Sigurisht, ata kurrë nuk kaluan vetëm në një për arsye praktike zhvillimi (p.sh., pasojat e një përçarjeje potenciale), por teoria ishte interesante. Një depo për të gjithë universin (, për rastin, dikush e di, a e bëri Amazon këtë me Sable e saj?)
Pavarësisht kësaj, këtu është historia ime.
Në atë kohë kisha punuar në Google për pak më shumë se dy vjet, dhe një ditë më erdhi një email nga ekipi inxhinierik i Bigtable me një përmbajtje të tillë:
I dashur Steve,
Përshëndetje nga ekipi i Bigtable. Dëshirojmë të ju informojmë se në qendrën e të dhënave [emri i qendrës së të dhënave] po përdorni një skedar binar Bigtable shumë, shumë të vjetëruar. Kjo version nuk mbështetet më dhe dëshirojmë t'ju ndihmojmë të kaloni në versionin më të fundit.
Ju lutem, na njoftoni nëse mund të planifikoni pak kohë për të punuar së bashku mbi këtë çështje.
Të gjitha të mirat,
Ekipi i Bigtable
Në Google, ju vijnë shumë emaile, andaj që nga shikimi i parë e lexova përafërsisht kështu:
I dashur marrës,
Përshëndetje nga ndonjë ekip. Dëshirojmë të ju informojmë që bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, dhe bla-bla-bla menjëherë.
Ju lutem, na njoftoni nëse mund të planifikoni një pjesë të kohës suaj të çmuar për bla-bla-bla.
Të gjitha të mirat,
Një ekip i caktuar
Po e fshija pothuajse menjëherë, por në kufijtë e vetëdijes ndjeva një ndjesi të rëndë dhe të dhimbshme se nuk ishte krejtësisht si një letër formale, megjithatë eshte e qarte, se e kishin gabim me marrësin, pasi unë nuk e përdorja Bigtable.
Por, kjo ishte e çuditshme.
Pjesa tjetër e ditës e kalova duke menduar në mënyrë të alternuar për punën dhe për cilin lloj mishi peshkaqeni të provoj në mikro-kuzhinë, nga të cilat së paku tre ishin mjaft afër për t'u goditur me një goditje të shkëlqyer biskotë nga vendi im, por mendimi për emailin nuk më la me një ndjenjë në rritje të shqetësimit të lehtë.
Ata e quartë përmendi emrin tim. Dhe letra është dërguar në adresën time të postës elektronike, e jo në dikë tjetër, dhe kjo nuk është në cc: ose bcc:. Toni është shumë personal dhe i qartë. A mund të jetë një gabim ndonjëherë?
Më në fund, kureshtja merr mbi dorë dhe unë shkoj të shoh konsolën Borg në qendrën e të dhënave që ata përmendën.
Dhe sigurisht, unë kam pasur në menaxhim një depo BigTable. Çfarë? E shikoja përmbajtjen e saj, dhe – ma merr mendja! Ajo ishte nga inkubatori Codelab, ku isha ulur javën e parë të punës time në Google në qershor 2005. Codelab të detyronte të aktivizosh Bigtable, që të regjistroje disa vlera, dhe duket se nuk e kam mbyllur depozitin pas kësaj. Ajo ende punonte, megjithëse kishin kaluar më shumë se dy vjet.
Në këtë histori ka disa aspekte të shquara. Së pari, funksionimi i Bigtable ishte aq i papërfillshëm në masën e Google, sa që vetëm pas dy vjetësh dikush e vuri re depozitën e tepërt, dhe gjithashtu vetëm sepse versioni i binarit kishte skaduar. Për të bërë një krahasim, njëherë kisha shqyrtuar mundësinë e përdorimit për lojën time online. Në atë kohë, ky shërbim kushtonte rreth $16,000 në vit për një depo të zbrazët Bigtable në GCP. Nuk po them se ata ju mashtrojnë, por sipas mendimit tim personal, kjo është një shumë e madhe për një bazë të dhënash të zbrazët.
Një tjetër aspekt i shquar është se depoja ka funksionuar ende pas dy vjetësh. WTF? Qendrat e të dhënave vijnë dhe shkojnë; ato hasin ndërprerje, kalojnë në mirëmbajtje të planifikuar, ato ndryshojnë vazhdimisht. Hardueri përmirësohet, switch-at ndryshojnë vendet, gjithçka vazhdimisht përmirësohet. Si, më dreq, ata arritën ta mbajnë programin tim të aktivizuar për dy vjet duke marrë parasysh këto ndryshime? Mund të duket si një arritje modeste në vitin 2020, por nga 2005-2007 ishte vërtet impresionuese.
Dhe aspekti më i mrekullueshëm është se një ekip inxhinierësh të huaj në një shtet tjetër më kontakton, pronar i një ekzemplari të vogël, praktikisht të zbrazët të Bigtable, i cili ka trafik zero për dy vitet e fundit – dhe ofron asistencë për ta përditësuar atë.
I falënderova ata, e fshiva depoziten dhe jeta vazhdoi si zakonisht. Por së bashku me trembëdhjetë vjet tani, unë ende po mendoj për këtë letër. Sepse ndonjëherë më vijnë letra të ngjashme nga Google Cloud. Ato duken kështu:
I dashur përdorues i Google Cloud,
Kujtojmë se ne do të ndërpresim shërbimin e [shërbimit të rëndësishëm që po përdorni] që nga gushti 2020, pas të cilit nuk do të jeni në gjendje të përditësoni instancat tuaja. Ju rekomandojmë të kaloni në versionin e fundit, i cili është duke u testuar në beta, nuk ka asnjë dokumentacion, asnjë rrugë migrimi dhe që ka skaduar paraprakisht me ndihmën tonë të mirë.
Ne arrijmë që ky ndryshim të ndikojë minimalisht te të gjithë përdoruesit e platformës Google Cloud.
Mik të përjetshëm,
Platforma e cloud-it Google
Por unë pothuajse nuk i lexoj kështu letra, sepse në të vërtetë ato thonë këtë:
I dashur marrës,
Shko në ferr. Shko, shko, shko. Hidh gjithçka që po bën, sepse nuk ka rëndësi. Çfarë ka rëndësi është koha jonë. Ne po shpenzojmë kohë dhe para për të mbështetur gjërat tona, dhe jemi lodhur nga kjo, prandaj nuk do ta mbështesim më. Pra, lëre planin tënd të qorr, dhe fillo të gërmosh në dokumentacionin tonë të ndyrë, duke kërkuar mbetje në forume, dhe, për rastin e fatit, gjërat tona të reja ndryshojnë plotësisht nga ato të vjetrat, sepse ne e shkatërruam disi këtë dizajn, hehe, por kjo është problemi yt, jo ynë.
Ne vazhdojmë të bëjmë përpjekje që të gjitha zhvillimet e tua të bëhen të papërdorshme brenda një viti.
Të lutem shko në ferr,
Platforma e cloud-it Google
Dhe e vërteta është se marr letra të tilla rreth një herë në muaj. Ato ndodhin aq shpesh dhe aq vazhdimisht, sa që ata përfundimisht më larguan nga GCP në kampin e kundërshtarëve të cloud-it. Nuk jam më dakord të varem nga zhvillimet e tyre pronarë, sepse në të vërtetë devops është më e lehtë të mbështesë një sistem me burim të hapur në një virtualizim të pastër, sesa të përpiqem të arrij Google me politikën e saj të mbylljes së produkteve 'të vjetra'.
Para se të rikthehem te Google Cloud, sepse unë madje gjysmë nukë e përfundoi kritikën e tij, le të shohim punën e kompanisë në disa fusha të tjera. Inxhinierët e Google krenohen me disiplinën e tyre në zhvillimin e softuerit, dhe kjo në të vërtetë krijon probleme. Krenaria është një kurth për të papërgjegjshmit, e cila i ka bërë shumë punonjës të Google të mendojnë se zgjidhjet e tyre janë gjithmonë të sakta dhe se saktësia (sipër një definicioni të pasigurt) është më e rëndësishme se pretendimi për klientët.
Do të jap disa shembuj të rastësishëm nga projekte të tjera të mëdha jashtë Google, por shpresoj se do të shihni këtë model kudo. Ai përqendrohet në këtë: kompatibiliteti prapa mbështet jetëgjatësinë dhe relevancën e sistemeve për dekada.
Kompatibiliteti prapa është një qëllim i projektimit të të gjithë sistemeve të suksesshme, të destinuara për përdorim të hapur, domethënë të realizuara me burim të hapur dhe / ose në standarde të hapura. Ndjehem se po them diçka tepër të dukshme, që të gjithë e dinë, por jo. Ky është një çështje politike, prandaj nevojiten shembuj.
Sistemi i parë që do të zgjedh, është më i vjetër: GNU Emacs, është një lloj hibridi midis Notebook Windows, bërthamës së OS dhe Stacionit Ndërkombëtar të Hapësirës. Është pak e vështirë për ta shpjeguar, por në dy fjalë Emacs - është një platformë e krijuar në vitin 1976 (po, pothuajse pesëdhjetë vjet më parë) për programim, për të rritur produktivitetin tuaj, por maskohet si një redaktues teksti.
E përdor Emacs çdo ditë të Zotit. Po, gjithashtu përdor IntelliJ çdo ditë, ajo tashmë është shndërruar në një platformë të fuqishme mjetesh. Por shkruarja e zgjatjeve për IntelliJ është një detyrë shumë më ambicioze dhe më e komplikuar se sa shkruarja e zgjatjeve për Emacs. Dhe çka është edhe më e rëndësishme, çdo gjë e shkruar për Emacs ruhet përherë..
Ende po përdor software që kam shkruar për Emacs që nga viti 1995. Dhe jam i sigurt se dikush po përdor module, të shkruara për Emacs në mesin e viteve '80, nëse jo më herët. Nga koha në kohë ato mund të kërkojnë ndonjë përshtatje të vogël, por kjo në të vërtetë ndodh shumë rrallë. Nuk di asgjë prej atyre që kam shkruar ndonjëherë për Emacs (dhe kam shkruar shumë), që ka pasur nevojë të riprojektosh arkitekturën.
Në Emacs ka një funksion të quajtur make-obsolete për entitetet e skaduara. Terminologjia e Emacs për konceptet themelore kompjuterike (për shembull, çfarë është një "dritare") shpesh ndryshon nga ritshikat industriale, sepse Emacs i ka futur ato shumë kohë më parë. Kjo është një rrezik tipik për ata që e kanë kaluar kohën e tyre: të gjitha termet tuaja janë të pasakta. Por në Emacs ka vërtet një koncept të skadimit, i cili në zhargonin e tyre quhet skadim.
Por në botën e Emacs, duket se ka një definicion të ndryshëm funksional. Një filozofi tjetër themelore, nëse doni.
Në botën e Emacs (dhe në shumë fusha të tjera që do të shqyrtojmë më poshtë) statusi i API-ve të skaduara në masë të madhe do të thotë: "Vërtet nuk duhet ta përdorni këtë qasje, sepse, ndonëse funksionon, ajo vuante nga mangësi të ndryshme, të cilat do t'i listojmë këtu. Por, në fund të ditës, zgjedhja është e juaja."
Në botën e Google, statusi i një produkti të skaduar do të thotë: "Ne po shkelim detyrimet tona ndaj jush." Kjo është vërtet e vërtetë. Këtu është se çfarë do të thotë në thelb. Kjo do të thotë se ata do t'ju detyrojnë regullisht të bëni një punë, ndoshta një punë të madhe, si ndëshkim për atë që besuat në reklamat e tyre : kemi softuerin më të mirë. Më të shpejtin! Ju bëni gjithçka sipas udhëzimeve, aktivizoni aplikacionin ose shërbimin tuaj, dhe më pas — bam, pas një viti ose dy, ajo prishet.
Kjo është si të shesësh një makinë të përdorur, e cila me siguri do të prishë pas 1500 km.
Këto janë dy përkufizime tërësisht të ndryshme filosofike të "skadimit". Përcaktimi i Google-t ka aromë . Nuk besoj se është në të vërtetë skadim i planifikuar në të njëjtën kuptim si Apple. Por Google me siguri planifikon të prishë programet tuaja, në një mënyrë indirekte. E di këtë, sepse kam punuar si inxhinier programi atje për më shumë se 12 vjet. Ata kanë rekomandime të paqarta të brendshme se deri në çfarë mase duhet të respektojnë përputhshmëritë e kundërta, por në fund të fundit, kjo varet nga çdo ekip ose shërbim i veçantë. Nuk ka rekomandime të nivelit korporativ ose inxhinierik, dhe rekomandimi më i guximshëm nga pikëpamja e cikleve të skadimit është "provoni t'u jepni klientëve 6-12 muaj për të përditësuar, para se të prishni tërë sistemin e tyre."
Problemi është shumë më serioz se sa mendojnë ata, dhe do të vazhdojë për shumë vite, sepse kujdesi ndaj klientëve nuk është në ADN-në e tyre. Më shumë rreth kësaj më poshtë.
Në këtë moment, po bëj një pohim guximtar se Emacs është në masë të madhe i suksesshëm dhe madje në përgjithësi për shkak se ata e marrin shumë seriozisht përputhshmërinë mbrapa. Në fakt, kjo është tezë e artikullit tonë. Sistemet e hapura të suksesshme dhe me jetëgjatësi e kanë borxh suksesin e tyre mikroshoqërive, të cilat jetojnë për dekada rreth zgjerimeve/pluginëve. Kjo është ekosistema. Unë kam folur për thelbin e platformave dhe për rëndësinë e tyre, dhe për atë se Google kurrë në të gjithë historinë e saj korporative nuk ka kuptuar se çfarë përfshin krijimi i një platforme të suksesshme të hapur, përveç Android-it ose Chrome-it.
Në të vërtetë, duhet të përmend shkurt Android-in, sepse me siguri keni menduar për të.
Së pari, Android-i nuk është Google. Ata nuk kanë pothuajse asgjë të përbashkët me njëri-tjetrin. Android është një kompani që u ble nga Google në korrik të vitit 2005, kësaj kompanie iu dha leje të punojë më shumë ose më pak autonomisht dhe në të vërtetë ajo mbeti në masë të madhe e paprekur gjatë viteve të kaluara. Android-i është një stivë teknologjike e njohur dhe po aq e njohur për organizatën e saj të ngurtë. Siç tha një Google-u, "nuk është e lehtë të hysh në Android."
Në një nga artikujt e kaluar kam folur tashmë se sa të këqija ishin disa nga vendimet e hershme të dizajnit të Android. O Zot, kur po shkruaja atë artikull, ata po angazhonin veten në shpërndarjen e diçkaje të quajtur "aplikacione të menjëhershme", të cilat tani (surprizë!) , dhe ndjej keqardhje nëse ishit mjaft të budallallë për të dëgjuar Google-in dhe për të transferuar përmbajtjen tuaj në këto aplikacione të menjëhershme.
Por këtu ka një ndryshim, një ndryshim të rëndësishëm që lidhet me faktin se njerëzit nga Android e kuptojnë vërtet sa të rëndësishme janë platformat, ata përpiqen me ngulm të ruajnë funksionalitetin e aplikacioneve më të vjetra Android. Në të vërtetë, përpjekjet e tyre për të ruajtur përputhshmërinë e prapme janë aq ekstreme, sa unë, gjatë qëndrimit tim të shkurtër në njësinë Android disa vite më parë, e kuptova se po përpiqesha t'i bindja ata të hiqnin dorë nga mbështetje për disa nga pajisjet dhe API-të më të vjetra (isha gabim, ashtu si në shumë gjëra të tjera në të kaluarën dhe të tashmen. Më falni, njerëz të Android! Tani që kam qenë në Indonezi, e kuptoj pse na nevojitet).
Njerëzit nga Android mbështesin përputhshmërinë e prapme deri në ekstreme thuajse të paimagjinueshme, duke grumbulluar një sasi të madhe borxhi teknik të vjetruar në sistemet dhe zinxhirët e tyre të veglave. O Zot, do të kishit parë disa gjëra të çmendura që ata duhet të bëjnë në sistemin e tyre të ndërtimit, dhe gjithçka në emër të përputhshmërisë.
Për këtë, unë i jap Android çmimin e dëshiruara "Ti nuk je Google". Ata vërtet nuk duan të bëhen Google, e cila nuk di të krijojë platforma të qëndrueshme, ndërsa Android e di, si ta bëjë këtë. Dhe për këtë arsye, Google comportohet shumë mençur në një aspekt: lejon njerëzit në Android të bëjnë gjithçka në mënyrën e tyre.
Megjithatë, aplikacionet e menjëhershme për Android ishin një ide mjaft e çuditshme. Dhe e dini pse? Sepse kërkonin të ribëni dhe ristrukturoni aplikacionin tuaj! Siç do të mendonit se njerëzit do të thoshin thjesht do ta rishtin dy milion aplikacione. Supozoj se aplikacionet e menjëhershme ishin ideja e ndonjë gugluesi.
Por këtu ka një ndryshim. Përputhshmëria e prapme është e lidhur me shpenzime të mëdha. Android e mban këto shpenzime vetë, ndërsa Google insistojnë që këtë barrë ta mbajnë ju, klient paguar.
Ju mund të shihni përkushtimin e Android ndaj përputhshmërisë së prapme në ndërfaqet e saj API. Kur keni katër ose pesë nën-sisteme të ndryshme për të kryer praktikisht të njëjtën gjë, është një shenjë e sigurt se mbështetje e prapme është në themel. Çka në botën e platformave është sinonim i përkushtimit tuaj ndaj klientëve tuaj dhe tregut tuaj.
Problemi kryesor i Google këtu është krenaria e tyre për higjienën e inxhinierisë. Atij nuk i pëlqen kur ka shumë mënyra të ndryshme për të bërë të njëjtën gjë, ku metodat e vjetra, të padëshiruara, janë pranë atyre të reja, më të çuditshme. Kjo rrit ngarkesën e mësimit për fillestarët në sistem, e rrit barrën e mbështetjes për API-të e vjetra, e ngadalëson shpejtësinë e funksioneve të reja, dhe mëkat i madh — është e shëmtuar. Google është si Lady Escot nga 'Alice në Botën e Çudirave' nga Tim Burton:
Lady Escot:
— Alice, diçka që kam frikë më shumë se çdo gjë tjetër?
— Rënia e aristokracisë?
— Kam frikë se do të kem nipër të shëmtuar.
Për të kuptuar kompromisin mes të bukurës dhe të praktikes, le të shohim platformën e tretë të suksesshme (pas Emacs dhe Android) dhe të shohim si funksionon: vetë Java.
Java ka një sasi të madhe API-sh të vjetra. Demtimi është shumë i njohur mes programuesve të Java, madje më popullor se në shumicën e gjuhëve të programimit. Në vetë Java, gjuha kryesore dhe bibliotekat vazhdimisht po demtohen API-të.
Nëse marim vetëm një nga mijëra shembuj, në fakt është e vjetruar. Ajo është demtuar që nga lansimi i Java 1.2 në dhjetor të vitit 1998. Ka kaluar 22 vjet që kur kjo është e vjetruar.
Por kodi im real në prodhim akoma mbyll procese çdo ditë. A është kjo e mirë? Absolutisht! Kam parasysh, sigurisht, nëse do ta rishtroja kodin sot, do ta realizoja ndryshe. Por kodi i lojës time, e cila ka bërë të lumtur qindra mijëra njerëz gjatë 20 viteve të fundit, është shkruar me funksionin e mbylljes së proceseve, të cilët rrinë shumë gjatë, dhe unë nuk kam pasur asnjëherë nevojë ta ndryshoj. E njoh sistemin tim më mirë se kushdo, kam literal 25 vjet përvojë pune me të në prodhim, dhe mund të them saktësisht: në rastin tim, mbyllja e këtyre proceseve specifike është krejtësisht e padëmshme. Nuk ka kuptim të harxhoj kohë dhe mund për ta rishtrojnë këtë kod, dhe lavdi Larry Ellison-it (ndoshta), që Oracle nuk më detyroi ta rishtroj atë.
Ndoshta, Oracle e di gjithashtu për platformat. Kush e di.
Dëshmi mund të gjejmë në të gjitha API-të kryesore të Java-s, të cilat janë të mbushura me valë të plakesës, si linjat e akullnajës në kanion. Në bibliotekën Java Swing, është e lehtë të gjesh pesë ose gjashtë menaxherë të ndryshëm për navigimin me tastierë (KeyboardFocusManager). Në të vërtetë, është e vështirë të gjesh një API të Java-s që nuk është i plakuar. Por ato ende funksionojnë! Mendoj se ekipi i Java-s do ta fshijë me të vërtetë API-në vetëm nëse interfaci do të shkaktonte një problem të rëndësishëm sigurie.
Ja se çfarë është, djem: ne, zhvilluesit e softuerit, jemi të gjithë shumë të zënë, dhe në çdo fushë të softuerit, ne përballëmi me alternativa konkurruese. Në çdo moment të vetëm, programuesit në gjuhën X e shikojnë gjuhën Y si një zëvendësim të mundshëm. O, nuk më besoni? Doni të flisni për Swift? Të thoni se të gjithë migrojnë në Swift dhe askush nuk e braktis atë, apo jo? O, sa pak e dini. Kompanitë po shqyrtojnë kostot e ekipeve të dyfishta për zhvillimin e aplikacioneve mobile (iOS dhe Android) - dhe ata fillojnë të kuptojnë se këto sisteme zhvillimi për platforma të ndryshme me emra qesharakë, si Flutter dhe React Native, në të vërtetë funksionojnë, dhe me ndihmën e tyre mund të reduktojnë përmasat e ekipeve të tyre mobile me gjysmë ose, përkundrazi, t'i bëjnë ato dyfish produktive. Po flasim për para reale. Po, ka kompromis, por, nga ana tjetër, para.
Supozoni hipotetikisht se Apple, për injorancë, ka marrë shembull nga Guido van Rossum dhe shpalli se Swift 6.0 nuk është në përputhje me Swift 5.0, ashtu si Python 3 nuk është në përputhje me Python 2.
Mund të kenë kaluar rreth dhjetë vjet që nga hera e fundit që e kam treguar këtë histori, por pesëmbëdhjetë vjet më parë, unë isha në kampin Foo Camp të O’Reilly, duke qëndruar me Guido, duke fjetur në një çadër me Paul Graham dhe një grup të njohurish. Po prisnim në një vapë të nxehtë për të parë kur Larry Page do të fluturonte me helikopterin e tij privat, dhe Guido i fliste ngadalë për "Python 3000", emri që e kishte dhënë për vitet që do të duhen për të migruar atje. Ne e pyetëm vazhdimisht pse po shkelte përputhshmërinë, dhe ai përgjigjej: “Unicode”. Dhe e pyetëm, nëse do të duhej t'i ripisnim kodet tona, çfarë përfitimesh të tjera do të shihnim? Ai tha “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Nëse instaloni Google Cloud Platform SDK (“gcloud”), do të merrni njoftimin e mëposhtëm:
I dashur marrës,
Ne kemi dëshirë t'ju kujtojmë se mbështetja për Python 2 është përfunduar, prandaj, shko të rrish.
… dhe kështu me radhë. Rrethi i jetës.
Por çështja është se çdo zhvillues ka zgjedhjen e tij. Dhe nëse i detyron ata të rikrijojnë kodin shpesh mjaft, ata mund të mendojnë edhe për të tjerë mundësi të tjera. Ata nuk janë robërit tuaj, pavarësisht se sa e dëshironi këtë. Ata janë mysafirët tuaj. Python mbetet një gjuhë programimi shumë popullore, por, përtej kësaj, Python 3(000) krijoi një kaos të tillë në komunitetet e tij dhe te përdoruesit e tyre, saqë pasojat e tij nuk mund të zgjidhen për pesëmbëdhjetë vjet.
Sa shumë programe Python janë shkruar në Go (ose Ruby, ose ndonjë alternativë tjetër) për shkak të këtij moskombimi të pastruar? Sa shumë softuer të ri është shkruar në ndonjë gjë tjetër përveç Python-it, edhe pse mund të ishte shkruar në Python, nëse Guido nuk do të kishte djegur fshatin? Është e vështirë të thuash, por Python ka pësuar qartë. Kjo është një kaos i madh, dhe të gjithë janë në humbje.
Tani le të supozojmë se Apple ndjek shembullin e Guidos dhe shkel kompatibilitetin. Çfarë mendoni se do të ndodhë më pas? Po, ndoshta 80-90% e zhvilluesve do të rivendosin softuerin e tyre nëse është e mundur. Në fjalë të tjera, 10-20% e bazës së përdoruesve automatikisht do të kalojnë në një gjuhë konkurruese, si Flutter.
Bëni këtë disa herë — dhe do të humbni gjysmën e bazës suaj të përdoruesve. Ashtu si në sport, forma e tanishme gjithashtu ka rëndësi të gjitha. Çdo kush që humb gjysmën e përdoruesve për pesë vjet, do të konsiderohet një Dështim i Madh. Ju duheni të jeni në trend në botën e platformave. Por pikërisht këtu heqja e mbështetjes për versionet e vjetra me kalimin e kohës do t'ju dëmtojë. Sepse çdo herë që i heqni një pjesë të zhvilluesve, ju (a) humbni ata përgjithmonë, sepse ata zemërohen me ju për shkeljen e kontratës, dhe (b) i jepni ata konkurentëve tuaj.
Me ironinë, unë gjithashtu ndihmova Google të shndërrohet në një primadonë të tillë, e cila injoron kthimin në përputhshmëri, kur krijova Grok, një sistem analize dhe kuptimi të kodit burimor, i cili lehtëson automatizimin dhe armaturën e mjeteve të bazuara në të njëjtin kod — duket si një IDE, por këtu shërbimi në re mban pamjet materializuara të të gjitha miliardave rreshtave të kodit burimor të Google në një depo të madhe të dhënash.
Grok i ka ofruar gugalëve një bazë të fuqishme për të kryer riaktualizim automatizuar në të gjithë bazën e kodit (në mënyrë të vërtetë në të gjithë Google). Sistemi llogarit jo vetëm varësitë tuaja në rritje (nga të cilat varet), por gjithashtu varësitë në rënie (që varen nga ju), kështu që kur ndryshoni API-në, dini të gjithë ata që po thyeni! Kështu, kur bëni ndryshime, mund të kontrolloni që çdo konsumator i API-së tuaj është azhurnuar në versionin e ri, dhe në të vërtetë shpesh me ndihmën e mjetit Rosie, të cilin ata e kanë shkruar, mund të automatizoni plotësisht procesin.
Kjo i lejon bazës së kodit të Google të jetë brenda saj pothuajse jashtëzakonisht "të pastër", pasi ato shërbëtorë robotikë lëvizin nëpër tërë shtëpinë dhe pastrojnë automatikisht gjithçka, nëse ata e kanë riemëruar SomeDespicablyLongFunctionName në SomeDespicablyLongMethodName, sepse dikush vendosi se kjo është një nip i shëmtuar dhe duhet të flenë.
Dhe, me sinqeritet, kjo funksionon mjaft mirë për Google… brenda. Dua të them, po, komuniteti Go në Google vërtet e ka një kthesë miqësore me komunitetin Java në Google për shkak të zakonit të tyre për riaktualizim të vazhdueshëm. Nëse po e rilançoni diçka N herë, atëherë kjo do të thotë se nuk vetëm se e keni prishur atë N-1 herë, por pas një kohe bëhet krejtësisht e qartë se ndoshta e keni prishur atë edhe me përpjekjen e N-të. Por, në thelb, ata mbeten mbi këtë tërbim dhe e mbajnë kodin "të pastër".
Problemet fillojnë kur ata përpiqen t'i imponojnë një qëndrim të tillë klientëve të tyre të cloud dhe përdoruesve të API-ve të tjera.
Ju kam prezantuar pak me Emacs, Android dhe Java; le të shikojmë platformën e fundit të suksesshme dhe me jetë të gjatë: vetë Webin. Mund ta imagjinoni përmes sa iteracioneve ka kaluar HTTP që nga viti 1995, kur ne përdornim etiketat bifokuese dhe simbolet "Në zhvillim" në faqet e internetit.
Por, kjo ende funksionon! Dhe këto faqe ende funksionojnë! Po, djem, shfletuesit janë kampionë të botës në mbështetje të prapshme. Chrome është një tjetër shembull i një platforme të rrallë të Google, ku kokat janë montuar siç duhet, dhe, siç e keni kuptuar, Chrome vepron efektivisht si një kompani e izoluar ndarë nga pjesa tjetër e Google.
Dua dhe të falënderoj miqtë tanë mes zhvilluesve të sistemeve operative: Windows, Linux, JO APPLE MERR SHKO APPLE, FreeBSD dhe të tjera, për punën e madhe që kanë bërë në ruajtjen e përputhshmërisë së prapme në platformat e tyre të suksesshme (Apple merr në maksimum një tre të minus, pasi vazhdimisht thyen gjithçka pa një motiv të arsyeshëm, por në njëfarë mënyre komuniteti e menaxhon këtë në çdo lëshim, dhe deri tani kontejnerët me OS X nuk janë plotësisht të vjetëruar... për momentin).
Por prisni, do të thoni. A nuk po krahasojmë mollë me portokalle - sisteme software autonome në një makinë, si Emacs/JDK/Android/Chrome, me sisteme shumë serverësh dhe API, si në shërbimet në re?
Epo, e shkrova këtë dje në Twitter, por në stilin e Larry Wall (krijuesi i gjuhës programimi Perl - shën. përk.) sipas parimit "lloj i keq/rules", kërkova fjalën deprecated në faqet e zhvilluesve të Google dhe Amazon. Dhe megjithëse AWS ka qindra herë më shumë shërbime sesa GCP, dokumentacioni i zhvilluesve të Google e përmend moshimin rreth shtatë herë më shpesh.
Nëse dikush nga Google e lexon këtë, me siguri janë të gatshëm të nxjerrin grafikët duke treguar se çfarë bëjnë realisht gjithçka në rregull, dhe se unë nuk duhet të bëj krahasime të padrejta, të tilla si "numri i përmendjeve të fjalës deprecated në varësi të numrit të shërbimeve".
Por pas kaq shumë vitesh, Google Cloud ende mbetet shërbimi Nr. 3 (nuk kam shkruar ende një artikull për përpjekjen e dështuar për të qenë Nr. 2), por nëse besojmë burimeve të brendshme, ka disa shqetësime që ata mund të bien së shpejti në Nr. 4.
Nuk kam argumente të fuqishme për të "provuar" tezën time. E gjithë ajo që kam janë shembuj të ngjyrosur që kam mbledhur për 30 vjet si zhvillues. Kam përmendur tashmë natyrën thellësisht filozofike të këtij problemi; në njëfarë kuptimi, është politizuar në komunitetet e zhvilluesve. Disa besojnë se krijuesit e platformave duhet të jenë të kujdesshëm për përputhshmërinë, ndërsa të tjerë besojnë se kjo është përgjegjësi përdoruesit (e vetë zhvilluesve). Një nga të dyja. Dhe në të vërtetë, a nuk është një çështje politike kur vendosim se kush duhet të mbajë kostot për problemet e përbashkëta?
Pra, kjo është politikë. Dhe me siguri do të ketë përgjigje të zemëruara ndaj fjalimit tim.
Si përdorues Si platformën cloud të Google, si dhe si përdorues i AWS për dy vjet (duke punuar në kompaninë Grab), mund të them se ekziston një diferencë e madhe midis filozofive të Amazon dhe Google kur bëhet fjalë për prioritetet. Unë nuk merrem aktivisht me zhvillimin në AWS, prandaj nuk e di shumë mirë se sa shpesh ata heqin API të vjetra. Por kam dyshime se kjo ndodh shumë më rrallë sesa në Google. Dhe unë besoj sinqerisht se ky burim i vazhdueshëm i polemikave dhe shqetësimeve në GCP është një nga faktorët më të mëdhenj që frenojnë zhvillimin e platformës.
E di që nuk përmenda shembuj konkretë të sistemeve GCP, mbështetje e të cilave është ndërprerë. Mund të them se pothuajse gjithçka që kam përdorur, nga rrjetet (nga më të vjetrat deri te VPC) deri te ruajtjet (Cloud SQL v1-v2), Firebase (tani Firestore me një API krejtësisht të ndryshëm), App Engine (mos ta fillojmë fare), pikapet cloud Cloud Endpoint dhe deri te... nuk e di — absolutisht gjithçka kjo më ka detyruar të rishkruaj kodin maksimal përmes 2-3 vjetëve, dhe ata kurrë nuk e kanë automatizuar migrimin për ju, shpesh . Si të ishte kështu e destinuar.
Dhe çdo herë që shikoj në AWS, pyes veten se çfarë dreqin bëj akoma në GCP. Ata duket se nuk kanë nevojë për klientë. Ata kanë nevojë për blerës. E kuptoni diferencën? Le të shpjegoj.
Google Cloud ka një , ku njerëzit ofrojnë zgjidhjet e tyre software, dhe për të shmangur efektin e restorantit të zbrazët, duhej ta mbushnin atë me disa oferta, prandaj ata lidhën një kontratë me kompaninë Bitnami për të krijuar shumë zgjidhje që shpërndahen "me një klik" ose unë vetë duhet të shkruaj "zgjidhje", sepse këto nuk zgjidhin asgjë. Ato thjesht ekzistojnë si shënjues, si mbushës marketingu, dhe Google nuk ka pasur gjithmonë kujdes nëse ndonjë nga mjetet funksionon në të vërtetë. Njoh menaxherë produkti që ishin në timon, dhe mund t'ju siguroj se këtyre njerëzve nuk u intereson.
Le të marrim, për shembull, zgjidhjen me shpërndarje supozuar "me një klik" . Më kanë bezdisur në mënyrë të përjetshme trukimet e Google Cloud SQL, kështu që fillova të shqyrtoj si alternativë krijimin e klasterit tim Percona. Dhe këtë herë Google duket se bëri një veprim të mirë, ata planifikuan të kursenin pak kohë dhe përpjekje me një klik të vetëm!
Mirë, le të shkojmë. Të kalojmë në lidhjen dhe të klikojmë këtë buton. Zgjedhim "Po" për të pranuar të gjitha parametrat përkatës dhe për të zgjeruar klasterin në projektin tuaj në Google Cloud. Haha, nuk funksionon. Asgjë nga kjo gjë nuk funksionon. Ky mjet nuk është testuar kurrë, dhe ka filluar të kalbet që nga minuta e parë, dhe nuk do të ma merrte mendja nëse më shumë se gjysma e "zgjidhjeve" për shpërndarje me një klikim (tani e kuptojmë pse me cita) do të dështojë. në përgjithësi nuk funksionon. Kjo është një errësirë e tmerrshme, ku është më mirë të mos hysh.
Por Google kërkon me të vërtetë që ti t'i përdorësh ato. Ata duan që ti t'i blesh.Për ta, kjo është një transaksion. Ata nuk duan të mbështesin asgjë. Kjo nuk është pjesë e ADN-së së Google. Po, inxhinierët mbështesin njëri-tjetrin, siç tregon historia ime me Bigtable. Por në produktet dhe shërbimet për njerëzit e zakonshëm, atakanë qenë gjithmonë të ashpër në mbylljen e çdo shërbimi Dhe kjo paraqet një problem të vërtetë për GCP, sepse kjo ADN qëndron pas të gjitha ofertave në cloud. Ata nuk janë të interesuar të mbështesin asgjë; është e njohur se ata refuzojnë të hostojnë (si një shërbim i menaxhuar) çdo softuer të palës së tretë
deri sa AWS të bëjë të njëjtën gjë dhe të ndërtosh një biznes të suksesshëm përreth tij, dhe kur klientët të kërkojnë me të vërtetë të njëjtën gjë. Megjithatë, është e nevojshme të bësh përpjekje për të bërë që Google të mbështesë diçka. Ky mungesë kulture mbështetjeje, së bashku me parimin "le të thyejmë, për ta bërë më të bukur", i largon zhvilluesit nga ata.Dhe kjo nuk është shumë e mirë, nëse do të ndërtosh një platformë të qëndrueshme.
Google, zgjohet, më çfarë djalli. Tani është viti 2020. Ti ende po humb. Koha për të kthyer një sy në pasqyrë dhe për t'u përgjigjur, nëse vërtet do të mbetesh në biznesin e cloud.
Nëse dëshiron të mbetesh, atëherë
ndalo së thyerit gjithçka.
Djem, ju jeni të pasur. Ne, zhvilluesit - nuk jemi. Prandaj, kur vjen çështja e ndërsjelltësisë, ju duhet ta merrni përsipër këtë. Jo ne. Sepse ka edhe të paktën tre cloud tjera vërtet të mira. Ata të tërheqin.Tani do të shkoj të riparoj të gjitha sistemet e mia të thyer. Ah.
Derisa të takohemi përsëri!
А теперь я пойду дальше чинить все свои сломанные системы. Эх.
До следующего раза!
P. S. Një azhurnim pas leximit të disa diskutimeve rreth këtij artikulli (diskutimet janë jashtëzakonisht të mira, për të thënë të drejtën). Mbështetje për Firebase nuk është ndërprerë dhe nuk ka asnjë plan që unë të di. Megjithatë, ata kanë një defekt të padëshiruar në transmetim, që bën që klienti Java të ndalet në App Engine. Një nga inxhinierët e tyre më ndihmoi të merrem me këtë problem, kur punoja në Google, por ata kurrë nuk e riparuan vërtet defektin, kështu që unë kam një zgjidhje të keqe, duke qenë se duhet ta ripërsëris aplikacionin GAE çdo ditë. Kështu ka ndodhur për katër vjet! Tani ata kanë Firestore. Do të kërkojë shumë punë për të migruar në të, pasi kjo është një sistem krejtësisht ndryshe, dhe defekti i Firebase nuk do të riparohet kurrë. Cila është konkluzioni? Ju mund të merrni ndihmë, nëse punoni në një kompani. Ndoshta unë jam i vetmi që përdor Firebase në GAE, sepse regjistroj më pak se 100 çelësa në një aplikacion 100% natyror, dhe ai ndalon së punuari çdo disa ditë për shkak të një defekti të njohur. Çfarë mund të themi këtu përveç se ta përdorim me rrezik? Unë po kaloj në Redis.
Kam parë gjithashtu se disa përdorues më të përvojshëm të AWS thonë se AWS zakonisht kurrë nuk ndalon mbështetje për asnjë shërbim, dhe SimpleDB është një shembull i shkëlqyer. Supozimet e mia se në AWS nuk ka një sëmundje të tillë me ndërprerjen e mbështetjes si në Google, duken të justifikuara.
Për më tepër, kam vënë re se 20 ditë më parë ekipi i Google App Engine prishi hostimin e një biblioteke kritike Go, duke e mbyllur aplikacionin GAE nga një nga zhvilluesit kryesorë të Go. Në të vërtetë, ishte për të ardhur keq.
Më në fund, kam dëgjuar se ata të Google tashmë po diskutojnë këtë çështje dhe në përgjithësi bien dakord me mua (ju dua, djem!). Por duket se ata e konsiderojnë problemin të pazgjidhshëm, sepse në kulturën e Google kurrë nuk ka pasur një strukturë të duhur stimujsh. Mendoj se do të ishte mirë të gjej pak kohë për të biseduar për përvojën absolutisht të mrekullueshme që kam pasur me inxhinierët e AWS, kur punoja në kompaninë Grab. Shpresoj që në të ardhmen!
Po dhe, në vitin 2005 ata vërtet kishin lloje të ndryshme mishi peshkaqeni në një bufet të madh në ndërtesën 43, dhe më pëlqeu më shumë mishi i peshkaqenëve me kokë të gjata. Megjithatë, në vitin 2006, Larry dhe Sergey hoqën të gjitha snacks të pashëndetshme. Prandaj, gjatë historisë me Bigtable në vitin 2007, nuk kishte asnjë peshkaqen dhe ju kam mashtruar në mënyrë të ndyrshme.
Kur po shikoja Bigtable në cloud katër vjet më parë (më shumë apo më pak), çmimi ishte pikërisht ky. Duket se tani ka rënë pak, por akoma është shumë për një depo të zbrazët të të dhënave, sidomos duke pasur parasysh se tregimi im i parë tregon se sa e parëndësishme është një tabelë e madhe e zbrazët në shkallën e tyre.
Më vjen keq që ofendova komunitetin e Apple dhe që nuk thashë asgjë të mirë për Microsoft etj. Të gjithë keni të drejtë, e vlerësoj shumë të gjitha diskutimet që shkaktoi ky artikull! Por ndonjëherë duhet të turbullosh pak ujërat për të filluar një diskutim, e kuptoni?
Faleminderit për leximin.
Përditësimi 2, 19.08.2020. Stripe !
Përditësimi 3, 31.08.2020. Më kontaktoi një inxhinier i Google në Cloud Marketplace, që doli të ishte një mik i vjetër. Ai donte të kuptonte pse C2D nuk funksiononte, dhe në fund e zbuluam: arsyeja ishte se unë krijova rrjetin tim disa vite më parë, dhe C2D nuk funksionon në rrjete të vjetra për shkak të parametrave të munguar të subnet në modelet e tyre. Mendoj se përdoruesit potencialë të GCP duhet të sigurohen që të kenë inxhinierë të njohur mirë në Google...
Burimi: habr.com
