O Zot, Google, nuk doja sërish të shkruaja në blog. Kam kaq shumë gjëra për të bërë. Të shkruash në blog kërkon kohë, energji dhe krijimtari, të cilat mund t'i përdorja për diçka më të dobishme: librat e mi, , lojën time dhe kështu me radhë. Por m'i dhezëm mjaft, kështu që do ta shkruaj këtë.
Prandaj, le të mbyllim këtë.
Do të filloj me një histori të vogël, por mësimdhënëse nga ato kohë kur sapo kisha filluar të punoja 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 të dobëta biznesore. Megjithatë, duhet t'ia jap meritat: infrastruktura e brendshme e Google është vërtet e jashtëzakonshme, mund të thuhet se sot nuk ka asgjë më të mirë. Themeluesit e Google ishin inxhinierë shumë më të mirë se çfarë do të bëhem ndonjëherë, dhe kjo histori vetëm e konfirmon këtë fakt.
Së pari, pak për të kaluarën: Google ka një teknologji ruajtjeje të të dhënave të quajtur . Ky ishte një arritje teknike e jashtëzakonshme, një nga të parat (nëse jo e para) ruajtje “të papërfunduar” të çiftave “çelës-vlerë” (key-value store, K/V): në thelb, fillimi i NoSQL. Në ditët e sotme, Bigtable ende qëndron fort në një hapësirë të mjaftueshme të mbushur të ruajtjeve K/V, por atëherë (në vitin 2005) ishte jashtëzakonisht interesante.
Një detaj interesant i Bigtable është se ata kishin objekte të brendshme të planit të kontrollit (si pjesë e implementimit) të quajtur serverë tableti, me indekse të mëdha, dhe në një moment ata u bënë ngushtica në shkallëzimin e sistemit. Inxhinierët e Bigtable po mendonin si të realizonin shkallëzimin dhe papritmas kuptuan se mund të zëvendësonin serverët e tabletëve me ruajtje të tjera Bigtable. Pra, Bigtable është një pjesë e implementimit të Bigtable. Këto ruajtje janë atje në të gjitha nivelet.
Një detaj tjetër i interesant është se për një kohë të caktuar, Bigtable u bënë të njohur dhe të pranishëm brenda Google, dhe çdo ekip kishte magazinën e tij. Prandaj, gjatë një prej mbledhjeve të premtes, Larry Page e pyeti rastësisht: „Pse kemi më shumë se një Bigtable? Pse të mos kemi vetëm një?” Teorikisht, një magazinë kishte mjaft për të gjitha nevojat e ruajtjes së Google. Sigurisht, ata kurrë nuk kaluan vetëm në një për arsyet praktike të zhvillimit (për shembull, pasojat e një dështimi potencial), por teoria ishte interesante. Një magazinë për të gjithë universin (ndërkohë, dikush e di, a e bëri Amazon këtë me Sable-n e saj?)
Pavarësisht kësaj, kjo është historia ime.
Në atë kohë, unë po punoja në Google për pak më shumë se dy vjet dhe një ditë mora një email nga ekipi inxhinierik i Bigtable, diçka në këtë përmbajtje:
I dashur Steve,
Përshëndetje nga ekipi i Bigtable. Ne duam 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 shumë, shumë të vjetër të Bigtable. Kjo version nuk mbështetet më, dhe ne duam t'ju ndihmojmë të kaloni në versionin e fundit.
Ju lutem na tregoni nëse mund të planifikoni pak kohë për të punuar bashkërisht mbi këtë çështje.
Të gjitha më të mirat,
Ekipi Bigtable
Në Google, ju vijnë shumë emaile, prandaj nga një shikim i parë, e lexova diku si:
I nderuar marrës,
Përshëndetje nga një ekip i caktuar. Duam t'ju njoftojmë se bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, dhe bla-bla-bla menjëherë.
Ju lutem na informoni nëse mund të planifikoni një pjesë të kohës suaj të çmuar për bla-bla-bla.
Të gjitha më të mirat,
Një ekip i caktuar
Gati sa e hoqa menjëherë, por në kufirin e vetëdijes ndjeva një ndjesi e ngarkuar, por shqetësuese, se kjo nuk është saktësisht një letër formale, edhe pse dukshëm, që pati një gabim me marrësin, sepse nuk përdora Bigtable.
Por ishte e çuditshme.
Pjesën tjetër të ditës, unë e mendova me alternim punën dhe cilin lloj mishi peshkaqeni të provoj në mikro-kuzhinë, nga të cilat të paktën tre ishin mjaft afër për të goditur nga vendi im me një hedhje të saktë të biskotave, por mendimi për letrën nuk më la të qetë me një ndjenjë të rritjes së ankthit.
Ata e thjeshtë e thirrjeve të emrit tim. Dhe letra është dërguar në adresën time elektronike, jo në dikë tjetër, dhe kjo nuk është cc: ose bcc:. Toni është shumë personal dhe i qartë. A është ndonjë gabim?
Më në fund, kurioziteti mori kryesimin dhe shkova të shihja konsolën Borg në qendrën e të dhënave që ata përmendën.
Dhe sigurisht, unë kisha në menaxhim një ruajtje BigTable. Çfarë? E shikova përmbajtjen e saj dhe - më duhet të them! Kishte nga inkubatori Codelab, ku qëndrova javën e parë të punës time në Google në qershor 2005. Codelab e bënte që t'i japësh jetë Bigtable për të ruajtur disa vlera, dhe duket se nuk e mbylla ruajtjen pas kësaj. Ajo ende punonte, edhe pse kishin kaluar mbi dy vjet.
Kjo histori ka disa aspekte të rëndësishme. Së pari, puna e Bigtable ishte kaq e parëndësishme në shkallën e Google, sa vetëm pas dy vjetësh dikush e vuri re ruajtjen e tepërt dhe për këtë vetëm sepse versioni i binarëve ishte mbetur në opozitë. Për krahasim, një herë e kam konsideruar përdorimin për lojën time online. Në atë kohë, ky shërbim kushtonte rreth 16,000 dollarë në vit për të zbrazët Bigtable në GCP. Nuk po them që po ju mashtrojnë, por, sipas mendimit tim personal, këto janë shumë para për një bazë të dhënash të kotë.
Një aspekt tjetër i rëndësishëm është se ruajtja përmirësohej edhe pas dy vjetësh. Çfarë po ndodh? Qendrat e të dhënave vijnë e shkojnë; ato kalojnë nëpër ndërprerje, kalojnë në mirëmbajtje të planifikuar, ndryshojnë vazhdimisht. Pajisjet përditësohen, kalimet ndërrohen, gjithçka përmirësohet vazhdimisht. Si, e di Zoti, ata arranë të mbajnë programin tim aktiv për dy vjet duke marrë parasysh të gjitha këto ndryshime? Kjo mund të duket si një arritje modeste në vitin 2020, por në vitet 2005-2007 ishte mjaft mbresëlënëse.
Dhe aspekti më i mahnitshëm është se një ekip inxhinierësh nga një shtet tjetër më kontaktin me mua, pronarin e një instancë të vogël, pothuajse bosh të Bigtable, i cili ka trafik zero në dy vitet e fundit - dhe ofrojnë ndihmë për ta përditësuar.
I falenderova ata, hoqa depoja, dhe jeta shkoi përpara. Por tridhjetë vjet më pas, unë ende mendoj për këtë letër. Sepse ndonjëherë marr letra të ngjashme nga Google Cloud. Ato duken kështu:
Të nderuar përdorues të Google Cloud,
Ju rikujtojmë se shërbimi [shërbimi i rëndësishëm që po përdorni] do të ndalet nga gushti 2020, pas së cilës nuk do të keni mundësi të përditësoni instancat tuaja. Ju rekomandojmë të kaloni në versionin e fundit, i cili është në beta-testim, nuk ka dokumentacion të ndonjë lloj, nuk ka as një rrugë migrimi dhe që është tejet e vjetruar me ndihmën tonë të mirësjelljes.
Ne përpiqemi që ky ndryshim të ndikojë sa më pak në të gjithë përdoruesit e platformës Google Cloud.
Miq të përjetshëm,
Platforma Cloud e Google
Por unë pothuajse nuk i lexoj këto letra, sepse në të vërtetë ato thonë këtë:
I nderuar marrës,
Shko te djalli. Shko te, shko te, shko te. Hidh gjithçka që po bën, sepse nuk ka rëndësi. Ajo që ka rëndësi është koha jonë. Ne po shpenzojmë kohë dhe para për të mbajtur bllokimet tona, dhe jemi lodhur nga kjo, prandaj më nuk do ta mbajmë. Prandaj, lëre planin tënd të mallkuar dhe fillo të gërmosh në dokumentacionin tonë të keq, duke kërkuar mbetje në forumet, dhe, për më tepër, gjëja jonë e re është krejt ndryshe nga ajo e vjetër, sepse e prishëm dizajnin mjaft keq, heh, por kjo është problemi yt, jo yni.
Ne vazhdojmë të punojmë për t'i bërë të gjitha zhvillimet e tua të papërdorshme brenda një viti.
Të lutem, shko ndonjëherë,
Platforma Cloud e Google
Dhe e vërteta është se po marr letra të tilla rreth një herë në muaj. Kjo ndodh kaq shpesh dhe kaq vazhdueshëm, saqë ato patjetër të larguan nga GCP në kampin e kundërshtarëve të cloud-it. Nuk dëshiroj më të varem nga zhvillimet e tyre proprietare, sepse në të vërtetë është më e lehtë për një devop të mbajë një sistem me burim të hapur në një virtualizim të zbrazët, sesa të përpiqet të ndjekë Google me politikat e saj të mbylljes së produkteve "të vjetra".
Para t'u rikthyer në Google Cloud, sepse unë as që i afrohem nuk kam përfunduar të kritikoj, le të shqyrtojmë punën e kompanisë në disa fusha të tjera. Inxhinierët e Google janë krenarë për disiplinën e tyre të zhvillimit të softuerit, dhe kjo në të vërtetë shkakton probleme. Krenaria është një kurth për ata që janë të pakujdesshëm, ajo bën që shumë punonjës të Google të mendojnë se zgjidhjet e tyre gjithmonë janë të sakta dhe se saktësia (sipër një përkufizim të paqartë) është më e rëndësishme se kujdesi për klientët.
Do t'i sjell disa shembuj të rastësishëm nga projekte të tjera të mëdha përtej Google, por shpresoj se do të shihni këtë model kudo. Ai përfshihet në këtë: mbështetje e prapshme ruan jetëgjatësinë dhe relevancën e sistemeve për dekada.
Mbështetje e prapme është një qëllim projektimi për të gjitha sistemet e suksesshme që janë të destinuara për përdorim , domethënë ato që janë realizuar me kod të hapur dhe/ose mbi standarte të hapura. Ndjehem sikur po them diçka shumë të qartë, që gjithkush e din, por jo. Ky është një çështje politike, prandaj nevojiten shembuj.
Sistemi i parë që do të zgjidhja është më i vjetër: GNU Emacs, një hibrid mes Bloknotit Windows, bërthamës së OS dhe Stacionit Ndërkombëtar të Hapësirës. Është disi e vështirë të shpjegohet, por në dy fjalë, Emacs është një platformë e krijuar në vitin 1976 (po, gati një shekull më parë) për programim për të rritur produktivitetin tuaj, por duket si një redaktues teksti.
Unë përdor Emacs çdo ditë. Po, gjithashtu përdor IntelliJ çdo ditë, ajo ka evoluar në një platformë të fuqishme rrjetë. Por, shkruarja e zgjerimeve për IntelliJ është një detyrë shumë më ambicioze dhe e ndërlikuar se sa shkruarja e zgjerimeve për Emacs. Dhe më e rëndësishmja, gjithçka e shkruar për Emacs ruhet përjetësisht.
Unë ende përdor softuerin që kam shkruar për Emacs që në vitin 1995. Dhe jam i sigurt se dikush përdor module të shkruara për Emacs që në mes të viteve '80, nëse jo më herët. Herë pas here ata mund të kërkojnë rregullime të vogla, por kjo ndodh vërtet shumë rrallë. Nuk di asgjë nga ajo që kam shkruar ndonjëherë për Emacs (dhe kam shkruar shumë), që do të kishte nevojë për një rindërtim të arkitekturës.
Në Emacs ekziston një funksion i quajtur make-obsolete për entitetet e shpërndara. Terminologjia e Emacs për konceptet themelore kompjuterike (p.sh., çfarë është një "dritare") shpesh ndryshon nga konvencionet e industrisë, sepse Emacs i futi ato shumë kohë më parë. Kjo është një rrezik tipik për ata që ishin përpara kohës së tyre: të gjitha termat tuaj janë të pasakta. Por në Emacs, vërtet ekziston koncepti i obsoleshencës, i cili në zhargonin e tyre quhet obsoleshencë.
Por në botën e Emacs, duket se ka një përkufizim tjetër punues. Një filozofi themelore tjetër, nëse doni.
Në botën e Emacs (dhe në shumë fusha të tjera që do të shqyrtojmë më poshtë), statusi i API-eve të shpërndara në thelb do të thotë: "Nuk duhet ta përdorni këtë qasje, sepse, megjithëse funksionon, ka shumë disavantazhe që do t'i rendisim këtu. Por, në fund të fundit, kjo është zgjedhja juaj."
Në botën e Google, statusi i një produkti të shpërndarë do të thotë: "Ne po shkelim angazhimet tona ndaj jush." Vërtet është kështu. Kjo është ajo që në thelb do të thotë. Kjo do të thotë se ata do t'ju bëjnë rregullisht të bëni disa punë, ndoshta punë të madhe, si ndëshkim për besimin tuaj në ta : ne kemi softin më të mirë. Më të shpejtin! Ju ndiqni udhëzimet, nisni aplikacionin ose shërbimin tuaj, dhe pastaj—bam, pas një viti ose dy, dështon.
Kjo është si të shesësh një makinë të përdorur që me siguri do të dështojë pas 1500 km.
Këto janë dy përkufizime të ndryshme filozofike të "rritjes në moshë". Përkufizimi i Google mban erën e . Unë nuk besoj se është në të vërtetë rritje e planifikuar në të njëjtin kuptim si Apple. Por Google me siguri planifikon të prishë programet tuaja, në mënyrë të ndërlikuar. E di këtë sepse kam punuar atje si inxhinier software për mbi 12 vjet. Ata kanë udhëzime të paqarta të brendshme për sa duhet të respektohen retrokompatibiliteti, por përfundimisht kjo varet nga çdo ekip ose shërbim i veçantë. Nuk ka asnjë rekomandim në nivelin korporativ ose inxhinierik, dhe rekomandimi më i guximshëm në terma të cikleve të rritjes në moshë është "provoni t'iu 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ë.
Aktualisht, unë po bëj një pohim guximtar që Emacs është i suksesshëm në masë të madhe dhe madje kryesisht për shkak se ata i japin kaq seriozitet përkatësisë së prapambetjes. Në fakt, ky është teza e artikullit tonë. Sistemet e hapura që kanë sukses dhe jetojnë gjatë i detyrohen mikrokomuniteteve që jetojnë për dekada përreth zgjerimeve/plugin-eve. Kjo është ekosistemi. Unë kam diskutuar më parë mbi natyrën e platformave dhe sa të rëndësishme janë ato, dhe se Google kurrë në historinë e saj korporative nuk ka kuptuar se çfarë përfshihet në krijimin e një platforme të hapur të suksesshme, përveç Android ose Chrome.
Në të vërtetë, duhet të përmend shkurtimisht Android, sepse sigurisht që keni menduar për të.
Së pari, Android nuk është Google. Ato nuk kanë aspak lidhje me njëri-tjetrin. Android është një kompani e blerë nga Google në korrik 2005, dhe asaj i është lejuar të punojë më shumë ose më pak në mënyrë autonome, duke mbetur në një masë të madhe e paprekur gjatë viteve. Android është një stak teknologjik i njohur për problemet dhe një organizatë po aq e njohur për dhimbjet. Siç e shprehu një punonjës i Google, "nuk mund të futesh thjesht në Android".
Në një nga artikujt e kaluar, unë kam diskutuar mbi sa të këqija ishin disa nga vendimet fillestare të dizajnit të Android. O Zot, kur shkrova atë artikull, ata po përfundonin shpërndarjen e një plani të keq të quajtur "aplikacionet instant", të cilat tani (surprizë!) , dhe më vjen keq nëse ishit mjaft të paditur për t'i besuar Google dhe për të transferuar përmbajtjen tuaj në këto aplikacione të menjëhershme.
Por këtu ka një ndryshim, një ndryshim thelbësor, që lidhet me faktin se njerëzit nga Android e kuptojnë vërtet se sa të rëndësishme janë platformat. Ata përpiqen me gjithë forcën të ruajnë funksionalitetin e aplikacioneve të vjetra Android. Në të vërtetë, përpjekjet e tyre për të ruajtur përputhshmërinë me versionet e mëparshme janë kaq të ashpra, saqë dhe unë, gjatë qëndrimit tim të shkurtër në departamentin Android disa vite më parë, e gjetëm veten duke u përpjekur t'i bindja ata që të hiqnin dorë nga mbështetja për disa nga pajisjet dhe API-të më të vjetra (gabim, si në shumë gjëra të tjera të së kaluarës dhe të tashmes. Më falni, djemtë e Android! Tani që kam vizituar Indonezinë, e kuptoj se pse na duhen ata).
Njerëzit nga Android mbështetin përputhshmërinë me versionet e mëparshme deri në ekstreme pothuajse të pafundme, duke krijuar një sasi të madhe borxhi teknik në sistemet dhe zinxhirët e tyre të mjeteve. O Zot, do të shihni disa gjëra të çmendura që ata duhet të bëjnë në sistemin e tyre të ndërtimit, dhe gjithçka kjo në emër të përputhshmërisë.
Për këtë, i jap Android çmimin e dëshiruari 'Ti nuk je Google'. Ata në të vërtetë nuk duan të bëhen Google, e cila nuk di të krijojë platforma të qëndrueshme, por Android e di. di, si ta bëjë këtë. Prandaj Google sillet shumë mençurisht në një aspekt: u jep njerëzve në Android mundësinë të bëjnë gjithçka siç dëshirojnë.
Megjithatë, aplikacionet e menjëhershme për Android ishin një ide mjaft e marrë. Dhe e dini pse? Sepse ato kërkonin të ripërshkruani dhe riprojektoni aplikacionin tuaj! Siç do të thoshte ndokush, njerëzit nuk do ta bëjnë dot këtë për dy milion aplikacione. Supozoj se aplikacionet e menjëhershme ishin ideja e ndonjë gjeje mëngjese.
Por këtu ka një diferencë. Pajtueshmëria mbrapa është e lidhur me kosto të mëdha. Android e mbajnë këtë barrë, ndërsa Google insistojnë që këtë barrë ta mbajnë ju, klientët e paguar.
Mund të shihni angazhimin e Android për përputhshmërinë prapa në API-të e saj. Kur keni katër ose pesë nënsisteme të ndryshme për të kryer dosido të njëjtën gjë, kjo është një shenjë e sigurtë se në bazë qëndron angazhimi për përputhshmërinë prapa. Në botën e platformave, kjo është sinonim i angazhimit ndaj klientëve tuaj dhe tregut tuaj.
Problemi kryesor i Google këtu është krenaria e tyre për higjienën ingjinierike. Nuk u pëlqen kur ka shumë mënyra të ndryshme për të bërë të njëjtën gjë, sidomos kur mënyrat e vjetra, më pak të dëshiruara, qëndrojnë pranë atyre më të reja dhe më të pazakonta. Kjo rrit kurbën e të mësuarit për fillestarët e sistemit, rrit barrën e mbështetjes për API-të e vjetra, ngadalëson shpejtësinë e funksioneve të reja dhe mëkat kyç është - nuk është bukur. Google është si Lady Escot nga "Alica në Botën e Mrekullive" e Tim Burton:
Lady Escot:
— Alica, e di çfarë kam frikë më shumë?
— Mbetja e aristokracisë?
— Kam frikë se do të kem mbesa të shëmtuara.
Për të kuptuar kompromisin mes bukures dhe praktikës, le të shohim platformën e tretë të suksesshme (pas Emacs dhe Android) dhe të shikojmë se si funksionon: vetë Java.
Në Java ka shumë API që janë të vjetra. Vjetërsimi është shumë i zakonshëm mes programuesve Java, madje më i zakonshëm se në shumicën e gjuhëve të tjera të programimit. Në vetë Java, gjuha kryesore dhe bibliotekat, API-të vazhdimisht po vjetrohen.
Nëse shohim vetëm një nga mijëra shembujt, në konsiderohet e vjetruar. Ajo është e vjetruar që nga lançimi i Java 1.2 në dhjetor 1998. Janë kaluar 22 vjet prej atëherë që kjo është vjetruar.
Por kodi im real në prodhim ende vret rrjedhat çdo ditë. A është kjo e mirë? Absolutisht! Dua të them, natyrisht, sikur të kisha shkruar kodin sot, do ta implementoja ndryshe. Por kodi i lojës sime, e cila në dy dekadat e fundit ka bërë të lumtur qindra mijëra njerëz, është shkruar me funksionin e mbylljes së rrjedhave, të cilat qëndrojnë shumë gjatë, dhe unë nuk kam pasur kurrë nevojë ta ndryshoja. Unë e njoh sistemin tim më mirë se kushdo, kam përvojë literal 25-vjeçare me të në prodhim, dhe mund të them me siguri: në rastin tim, mbyllja e këtyre rrjedhave të veçanta është krejtësisht e padëmshme. Nuk e keni të nevojshme të humbni kohë dhe përpjekje duke e riparuar këtë kod, dhe lavdi Larry Ellison (ndoshta) që Oracle nuk më detyroi ta rishkruaj atë.
Ndoshta, Oracle gjithashtu e di se si të punojë me platformat. Kush e di.
Dëshmitë e këtij fenomeni mund të gjenden në të gjitha API-të kryesore të Java-s, të cilat janë të mbushura me valë të mbetura përjetësisht, si linjat e akullit në kanion. Në bibliotekën Java Swing, mund të gjeni lehtësisht pesë ose gjashtë menaxherë të navigimit me tastierë (KeyboardFocusManager). Në të vërtetë, është e vështirë të gjesh një API Java që nuk është i mbetur. Por ato ende funksionojnë! Mendoj se ekipi i Java do të eliminojë vërtet API-në vetëm nëse ndërfaqja shkakton një problem të dukshëm të sigurisë.
Ja, çfarë po themi, miq: ne, zhvilluesit e softuerit, jemi të gjithë shumë të zënë, dhe në çdo fushë të softuerit përballemi me alternativa konkurruese. Në çdo moment, programuesit në gjuhën X po shqyrtojnë gjuhën Y si një mundësi zëvendësimi. O, nuk më besoni? A doni të thoni Swift? Thuani se të gjithë po migrojnë në Swift dhe askush nuk e braktis atë, apo jo? Oh, sa pak dini. Kompanitë po shqyrtojnë shpenzimet për dy ekipe të zhvillimit mobil (iOS dhe Android) — dhe fillojnë të kuptojnë se këto sisteme të zhvillimit multidisiplinar me emra komikë, si Flutter dhe React Native, në të vërtetë funksionojnë, dhe me ato mund të zvogëlojnë numrin e ekipeve të tyre mobile me gjysmën ose, përndryshe, t'i bëjnë ato dyfish më produktive. Janë në lojë para të vërteta. Po, ka kompromentime, por, nga ana tjetër, para.
Supozoni hipotetikisht se Apple, për inat, ka marrë një shembull nga Guido van Rossum dhe shpalli se Swift 6.0 nuk është i përputhshëm me Swift 5.0, shumë si Python 3 nuk është i përputhshëm me Python 2.
Mundësi të jetë se e kam treguar këtë histori para dhjetë vjetësh, por rreth pesëmbëdhjetë vjet më parë isha në kampin O’Reilly’s Foo Camp me Guido, duke qëndruar në një tendë me Paul Graham dhe një grup të njohurish. Ndodheshim nën një vapë të fortë, duke pritur që Larry Page të fluturojë me helikopterin e tij personal, ndërsa Guido fliste monotone për "Python 3000", të cilin e emërtoi sipas numrit të viteve që do të duhen për të migruar të gjithë atje. I bënim vazhdimisht pyetje pse po shkelte kompatibilitetin, dhe ai përgjigjej: “Unicode”. Dhe ne e pyetëm, nëse na nevojitet të ribëjmë kodin tonë, çfarë përfitimesh të tjera do të shohim? Ai përgjigjej “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Nëse instaloni Google Cloud Platform SDK (“gcloud”), do të merrni njoftimin e mëposhtëm:
I nderuar marrës,
Dëshirojmë t'ju kujtojmë se mbështetja për Python 2 ka skaduar, kështu që shkoooooni të gjithëve
… dhe kështu me radhë. Rrethi i jetës.
Por, çështja është se çdo zhvillues ka një zgjedhje. Dhe nëse i detyron ata të ribëjnë kodin mjaft shpesh, ata mund të mendojnë edhe për të tjera përzgjedhjeve. Ata nuk janë robërit tuaj, për aq sa do të dëshironit. Ata janë mysafirët tuaj. Python mbetet një gjuhë programimi shumë e njohur, por, për fat të keq, Python 3(000) krijoi një kaos në bashkësitë e tij dhe te përdoruesit e tyre, saqë pasojat nuk janë pastruar për pesëmbëdhjetë vjet.
Sa shumë programe Python janë rishkruar në Go (ose Ruby, ose ndonjë alternativë tjetër) për shkak të këtij mosefikasiteti? Sa shumë software të ri janë shkruar në diçka tjetër përveç Python, edhe pse mund të ishin shkruar në Python, nëse Guido nuk do të kishte djegur të gjithë fshatin? E vështirë të thuhet, por Python padyshim ka pësuar. Kjo është një kaos i madh, dhe të gjithë janë në humbje.
Pra, le të supozojmë se Apple merr shembull nga Guido dhe thyen kompatibilitetin. Si mendoni se do të vazhdojë? Hmm, ndoshta 80-90% e zhvilluesve do të rishkruajnë 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ë ndonjë gjuhë konkuruese, si p.sh. Flutter.
Bëni këtë disa herë - dhe do të humbni gjysmën e bazës suaj të përdoruesve. Ashtu si në sport, edhe në botën e programimit forma aktuale gjithashtu ka rëndësi çdo gjë. Çdokush që humb gjysmën e përdoruesve brenda pesë vjetësh do të konsiderohet një Dështim i Madh. Ju duhet të jeni në hap me botën e platformave. Mirëpo, pikërisht këtu heqja dorë nga mbështetja për versionet e vjetra do t'ju shkatërrojë me kalimin e kohës. Sepse çdo herë që hiqni një pjesë të zhvilluesve, ju (a) humbni ata përherë, sepse ata zemërohen me ju për shkeljen e kontratës, dhe (b) u jepni atyre konkurentëve tuaj.
Për ironic, edhe unë ndihmova Google të bëhej një primadonë që injoron pajtueshmërinë mbrapa, kur krijova Grok, një sistem analize dhe kuptimi të kodit burimor që lehtëson automatizimin dhe pajisjen me mjete që bazohen në vetë kodin – duket si IDE, por këtu shërbimi në re ruan pamjet materializuara të të gjitha miliardëve të rreshtave të kodit burimor të Google në një depo të madhe të të dhënave.
Grok ofroi një bazë të fuqishme për zhvilluesit e Google për të kryer riformatim automatizuar në të gjithë bazën e kodit (literalisht në gjithë Google). Sistemi llogarit jo vetëm varësitë tuaja ngjitëse (nga të cilat varet), por edhe varësitë zbritëse (të cilat varen nga ju), kështu që kur të ndryshoni API-në, ju e dini gjithë atë që prishni! Kështu, me ndryshimet e bëra, mund të kontrolloni që çdo përdorues i API-t 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 ta automatizoni plotësisht procesin.
Kjo lejon që baza e kodit në Google brenda të jetë pothuajse mbi-natyrore 'e pastër', pasi ata kanë këta shërbëtorë robotë që lëvizin për gjithë shtëpinë dhe automatikisht pastruan gjithçka, nëse ata e kanë riemëruar SomeDespicablyLongFunctionName në SomeDespicablyLongMethodName, sepse dikush vendosi se ky është një nip i shëmtuar dhe duhet ta çojë në gjumë.
Dhe, sinqerisht, kjo funksionon mjaft mirë për Google... në mënyrë të brendshme. Kam parasysh, po, komuniteti Go në Google me të vërtetë qesh me dashuri me komunitetin Java në Google për shkak të zakonit të tyre të vazhdueshëm të rifaktorizimit. Nëse rilançoni diçka N herë, atëherë kjo do të thotë se ju të paktën 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 N. Por, në përgjithësi, ata mbeten mbi këtë zhurmë dhe e mbajnë kodin 'të pastër'.
Problemet fillojnë kur provojnë të imponojnë një qasje të tillë ndaj klientëve të tyre në shpërndarjen e cloud dhe përdoruesve të tjerë të API-ve.
Pak e njeh Emacs, Android dhe Java; le të shohim platformën e fundit të suksesshme me jetëgjatësi: vetë Web-i. A mund të imagjinoni përmes sa iteracioneve ka kaluar HTTP që nga viti 1995, kur ne përdornim etiketat që qanë <blink> dhe ikonat "Në zhvillim" në faqet e internetit.
Por ky proces akoma funksionon! Dhe këto faqe akoma funksionojnë! Po, djem, shfletuesit janë kampionët botërorë të kompatibilitetit pasardhës. Chrome është një tjetër shembull i një platforme të rrallë nga Google, ku kokat janë montuar siç duhet, dhe, siç e keni marrë me mend, Chrome funksionon efektivisht si një kompani e izoluar, ndaras nga pjesa tjetër e Google.
Dëshiroj gjithashtu të falenderoj miqtë tanë midis zhvilluesve të sistemeve operative: Windows, Linux, JO APPLE SHKO APPLE, FreeBSD e kështu me radhë, për punën e madhe që kanë bërë në mbështetje të përputhshmërisë mbrapa në platformat e tyre të kë_SUCCESS_SHME (Apple merr në maksimum një tre me minus, sepse ata vazhdimisht prishin gjithçka pa ndonjë arsye të drejtë, por ndonjëherë tashmë komuniteti e menaxhon këtë në çdo lëshim, dhe ende kontejnerët me OS X nuk janë plotësisht të vjetëruar... për tani).
Por prisni, do të thoni ju. A nuk po krahasojmë mollët me portokallët — sisteme softuerike autonome në një makinë, si Emacs/JDK/Android/Chrome, me sisteme me shumë serverë dhe API, si në shërbimet në cloud?
Epo, kam shkruar për këtë dje në Twitter, por në stilin e Larry Wall (krijuesi i gjuhës së programimit Perl — shënim i përkthyesit) sipas parimit 'disaster/rules' kërkova fjalën joveprues në faqet për zhvillues nga Google dhe Amazon. Dhe megjithëse AWS ka qindra herë më shumë shërbime sesa GCP, dokumentacioni i zhvilluesve të Google përmend vjetërsimin rreth shtatë herë më shpesh.
Nëse dikush nga Google po e lexon këtë, me siguri ata janë gati të nxjerrin diagramet në stilin e Donald Trump, që në të vërtetë bëjnë gjithçka siç duhet, dhe që unë nuk duhet të bëj krahasime të padrejta, si 'numri i përmendjeve të fjalës deprecated në krahasim me numrin e shërbimeve'.
Por pas kaq shumë vitesh, Google Cloud vazhdon të mbetet shërbimi numër 3 (nuk kam shkruar akoma artikullin për përpjekjen time të dështuar për të qenë numër 2), por nëse i besojmë burimeve të brendshme, ka disa shqetësime se ata mund të bien së shpejti në numrin 4.
Nuk kam argumente të forta për të 'provuar' tezën time. Gjithçka që kam, janë shembujt e ngjyrosur që kam mbledhur gjatë 30 viteve si zhvillues. Kam përmendur tashmë natyrën e thellë filozofike të këtij problemi; në një farë mënyre, ajo është politizuar në komunitetet e zhvilluesve. Disa mendojnë se krijuesit e platformave duhet të kujdesen për kompatibilitetin, ndërsa të tjerë mendojnë se kjo është përgjegjësi përdoruesit (e zhvilluesve vetë). Një nga dyja. Pra, a nuk është me të vërtetë një çështje politike kur vendosim se kush duhet të mbajë kostot për problemet e zakonshme?
Kështu që kjo është politika. Dhe sigurisht do të ketë ndonjë reagim të zemëruar ndaj fjalimit tim.
Si përdorues Duke qenë përdorues i platformës Google Cloud, si dhe duke përdorur AWS për dy vjet (duke punuar në kompaninë Grab), mund të them se ekziston një diferencë e madhe mes filozofive të Amazon dhe Google kur flitet për prioritetet. Nuk bëj zhvillim aktiv në AWS, kështu që nuk e di mirë se sa shpesh heqin API-të e vjetra. Por kam dyshime se kjo ndodh aq shpesh sa në Google. Dhe besoj sinqerisht se ky burim i vazhdueshëm i mosmarrëveshjeve dhe zhgënjimeve në GCP është një nga faktorët më të mëdhenj që ndalon zhvillimin e platformës.
E di që nuk përmenda shembuj konkretë të sistemeve GCP, mbështetjeja e të cilave është ndërprerë. Mund të them se praktikisht e gjithë ajo që kam përdorur, nga rrjetet (nga ato më të vjetra deri te VPC) deri te ruajtjet (Cloud SQL v1-v2), Firebase (tani Firestore me një API krejtësisht të ndryshëm), App Engine (mos e filloni fare), piketat e ndërlidhjes Cloud Endpoint dhe deri te… nuk e di – absolutisht gjithçka kjo m’u detyrua të riprogramoja kodin maksimalisht çdo 2-3 vjet, dhe ata kurrë nuk e automatizuan migrimin për ju, shpesh herë. . Siç duket, kështu do të jetë.
Dhe çdo herë që shoh AWS, pyes veten, çfarë po bëj akoma me GCP. Ata duket se nuk kanë nevojë për klientë. Ata duan blejës. E kuptoni ndryshimin? Le të shpjegoj.
Google Cloud ka , ku njerëzit ofrojnë zgjidhjet e tyre software, dhe për të evituar efektin e një restoranti të zbrazët, duheshin mbushur me disa oferta, prandaj ata nënshkruan një kontratë me kompaninë Bitnami për të krijuar një sërë zgjidhjesh që implementohen "me një klik të vetëm", ose unë duhet të shkruaj "zgjidhje" vetë, sepse këto nuk zgjidhin asgjë. Ato thjesht ekzistojnë si shënja, si mbushje marketingu, dhe Google nuk është shqetësuar kurrë nëse ndonjë nga mjetet punon në të vërtetë. Unë njoh menaxherë produkti që ishin në timon, dhe mund t'ju siguroj se këta njerëz nuk i intereson.
Merrni për shembull zgjidhjen për implementimin e pretenduar "me një klik të vetëm" . Më kanë lodhur për vdekje hilejat e Google Cloud SQL, prandaj fillova të shqyrtoj si alternativë krijimin e një klasteri Percona. Dhe këtë herë Google duket se bëri një punë të mirë; ata po planifikonin të më kursejnë pak kohë dhe përpjekje me një klik të vetëm!
Mirë, le t'ia fillojmë. Le të shkojmë te linku dhe të klikojmë këtë buton. Zgjidhim "Po" për të pranuar të gjitha parametrat e paracaktuar dhe për të vendosur klasterin në projektin tim në Google Cloud. Ha-ha, nuk punon. Asgjë nga ky gajle nuk funksionon. Vegla kurrë nuk u testua dhe filloi të prishët që në minutën e parë, dhe nuk do të më befasojë nëse më shumë se gjysma e "zgjidhjeve" për vendosjen me një klik (tani e kuptojmë pse janë në thonjëza) nuk punojnë. Kjo është një errësirë e plotë, në të cilën nuk është mirë të hyhet.
Por Google teknikisht të blejë. Për ta, kjo është një transaksion. Ata nuk duan asgjë mbështesin. Kjo nuk është pjesë e ADN-së së Google. Po, inxhinierët ndihmojnë njëri-tjetrin, siç dëshmon historia ime me Bigtable. Por në produktet dhe shërbimet për njerëzit e zakonshëm, ata përherë kanë qenë të pamëshirshëm në , i cili nuk përputhet me standardin e fitimit, edhe nëse ka miliona përdorues.
Dhe kjo paraqet një problem të vërtetë për GCP, sepse kjo ADN është pas të gjitha ofertave në cloud. Ata nuk përpiqen të mbështesin diçka; është e njohur mirë se ata refuzojnë të hostojnë (si një shërbim të menaxhuar) ndonjë softuer të palës së tretë. deri sa, derisa AWS të bëjë të njëjtën gjë dhe të ndërtojë një biznes të suksesshëm rreth saj, dhe kur klientët të kërkojnë literalisht të njëjtën gjë. Megjithatë, duhet të bëhen përpjekje të caktuara 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 alienon zhvilluesit.
Dhe kjo nuk është shumë mirë, nëse dëshiron të ndërtosh një platformë jetëgjatë.
Google, zgjohet, qoftë zot! Janë vitet 2020. Ti ende po humb. Është koha të shikosh me kujdes në pasqyrë dhe të përgjigjesh, a dëshiron vërtet të mbetesh në biznesin e cloud.
Nëse dëshiron të mbetesh, atëherë ndalo gjithçka që po thyen.. Djemtë, ju jeni të pasur. Ne, zhvilluesit - jo. Prandaj, kur vjen puna te kush do të merrte mbi vete barrën e kompatibilitetit, ju duhet ta merrni atë përgjegjësi. Nuk është puna jonë.
Sepse ka të paktën tre mjete të tjera të shkëlqyera në bl CLOUD. Ato tërheqin drejt vetes.
Tani do të shkoj të riparoj të gjithë sistemet e mia të prishura. Ah.
Shihemi herën tjetër!
P. S. Një përditësim pas leximit të disa diskutimeve mbi këtë artikull (diskutimet janë të shkëlqyera, për shpirtin). Mbështetjeja për Firebase nuk është ndalur, dhe nuk ka asnjë plan që di unë. Megjithatë, ata kanë një problem të çuditshëm me transmetimin, që bën që klienti Java të ndalojë në App Engine. Një nga inxhinierët e tyre më ndihmoi të përballja me këtë problem, kur punoja në Google, por ata kurrë nuk e rregulluan vërtet gabimin, kështu që kam një zgjidhje të keqe, duke qenë se çdo ditë duhet të riaktivizoj aplikacionin GAE. Kështu ka qenë për katër vjet! Tani ata kanë Firestore. Do të duhet shumë punë për t'u migruar, sepse është një sistem krejtësisht ndryshe, dhe gabimi i Firebase kurrë nuk do të rregullohet. Çfarë përfundimi mund të bëjmë? 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% nativ dhe ai ndalon së punuari çdo disa ditë për shkak të një gabimi të njohur. Çfarë mund të themi për këtë, përveç se ta përdorni në rrezikun tuaj. Po kaloj në Redis.
Po ashtu, kam parë disa përdorues më të përvojshëm të AWS që kanë thënë se AWS zakonisht kurrë nuk ndalon mbështetje për ndonjë shërbim, dhe SimpleDB është një shembull i shkëlqyer. Supozimet e mia se në AWS nuk ka një problem me ndalimin e mbështetjes, siç është rasti me Google, duken të justifikuara.
Për më shumë, vura re se 20 ditë më parë ekipi i Google App Engine thau hosting-un e një biblioteke kritike Go, duke ndaluar aplikacionin GAE nga një nga zhvilluesit kryesorë të Go. Vërtet, doli që është shumë budallaçke.
Më në fund, kam dëgjuar se njerëzit e Google kanë diskutuar këtë çështje dhe në përgjithësi pajtohen me mua (ju dua, djem!). Por duket se ata e shpallin problemin të pazgjidhshëm, sepse në kulturën e Google nuk ka pasur ndonjëherë një strukturë të duhur stimulimesh. Mendoj se do të ishte mirë të gjej pak kohë për të biseduar për përvojën krejt të jashtëzakonshme që kam pasur me inxhinierët e AWS, kur punoja në kompaninë Grab. Shpresoj që ndonjëherë në të ardhmen!
Dhe po, në vitin 2005 ata vërtet kishin lloje të ndryshme mishit të peshkaqenëve në një buffet gjigande në ndihmën 43, dhe më pëlqente më shumë mishi i peshkaqenëve mako. Megjithatë, deri në vitin 2006, Larry dhe Sergey u hoqën nga të gjitha snacks të pa-shëndetshme. Pra, gjatë historisë së Bigtable në vitin 2007, në të vërtetë nuk kishte asnjë peshkaqen, dhe ju kam mashtuar poshtërsisht.
Kur shikoja Bigtable në cloud katër vjet më parë (plus-minus), çmimi ishte pikërisht ky. Duket se tani ka rënë pak, por akoma është shumë e lartë për një depo të zbrazët të të dhënave, sidomos duke pasur parasysh se historia ime e parë tregon sa e parëndësishme është një tabelë e madhe e zbrazët në shkallën e tyre.
Më vjen keq që ofendova komunitetin Apple dhe që nuk thashë asgjë të mirë për Microsoft dhe të tjerë. Të gjithë jeni të drejtë, e vlerësoj shumë të gjitha diskutimet që ka shkaktuar ky artikull! Por ndonjëherë është e nevojshme të provokosh pak për të filluar një diskutim, ashtu siç e kuptoni?
Faleminderit që e lexuat.
Aktualizimi 2, 19.08.2020. Stripe !
Aktualizimi 3, 31.08.2020. Më kontaktoi një inxhinier i Google në Cloud Marketplace, i cili doli të ishte një mik i vjetër. Ai donte të zbulojë pse C2D nuk punonte, dhe përfundimisht zbuluam: arsyeja është se kam krijuar rrjetin tim disa vite më parë, dhe C2D nuk funksionon në rrjete të vjetra për shkak të mungesës së parametrave të subnet-it në modelet e tyre. Mendoj se përdoruesit e ardhshëm të GCP duhet të sigurohen që të kenë inxhinierë të njohur mirë me Google...
Burimi: habr.com
