Kuradi, Google, ma ei tahtnud jälle blogisse kirjutada. Mul on nii palju teha. Blogimise jaoks on vaja aega, energiat ja loomingulisust, mida võiksin kasutada paremini: minu raamatud, , mu mäng ja nii edasi. Aga sa oled mind piisavalt vihasteks ajanud, et see on kirjutamise ära teeninud.
Nii et lõpetame selle.
Alustan väikese, kuid õpetliku looga ajast, mil ma Google'is töötama hakkasin. Tean, et olen hiljuti rääkinud palju halba Google'ist, kuid see ärritab mind, kui oma ettevõte teeb regulaarselt ebamugavaid ärilisi otsuseid. Sellegipoolest tuleb tunnustada: Google'i sisemine infrastruktuur on tõeliselt erakordne, võib julgelt väita, et täna pole midagi paremat. Google'i asutajad olid palju paremad insenerid, kui ma kunagi olema hakkan, ja see lugu kinnitab seda fakti.
Esiteks veidi tausta: Google'il on andmete salvestamise tehnoloogia nimega . See oli suur tehniline saavutus, üks esimesi (kui mitte esimene) "lõpmatult skaleeritav" võtme-väärtuse salvestus (key-value store, K/V): põhimõtteliselt NoSQL algus. Tänapäeval tunneb Bigtable end endiselt hästi üsna rahvarohkes K/V salvestusruumis, kuid sel ajal (2005. aastal) oli see uskumatult lahe.
Üks naljakas detail Bigtable'i kohta on see, et neil olid sisemised juhtimistaseme objektid (osana rakendusest), mida nimetatakse tablet-serveriteks, suurte indeksitega, ja mingil hetkel muutusid nad süsteemi skaleerimise kitsaskohaks. Bigtable'i insenerid pusisid, kuidas skaleeritavust rakendada, ja äkitselt mõistsid nad, et saavad asendada tablet-serverid teiste Bigtable'i salvestustega. Nii et Bigtable on osa Bigtable'i rakendusest. Need salvestused on kõikidel tasanditel.
Veel huvitav detail on see, et Bigtable'dest sai mingil hetkel Google'is väga populaarsed ja iga meeskond omas oma salvestust. Seetõttu küsis Larry Page ühe reede koosoleku ajal pealiskaudselt: "Miks meil on rohkem kui üks Bigtable? Miks me ei saa hakkama vaid ühega?" Teoreetiliselt oleks pidanud üht salvestust piisama kõigiks Google'i salvestamisvajadusteks. Loomulikult ei läinud nad kunagi ainult ühelt praktiliste arendusprobleemide tõttu (nt võimaliku rikke tagajärjed), kuid teooria oli huvitav. Üks salvestus kogu Universumile (üldse, kas keegi teab, kas Amazon tegi oma Sable'iga sama?)
Nii või naa, siin on minu lugu.
Sel ajal olin ma Google'is töötanud natuke üle kahe aasta ja ühel päeval sain kirja Bigtable'i insenerimeeskonnalt, mille sisu oli umbes selline:
Lugupeetud Steve,
Tere Bigtable'i meeskonnalt. Tahame teavitada, et andmekeskuses [data center name] kasutate väga, väga vana Bigtable'i binaarfaili. See versioon ei ole enam toetatud ja tahame aidata teil üle minna viimasele versioonile.
Palun andke teada, kui saate plaanida aega selle küsimuse lahendamiseks koos töötamiseks.
Parimate soovidega,
Bigtable'i meeskond
Google'is tuleb sul palju postkasti, seega lugesin esmapilgul umbes nii:
Lugupeetud saaja,
Tere mingist meeskonnast. Tahame teavitada, et blaa-blaa-blaa-blaa-blaa. Blaa-blaa-blaa-blaa-blaa-blaa ja blaa-blaa-blaa kohe.
Palun andke meile teada, kui saate plaanida osa oma väärtuslikust ajast blaa-blaa-blaa jaoks.
Parimate soovidega,
Mingisugune meeskond
Ma peaaegu kustutasin selle kohe, kuid teadvuse serval tundsin vaevalist, torkivat tunnet, et see ei ole täpselt formaalse kirja moodi, kuigi ilmne, et adressaat oli vale, kuna ma ei kasutanud Bigtable'i.
Aga see oli kummaline.
Ülejäänud päev mõtlesin kordamööda tööl ja sellele, millist hainaha tüüp mikro-köögis proovida, kus vähemalt kolm olid piisavalt lähedal, et visata mu kohalt täpselt küpsiseheitmisega, kuid mõte kirjast ei lahkunud mind kasvava kerge ärevuse tundega.
Nad kindlasti mainisid nad minu nime. Ja kiri saadeti minu e-posti aadressile, mitte kellegi teise nimele, ega ollut cc: või bcc:. Toon on väga isiklik ja selge. Võib-olla on see mingi viga?
Lõpuks võitis uudishimu jagu ja ma läksin vaatama Borgi konsooli andmekeskuses, millest nad rääkisid.
Ja muidugi oli mul haldamises BigTable'i salvestus. Mida? Vaatasin selle sisu ja – küll see oli! See oli Codelabi inkubaatorist, kus ma olin esimese nädala Google’is juunis 2005. Codelab sundis sind käivitama Bigtable'i, et salvestada sinna mõned väärtused, ja ma ilmselt ei sulgenud seda salvestust pärast seda. See töötas endiselt, kuigi möödas oli üle kahe aasta.
Selles loos on mitmeid tähelepanuväärseid aspekte. Esiteks, Bigtable'i töö oli Google'is nii tähtsusetu, et ainult kaks aastat hiljem keegi märkas, et see salvestus on üleliigne, ja seda ainult seetõttu, et binaari versioon oli aegunud. Võrdluseks, ma olen kunagi kaalunud Bigtable'i kasutamist oma veebi mängu jaoks. Sel ajal maksis see teenus umbes $16 000 aastas tühja Bigtable'i kohta GCP-s. Ma ei ütle, et nad petavad teid, aga minu isikliku arvamuse kohaselt on see palju raha tühja kuradima andmebaasi eest.
Veel üks tähelepanuväärne aspekt on see, et salvestus töötas endiselt kahel aastal hiljem. WTF? Andmekeskused tulevad ja lähevad; nad kogevad katkestusi, nad läbivad planeeritud hooldust, nad muutuvad pidevalt. Riistvara uuendatakse, lülitid vahetatakse välja, kõik paraneb pidevalt. Kuidas paganama nad suutsid mu programmi kahe aasta jooksul aktiivsena hoida, arvestades kõiki neid muudatusi? See võib 2020. aastal tunduda tagasihoidlik saavutus, kuid 2005-2007 oli see üsna muljetavaldav.
Ja kõige imelisem aspekt on see, et mõni välismaine inseneritehnika meeskond mingist teisest osariigist pöördub minu poole, kellel on mingi tilluke, praktiliselt tühi Bigtable'i eksemplar, millel on null liiklust möödunud kahe aasta jooksul – ja pakuvad abi selle uuendamiseks.
Ma tänasin neid, kustutasin salvestuse ja elu läks edasi. Kuid kolmeteistkümne aasta pärast mõtlen endiselt sellele kirjale. Sest mõnikord saan ma sarnaseid kirju Google Cloudilt. Need näevad välja sellised:
Lugupeetud Google Cloudi kasutaja,
Tuletame meelde, et lõpetame teenuse [teie kasutatav oluline teenus] toe alates 2020. aasta augustist, pärast mida te ei saa oma instantsse uuendada. Soovitame minna üle viimasele versioonile, mis on beetatestimises, millel ei ole mingit dokumentatsiooni, migratsiooniteed ja mis on meie lahkel abiga juba ette aegunud.
Meie eesmärk on, et see muudatus mõjutaks Google Cloudi platvormi kõiki kasutajaid minimaalselt.
Parimad sõbrad igavesti,
Google'i pilveplatvorm
Aga ma ei loe peaaegu kunagi selliseid kirju, sest tegelikult ütlevad need järgmist:
Lugupeetud saaja,
Mine pekki. Mine, mine, mine. Jäta kõik, mida sa teed, sest see pole oluline. Mis on oluline, on meie aeg. Me kulutame aega ja raha, et hoida oma jama korras, ja me oleme sellest väsinud, nii et me ei toeta seda enam. Nii et viska oma kuradi plaanid prügikasti ja alusta meie sitase dokumentatsioonis surfamist, kerjates jäänuseid foorumites ja muide, meie uus jama on täiesti erinev vanast jamast, sest me oleme seda disaini üsna palju rikkunud, heh, aga see on sinu probleem, mitte meie.
Me pingutame endiselt, et kõik sinu arendused muutuksid kasutuskõlbmatuks ühe aasta jooksul.
Palun mine pekki,
Google'i pilveplatvorm
Ja asi on selles, et ma saan selliseid kirju umbes kord kuus. See juhtub nii tihti ja pidevalt, et need paratamatult tõukavad mind GCP-st pilveteenuste vastaste ridadesse. Ma ei soovi enam sõltuda nende patenditud lahendustest, sest tegelikult on devopsil lihtsam hallata avatud lähtekoodiga süsteemi puhtal virtuaalmasinal kui püüda joosta Google'i ajakava järgi, mis sulgeb 'aegunud' tooteid.
Enne kui ma tagasi Google Cloudi lähen, sest ma isegi ei ole lähedal Ärge lõpetage nende kritiseerimist, vaatame ettevõtte tööd ka mõnes muus valdkonnas. Google'i insenerid uhkustavad oma tarkvaraarenduse distsipliini üle, ja just see tekitab probleeme. Uhkustunne on ohtlike valikute teema, see on pannud paljusid Google'i töötajaid arvama, et nende lahendused on alati õiged ja et õigusus (mingisuguse määratlemata ja ebaselge definitsiooni järgi) on olulisem kui klientide mured.
to bring some arbitrary examples from other big projects outside of Google, but I hope you see this pattern everywhere. It is as follows: tagasiühilduvus toetab süsteemide elujõudu ja asjakohasust aastakümnete jooksul.
Tagasiühilduvus on disaini eesmärk, mis on vajalik kõigi eduka süsteemi jaoks, mis on mõeldud avatud kasutamiseks, st rakendatud avatud lähtekoodiga või / ja avatud standardite alusel. Tunnen, et räägin millestki liiga ilmsemast, et kõigile isegi ebamugavust tekitada, aga ei. See on poliitiline küsimus, seega on vaja näiteid.
Esimene süsteem, mille ma valin, on kõige vanem: GNU Emacs, mis on omamoodi hübriid Windowsi Notepad’i, operatsioonisüsteemi tuuma ja Rahvusvahelise Kosmosejaama vahel. Seda on natuke keeruline selgitada, kuid lühidalt öeldes on Emacs platvorm, mis loodi 1976. aastal (jah, peaaegu pool sajandit tagasi) programmeerimise jaoks, et suurendada teie tootlikkust, kuid see maskeeritakse tekstiredaktorina.
Ma kasutan Emacs'i iga jumala päev. Jah, ma kasutan ka IntelliJ iga päev, see on juba ise muutunud võimsaks tööriistade platvormiks. Kuid laienduste kirjutamine IntelliJ-s on palju ambitsioonikam ja keerulisem ülesanne kui laienduste kirjutamine Emacs'e jaoks. Ja mis veelgi tähtsam, kõik, mis on kirjutatud Emacs'e jaoks, püsib igavesti.
Ma kasutan endiselt tarkvara, mille ma Emacs'i jaoks kirjutasin juba 1995. aastal. Ja olen veendunud, et keegi kasutab ka Emacsi jaoks 80-ndate keskpaiku kirjutatud mooduleid, kui mitte varem. Aeg-ajalt võivad nad vajada pisut kohandamist, kuid see on tõeliselt üsna harv. Ma ei tea midagi sellist, mida ma kunagi Emacs'e jaoks kirjutasin (ja ma olen kirjutanud palju), mille arhitektuuri oleks pidanud ümber ehitama.
Emacs-l on funktsioon nimega make-obsolete vananenud üksuste jaoks. Emacs'i terminoloogia fundamentaalsete arvutikontseptide osas (näiteks mis on "aken") erineb sageli tööstusharu konventsioonidest, kuna Emacs tutvustas neid juba väga ammu. See on tüüpiline oht neile, kes on oma ajast ees: kõik teie terminid on mittetäpsed. Aga Emacs'is on tõepoolest käsitletud vananemise kontseptsiooni, mida nende žargoonis nimetatakse vananemiseks.
Kuid Emacs'i maailmas näib olevat teine töötav definitsioon. Teine alusfilosoofia, kui soovite.
Emacs'i maailmas (ja paljude teistes valdkondades, mida allpool käsitleme) tähendab vananenud API staatus peamiselt: "Te tõepoolest ei peaks seda lähenemist kasutama, kuna kuigi see töötab, on tal mitmeid puudusi, mida me siin loetleme. Lõppkokkuvõttes on see aga teie valik."
Google'i maailmas tähendab vananenud toote staatus: "Me rikume oma kohustusi teie ees". See on tõsi. See on sellele sisuliselt tähenduse andmine. See tähendab, et nad sunnivad teid regulaarselt tegema mingit tööd, võib-olla suurt tööd, karistuseks selle eest, et uskusite nende : meil on parim tarkvara. Kõige kiirem! Teete kõike juhiste järgi, käivitate oma rakenduse või teenuse ja siis — bum, aasta või kahe pärast see puruneb.
See on sama, mis müüa kasutatud autot, mis puruneb kindlasti 1500 km pärast.
Need on kaks täiesti erinevat filosoofilist definitsiooni "vananemisest". Google'i definitsioon haiseb . Ma ei usu, et see on tõeliselt plaanitud vananemine sama mõttes nagu Apple'i puhul. Kuid Google plaanib kindlasti teie programme purustada, kaudselt. Ma tean seda, sest olen töötanud seal insener-programmeerijana üle 12 aasta. Neil on hägusad sisemised suunised, mil määral peab tagurpidi ühilduvust järgima, kuid lõpuks sõltub see igast eraldi meeskonnast või teenusest. Üldpoliitika või inseneri tasandi soovitusi ei ole ning julgeim soovitus vananemise tsüklite osas on "proovige anda klientidele 6–12 kuud uuendamiseks, enne kui rikute nende süsteemi täielikult."
Probleem on palju tõsisem, kui nad arvavad, ja see kestab veel aastaid, sest klienditeenindus ei ole nende DNA-s. Lisainfot selle kohta allpool.
Praegu kavatsema teha julge väite, et Emacs on saavutanud oma edu suuresti ja isegi peamiselt selle tõttu, et nad suhtuvad tõsiselt tagurpidi ühilduvusse. Just see ongi meie artikli tees. Edukad pikaajalised avatud süsteemid peavad oma edu mikrosotsiaalsetele kogukondadele, mis on aastakümneid eksisteerinud laiendite/plugin'ite. See on ökosüsteem. Olen juba rääkinud platvormide olemusest ja nende tähtsusest, ning sellest, et Google ei ole oma ettevõtte ajaloos kunagi mõistnud, mis on vajalik eduka avatud platvormi loomisel, välja arvatud Android või Chrome.
Tegelikult peaksin ma lühidalt mainima Androidi, kuna te olete ilmselt sellele mõelnud.
Esiteks, Android ei ole Google. Neil pole peaaegu midagi ühist. Android on ettevõte, mille Google ostis juulis 2005, selle ettevõtte lubati töötada enam-vähem autonoomselt ja tegelikult on see jäänud suuresti puutumatuks viimastel aastatel. Android on kurikuulus tehnilise teeki ja sama kurikuulus hõre organisatsioon. Nagu ütles üks Google'i töötaja, "te ei saa lihtsalt niisama sisse astuda Androidi".
Ühes varasemas artiklis arutasin juba, kui halvad olid mõned varased Androidi disainilahendused. Kurat, kui ma seda artiklit kirjutasin, käidi nad käivitamas jama nimega "kohese rakendused", mis nüüd (üllatus!) , ja mul on kahju, kui olite piisavalt rumal, et kuulata Google’i ja kolida oma sisu sellistesse kohestesse rakendustesse.
Aga siin on erinevus, oluline erinevus, mis seisneb selles, et Androidi inimesed mõistavad tõeliselt, kui tähtsad on platvormid. Nad pingutavad, et säilitada vanade Androidi rakenduste töökorrasolek. Tegelikult on nende pingutused tagada väärtlust hoida tagurpidi ühilduvus nii äärmuslikud, et isegi mina, kui olin paar aastat tagasi Androidi osakonnas, proovisin neid veenda loobuma toest mõnede vanade seadmete ja API-de osas (ma eksisin, nagu ka paljude teiste asjade puhul minevikus ja olevikus. Vabandust, Androidi inimesed! Nüüd, kui olen käinud Indoneesias, mõistan, miks nad on meile vajalikud).
Androidi inimesed toetavad tagurpidi ühilduvust peaaegu kujuteldavatesse äärmustesse, mis põhjustab nõgise hulga vananenud tehnilisi võlgu nende süsteemides ja tööriistade ahelates. Oh, sa ei kujutaks ette, milliseid pööraseid asju nad peavad oma kogumistootmise süsteemis tegema, ja kõik see ühilduvuse nimel.
Sellega kaasistan Androidile ihaldatud auhinna "Sa ei ole Google". Nad tõeliselt ei taha saada Googlest, kes ei oska luua püsivaid platvorme, Android aga teab, kuidas seda teha. Ja seepärast käitub Google ühes suhtes väga targalt: lubab Androidi inimestel teha kõike omamoodi.Kuid Androidi kohesed rakendused olid üsna rumal idee. Ja tead miks? Sest nad nõudsid
teie rakenduse ümberkirjutamist ja ümberkujundamist ! Nagu inimesed lihtsalt võtaksid ja kirjutaksid ümber kaks miljonit rakendust. Eeldan, et kohesed rakendused oli mõne Googler'i idee.Aga siin on erinevus. Tagurpidi ühilduvus toob kaasa suured kulud. Android kannab neid kulusid ise, samas kui Google nõuab, et need kulud kannaksite
teie , tasuline klient.Te saate näha Androidi pühendumist tagurpidi ühilduvusele selle API-de kaudu. Kui teil on neli või viis erinevat alussüsteemi, et teha praktiliselt sama asja, on see kindel märk, et põhjus on pühendumus tagurpidi ühilduvusele. Mis on platvormide maailmas sünonüüm pühendumisele teie klientidele ja teie turule.
Androidi API-de kaudu. Kui teil on neli või viis erinevat alussüsteemi, et teha praktiliselt sama asja, on see kindel märk, et põhjus on pühendumus tagurpidi ühilduvusele. Mis on platvormide maailmas sünonüüm pühendumusele teie klientidele ja teie turule.
Google'i peamine probleem on nende uhkus oma inseneriteaduse puhtuse üle. Neile ei meeldi, kui on palju erinevaid viise sama asja tegemiseks, kusjuures vanad, vähem soovitavad meetodid on kõrvuti uute, veidi kapriissetega. See suurendab õppimiskurvi süsteemis uuteks tulijatele, keerab vanade API-de hoidmise koormust, aeglustab uute funktsioonide jõudmist ning peamine patt — see on kole. Google on nagu Tim Burtoni "Alicias Imedemaal" olev leedi Escot:
Leedi Escot:
— Alice, tead, mida ma kõige rohkem kardan?
— Aristokraatia langust?
— Ma kartsin, et mul on kolete lapselastele.
Et mõista kompromissi kauni ja praktilise vahel, vaatame kolmandat edukat platvormi (Emacsi ja Androidi järel) ja vaadakem, kuidas see töötab: ise Java.
Javas on palju vananenud API-sid. Vananemine on Java arendajate seas väga populaarne, isegi populaarsem kui enamikus programmeerimiskeeltest. Ise Java, peamine keel ja raamatukogud, vananevad pidevalt.
Kui võtta vaid üks tuhandest näiteks, peetakse vananenuks. See vananes alates Java 1.2 väljaandmisest detsembris 1998. On möödunud 22 aastat sellest ajast.
Aga minu reaalne kood tootmises tapab endiselt lõime igal päeval. Kas see on hea? Absoluutselt! Ma mõtlen, muidugi, kui ma kirjutaksin koodi täna, teeksin ma seda teisiti. Aga minu mängu kood, mis on viimase kahe kümnendi jooksul teinud õnnelikuks sadu tuhandeid inimesi, on kirjutatud lõime sulgemise funktsiooniga, mis jääb liiga kauaks ja mul pole kunagi tulnud seda muuta. Ma tunnen oma süsteemi paremini kui keegi teine, mul on selle tootmises töötamisel peaaegu 25-aastane kogemus, ja ma võin täpselt öelda: minu puhul on nende konkreetsete tööprotsesside sulgemine täiesti kahjutu. Pole väärt aega ja vaeva selle koodi ümberkirjutamiseks, ja kiitus Larry Ellisonile (võib-olla), et Oracle ei sundinud mind seda ümber kirjutama.
Võib-olla mõistab Oracle ka platforme. Kes teab.
Tõendid võite leida kõigist peamistest Java API-dest, mis on läbistatud aegumiste lainetega, nagu liustiku jooned kanjonis. Java Swing'i raamatukogust leiate kergesti viis või kuus erinevat klaviatuurihalduse haldurit (KeyboardFocusManager). Tegelikult on raske leida Java API-d, mis poleks aegunud. Kuid need töötavad endiselt! Arvan, et Java meeskond eemaldab API-d tõeliselt ainult siis, kui liides tekitab kriitilise turvaprobleemi.
Siin on asi, poisid: meie, tarkvaraarendajad, oleme kõik väga hõivatud ja igas tarkvaravaldkonnas võtame vastu konkurentsivõimelisi alternatiive. Igal ajahetkel kaaluvad X keele programmeerijad Y keelt võimaliku asendusena. Oh, kas te ei usu mind? Kas soovite nimetada Swift'i? Küll, kõik migreerivad Swift'i ja keegi ei loobu sellest, eks? Ohoo, kui vähe te teate. Ettevõtted arvestavad mobiiliarenduse kahekordsete meeskonna kuludega (iOS ja Android) — ja nad hakkavad aru saama, et sellised platvormidevahelised arendussüsteemid naljakate nimedega nagu Flutter ja React Native töötavad tõeliselt ning nende abil on võimalik kahekordistada oma mobiilsete meeskondade suurust või vastupidi, muuta nad kahekordselt produktiivsemaks. Mängus on päris raha. Jah, kompromisse on, kuid teisest küljest de-e-ē-ē-ēnni.
Eeldame hüpoteetiliselt, et Apple rumaluse tõttu võttis Guido van Rossumist eeskuju ja kuulutas, et Swift 6.0 on tagasiühilduv Swift 5.0-ga, sarnaselt sellele, kuidas Python 3 ei ole ühilduv Python 2-ga.
Ilmselt rääkisin ma seda lugu kümme aastat tagasi, kuid viisteist aastat tagasi käisin O'Reilly Foo Camp'is koos Gvido, istudes telgis Paul Grahami ja hulga suurte nimedega. Me olime häirivas kuumuses ja ootasime, et Larry Page lendaks oma isikliku helikopteriga, samas kui Guido monotoniseerivalt jutustas "Python 3000"-st, mida ta nimetas selle ajavahemiku järgi, mis kulub kõigil migrationiks. Korduvalt küsisime temalt, miks ta ühilduvust rikub, ja ta vastas: "Unicode". Ja me küsisime, kui peame oma koodi ümber kirjutama, siis milliseid muid eeliseid me näeme? Ja ta vastas "Yoooooooooooooouuuuuuuniiiiiiicoooooooode".
Kui installite Google Cloud Platform SDK (“gcloud”), siis saate järgmise teate:
Lugupeetud saaja,
Soovime teile meelde tuletada, et Python 2 tugi on aegunud, nii et minge te peate minema
… ja nii edasi. Eluring.
Aga asi on selles, et igal arendajal on valik. Ja kui sundida neid koodi piisavalt tihti ümber kirjutama, võivad nad mõelda ka muudele võimalustele. Nad ei ole teie pantvangid, nagu te sooviksite. Nad on teie külalised. Python on endiselt väga populaarne programmeerimiskeel, kuid, pagan, Python 3(000) on oma kogukondades ja kasutajate seas nii palju segadust tekitanud, et tagajärgi ei ole suudetud viisteist aastat lahendada.
Kui palju Pythonis kirjutatud programme on kirjutatud Go-sse (või Ruby'sse, või mõnda teise alternatiivi) selle tagurpidi mitteühilduvuse tõttu? Kui palju uut tarkvara on kirjutatud millegagi muuga kui Python, kuigi see võinuks olla kirjutatud Pythonis, kui Guido ei oleks kogu küla põlema pannud? Raske öelda, kuid Python on selgelt kannatanud. See on tohutu segadus ja kõik on kaotuses.
Nii et oletame, et Apple inspiratsiooniks Guido ja rikub ühilduvust. Mida te arvate, mida edasi juhtub? Noh, võib-olla 80–90% arendajatest kirjutavad oma tarkvara uuesti, kui see on võimalik. Teisisõnu, 10–20% kasutajabaasist läheb automaatselt mõnele konkurentsitavale keelele, näiteks Flutterile.
Tehke seda paar korda – ja kaotate poole oma kasutajabaasist. Nagu spordis, tähistab ka programmimaailmas praegune vorm kõike. Igaüks, kes kaotab viie aastaga poole oma kasutajatest, loetakse Suureks Paksuks Ebaõnnestumiseks. Te peate olema platvormide maailmas trendikas. Kuid just siinkohal viib vanade versioonide toe lõpetamine teid lõpuks hukka. Sest iga kord, kui vabastate osa arendajatest, (a) kaotate nad igaveseks, sest nad on vihased teie lepingurikkumise pärast, ja (b) annate nad oma konkurentidele.
Irsoodumisel aitasin ka Google'il muutuda selliseks primadonnaks, kes ignoreerib tagurpidi ühilduvust, kui lõin Grok'i, koodi analüüsi ja arusaamise süsteemi, mis lihtsustab automatiseerimist ja tööriistade varustamist koodi enda põhjal – see on nagu IDE, kuid siin salvestab pilveteenus kõik miljardid Google'i lähtekoodi read suurde andmehoidlasse.
Grok pakkus Google'ile tugeva aluse kogu koodibaasi automatiseeritud refaktoreerimiseks (literally üle kogu Google). Süsteem arvutab mitte ainult teie ülespoole suunatud sõltuvused (millest te sõltute), vaid ka allapoole suunatud (kes sõltuvad teist), seega kui API-d muudetakse, teate, kes kõik purustada! Nii et muudatuste tegemisel saate kontrollida, et iga teie API kasutaja on uuendatud uuele versioonile, ja tegelikult saate sageli kasutada nende loodud tööriista Rosie, et protsess täielikult automatiseerida.
See võimaldab Google'i koodibaasil sisemiselt olla peaaegu üli „puhtad”, kuna neil on robotteenrid, kes liiguvad ringi ja koristavad automaatselt, kui nad on ümbernimetanud SomeDespicablyLongFunctionName, et SomeDespicablyLongMethodName, kuna keegi otsustas, et see on kole lapselaps ja tuleb uinuda.
Ja ausalt öeldes töötab see Google'is üsna hästi… sisemiselt. Ma mõtlen, jah, Google'i Go kogukond naeratab sõbralikult Google'i Java kogukonna üle nende pideva refaktoreerimise harjumuse. Kui käivitate midagi N korda, tähendab see, et olete seda rikkunud N-1 korda ja hiljem on täiesti selge, et tõenäoliselt olete seda rikkunud ka N-ndal katsel. Aga üldiselt jäävad nad sellest saginast üle ja hoiavad koodi 'puhtana'.
Probleemid algavad, kui nad püüavad sellist suhtumist oma pilveteenuse klientidele ja teiste API kasutajatele peale sundida.
Ma olen natuke tutvustanud teid Emacsi, Androidi ja Java'ga; vaadakem nüüd viimast edukat pikaajalist platvormi: veeb ise. Kas suudate ette kujutada, kui palju iteratsioone on HTTP läbi teinud alates 1995. aastast, mil kasutasime vilkuvaid märke <blink> ja 'Arendamisel' ikoonide paneelide veebilehtedel.
Aga see töötab endiselt! Ja need lehed töötavad endiselt! Jah, poisid, brauserid on maailme meistrid tagurpidi ühilduvuses. Chrome on veel üks haruldane Google'i platvorm, millel on pea õigesti kinni keeratud ja, nagu juba arvate, Chrome toimib tõhusalt isoleeritud ettevõttena eraldi ülejäänud Google'ist.
Ma tahan tänada ka meie sõpru operatsioonisüsteemide arendajate seas: Windows, Linux, ÄRA APPLE, APPLE, FreeBSD ja nii edasi, kes on teinud tohutut tööd tagasipöörduva ühilduvuse nimel nende edukates platvormides (Apple saab parimal juhul madala kolme, kuna nad rikuvad pidevalt asju ilma igasuguse põhjenduseta, kuid kuidagi suudab kogukond sellega iga väljalaske puhul toime tulla ja OS X konteinerid ei ole veel täielikult vananenud ... vähemalt veel).
Aga oodake, ütlete teie. Kas me ei võrdle õunu apelsinidega — iseseisvat tarkvara ühel masinal, nagu Emacs/JDK/Android/Chrome, mitme serveriga süsteemide ja API-dega, nagu pilveteenustes?
Noh, ma kirjutasin sellest eile Twitteris, kuid Larry Wali stiilis (Perl programmeerimiskeele looja — toim.) põhimõttega 'fakk/äge' otsisin sõna deprecated Google'i ja Amazoni arendaja saitidelt. Ja kuigi AWS-il on sadu kordades rohkem teenusepakette kui GCP-l, mainib Google'i arendaja dokumentatsioon vananemist umbes seitse korda sagedamini.
Kui keegi Google'ist seda loeb, on nad kindlasti valmis tõestama diagramme Donald Trumpi stiilis, näidates, et nad teevad kõik õigesti ja et ma ei peaks tegema ebaausaid võrdlusi, nagu 'vananemise mainimiste arv teenuste arvu järgi'.
Kuid pärast nii palju aastaid on Google Cloud endiselt number 3 teenus (ma pole isegi kirjutanud artiklit katsetest saada number 2), kuid kui usaldada insider'ite teateid, on muresid, et nad võivad peagi langeda numbrile 4.
Mul ei ole tugevate argumentide kogumit, et 'tõestada' oma teesi. Kõik, mis mul on, on värvikad näited, mille olen kogunud 30 aasta jooksul arendajana. Olen juba maininud selle teema sügavalt filosoofilist olemust; mõnes mõttes on see arendajate kogukondades poliitiseeritud. Mõned arvavad, et platvormide looja peaks hoolitsema ühilduvuse eest, teised arvavad, et see on kasutajate (isegi arendajate) mure. Üks või teine. Ja tõepoolest, ei ole see poliitiline küsimus, kui me otsustame, kes peab kandma kulusid üldiste probleemide eest?
Nii et see on poliitika. Ja kindlasti tulevad minu esitlusele tulised vastused.
Kuidas kasutaja Google'i pilveplatvormi ning AWS-i kasutajana kahe aasta jooksul (töötades ettevõttes Grab) võin öelda, et Amazon ja Google omavad täiesti erinevat filosoofiat, kui räägime prioriteetidest. Ma ei tegele aktiivselt AWS-i arendusega, seega ei tea ma väga hästi, kui sageli nad vanu API-sid eemaldavad. Kuid mul on kahtlus, et see ei toimu sugugi nii tihti kui Google'is. Ja ma usun siiralt, et see pidev vaidluste ja pettumuste allikas GCP-s on üks peamisi tegureid, mis piirab platvormi arengut.
Tean, et ei toonud välja konkreetseid näiteid GCP süsteemidest, mille tugi on peatatud. Võin öelda, et praktiliselt kõik, mida ma olen kasutanud, alates võrkudest (vanimatest kuni VPC-d) kuni salvestusteni (Cloud SQL v1-v2), Firebase'ist (nüüd Firestore täiesti uue API-ga), App Engine'ist (ärgem isegi alustagem) ja pilve lõpp-punktidest Cloud Endpoint kuni… ma ei tea - absoluutselt kõik need sunniid mind koodi ümber kirjutama maksimaalselt 2-3 aasta jooksul, ja nad ei ole kunagi automatiseerinud migratsiooni teie jaoks, ja tihti . Justkui see oleks nii ette nähtud.
Ja iga kord, kui ma vaatan AWS-i, küsin endalt, miks ma ikkagi olen GCP-s. Neile ei vaja selgelt kliente. Neile on vajalikud ostjad. Kas sa mõistad erinevust? Las ma selgitan.
Google Cloud'il on , kus inimesed pakuvad oma tarkvaralahendusi, ja et vältida tühja restorani efekti, pidi see olema mõne pakkumisega täidetud, seega sõlmisid nad lepingu ettevõttega Bitnami, et luua hulk lahendusi, mida saab rakendada 'ühe hiireklõpsuga', või pean ise kirjutama 'lahendused', kuna need ei lahenda tegelikult midagi. Need eksisteerivad lihtsalt nagu märkmed, nagu turunduslik täidis, ja Google'i pole kunagi huvitanud, kas mõni nende tööriist tegelikult töötab. Ma tunnen tootejuhte, kes on selle taga, ja võin teid kinnitada, et nendele inimestele ei ole see ükskõik.
Võtame näiteks lahenduse, mis tundub olevat 'ühe hiireklõpsuga' rakendatav . Ma olen surmani väsinud Google Cloud SQL-i trikkidest, seega hakkasin kaaluma oma Percona klastrite loomist alternatiivina. Ja sel korral tundus, et Google tegi head tööd, nad pidid aitama mul veidi aega ja vaeva kokku hoida ühe nupuvajutusega!
No nii, läheme. Kliki lingil ja vajuta sellele nupule. Valime "Jah", et nõustuda kõigi vaikeparameetritega ja avada klaster oma Google'i pilvprojektis. Haha, see ei tööta. Miski sellest jama ei tööta. Tööriista pole kunagi testitud ja see on hakanud mädanema esimesest minutist ning mulle ei üllatuks, kui rohkem kui pooled "lahendustest" ühekordseks kasutamiseks (nüüd me mõistame, miks jutumärgid) üldse ei tööta. See on täielik pimedus, kuhu peaks parema meelega sisenema.
Aga Google kutsub otseselt teid üles kasutama neid. Nad tahavad, et sa ostaksid. Nende jaoks on see tehing. Nad ei soovi midagi toetada. See pole Google'i DNA osa. Jah, insenerid toetavad üksteist, millest tõendab minu lugu Bigtablest. Kuid tavainimeste toodetes ja teenustes on nad alati ilma halastamata , mis ei vasta kasumlikkuse künnisele, isegi kui tal on miljoneid kasutajaid.
Ja see esitab tõsise probleemi GCP-le, kuna see DNA on tugipunktiks kõigis pilvepakkumistes. Nad ei püüa midagi toetada; on hästi teada, et nad keeldusid majutamast (nagu hallatav teenus) ühtegi kolmanda osapoole tarkvara kuni AWS teeb sama asja ja ehitab selle ümber eduka äri, ja kui kliendid küsivad seda sõna otseses mõttes. Siiski tuleb teha teatavaid jõupingutusi, et sundida Google'it midagi toetama.See toetuskultuuri puudumine, koos põhimõttega "purustame selle, et teha ilusamaks", võõrandab arendajaid neist.
Ja see ei ole väga hea, kui soovid ehitada pikaajalist platvormi.
Google, ärka üles, kurat. Praegu on 2020. aasta. Sa ikka kaotad. Aeg on tõsiselt peeglisse vaadata ja otsustada, kas sa tõeliselt tahad jätta end pilveäri.
Kui soovid jääda, siis
lõpeta kõik purustamine . Poisid, te olete rikkad. Meie, arendajad, ei ole. Seetõttu, kui asi puudutab ühilduvuse koormuse kandmist, peate selle endale võtma. Mitte meie.Sest on veel vähemalt kolm tõeliselt head pilve. Need meelitavad enda juurde.
Ja nüüd lähen edasi parandama kõiki oma katki süsteeme. Oh.
Järgmise korrani!
Kuni järgmise korrani!
P. S. Uuendus pärast mõningate arutelude lugemist sellest artiklist (arutelud on muide suurepärased). Firebase'i tugi ei ole lõpetatud ega ole mul teada, et oleks mingeid plaane selle peatamiseks. Siiski on neil ebameeldiv voogedastuse viga, mis põhjustab Java kliendi peatumise App Engine'is. Üks nende inseneridest aitas mul selle probleemiga toime tulla, kui ma töötasin Google'is, kuid nad ei ole kunagi tõeliselt viga parandanud, seega on mul halb lahendus, kus pean iga päev GAE rakendust taaskäivitama. Nii on juba neli aastat! Nüüd on neil Firestore. Migratsiooniks on palju tööd, kuna see on täiesti teine süsteem ja Firebase'i viga ei saa kunagi parandatud. Mis on kokkuvõte? Te saate abi, kui töötate ettevõttes. Ilmselt olen ma ainus, kes kasutab Firebase'i GAE's, kuna ma salvestan vähem kui 100 võtit päris 100% rakenduses ja see lakkab töötamast iga paar päeva tagasitõukava vea tõttu. Mida siin öelda, peale selle, et kasutada seda omal vastutusel. Ma lähen üle Redis'e peale.
Olen ka näinud, kuidas mõned kogenumad AWS kasutajad ütlesid, et AWS ei lõpetanud tavaliselt kunagi oma teenuseid ja SimpleDB on suurepärane näide. Minu arvamused, et AWS-il ei ole sellist toetuse lõpetamise haigust nagu Google'il, tunduvad olevat õigustatud.
Lisaks olen ma märganud, et 20 päeva tagasi rikkus Google App Engine'i meeskond olulise Go teegi majutamise, blokeerides GAE rakenduse ühe peamise Go arendaja juurdepääsu. Tõeliselt rumal olukord.
Lõpuks olen kuulnud, et Google'is arutatakse seda küsimust ja enamasti ollakse minuga nõus (armastan teid, poisid!). Kuid tundub, et nad peavad probleemi lahendamatuteks, kuna Google'i kultuuris ei ole kunagi olnud õiget stiimulite struktuuri. Arvan, et oleks hea eraldada veidi aega, et arutada täiesti hämmastavat kogemust AWS inseneridega töötades, kui töötasin ettevõttes Grab. Loodetavasti tulevikus!
Ja, 2005. aastal olid neil tõepoolest erinevad hõrgutised hai lihast hiiglaslikul Rootsi lauas hoones 43, ja mulle meeldis kõige rohkem liivahai liha. Kuid 2006. aastaks vabastasid Larry ja Sergey kõik ebatervislikud suupisted. Nii et Bigtable'i looga 2007. aastal ei olnud tõesti haisid ja ma petsin teid halastamatult.
Kui ma vaatasin nelja aasta eest (umbes) pilv Bigtable'i, oli hind just selline. Paistab, et see on natuke langenud, kuid see on endiselt järjekordse andmehoidla tühi hind, eriti arvestades, et minu esimene lugu näitab, kui ebaoluline on tühi suur tabel nende mastaabis.
Vabandan, et solvasin Apple'i kogukonda ja et ei öelnud midagi head Microsofti kohta jne. Te kõik olete õiged, hindan väga kõiki arutelusid, mille see artikkel tekitas! Aga mõnikord on vajalik veidi laineid lüüa, et arutelu alustada, te mõistate ju?
Aitäh lugemise eest.
Uuendus 2, 19.08.2020. Stripe !
Uuendus 3, 31.08.2020. Minuga võttis ühendust Google'i insener Cloud Marketplace'is, kes juhtus olema minu vana sõber. Ta tahtis teada saada, miks C2D ei tööta, ja lõpuks selgus, et põhjus on selles, et ma lõin oma võrgu paar aastat tagasi, ja C2D ei tööta aegunud võrkudes, kuna nende mallides puudub alamsubtiidi parameeter. Arvan, et GCP potentsiaalsetel kasutajatel on parem veenduda, et neil on Google'is piisavalt tuttavaid insenere...
Allikas: habr.com
