Kuradi, Google, ma ei tahtnud taas blogisse kirjutada. Mul on nii palju tegemist. Blogimine nõuab aega, energiat ja loovust, mida võiksin paremini ära kasutada: mu raamatud, , mu mäng ja nii edasi. Aga sa oled mind piisavalt vihastanud ja pean selle kirja panema.
Nii et hakkame sellega pihta.
Alustan väikesest, kuid õpetlikust loost ajast, mil ma alles alustasin tööd Google'is. Tean, et olen viimasel ajal palju halba rääkinud Google'ist, kuid mind häirib, kui minu endine ettevõte teeb pidevalt ebakompetentseid äriotsuseid. Samas tuleb tunnustada, et Google'i sisemine infrastruktuur on tõeliselt erakordne, võib julgelt öelda, et täna pole midagi paremat. Google'i asutajad olid palju paremad insenerid, kui ma kunagi olema saan, ja see lugu kinnitab seda tõsiasja.
Esiteks natuke eelstory: Google'il on andmete salvestamise tehnoloogia nimega . See oli märkimisväärne tehniline saavutamine, üks esimesi (kui mitte esimene) 'lõputult skaleeritav' võtme-väärtuse salvestus (key-value store, K/V): sisuliselt NoSQL algus. Tänapäeval tunneb Bigtable end endiselt üsna tihedas K/V salvestuse ruumis hästi, kuid sel ajal (2005. aastal) oli see uskumatult lahe.
Üks lõbus detail Bigtable'i kohta on see, et neil oli sisemised juhtimistasandi objektid (osa rakendusest), mida nimetati tablet-serveriteks, suurte indeksitega, ja mingil hetkel muutusid nad süsteemi skaleerimise kitsaskohaks. Bigtable'i insenerid mõtlesid, kuidas saavutada skaleeritavust, ning ühel hetkel sai neile selgeks, et nad saavad asendada tablet-serverid teiste Bigtable'i salvestustega. Nii et Bigtable on osa Bigtable'i rakendusest. Need salvestused asuvad igal tasemel.
Veel huvitav on see, et mingil ajal muutusid Bigtable'id Google'is populaarseks ja igapäevaseks, kus iga meeskond kasutas oma salvestusruumi. Seetõttu küsis Larry Page ühel reedel juhuslikult: „Miks meil on rohkem kui üks Bigtable? Miks me ei saa hakkama ainult ühega?” Teoreetiliselt oleks üks salvestusruum pidanud piisama kõigi Google'i salvestusvajaduste jaoks. Muidugi ei läinud nad kunagi üle ainult ühele praktiliste arenduse tõttu (näiteks potentsiaalsete rikete tagajärjed), kuid teooria oli huvitav. Üks salvestusruum kogu Universumile (muide, kas keegi teab, kas Amazon tegi selle oma Sable'iga?)
Igatahes, siin on minu lugu.
Sel ajal olin Google'is töötanud natuke üle kahe aasta ja ühel päeval sain Bigtable'i insenerimeeskonnalt kirja, mille sisu oli umbes selline:
Loodan, et teie päev on hea,
Tere Bigtable'i meeskonnalt. Soovime teid teavitada, et andmekeskuses [название дата-центра] kasutate väga, väga vana Bigtable'i binaarfaili. See versioon ei ole enam toe all ja me tahame aidata teil üle minna viimasele versioonile.
Palun andke teada, kui saate kokku leppida aega selle küsimuse kallal koostööd teha.
Parimat,
Bigtable meeskond
Google'i postkasti saab palju kirju, seega lugesin esmapilgul umbes nii:
Austatud saaja,
Tere mõnelt meeskonnalt. Me soovime teavitada teid, et blaa-blaa-blaa-blaa-blaa. Blaa-blaa-blaa-blaa-blaa-blaa ja blaa-blaa-blaa kohe.
Palun andke meile teada, kui saate oma väärtuslikust ajast osa pühendada blaa-blaa-blaale.
Parimat,
Mõni meeskond
Hakkasin selle kohe kustutama, kuid alateadlikult tundsin, et see ei ole päris nagu ametlik kiri, kuigi ilmne, et adressaat on vale, kuna ma ei kasutanud Bigtable'i.
Aga see oli kummaline.
Ülejäänud päeva mõtlesin vaheldumisi tööle ja sellele, millist hai liha mikro-köögis proovida, millest vähemalt kolm olid piisavalt lähedal, et tabada minu kohalt ühe biskviidi täpse viskega, kuid mõte kirjale ei jätnud mind kasvava kergelt äreva tundega.
Nad nimeltasid selgelt mu nime. Ja kiri saadeti minu e-posti aadressile, mitte kellegi teise, ja see ei ole cc: ega bcc:. Toon on väga isiklik ja selge. Kas võib-olla see on mingi viga?
Lõpuks võttis uudishimu üle ja ma läksin vaatama Borgi konsooli andmekeskuses, millest nad rääkisid.
Ja muidugi oli mul halduses BigTable'i salvestus. Mis? Ma vaatasin selle sisu ja — no küll! See oli Codelabi inkubaatorist, kus ma viibisin oma esimesel nädalal Google'is juunis 2005. Codelab sundis teid Bigtable'i käivitama, et salvestada sinna mõned väärtused, ja ma ilmselt ei sulgenud salvestust pärast seda. See töötas endiselt, kuigi oli möödunud üle kahe aasta.
Selles loos on paar tähelepanuväärset aspekti. Esiteks, Bigtable'i töö oli Google'is nii ebaoluline, et alles kahe aasta pärast keegi märkis üleliigse salvestuse, ja isegi siis ainult seetõttu, et binaarversioon oli aegunud. Võrdluseks, ma kunagi kaalusin Bigtable'i kasutamist oma online-mängu jaoks. Sel ajal maksis see teenus umbes 16 000 dollarit aastas tühi Bigtable GCP-l. Ma ei ütle, et nad petavad teid, aga isiklikult arvan, et see on palju raha tühja, kuradi andmebaasi eest.
Teine märkimisväärne aspekt on see, et salvestus oli endiselt töökindel kaks aastat. WTF? Andmekeskused tulevad ja lähevad; nad kogevad katkestusi, nad saavad plaanitud hooldust, nad muutuvad pidevalt. Riistvara uuendatakse, lülitid vahetatakse välja, kõik paraneb pidevalt. Kuidas, kurat, suutsid nad hoida minu programmi töökindlat kaks aastat, arvestades kõiki neid muudatusi? See võib 2020. aastal tunduda tagasihoidlik saavutus, kuid 2005-2007 oli see tõeliselt muljetavaldav.
Ja kõige hämmastavam aspekt on see, et mingi teise osariigi välist insenerimeeskond ühendab mind, omanikuna mingist väikest ja praktiliselt tühja Bigtable eksemplarist, millel on null liiklust viimase kahe aasta jooksul — ja pakuvad abi selle värskendamiseks.
Ma tänasin neid, kustutasin salvestuse ja elu läks edasi. Kuid kaksteist aastat hiljem mõtlen ma endiselt sellele kirjale. Sest mõnikord saadetakse mulle selliseid kirju Google Cloudilt. Need näevad välja sellised:
Lugupeetud Google Cloudi kasutaja,
Tuletame meelde, et lõpetame teenuse [oluline teenus, mida te kasutate] toetamise augustist 2020, misjärel te ei saa oma instantsse uuendada. Soovitame üleminekut viimasele versioonile, mis on beetatestimisel, millel pole mingit dokumentatsiooni, mingit migreerimise teed ning mis on meie heatahtlikkuse tõttu eelnevalt aegunud.
Me püüame, et see muudatus mõjutaks Google Cloudi platvormi kõiki kasutajaid minimaalselt.
Parimate soovidega,
Google Cloudi platvorm
Aga ma peaaegu ei loe selliseid kirju, sest tegelikult öeldakse neis järgmist:
Austatud saaja,
Mine tõesti, mine pekki. Mine pekki, mine pekki, mine pekki. Jätka kõrvale kõik, mida sa teed, sest see ei ole oluline. Oluline on meie aeg. Me kulutame aega ja raha, et hoida oma jama käimas, ja me oleme sellest väsinud, seetõttu ei toeta me seda enam. Niisiis, viska oma peened plaanid kõrvale ja hakka kaevama meie jamasse, mingitki infot lunides foorumitest; ja muide, meie uus jama on täielikult erinev vanast jamast, sest me oleme selle disaini üsna ära rikkunud, heh, aga see on sinu probleem, mitte meie.
Me jätkame pingutusi, et kõik sinu arendused muutuksid kasutuskõlbmatuks ühe aasta jooksul.
Palun mine pekki,
Google Cloudi platvorm
Ja asi on selles, et ma saan selliseid kirju umbes kord kuus. See juhtub nii tihti ja nii pidevalt, et nad paratamatult tõukavad mind GCP-st eemale ja pilkuma pilvise vastupidinyh. Ma ei soovi enam sõltuda nende patendi all oleva arenduse toimetamisest, sest tegelikult on DevOps-il lihtsam toetada avatud lähtekoodiga süsteemi tühjal virtuaalmasinal, kui püüda joosta Google'i sabas oma «ajakohastamise» poliitika tõttu.
Enne naasime tagasi Google Cloudi juurde, sest ma ei ole isegi lähedal kriitika lõpetamisele, vaatame, kuidas ettevõte muudes valdkondades töötab. Google'i insenerid uhkustavad oma tarkvaraarenduse distsipliini üle, kuid just see toob esile probleemid. Uhkus on petlik, see on petlik lõks, mis on pannud paljusid Google'i töötajaid uskuma, et nende lahendused on alati õiged ja et õiglus (mingi määratlemata häguses tähenduses) on olulisem kui kliendihooldus.
Toon mõned juhuslikud näited teistelt suurprojektidelt väljaspool Google'i, kuid loodan, et märkate seda mustrit igal pool. See seisneb järgmisest: tagasiühilduvus toetab süsteemide elujõudu ja asjakohasust aastakümnete jooksul.
Tagasiühilduvus on disaini eesmärk kõikidele edukaile süsteemidele, mis on mõeldud avamiseks kasutamiseks, st rakendatud avatud lähtekoodiga ja/või avatud standarditel. Tunnen, et räägin millestki liiga ilmseks, mis teeb kõiki isegi ebamugavaks, kuid ei. See on poliitiline küsimus, seega on vajalikud näited.
Esimene süsteem, mille ma valin, on kõige vanem: GNU Emacs, mis on omamoodi hübriid Windowsi Notepad’i, operatsioonisüsteemi südamiku ja Rahvusvahelise Kosmosejaama vahel. See on natuke keeruline seletada, aga lühidalt öeldes on Emacs platvorm, mis loodi 1976. aastal (jah, peaaegu pool sajandit tagasi) programmeerimise tõhustamiseks, kuid maskeeritakse tekstiredaktorina.
Ma kasutan Emacsi iga päev. Jah, ma kasutan iga päev ka IntelliJ’d, see on juba muutunud võimsaks tööriistade platvormiks. Aga laienduste kirjutamine IntelliJ jaoks on palju ambitsioonikam ja keerulisem ülesanne kui Emacsi laienduste kirjutamine. Ja mis veelgi olulisem, kõik, mis Emacsi jaoks kirjutatakse, säilib igavesti.
Kasutatakse endiselt tarkvara, mille ma Emacsi jaoks kirjutasin juba 1995. aastal. Ja olen kindel, et mõni kasutab Emacsi mooduleid, mis on kirjutatud 80-ndate keskpaiku, kui mitte varem. Aeg-ajalt võivad need vajada vähest kohandamist, kuid see on tõeliselt haruldane. Ma ei tea ühtegi asja, mida ma kunagi Emacsi jaoks kirjutasin (aga ma kirjutasin palju), mille puhul oleks pidanud arhitektuuri ümber ehitama.
Emacsis on funktsioon nimega make-obsolete vananenud üksuste jaoks. Emacsi terminoloogia põhikontseptsioonide jaoks (nt mis on "aken") erineb sageli tööstusharu konventsioonidest, sest Emacs tutvustas neid juba ammu. See on tavaline oht neile, kes olid oma ajast ees: kõik teie terminid on ebatäpsed. Kuid Emacsis on tõepoolest kontseptsioon vananemisest, mida nad oma žargoonis nimetavad obsolescence.
Kuid Emacsi maailmas näib olevat teine töömääratlus. Teine põhifilosooofia, kui soovite.
Emacsi maailmas (ja paljuski muudes valdkondades, mida allpool käsitleme) tähendab vananenud API staatus põhiliselt: "Te ei tohiks tegelikult seda lähenemist kasutada, sest kuigi see töötab, kannatab see mitmete puuduste all, mille loetleme siin. Kuid lõpuks on see teie valik."
Google'i maailmas tähendab vananenud toote staatus: "Me rikume oma kohustusi teie ees." See on tõesti nii. Just see see põhimõtteliselt tähendab. See tähendab, et nad sunnivad teid regulaarselt teatud tööd tegema, võib-olla isegi suurt tööd, karistuseks selle eest, et uskusite neisse : meil on parim tarkvara. Kõige kiiremad! Te järgite kõiki juhiseid, käivitate oma rakenduse või teenuse ning siis - pauguga, aasta või kahe pärast, see puruneb.
See on nagu müüa kasutatud autot, mis laguneb kindlasti pärast 1500 km.
Need on kaks täiesti erinevat filosoofilist määratlust "aegumisest". Google'i määratlus seda kutsub . Ma ei usu, et see on tõepoolest planeeritud aegumine sama mõttes nagu Apple'il. Kuid Google plaanib kindlasti teie programme lõhkuda kaudsel viisil. Tean seda, kuna töötasin seal tarkvarainsenerina üle 12 aasta. Neil on hägused sisemised juhised, mil määral peaks tagasitagavus olema, kuid lõppkokkuvõttes sõltub see igast eraldi meeskonnast või teenusest. Ükski korporatiivne või inseneritase soovitusi ei ole olemas, ja kõige julgem soovitus aegumise tsüklite osas on "püüdke anda klientidele 6-12 kuud aega uuendamiseks, enne kui nad kogu süsteemi purunevad".
Probleem on palju tõsisem, kui nad arvavad, ja see püsib veel aastaid, sest klienditeenindus ei kuulu nende DNAsse. Rohkem selle kohta allpool.
Praegu julgen öelda, et Emacs on suures osas edukas ja isegi peamiselt sellepärast, et nad võtavad tagurpidi ühilduvust nii tõsiselt. See ongi meie artikli tees. Edukad pikaajalised avatud süsteemid on oma edusammud võlgnemas mikroühiskondadele, mis on aastakümneid elanud nende ümber laiendite/plugin'ide. See ongi ökosüsteem. Olen juba rääkinud platvormide olemusest ja nende tähtsusest ning sellest, kui vähe Google on oma ettevõtte ajaloo jooksul mõistnud, mis on vajalik eduka avatud platvormi loomisel, välja arvatud Android või Chrome.
Ütleme nii, et ma peaksin lühidalt mainima Androidit, sest sa oled tõenäoliselt sellele mõelnud.
Esiteks, Android ei ole Google. Nad ei oma vahel praktiliselt midagi ühist. Android on ettevõte, mille Google omandas juulis 2005. aastal, ja sellele ettevõttele anti lubatud tegutseda enam-vähem iseseisvalt, jäädes tegelikult suuresti puutumatuks viimastel aastatel. Android on kurikuulus tehniline tipp ja sama kurikuulus järsk organisatsioon. Nagu ütles üks Google'i töötaja: "ei saa lihtsalt niisama sisse astuda Androidi."
Ühes varasemas artiklis arutasin juba, kui halvad olid mõned varajased disainilahendused Androidis. Kuidas on see võimalik, kui ma seda artiklit kirjutasin, siis nad olid hädas kõigi nende "kiirete rakenduste" juurutamisega, mis nüüd (üllatus!) , ja mul on kahju, kui olite piisavalt rumal, et kuulata Google'i ja viia oma sisu nende kiiretesse rakendustesse.
Kuid siin on vahe, oluline vahe, mis seisneb selles, et Androidi inimesed mõistavad tõeliselt, kui tähtsad on platvormid, nad pingutavad, et hoida vanu Androidi rakendusi töötamas. Tegelikult on nende pingutused tagada tagasivaatav ühilduvus nii äärmuslikud, et isegi mina, oma lühikese aja jooksul Androidi osakonnas mõni aasta tagasi, leidsin, et püüan neid veenda loobuma teatud vanade seadmete ja API-de toetamisest (ma eksisin, nagu paljude teiste asjade puhul minevikus ja olevikus. Vabandust, Androidi inimesed! Nüüd, kui olen Indoneesias käinud, mõistan, miks nad meile vajalikud on).
Androidi inimesed toetavad tagasivaatavat ühilduvust peaaegu arusaamatutes äärmustes, mis kuhjab nende süsteemidesse ja tööriistade ahelatesse tohutu hulga aegunud tehnilisi võlgu. Oh jumal, te näeksite mõningaid hetki, mida nad peavad oma kogumissüsteemis tegema, ja see kõik ühilduvuse nimel.
Seetõttu annan Androidile auhinna «Sa ei ole Google». Nad tõeliselt ei soovi muutuda Googleseks, kes ei oska luua püsivaid platvorme, samas nagu Android. teab, kuidas seda teha. Ja seetõttu käitub Google ühes suhtes väga küllaltki arukalt: laseb inimestel Androidis kõik oma moodi teha.
Kuid Androidi kohapealsed rakendused olid üsna rumal idee. Ja tead miks? Sest need nõudsid oma rakenduse ümberkirjutamist ja ümberkujundamist! Justkui inimesed lihtsalt võtaksid ja kirjutaksid kaks miljonit rakendust ümber. Ma arvan, et kohapealsed rakendused olid mõne Google'i töötaja idee.
Aga siin on erinevus. Tagasiühilduvuse säilitamine toob kaasa suured kulud. Android ise kannab selle koormuse, samas kui Google nõuab, et selle koormuse kannaksid te, tasuline klient.
Saate näha Androidi tagasipööratavuse pühendumust selle API-des. Kui teil on neli või viis erinevat allikat, mis täidavad põhimõtteliselt sama ülesannet, on see kindel märk tagasipööratavuse pühendumusest. See on platvormide maailmas sünonüüm pühendumusele oma klientidele ja turule.
Google'i peamine probleem on nende uhkus oma insenerigigihügieeni üle. Neile ei meeldi, kui on palju erinevaid viise, kuidas sama asja teha, kui vanad, vähem soovitavad meetodid koosnevad uutes, kätkevates meetoditest. See tõstab õppimiskurvi uutele süsteemi kasutajatele, suurendab vananenud APIde hooldamise koormust, aeglustab uute funktsioonide väljaandmise tempot ja peamine patt on see, et see on kole. Google on nagu Tim Burtoni 'Alice Imedemaal' Lady Escote:
Lady Escote:
— Alice, tead, mida ma kõige rohkem kardan?
— Aristokraatia langust?
— Ma kartsin, et mul on inimesed, kes pole ilusad.
Et mõista kompromissi ilusa ja praktilise vahel, vaatame kolmandat edukat platvormi (pärast Emacsi ja Androidi) ja näeme, kuidas see töötab: Java ise.
Java-s on palju aegunud API-sid. API-de aegumine on Java-arendajate seas väga levinud, isegi populaarsem kui enamikus programmeerimiskeeltes. Isegi Java-s, peases ja raamatukogudes, toimub pidev API-de aegumine.
Kui võtta vaid üks tuhandest näiteks, peetakse aegunuks. See muutus aegunuks alates Java 1.2 väljaandmisest 1998. aasta detsembris. Selle aegumise hetkest on möödunud 22 aastat.
Kuid minu tegelik kood tootmises tapab siiski vooge iga päev. Kas see on hea? Absoluutselt! Muidugi, kui ma kirjutaksin koodi täna, teeksin ma seda teisiti. Kuid mu mängu kood, mis on viimase kahe kümnendi jooksul teinud õnnelikuks sadu tuhandeid inimesi, on kirjutatud voogude sulgemise funktsiooniga, mis jäävad liiga kauaks, ja mulle ei ole kunagi olnud vajadust seda muuta. Ma tunnen oma süsteemi paremini kui keegi teine, mul on selles valdkonnas 25-aastane kogemus tootmises, ja ma oskan öelda: minu puhul on nende konkreetsete töövoogude sulgemine täiesti kahjutuks. Ära raiska aega ja energiat selle koodi ümberkirjutamiseks, ja kiitus Larry Ellisonile (võib-olla), et Oracle ei sundinud mind seda ümber kirjutama.
Tõenäoliselt mõistab Oracle ka platvorme. Kes teab.
Tõendeid võib leida kõikjal peamistes Java API-des, mis on küllastunud vananemise lainetega, nagu liustiku jäljed kanjonis. Java Swing'i teegis on kerge leida viis või kuus erinevat klaviatuurihalduse managerit (KeyboardFocusManager). Tegelikult on raske leida Java API-d, mis ei oleks vananenud. Aga nad töötavad endiselt! Arvan, et Java meeskond eemaldab API-d tõeliselt ainult siis, kui liides tekitab ägeda turvaprobleemi.
Asi on asi, poisid: me, tarkvaraarendajad, oleme kõik väga hõivatud ja igas tarkvaravaldkonnas seisame silmitsi konkurentsi alternatiividega. Igal ajahetkel kaaluvad X keele programmeerijad Y keelt võimaliku asendusena. Oh, sa ei usu mind? Tahad tuua Swift'i näiteks? Nagu, kõik migrivad Swift'ile ja keegi ei loobu sellest, eks? Oho, kui vähe sa tead. Ettevõtted arvutavad mobiiliarenduse (iOS ja Android) topeltmeeskondade kulusid ja nad hakkavad aru saama, et need naljakate nimedega ristplatvormilised arendusplatvormid nagu Flutter ja React Native tõeliselt toimivad ning nende abil on võimalik oma mobiilimeeskondade suurust poole võrra vähendada või vastupidi, nende tootlikkust kaks korda suurendada. Tehingud on tõeliselt rahaga seotud. Jah, kompromisse on, kuid teisest küljest, raha.
Kujutame end hüpoteetiliselt ette, et Apple eelnevalt idiootselt järgib Guido van Rossumit ja kuulutab, et Swift 6.0 ei ole tagasiühilduv Swift 5.0-ga, nagu Python 3 ei ole tagasiühilduv Python 2-ga.
Võib-olla rääkisin sellest loost kümme aastat tagasi, kuid viisteist aastat tagasi käisin O'Reilly's Foo Camp'is Guido kõrval, istusin Paul Grahamiga ja hulga suurte nimedega. Istusime tappvas kuumuses ja ootasin, millal Larry Page maandub oma isiklikul helikopteril, samal ajal kui Guido ühteviisi kordas "Python 3000", mille ta nimetas selle järgi, kui palju aega kulub kõigil sinna migreerimiseks. Küsisime temalt pidevalt, miks ta ühilduvust rikub, ja tema vastas: “Unicode”. Ja meie küsisime, et kui peame oma koodi ümber kirjutama, milliseid muid eeliseid me veel näeme? Ja tema vastas: “Yoooooooooooooouuuuuuuniiiiiiicoooooooode.”
Kui installite Google Cloud Platform SDK (“gcloud”), saate järgmise teate:
Austatud saaja,
Soovime teile meenutada, et Python 2 toe lõppemise aeg on käes, nii et olete juba…
… ja nii edasi. Eluring.
Aga fakt on see, et igal arendajal on valik. Ja kui neid piisavalt sageli oma koodi ümber kirjutama panna, võivad nad hakata mõtlema ka… teised variantides. Nad ei ole teie pantvangid, kuigi te seda soovite. Nad on teie külalised. Python on endiselt väga populaarne programmeerimiskeel, kuid, kurat, Python 3(000) on oma kogukondades ja nende kasutajates niivõrd segadust tekitanud, et tagajärgi ei ole suudetud juba viisteist aastat koristada.
Kui palju Pythoniga kirjutatud programme on Go (või Ruby, või mingi muu alternatiivi) peale üle kirjutatud selle tagasipöörduva ühilduvuse tõttu? Kui palju uut tarkvara on kirjutatud millegi muu peale, kuigi see võinuks olla kirjutatud Pythonis, kui Guido poleks kogu küla põletanud? Raske öelda, kuid Python on selgelt kannatanud. See on tohutu segadus ja kõik on hädas.
Nii et oletame, et Apple järgib Guido eeskuju ja rikub ühilduvust. Kuidas arvate, et läheb edasi? Noh, võib-olla 80-90% arendajatest kirjutavad oma tarkvara ümber, kui see on võimalik. Teisisõnu, 10-20% kasutajabaasist lahkub automaatselt mõnele konkurentsivõimelisele keelele, näiteks Flutterile.
Tehke seda paar korda – ja te kaotate poole oma kasutajabaasist. Nagu spordis, nii ka programmeerimises tähendab ka praegune vorm palju. kõik. Iga, kes kaotab viie aasta jooksul poole oma kasutajatest, loetakse suureks paksuks läbikukkujaks. Te peaksite olema platvormide maailmas trendis. Kuid just siin toob vanade versioonide toetamisest loobumine lõpuks teie hukatuse. Sest iga kord, kui loobute osast arendajatest, (a) kaotate nad igaveseks, kuna nad on vihased, et te rikute lepingut, ja (b) annate nad oma konkurentidele.
Irooniliselt aitasin ma ka Google'il saada selliseks primadonnaks, mis ignoreerib tagasipöörduvust, kui loonud Groki, lähtekoodi analüüsi ja mõistmise süsteemi, mis lihtsustab automatiseerimist ja varustamist tööriistadega, mis põhinevad koodil endal – see on nagu IDE, kuid siin hoiab pilveteenus materjaliseeritud vaateid kõigist miljarditest Google'i lähtekoodiridade ridadest suures andmehoidlas.
Grok andis Google'i arendajatele jõulise aluse automatiseeritud refaktoreerimiseks kogu koodibaasis (litteraalselt kogu Google'i ulatuses). Süsteem arvutab mitte ainult teie ülenevad sõltuvused (millest te sõltute), vaid ka alanevad (mis sõltuvad teist), seega kui API-d vahetate, teate, keda te kahjustate! Nii saate muudatusi tehes kontrollida, et iga teie API kasutaja on uuele versioonile üle läinud, ja tegelikult saab sageli Rosie'i tööriistaga, mille nad on kirjutanud, kogu protsessi täielikult automatiseerida.
See võimaldab Google'i koodibaasil sisemiselt olla peaaegu üliväärikalt 'puhtad', kuna neil need robotid tiirlevad ringi ja koristavad automaatselt, kui nad on renamed SomeDespicablyLongFunctionName SomeDespicablyLongMethodName'iks, sest keegi otsustas, et see on kole lapselaps ja tuleb magama panna.
Ja ausalt öeldes, see toimib Google'is üsna hästi... sisemiselt. Ma mõtlen, jah, Google'i Go kogukond naeruvääristab tõeliselt headmeelselt Java kogukonda nende pideva refaktoorimise kommetest. Kui taastate midagi N korda, tähendab see, et olete selle N-1 korda rikkunud, aga mõne aja pärast hakkab täiesti selgeks saama, et tõenäoliselt olete selle rikkunud ka N-ndal katsetusel. Kuid suuremalt jaolt jäävad nad sellest tõukest kõrgemale ja hoiavad koodi 'puhtana'.
Probleemid algavad siis, kui nad püüavad oma suhtumist oma pilveteenuse klientidele ja teiste API kasutajatele peale suruda.
Olen natuke tutvustanud teid Emacsi, Androidi ja Java'ga; vaatame nüüd viimast püsivat ja edukat platvormi: veeb ise. Kas suudate ette kujutada, kui paljude iteratsioonide kaudu on HTTP läbinud alates 1995. aastast, mil kasutasime vilkuvaid silte ja 'Töös' ikoone veebilehtedel.
Aga see kõik töötab endiselt! Ja need lehed töötavad endiselt! Jah, sõbrad, brauserid on maailmameistrid tagasipöördumise ühilduvuses. Chrome on veel üks näide haruldasest Google'i platvormist, mille osad on koos korralikult, ja nagu te juba arvasite, toimib Chrome tõhusalt isoleeritud ettevõttena eraldi ülejäänud Google'ist.
Soovin tänada ka meie sõpru operatsioonisüsteemide arendajate seas: Windows, Linux, mitte APPLE MINA APPLE, FreeBSD jne, nende suure töö eest tagurpidi ühilduvuse nimel oma edukates platvormides (Apple saab parimal juhul kolm miinus, kuna nad rikuvad pidevalt kõike ilma igasuguse põhjenduseta, kuid mingil moel suudab kogukond sellega igas väljaandes toime tulla ja OS X konteinerid pole siiani täielikult vananenud… veel).
Aga oota, ütlete teie. Kas me ei võrgle õunu apelsinidega – autonoomseid tarkvarasüsteeme ühel masinal, nagu Emacs/JDK/Android/Chrome, mitmeserveriliste süsteemidega ja API-dega, nagu pilveteenustes?
Noh, kirjutasin sellest eile Twitteris, kuid Larry Wali stiilis (Perl-i loomise autor – tõlk.) printsii «sitta/rulz» otsisin sõna deprecated Google'i ja Amazoni arendajate saitidelt. Ja kuigi AWS-l on sadu korduvalt rohkem teenusepakkumisi kui GCP-l, mainitakse Google'i arendajadokumentatsioonis vananemist umbes seitse korda sagedamini.
Kui keegi Googlest seda loeb, siis nad kindlasti on valmis tooma graafikuid Donald Trumpi stiilis, mis tõestab, et nad teevad kõik õigesti, ja et ma ei peaks tegema ebaõiglaseid võrdlusi, nagu "kui palju kordi sõna deprecated mainitakse võrreldes teenuste arvuga."
Kuid pärast nii pikka aega jääb Google Cloud endiselt kolmandaks teenuseks (ma ei ole veel kirjutanud artiklit ebaõnnestunud katsest saada teiseks), kuid kui uskuda siseinfole, siis on mõned mured, et nad võivad peagi langeda neljandaks.
Mul ei ole tugevaid argumendi, et "tõestada" oma väidet. Kõik, mis mul on, on värvikad näited, mille olen kogunud 30 aasta jooksul arendajana. Olen juba maininud, et selle probleemi olemus on sügavalt filosoofiline; teatud mõttes on see poliitiliselt laetud arendajate kogukondades. Mõned arvavad, et platvormi looja peavad hoolitsema ühilduvuse eest, teised aga arvavad, et see on kasutajad (enda arendajate) mure. Üks kahest. Ja kas see ei ole tõesti poliitiline küsimus, kui me otsustame, kes peaks kandma kulud kõrgete probleemide eest?
See, this is the policy. And there will surely be angry responses to my speech.
Kuidas kasutaja Olen Google'i pilveplatvorma kasutaja ning samuti olen kasutanud AWS-i kahe aasta jooksul (töötades ettevõttes Grab), siis võin öelda, et Amazon ja Google kasutavad ajaloo- ja arengu prioriteetides tohutut erinevust. Ma ei tee aktiivset arendust AWS-is, seega ei tea ma eriti hästi, kui sageli nad vanu API-sid eemaldavad. Kuid on kahtlus, et see ei toimu sugugi nii sageli, nagu Google'is. Ja ma usun siiralt, et see pidev vaidluste ja pettumuste allikas GCP-s on üks suurimaid tegureid, mis pidurdab selle platvormi arengut.
Ma tean, et ma ei maininud konkreetseid GCP süsteeme, mille toetamine on lõpetatud. Võin öelda, et praktiliselt kõik, mida ma kasutasin, alates võrkudest (kõige vanadest kuni VPC-d) kuni salvestuslahendusteni (Cloud SQL v1-v2), Firebase (nüüd Firestore hoopis teise API-ga), App Engine'ist (ärme isegi alusta) ja pilvekliendipunktidest Cloud Endpoint ning… ma ei tea - absoluutselt kõik see sunusid koodi ümber kirjutama maksimaalselt iga 2-3 aasta tagant, ning nad ei ole kunagi teie eest migreerimist automatiseerinud, vaid sageli . Justkui oleks see niimoodi ette nähtud.
Ja iga kord, kui ma vaatan AWS-i, küsin endalt, miks ma ikka veel GCP-s istun. Neil ei tundu olevat kliente vaja. Nad vajavad ostjaid. Kas sa saad aru vahetest? Las ma selgitan.
Google Cloudil on , kus inimesed pakuvad oma tarkvaralahendusi, ja et vältida tühja restorani efekti, pidi see olema täidetud mõnede pakkumistega, mistõttu nad sõlmisid lepingu ettevõttega Bitnami, et luua hulk lahendusi, mis on „ühe hiireklõpsuga” juurutatavad, või pean ma ise kirjutama „lahendused”, kuna need ei lahenda midagi. Nad eksisteerivad lihtsalt nagu kontrollmärgid, nagu turunduslik täitja, ja Google ei ole kunagi hoolinud, kas mõni tööriist töötab või mitte. Ma tunnen tootemanagere, kes olid roolis, ja võin teile kinnitada, et nendele inimestele ei meeldi.
Võtame näiteks lahenduse, mille juurutamine on väidetavalt „ühe hiireklõpsuga” . Olen surmani väsinud Google Cloud SQL mängudest, nii et hakkasin kaaluma Percona klastrite loomise alternatiivi. Seekord tundub, et Google on midagi õigesti teinud, nad kavatsevad säästa mulle natuke aega ja vaeva ühe nupuvajutusega!
Noh, suurepärane, lähme. Klõpsame lingil ja vajutame sellele nupule. Valime "Jah", et nõustuda kõikide vaikevalikutega ja juurutada klaster oma Google'i pilveprojektis. Haha, see ei tööta. Mitte miski sellest jamast ei toimi. Tööriista pole kunagi testitud ja see hakkas esimesest minutist lagunema, ning mind ei üllataks, kui rohkem kui pooled "lahendustest" ühe klõpsuga juurutamiseks (nüüd me mõistame, miks jutumärgid) üldiselt ei tööta. See on täiesti lootusetu pimedus, kuhu parem ei siseneda.
Aga Google kutsub selgelt teid seda kasutama. Nad tahavad, et te ostaksite selle. Nende jaoks on see tehing. Nad ei taha midagi. Nad neile on see tehing. Nad ei soovi midagi toetavad. See ei ole Google'i DNA osa. Jah, insenerid toetavad üksteist, nagu tõendab minu lugu Bigtable'i kohta. Aga tavalistele inimestele mõeldud toodetes ja teenustes on nad alati ilma halastusteta , mis ei vasta kasumipehmenduse kriteeriumile, isegi kui tal on miljoneid kasutajaid.
Ja see on GCP jaoks tõeline probleem, sest see DNA on kõikide pilvepakkumiste taga. Nad ei püüa midagi toetada; on hästi teada, et nad keeldusid (nagu hallatud teenus) igasuguste kolmandate osapoolte tarkvara majutamisest. kuni, kuni AWS teeb sama ja ehitab selle ümber eduka äri ning kui kliendid nõuavad seda sõna-sõnalt. Kuid Google'i toetamise sundimiseks tuleb teha teatud jõupingutusi.
See toetuskultuuri puudumine koos printsiibiga 'murdke, et teha selle asemel ilusam' võõrandab arendajad nende juurest.
Ja see ei ole eriti hea, kui soovid ehitada pikaealist platvormi.
Google, ärka üles, kurat. On 2020. aasta. Sa ikka kaotad. On aeg tähelepanelikult peeglisse vaadata ja küsida endalt, kas tõeliselt soovid pilveäris püsida.
Kui soovid jääda, siis lõpeta kogu selle katkestamine. Pois te olete ju rikkad. Meie, arendajad — ei ole. Seetõttu, kui tuleb valida, kes võtab enda kanda ühilduvuse koorma, peate selle endale võtma. Mitte meile.
Sest on veel vähemalt kolm tõeliselt head pilveteenust. Need tõmbavad enda poole.
Ja nüüd lähen edasi parandama kõiki oma purunenud süsteeme. Oh.
Järgmise korrani!
P.S. Uuendus pärast selle artikli mõningate arutelude lugemist (arutelud on muide suurepärased). Firebase'i tugi ei ole lõppenud ja ma ei tea mingitest plaanidest. Siiski on neil tülikas voogesituse viga, mis sunnib Java-klienti App Engine'is peatuma. Üks nende inseneridest aitas mul selle probleemiga toime tulla, kui ma töötasin Google'is, kuid nad pole kunagi tegelikult kuskile vea parandanud, seega mul on halb lahendus, pean iga päev GAE rakendust taaskäivitama. Nii on olnud juba neli aastat! Nüüd on neil Firestore. Üleminekuks kulub palju tööd, kuna see on täiesti teine süsteem ja Firebase'i viga ei saa kunagi parandatud. Milline järeldus veel teha? Te saate abi, kui töötate ettevõttes. Tõenäoliselt olen ma ainus, kes kasutab Firebase'i GAE-l, sest ma salvestan alla 100 võtme oma 100% kohaliku rakenduse jaoks, ja see lõpetab töö iga paari päeva tagant tuntud vea tõttu. Mida siin öelda, peale selle, et kasutage seda oma riskil. Ma lähen üle Redis'ile.
Olen ka näinud, kuidas mõned kogenumad AWS-i kasutajad on öelnud, et AWS ei katkesta tavaliselt kunagi ühtegi teenust, ja SimpleDB on suurepärane näide. Minu oletused, et AWS-il ei ole sellist toetuse katkestamise probleemi nagu Google'il, tunduvad olevat õiged.
Lisaks on ma märganud, et 20 päeva tagasi rikkus Google App Engine'i meeskond kriitilise Go teeki hostimist, sulgedes GAE rakenduse ühe olulise Go arendaja jaoks. Tõeliselt rumal olukord.
Lõpuks kuulsin, et Google'i töötajad arutavad seda teemat ja on minu arvamusega enamasti nõus (ma armastan teid, poisid!). Kuid tundub, et nad peavad probleemi lahendamatuks, kuna Google'i kultuuris pole kunagi olnud õiget stiimuli struktuuri. Arvan, et oleks hea, kui leiaks natuke aega, et arutada täiesti uskumatut koostööd AWS inseneridega, kui töötasin ettevõttes Grab. Loodan, et tulevikus saame seda teha!
Ja jah, 2005. aastal olid neil tõepoolest erinevad haimibiidid hiiglaslikul Rootsi lauas 43. hoones, ja mulle meeldis kõige enam lameda haiga liha. Kuid 2006. aastaks vabastas Larry ja Sergey kõik ebatervislikud suupisted. Nii et Bigtable'i loo ajal 2007. aastal ei olnud tõepoolest ühtegi haid ja pettes olin teid tõeliselt alt vedanud.
Kui ma neli aastat tagasi (pluss miinus) vaatasin pilve Bigtable'i, oli hind täpselt selline. Tundub, et see on nüüd natuke langenud, kuid see on endiselt hirmus palju tühja andmehoidla eest, eriti arvestades, et minu esimene lugu näitab, kui ebaoluline on tühi suur tabel nende mastaabis.
Vabandust, et riivasin 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 tõi! Aga mõnikord on vaja veidi laineid lüüa, et arutelu alustada, kas te ei arva?
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 osutus minu vanaks sõbraks. Ta soovis välja selgitada, miks C2D ei tööta, ja lõpuks avastasime: põhjus on see, et ma lõin oma võrgu mõned aastaid tagasi, ja C2D ei tööta vanades võrkudes puuduva alamsuure parameetri tõttu nende mallides. Arvan, et GCP potentsiaalsed kasutajad peaksid veenduma, et neil on piisavalt tuttavaid insenere Googles...
Allikas: habr.com
