Neetud Google, ma ei tahtnud enam blogida. Mul on nii palju teha. Blogimine võtab aega, energiat ja loovust, mida saaksin hästi ära kasutada: oma raamatud, , minu mäng ja nii edasi. Aga sa oled mind piisavalt vihale ajanud, et ma pean selle kirjutama.
Nii et teeme selle üle.
Lubage mul alustada lühikese, kuid õpetliku looga sellest ajast, kui Google'is tööle asusin. Ma tean, et olen viimasel ajal Google'i kohta palju halvasti öelnud, kuid see häirib mind, kui mu enda ettevõte teeb regulaarselt ebapädevaid äriotsuseid. Samal ajal peame andma oma kohustuse: Google'i sisemine infrastruktuur on tõeliselt erakordne, võib kindlalt öelda, et täna pole midagi paremat. Google'i asutajad olid palju paremad insenerid, kui mina kunagi olema saan ja see lugu ainult kinnitab seda fakti.
Esiteks natuke tausta: Google'il on andmesalvestustehnoloogia nimega . See oli märkimisväärne tehniline saavutus, üks esimesi (kui mitte esimene) "lõpmatult skaleeritav" võtmeväärtuste salvestaja (K/V): sisuliselt NoSQL-i algus. Tänapäeval läheb Bigtablel endiselt hästi rahvarohkes K/V salvestusruumis, kuid sel ajal (2005) oli see hämmastavalt lahe.
Üks naljakas asi Bigtable’i juures on see, et neil olid suurte indeksidega tahvelarvutiserveriteks nimetatud sisemised juhtimistasandi objektid (osa juurutusest) ja mingil hetkel muutusid need süsteemi skaleerimisel kitsaskohaks. Bigtable'i insenerid mõtlesid, kuidas skaleeritavust rakendada, ja mõistsid äkki, et nad võivad tahvelarvuti serverid asendada muu Bigtable'i salvestusruumiga. Nii et Bigtable on osa Bigtable'i juurutusest. Need laoruumid on olemas kõikidel tasanditel.
Veel üks huvitav detail on see, et Bigtable sai mõnda aega Google'is populaarseks ja üldlevinud, kusjuures igal meeskonnal oli oma hoidla. Nii küsis Larry Page ühel reedesel koosolekul möödaminnes: „Miks meil on rohkem kui üks Bigtable? Miks mitte ainult üks?" Teoreetiliselt peaks ühest salvestusruumist piisama kõigi Google'i salvestusvajaduste jaoks. Muidugi ei läinud nad kunagi praktiliste arengu põhjustel (nagu võimaliku ebaõnnestumise tagajärjed) vaid ühele, kuid teooria oli huvitav. Üks hoidla kogu universumi jaoks (Muide, kas keegi teab, kas Amazon tegi seda oma Sable'iga?)
Igatahes, siin on minu lugu.
Sel ajal töötasin Google'is veidi üle kahe aasta ja ühel päeval sain Bigtable'i insenerimeeskonnalt meili, mis kõlas umbes nii:
Kallis Steve,
Tere Bigtable meeskonnast. Anname teile teada, et kasutate saidil [andmekeskuse nimi] väga-väga vana Bigtable'i kahendfaili. Seda versiooni enam ei toetata ja me tahame aidata teil uusimale versioonile üle minna.
Palun andke mulle teada, kui saate selle probleemiga koos töötada.
Kõike paremat,
Bigtable meeskond
Google'is saate palju kirju, nii et esmapilgul loen midagi sellist:
Lugupeetud saaja!
Tere mõnest meeskonnast. Me tahame suhelda, et bla-bla-bla-bla. Bla bla bla bla bla bla ja kohe bla bla bla.
Palun andke meile teada, kui saate oma väärtuslikku aega bla-bla-bla jaoks ajastada.
Kõike paremat,
Mingi käsk
Ma peaaegu kustutasin selle kohe, kuid teadvuse piiril tundsin valusat ja närivat tunnet, et see mitte päris tundub siiski ametlik kiri ilmselt, et saaja eksis, kuna ma Bigtable'i ei kasutanud.
Aga see oli imelik.
Ülejäänud päeva mõtlesin vaheldumisi tööle ja sellele, millist hailiha proovida mikroköögis, millest vähemalt kolm olid piisavalt lähedal, et tabada mu istmelt hästi sihitud küpsiseviskega, kuid kirjutamise mõte ei jätnud mind kunagi kasvavat kerget ärevust.
Nad ütlesid selgelt mu nime. Ja meil saadeti minu, mitte kellegi teise e-posti aadressile ja see ei ole cc: või bcc:. Toon on väga isiklik ja selge. Võib-olla on see mingi viga?
Lõpuks sai uudishimu minust võitu ja läksin nende mainitud andmekeskuses Borgi konsooli vaatama.
Ja loomulikult oli mul hallatav BigTable'i salvestusruum. Vabandust, mida? Vaatasin selle sisu ja vau! See pärines Codelabi inkubaatorist, kus ma 2005. aasta juunis esimesel nädalal Google'is istusin. Codelab sundis teid Bigtable'i käivitama, et sinna mõned väärtused kirjutada, ja ilmselt ei sulgenud ma pärast seda salvestusruumi kunagi. See töötas endiselt, kuigi oli möödunud rohkem kui kaks aastat.
Sellel lool on mitmeid tähelepanuväärseid aspekte. Esiteks oli Bigtable’i töö Google’i mastaabis nii tühine, et alles kaks aastat hiljem märkas keegi lisamälu ja seda ainult seetõttu, et binaarfaili versioon oli aegunud. Võrdluseks kaalusin kunagi kasutamist minu võrgumängu jaoks. Sel ajal maksis see teenus umbes 16 000 dollarit aastas. tühi Bigtable GCP-s. Ma ei väida, et nad petavad teid, aga minu isikliku arvamuse kohaselt on see tühja kuradi andmebaasi eest palju raha.
Veel üks tähelepanuväärne aspekt on salvestusruum töötab veel kahe aasta pärast. WTF? Andmekeskused tulevad ja lähevad; neil esineb katkestusi, nad läbivad plaanipärase hoolduse, muutuvad kogu aeg. Riistvara uuendatakse, lülitid vahetatakse, kõike täiustatakse pidevalt. Kuidas kurat nad suutsid mu programmi kõigi nende muudatustega kaks aastat käigus hoida? See võib 2020. aastal tunduda tagasihoidlik saavutus, kuid aastatel 2005–2007 oli see üsna muljetavaldav.
Ja kõige imelisem aspekt on see, et minu poole pöördub mõnes teises osariigis asuv väljastpoolt insenerimeeskond, mõne pisikese, peaaegu tühja Bigtable'i eksemplari omaniku poole. null liiklust viimase kahe aasta jooksul – ja pakume abi selle uuendamiseks.
Tänasin neid, kustutasin hoidla ja elu läks nagu ikka. Kuid kolmteist aastat hiljem mõtlen sellele kirjale endiselt. Kuna mõnikord saan Google Cloudilt sarnaseid kirju. Need näevad välja sellised:
Lugupeetud Google'i pilve kasutaja!
Tuletame meelde, et alates 2020. aasta augustist lõpetame teenuse [teie kasutatav oluline teenus], pärast mida ei saa te oma eksemplare uuendada. Soovitame minna üle uusimale versioonile, mis on beetatestimisel, millel pole dokumentatsiooni, migratsiooniteed ja mis on meie lahke abiga varem aegunud.
Oleme pühendunud tagama, et sellel muudatusel oleks minimaalne mõju kõigile Google Cloudi platvormi kasutajatele.
Parimad sõbrad igavesti,
Google'i pilveplatvorm
Kuid ma ei loe selliseid kirju peaaegu kunagi, sest tegelikult öeldakse:
Lugupeetud saaja!
Mine põrgusse. Persse, persse, persse. Loobu kõigest, mida teed, sest see pole oluline. Tähtis on meie aeg. Me raiskame aega ja raha oma jama ülalpidamisele ja oleme sellest väsinud, nii et me ei toeta seda enam. Nii et lõpetage oma kuradi plaanid ja hakake uurima meie nõmedat dokumentatsiooni, kerjama foorumitest sissekannet ja muide, meie uus jama on täiesti erinev vanast jamast, sest me keerasime selle kujunduse päris hulluks, heh, aga see on sinu oma. probleem, mitte meie.
Teeme jätkuvalt jõupingutusi selle nimel, et kõik teie arendused muutuksid ühe aasta jooksul kasutuskõlbmatuks.
Palun mine persse
Google'i pilveplatvorm
Ja fakt on see, et ma saan selliseid kirju umbes kord kuus. Seda juhtub nii sageli ja nii pidevalt, et paratamatult eemale tõugatud mind GCP-st pilvevastasesse laagrisse. Ma ei ole enam nõus sõltuma nende patenteeritud arendustest, sest tegelikult on devopidel lihtsam säilitada avatud lähtekoodiga süsteemi tühjas virtuaalmasinas kui püüda sammu pidada Google'i poliitikaga sulgeda "aegunud" tooted.
Enne kui lähen tagasi Google Cloudi, sest ma isegi mitte lähedal ei ole neid kritiseerinud, vaatame ettevõtte tegevust mõnes muus valdkonnas. Google'i insenerid on uhked oma tarkvarainseneri distsipliini üle ja see põhjustabki probleeme. Uhkus on ettevaatamatute lõks ja see on pannud paljud Google'i töötajad arvama, et nende otsused on alati õiged ja õige olemine (mõne ebamäärase ebamäärase määratluse järgi) on olulisem kui klientidest hoolimine.
Toon mõned juhuslikud näited teistest suurtest projektidest väljaspool Google'it, kuid loodan, et näete seda mustrit kõikjal. See on järgmine: tagasiühilduvus hoiab süsteemid elus ja ajakohasena aastakümneid.
Tagasiühilduvus on kõigi edukate süsteemide disainieesmärk avatud kasutamine, st rakendatud avatud lähtekoodi ja/või avatud standarditega. Mulle tundub, et ma ütlen midagi liiga ilmset, et kõigil on isegi ebamugav, aga ei. See on poliitiline küsimus, nii et näiteid on vaja.
Esimene süsteem, mille ma valin, on vanim: GNU Emacs, mis on omamoodi hübriid Windows Notepadi, OS-i tuuma ja rahvusvahelise kosmosejaama vahel. Seda on veidi raske seletada, kuid lühidalt öeldes on Emacs platvorm, mis loodi 1976. aastal (jah, peaaegu pool sajandit tagasi) programmeerimiseks, et muuta teid produktiivsemaks, kuid maskeerub tekstiredaktorina.
Ma kasutan Emacsi iga päev. Jah, ma kasutan ka IntelliJ-d iga päev, see on kasvanud omaette võimsaks tööriistaplatvormiks. Kuid IntelliJ jaoks laienduste kirjutamine on palju ambitsioonikam ja keerulisem ülesanne kui Emacsi jaoks laienduste kirjutamine. Ja mis veelgi olulisem, kõik Emacsi jaoks kirjutatud on säilinud igavesti.
Kasutan endiselt tarkvara, mille kirjutasin 1995. aastal Emacsi jaoks. Ja ma olen kindel, et keegi kasutab mooduleid, mis on kirjutatud Emacsi jaoks 80ndate keskel, kui mitte varem. Neid võib aeg-ajalt veidi kohandada, kuid see on tõesti üsna haruldane. Ma ei tea midagi, mida oleksin kunagi Emacsi jaoks kirjutanud (ja ma olen palju kirjutanud), mis oleks vajanud ümberehitust.
Emacsil on vananenud olemite jaoks funktsioon nimega make-obsolete. Emacsi terminoloogia põhiliste arvutikontseptsioonide jaoks (nagu mis on "aken") erineb sageli tööstusharu tavapärastest tavadest, kuna Emacs tutvustas neid juba ammu. See on tüüpiline oht neile, kes on oma ajast ees: kõik teie tingimused on valed. Kuid Emacsil on deprekatsiooni mõiste, mida nende kõnepruugis nimetatakse vananemine.
Kuid Emacsi maailmas näib olevat erinev toimiv määratlus. Teistsugune alusfilosoofia, kui soovite.
Emacsi maailmas (ja paljudes teistes valdkondades, mida me allpool käsitleme) tähendab aegunud API olek põhimõtteliselt järgmist: "Te ei tohiks seda lähenemisviisi kasutada, sest kuigi see töötab, kannatab see mitmesuguste puuduste all, mida me nimekiri siin. Kuid päeva lõpuks on see teie valik."
Google'i maailmas tähendab vananemine: "Me rikume oma kohustust teie ees." See on tõsi. Seda see sisuliselt tähendab. See tähendab, et nad sunnivad sind regulaarselt tegema natuke tööd, võib-olla palju tööd, karistuseks nendesse uskumise eest : Meil on parim tarkvara. Kõige kiirem! Teete kõik vastavalt juhistele, käivitate oma rakenduse või teenuse ja siis bam, aasta või kahe pärast läheb see katki.
See on nagu kasutatud auto müük, mis pärast 1500 km kindlasti katki läheb.
Need on kaks täiesti erinevat vananemise filosoofilist määratlust. Google'i lõhna definitsioon . Ma ei usu seda tegelikult kavandatud vananemine samas mõttes nagu Apple. Kuid Google kavatseb kindlasti teie programmid ümberringi katkestada. Tean seda, sest töötasin seal tarkvarainsenerina üle 12 aasta. Neil on ebamäärased sisemised juhised selle kohta, kui palju tagasiühilduvust tuleks järgida, kuid see on lõppkokkuvõttes iga meeskonna või teenuse enda otsustada. Puuduvad ettevõtte- ega inseneritasandi soovitused ning kõige julgem soovitus vananemistsüklite osas on "püüdke anda klientidele 6–12 kuud aega uuendamiseks enne kogu süsteemi purustamist".
Probleem on palju suurem, kui nad arvavad, ja see püsib veel aastaid, sest klienditeenindus ei ole nende DNA-s. Lisateavet selle kohta allpool.
Siinkohal ütlen julgelt, et Emacs on suurel määral ja ühtlane edukas peamiselt sest nad võtavad tagasiühilduvust nii tõsiselt. Tegelikult on see meie artikli tees. Edukad, pikaealised avatud süsteemid võlgnevad oma edu mikrokogukondadele, kes on nende ümber aastakümneid elanud laiendused/pluginad. See on ökosüsteem. Olen juba rääkinud platvormide olemusest ja nende tähtsusest ning sellest, kuidas Google pole kogu oma ettevõtte ajaloo jooksul kunagi aru saanud, mis läheb eduka avatud platvormi loomisel väljaspool Androidi või Chrome'i.
Tegelikult peaksin lühidalt mainima Androidi, sest ilmselt mõtlete sellele.
Esiteks Android ei ole Google. Neil pole üksteisega peaaegu midagi ühist. Android on ettevõte, mille Google ostis 2005. aasta juulis, ettevõttel lubati enam-vähem autonoomselt tegutseda ja see on vahepealsetel aastatel tegelikult suures osas puutumata jäänud. Android on kurikuulus tehnoloogiapakk ja sama kurikuulus kipitav organisatsioon. Nagu üks Google'i töötaja ütles: "Te ei saa lihtsalt Androidi sisse logida."
Eelmises artiklis arutasin, kui halvad olid mõned Androidi varased disainiotsused. Kurat, kui ma seda artiklit kirjutasin, lasid nad välja jama nimega "kiirrakendused", mis on nüüd (üllatus!) , ja tunnen kaasa, kui olite piisavalt rumal, et kuulata Google'it ja teisaldada oma sisu nendesse installimata avatavatesse rakendustesse.
Kuid siin on erinevus, oluline erinevus, mis seisneb selles, et Androidi inimesed mõistavad tõesti, kui olulised on platvormid, nad annavad endast parima, et vanad Androidi rakendused töös hoida. Tegelikult on nende jõupingutused tagasiühilduvuse säilitamiseks nii ekstreemsed, et isegi mina paar aastat tagasi Androidi divisjonis viibides püüdsin neid veenda, et nad loobuksid mõnede vanimate seadmete ja API-de toetamisest (ma eksisin , nagu paljudes muudes asjades minevikus ja olevikus. Vabandust, Androidi poisid! Nüüd, kui olen Indoneesias käinud, saan aru, miks meil neid vaja on).
Androidi inimesed suruvad tagurpidi ühilduvuse peaaegu kujuteldamatutesse äärmustesse, kuhjades oma süsteemidesse ja tööriistaahelatesse tohutul hulgal pärandtehnilisi võlgu. Issand jumal, sa peaksid nägema mõningaid hullumeelseid asju, mida nad peavad oma ehitussüsteemis tegema, seda kõike ühilduvuse nimel.
Selle eest annan Androidile ihaldatud auhinna "You're Not Google". Nad tõesti ei taha saada Google'iks, kes ei oska luua vastupidavaid platvorme, vaid Androidiks teab, kuidas seda teha. Ja nii on Google ühes osas väga tark: lubades inimestel Androidis asju omal moel teha.
Androidi kiirrakendused olid aga üsna rumal idee. Ja kas sa tead, miks? Sest nad nõudsid kirjutage oma rakendus ümber ja kujundage see ümber! Inimesed kirjutavad kaks miljonit taotlust lihtsalt ümber. Ma arvan, et Instant Apps oli mõne Google'i töötaja idee.
Kuid on vahe. Tagasiühilduvus on kõrge hinnaga. Android kannab ise nende kulude koorma, samas kui Google nõuab selle koormuse kandmist sa oled, maksv klient.
Androidi pühendumust tagasiühilduvusele näete oma API-des. Kui teil on neli või viis erinevat alamsüsteemi, mis teevad sõna otseses mõttes sama asja, on see kindel märk, et keskmes on pühendumus tagasiühilduvusele. Mis on platvormide maailmas sünonüümiks pühendumusele teie klientidele ja teie turule.
Google'i peamine probleem on siin nende uhkus oma insenerihügieeni üle. Neile ei meeldi, kui sama asja tegemiseks on palju erinevaid viise, kusjuures vanad, vähem soovitavad viisid istuvad uute, uhkemate viiside kõrval. See suurendab süsteemi uute kasutajate õppimiskõverat, suurendab vanade API-de hooldamise koormust, aeglustab uute funktsioonide kiirust ja peamine patt on see, et see pole ilus. Google – nagu leedi Ascot Tim Burtoni filmist Alice in Wonderland:
Leedi Ascot:
- Alice, kas sa tead, mida ma kõige rohkem kardan?
- Aristokraatia allakäik?
- Ma kartsin, et oleksin koledad lapselapsed.
Kauni ja praktilise vahelise kompromissi mõistmiseks heidame pilgu kolmandale edukale platvormile (pärast Emacsi ja Androidi) ja vaatame, kuidas see töötab: Java ise.
Java-l on palju aegunud API-sid. Depreation on Java programmeerijate seas väga populaarne, isegi populaarsem kui enamikus programmeerimiskeeltes. Java ise, põhikeel ja raamatukogud kaotavad API-d pidevalt.
Kui võtta vaid üks näide tuhandetest, peetakse aegunuks. Alates Java 1.2 väljalaskmisest 1998. aasta detsembris on see aegunud. Sellest on möödunud 22 aastat, kui see aegunud oli.
Kuid minu tegelik kood tootmises tapab endiselt niite iga päev. Kas sa tõesti arvad, et see on hea? Absoluutselt! Muidugi, kui ma täna koodi ümber kirjutaksin, rakendaksin seda teisiti. Kuid minu mängu kood, mis on viimase kahe aastakümne jooksul sadu tuhandeid inimesi õnnelikuks teinud, on kirjutatud funktsiooniga, mis sulgeb liiga kaua rippuvad lõimed ja ma pole kunagi pidanud seda muutma. Tunnen oma süsteemi paremini kui keegi teine, mul on sõna otseses mõttes 25-aastane kogemus sellega tootmises ja võin kindlalt öelda: minu puhul on nende konkreetsete töötajate lõimede sulgemine täielikult kahjutu. Selle koodi ümberkirjutamine ei ole seda aega ja vaeva väärt ning tänan Larry Ellisoni (ilmselt), et Oracle ei sundinud mind seda ümber kirjutama.
Oracle mõistab ilmselt ka platvorme. Kes teab.
Tõendeid võib leida kõigist Java API-dest, mis on täis vananemislaineid, nagu liustiku jooned kanjonis. Java Swingi teegist leiate hõlpsalt viis või kuus erinevat klaviatuuri navigeerimishaldurit (KeyboardFocusManager). Tegelikult on raske leida Java API-d, mis ei oleks aegunud. Aga nad töötavad ikka! Arvan, et Java meeskond eemaldab API tõeliselt ainult siis, kui liides tekitab silmatorkavaid turvaprobleeme.
Siin on asi, inimesed: meie, tarkvaraarendajad, oleme kõik väga hõivatud ja igas tarkvaravaldkonnas seisame silmitsi konkureerivate alternatiividega. Igal ajahetkel kaaluvad keele X programmeerijad keelt Y võimaliku asendusena. Oh, sa ei usu mind? Kas soovite seda nimetada Swiftiks? Nagu kõik rändavad Swifti ja keegi ei hülga seda, eks? Vau, kui vähe sa tead. Ettevõtted arvestavad kahe mobiilse arendusmeeskonna (iOS ja Android) kulusid – ja nad hakkavad mõistma, et need platvormidevahelised arendussüsteemid naljakate nimedega, nagu Flutter ja React Native, tegelikult töötavad ja neid saab kasutada nende seadmete suuruse vähendamiseks. mobiilsed meeskonnad kaks korda või, vastupidi, muudavad need kaks korda tootlikumaks. Kaalul on päris raha. Jah, on kompromisse, aga teisest küljest raha.
Oletame hüpoteetiliselt, et Apple võttis rumalalt Guido van Rossumilt vihje ja teatas, et Swift 6.0 ei ühildu Swift 5.0-ga, nagu Python 3 ei ühildu Python 2-ga.
Rääkisin seda lugu vist kümmekond aastat tagasi, aga umbes viisteist aastat tagasi käisin koos Guidoga O'Reilly's Foo Campis, istusin koos Paul Grahamiga telgis ja hunnikus suuri võtteid. Istusime palavas kuumuses ja ootasime, millal Larry Page oma isikliku helikopteriga välja lendab, samal ajal kui Guido surises umbes "Python 3000" peal, millele ta andis nime aastate järgi, mis kulub selleks, et kõik sinna rännata. Küsisime talt pidevalt, miks ta ühilduvust rikub, ja ta vastas: "Unicode." Ja me küsisime, et kui peaksime oma koodi ümber kirjutama, siis milliseid eeliseid me veel näeksime? Ja ta vastas: "Yoooooooooooooouuuuuuuuniiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiinmäkid."
Kui installite Google Cloud Platformi SDK ("gcloud"), saate järgmise teatise.
Lugupeetud saaja!
Tuletame teile meelde, et Python 2 tugi on aegunud, nii et persse
… ja nii edasi. Eluring.
Kuid asi on selles, et igal arendajal on valik. Ja kui sunnite neid piisavalt sageli koodi ümber kirjutama, võivad nad sellele mõelda muu valikuid. Nad ei ole teie pantvangid, hoolimata sellest, kui väga te neid sooviksite. Nad on teie külalised. Python on endiselt väga populaarne programmeerimiskeel, aga pagan, Python 3(000) lõi nii iseenesest, oma kogukondades kui ka oma kogukondade kasutajate seas sellise segaduse, et selle tagajärgi pole juba viisteist aastat selgeks tehtud.
Kui palju Pythoni programme on Go (või Ruby või mõne muu alternatiivi) keeles selle tagasiühilduvuse tõttu ümber kirjutatud? Kui palju uut tarkvara on kirjutatud muus kui Pythonis, kuigi see võib olla Pythonis kirjutatud, kui Guido poleks kogu küla maha põletanud? Raske öelda, kuid Python on selgelt kannatanud. See on tohutu segadus ja kõik kaotavad.
Oletame, et Apple võtab Guidolt eeskuju ja rikub ühilduvuse. Mis sa arvad, mis juhtub järgmisena? No võib-olla 80-90% arendajatest kirjutab võimalusel oma tarkvara ümber. Ehk siis 10-20% kasutajaskonnast läheb automaatselt mõnele konkureerivale keelele, näiteks Flutterile.
Tehke seda mitu korda ja kaotate poole oma kasutajabaasist. Nii nagu spordis, nii ka programmeerimismaailmas loeb hetkevorm. kõik. Igaüht, kes kaotab viie aasta jooksul pooled oma kasutajatest, peetakse suureks paksuks kaotajaks. Peate olema platvormide maailmas trendikas. Kuid see on koht, kus vanemate versioonide mittetoetamine rikub teid aja jooksul. Sest iga kord, kui mõnest arendajast vabanete, (a) kaotate nad igaveseks, sest nad on teie peale lepingu rikkumise pärast vihased, ja (b) annate need oma konkurentidele ära.
Iroonilisel kombel aitasin Google'il saada selliseks primadonnaks, kes eirab tagasiühilduvust, kui lõin Groki, lähtekoodi analüüsi- ja mõistmissüsteemi, mis muudab koodi enda automatiseerimise ja instrumenteerimise lihtsaks – sarnaselt IDE-ga, kuid siin salvestab pilveteenus. realiseerinud esindused kõigist miljarditest Google'i lähtekoodi ridadest suures andmelaos.
Grok pakkus Google'i töötajatele võimsa raamistiku automatiseeritud ümbertegemise teostamiseks kogu nende koodibaasis (sõna otseses mõttes kogu Google'is). Süsteem ei arvuta mitte ainult teie ülesvoolu sõltuvusi (millest te sõltute), vaid ka allavoolu (mis on teie otsustada), nii et kui muudate API-sid, teate kõiki, keda rikute! Nii saate muudatuste tegemisel veenduda, et iga teie API tarbija on uuele versioonile värskendanud, ja tegelikult saate sageli nende kirjutatud Rosie tööriista abil protsessi täielikult automatiseerida.
See võimaldab Google'i koodibaasi sisemiselt olla peaaegu üleloomulikult puhas, kuna need robotteenijad sibavad mööda maja ja koristavad automaatselt kõike, kui nad nimetasid funktsiooni SomeDespicablyLongFunctionName ümber SomeDespicablyLongMethodName'iks, kuna keegi otsustas, et see on kole lapselaps ja ta tuleb magama panna.
Ja ausalt öeldes töötab see Google'i jaoks päris hästi... sisemiselt. Ma mõtlen, jah, Google'i Go kogukonnal on Google'i Java kogukonnaga hea naer, kuna neil on harjumus pidevalt ümber töötada. Kui taaskäivitate midagi N korda, tähendab see, et te mitte ainult ei keeranud selle N-1 korda üles, vaid mõne aja pärast saab üsna selgeks, et tõenäoliselt keerasite selle ka N-ndal katsel sassi. Kuid üldiselt jäävad nad kogu sellest kärast kõrgemale ja hoiavad koodi "puhtana".
Probleem saab alguse siis, kui nad üritavad seda suhtumist oma pilveklientidele ja teiste API-de kasutajatele peale suruda.
Olen teile veidi tutvustanud Emacsi, Androidi ja Java-d; vaatame viimast edukat pikaealist platvormi: veebi ennast. Kas kujutate ette, kui palju iteratsioone on HTTP läbinud alates 1995. aastast, kui kasutasime vilkuvaid silte? ja "Ehitamisel" ikoonid veebilehtedel.
Aga see töötab ikka! Ja need lehed töötavad siiani! Jah, poisid, brauserid on tagasiühilduvuse maailmameistrid. Chrome on veel üks näide haruldasest Google'i platvormist, mille pea on korralikult kinni keeratud, ja nagu võis arvata, toimib Chrome tõhusalt liivakastiettevõttena, mis on ülejäänud Google'ist eraldiseisev.
Samuti tahan tänada meie sõpru operatsioonisüsteemide arendajatest: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD jne. miinus on see, et nad lõhuvad kogu aeg kõike ilma mõjuva põhjuseta, kuid kogukond saab sellest iga väljalaskega kuidagi mööda ja OS X konteinerid pole ikka veel täiesti vananenud... veel).
Aga oota, ütled sa. Kas me ei võrdle õunu apelsinidega – eraldiseisvaid tarkvarasüsteeme ühes masinas, nagu Emacs/JDK/Android/Chrome, võrreldes mitme serveriga süsteemidega ja API-dega, nagu pilveteenused?
Noh, ma säutsusin selle kohta eile, aga Larry Walli (programmeerimiskeele Perl looja – ca per.) stiilis "imeb/reeglid" põhimõttel otsisin selle sõna üles. vananenud Google'i ja Amazoni arendaja saitidel. Ja kuigi AWS-il on sadu korda rohkem teenusepakkumisi kui GCP, mainitakse Google'i arendaja dokumentatsioonis kulumist umbes seitse korda sagedamini.
Kui keegi Google'ist seda loeb, on ta tõenäoliselt valmis välja tõmbama Donald Trumpi stiilis tabelid, mis näitavad, et nad teevad tegelikult kõike õigesti ja et ma ei tohiks teha ebaausaid võrdlusi, nagu "sõna aegunud mainimiste arv versus teenuste arv" "
Kuid pärast kõiki neid aastaid on Google Cloud endiselt teenus nr 3 (ma pole kunagi kirjutanud artiklit ebaõnnestunud katsest saada nr 2), kuid kui uskuda siseringi, siis on muresid, mis võivad peagi langeda. nr 4.
Mul ei ole oma lõputöö "tõendamiseks" kaalukaid argumente. Mul on vaid värvikad näited, mida olen arendajana 30 aasta jooksul kogunud. Olen juba maininud selle probleemi sügavalt filosoofilist olemust; mõnes mõttes on see arendajakogukondades politiseeritud. Mõned usuvad seda loojad platvormid peaksid ühilduvusest hoolima, samas kui teised arvavad, et see on probleem kasutajad (arendajad ise). Üks kahest. Tõepoolest, kas see pole poliitiline küsimus, kui me otsustame, kes peaks kandma ühiste probleemide kulud?
Nii et see on poliitika. Ja ilmselt tuleb mu kõnele vihaseid vastuseid.
Kui kasutaja Google Cloud Platform ja kaks aastat AWS-i kasutajana (Grabis töötades) võin öelda, et prioriteetide osas on Amazoni ja Google'i filosoofia vahel tohutu erinevus. Ma ei arenda aktiivselt AWS-i, nii et ma ei tea väga hästi, kui sageli nad vanu API-sid eemaldavad. Kuid on kahtlus, et seda ei juhtu peaaegu nii sageli kui Google'is. Ja ma usun siiralt, et see GCP pidevate vaidluste ja pettumuse allikas on üks suurimaid platvormi arengut takistavaid tegureid.
Tean, et ma ei nimetanud konkreetseid näiteid GCP-süsteemidest, mida enam ei toetata. Võin öelda, et peaaegu kõik, mida olen kasutanud, alates võrkudest (vanimast kuni VPC-ni) kuni salvestusruumini (Cloud SQL v1-v2), Firebase'i (nüüd täiesti erineva API-ga Firestore), App Engine'i (ärme isegi alusta) , pilve lõpp-punktid Cloud Endpoint ja kuni... Ma ei tea - absoluutselt kõike seda sundisid teid maksimaalselt 2–3 aasta pärast koodi ümber kirjutama ja nad ei automatiseerinud teie eest migreerimist kunagi ja sageli . Justkui nii pidi olema.
Ja iga kord, kui ma AWS-i vaatan, küsin endalt, miks ma ikka veel GCP-s kasutan. Ilmselgelt ei vaja nad kliente. Nad vajavad ostjad. Kas saate aru erinevusest? Las ma seletan.
Google Cloudil on , kus inimesed pakuvad välja oma tarkvaralahendusi ja tühja restorani efekti vältimiseks pidid nad selle mõne ettepanekuga täitma, nii et nad sõlmisid ettevõttega Bitnami lepingu, et luua hulk lahendusi, mis juurutatakse ühe klõpsuga või peaksid Kirjutan selle ise "lahendusteks", sest need ei lahenda kuradi asja. Need eksisteerivad lihtsalt märkeruutudena, turunduse täiteainena ja Google pole kunagi hoolinud, kas mõni tööriist ka tegelikult töötab. Tean tootejuhte, kes on olnud juhiistmel, ja võin teile kinnitada, et need inimesed ei hooli.
Võtke näiteks väidetavalt "ühe klõpsuga" juurutuslahendus. . Olin Google'i pilve SQL-i segadustest surnud, nii et hakkasin alternatiivina otsima oma Percona klastri ehitamist. Ja seekord tundus, et Google tegi head tööd, nad säästsid minult aega ja vaeva ühe nupuvajutusega!
Tore, lähme. Järgime linki ja klõpsake seda nuppu. Kõigi vaikeseadetega nõustumiseks ja klastri juurutamiseks oma Google'i pilveprojektis valige „Jah”. Haha, see ei tööta. Ükski see jama ei tööta. Tööriista ei testitud kordagi ja see hakkas mädanema esimesest minutist ning mind ei üllataks, kui üle poole "lahendustest" on ühe klõpsuga juurutamine (nüüd saame aru, miks jutumärgid) üldiselt ei tööta. See on täiesti lootusetu pimedus, kuhu on parem mitte siseneda.
Kuid Google'il on õigus tunge sa neid kasutama. Nad tahavad, et sa seda teeksid ostetud. Nende jaoks on see tehing. Nad ei taha midagi toetus. See ei ole osa Google'i DNA-st. Jah, insenerid toetavad üksteist, nagu näitab minu lugu Bigtable'iga. Kuid tavainimestele mõeldud toodetes ja teenustes nad seda teevad alati olid sisse halastamatud , mis ei vasta kasumlikkuse latti isegi siis, kui sellel on miljoneid kasutajaid.
Ja see on GCP jaoks tõeline väljakutse, sest see on DNA kõigi pilvepakkumiste taga. Nad ei püüa midagi toetada; On hästi teada, et nad keelduvad võõrustamast (hallatava teenusena) mis tahes kolmanda osapoole tarkvara kuni, kuni AWS teeb sama ja ehitab selle ümber eduka äri ning kui kliendid nõuavad sõna otseses mõttes sama. Siiski on vaja pingutada, et Google saaks midagi toetada.
Selline tugikultuuri puudumine koos mentaliteediga "murrame selle ilusamaks muutmiseks" võõrandab arendajaid.
Ja see pole hea, kui soovite ehitada pikaealise platvormi.
Google, ärka üles, neetud. Praegu on aasta 2020. Sa ikka kaotad. On aeg heita pilk peeglisse ja vastata, kas soovite tõesti pilveärisse jääda.
Kui tahad jääda, siis lõpeta kõige lõhkumine. Poisid, te olete rikkad. Meie, arendajad, mitte. Seega, kui rääkida sellest, kes ühilduvuse koorma enda kanda võtab, peate selle enda peale võtma. Mitte meie jaoks.
Sest seal on veel vähemalt kolm tõeliselt head pilvi. Nad viipavad.
Ja nüüd jätkan kõigi oma katkiste süsteemide parandamisega. Eh.
Järgmise korrani!
PS Värskendage pärast mõne selle artikli arutelu lugemist (arutelud on suurepärased, btw). Firebase'i tugi ei ole katkestatud ja ma ei tea ühtegi plaani. Neil on aga vastik voogesituse viga, mis põhjustab Java kliendi App Engine'is seiskumise. Üks nende inseneridest aitas mul selle probleemi lahendada, kui töötasin Google'is, kuid nad ei parandanud kunagi viga, nii et mul on halb lahendus, pean GAE rakenduse iga päev taaskäivitama. Ja nii on see kestnud neli aastat! Nüüd on neil Firestore. Sellele üleminek nõuab palju tööd, kuna see on täiesti erinev süsteem ja Firebase'i viga ei parandata kunagi. Millise järelduse saab teha? Saate abi saada kui töötate ettevõttes. Olen arvatavasti ainus, kes kasutab Firebase'i GAE-s, kuna login 100% omarakenduses alla 100 võtme ja see lakkab töötamast iga paari päeva tagant teadaoleva vea tõttu. Mis ma oskan muud öelda, kui kasutada seda omal vastutusel. Vahetan Redise vastu.
Olen ka näinud, et mõned kogenumad AWS-i kasutajad ütlevad, et tavaliselt ei lõpeta AWS kunagi ühegi teenuse toetamist ja SimpleDB on suurepärane näide. Minu oletused, et AWS-il ei ole samasugune tugihaigus nagu Google'il, näivad olevat õigustatud.
Lisaks märkasin, et 20 päeva tagasi rikkus Google App Engine'i tiim kriitilise Go teegi hostimise, sulgedes ühe Go põhiarendaja GAE-rakenduse. See oli tõesti loll.
Lõpuks olen kuulnud, et Google’i töötajad on seda teemat juba arutanud ja üldiselt minuga nõus (love you guys!). Kuid nad näivad arvavat, et probleem on lahendamatu, sest Google'i kultuuril pole kunagi olnud õiget stiimulistruktuuri. Arvasin, et oleks hea võtta veidi aega, et arutada täiesti hämmastavat kogemust, mida sain Grabis töötades AWS-i inseneridega töötades. Kunagi tulevikus, ma loodan!
Ja jah, 2005. aastal oli neil hoone 43 hiiglaslikus puhvetis erinevat tüüpi hailiha ja minu lemmik oli vasarhai liha. 2006. aastaks said Larry ja Sergei aga kõigist ebatervislikest suupistetest lahti. Nii et Bigtable’i loo ajal 2007. aastal haid tõesti polnud ja ma petsin teid.
Kui ma neli aastat tagasi pilve Bigtable'i vaatasin (anna või võta), siis see hind oli siin. Tundub, et see on nüüd veidi langenud, kuid tühja andmelao jaoks on see ikka kohutavalt palju, eriti kuna minu esimene lugu näitab, kui ebaoluline on tühi suur tabel nende mastaabis.
Vabandust, et solvasin Apple'i kogukonda ega öelnud midagi ilusat Microsofti jms kohta. Kõik on korras, hindan väga kogu selle artikli tekitatud arutelu! Aga vahel tuleb arutelu alustamiseks veidi laineid lüüa, tead?
Täname lugemise eest.
Värskendus 2, 19.08.2020. Triip !
Värskendus 3, 31.08.2020. Minuga võttis ühendust Cloud Marketplace'i Google'i insener, kes osutus mu vanaks sõbraks. Ta tahtis välja selgitada, miks C2D ei tööta, ja lõpuks saime aru, et see oli tingitud sellest, et olin aastaid tagasi oma võrgu ehitanud ja C2D ei töötanud pärandvõrkudes, kuna nende mallides puudus alamvõrgu parameeter. Arvan, et potentsiaalsetele GCP kasutajatele on kõige parem veenduda, et nad tunnevad Google'is piisavalt insenere...
Allikas: www.habr.com