Vittu Google, en halunnut enää kirjoittaa blogia. Minulla on niin paljon tekemistä. Bloggaaminen vie aikaa, energiaa ja luovuutta, joita voisin käyttää hyväksi: kirjani, , pelini ja niin edelleen. Mutta olet suuttunut niin paljon, että minun on kirjoitettava tämä.
Joten lopetetaan tämä.
Aloitan lyhyellä mutta opettavaisella tarinalla siitä hetkestä, kun aloitin työskentelyn Googlella. Tiedän, että olen sanonut paljon pahaa Googlesta viime aikoina, mutta minua ärsyttää, kun oma yritykseni tekee säännöllisesti epäpäteviä liiketoimintapäätöksiä. Samalla meidän on annettava sille ansionsa: Googlen sisäinen infrastruktuuri on todella poikkeuksellinen, voidaan turvallisesti sanoa, että tänään ei ole parempaa. Googlen perustajat olivat paljon parempia insinöörejä kuin minä koskaan tulen olemaan, ja tämä tarina vain vahvistaa tämän tosiasian.
Ensinnäkin vähän taustaa: Googlella on tiedontallennustekniikka nimeltä . Se oli merkittävä tekninen saavutus, yksi ensimmäisistä (ellei ensimmäinen) "lopetta skaalautuva" avainarvovarasto (K/V): pohjimmiltaan NoSQL:n alku. Nykyään Bigtable pärjää edelleen hyvin melko ahtaassa K/V-tallennustilassa, mutta siihen aikaan (2005) se oli hämmästyttävän siistiä.
Yksi hassu juttu Bigtablessa on, että heillä oli sisäisiä ohjaustasoobjekteja (osana toteutusta), joita kutsutaan tablet-palvelimiksi, suurilla indekseillä, ja niistä tuli jossain vaiheessa pullonkaula järjestelmää skaalattaessa. Bigtable-insinöörit ihmettelivät skaalautuvuuden toteuttamista ja tajusivat yhtäkkiä, että he voisivat korvata tablet-palvelimet muilla Bigtable-tallennusvälineillä. Bigtable on siis osa Bigtable-toteutusta. Näitä varastotiloja on kaikilla tasoilla.
Toinen mielenkiintoinen yksityiskohta on, että Bigtablesta tuli jonkin aikaa suosittu ja kaikkialla Googlessa, ja jokaisella joukkueella oli oma arkisto. Joten yhdessä perjantain kokouksista Larry Page kysyi ohimennen: ”Miksi meillä on useampi kuin yksi Bigtable? Miksei vain yksi?" Teoriassa yhden tallennustilan pitäisi riittää kaikkiin Googlen tallennustarpeisiin. Tietenkään he eivät koskaan menneet vain yhteen käytännön kehityssyistä (kuten mahdollisen epäonnistumisen seurauksista), mutta teoria oli mielenkiintoinen. Yksi varasto koko universumille (Muuten, tietääkö kukaan, tekikö Amazon tämän Sablen kanssa?)
Joka tapauksessa, tässä on minun tarinani.
Olin tuolloin työskennellyt Googlella hieman yli kaksi vuotta, ja eräänä päivänä sain Bigtablen suunnittelutiimiltä sähköpostin, joka meni suunnilleen näin:
Rakas Steve,
Terveisiä Bigtable-tiimistä. Haluamme ilmoittaa, että [palvelinkeskuksen nimi] käytät hyvin, hyvin vanhaa Bigtable-binaaria. Tätä versiota ei enää tueta, ja haluamme auttaa sinua päivittämään uusimpaan versioon.
Kerro minulle, jos voit varata aikaa tämän asian käsittelemiseen yhdessä.
Kaikki parhaat,
Bigtable joukkue
Googlessa saat paljon postia, joten ensi silmäyksellä luin jotain tällaista:
Arvoisa vastaanottaja,
Terveisiä jostain tiimistä. Haluamme viestiä, että blaa blaa blaa blaa. Bla blaa blaa blaa blaa ja blaa blaa blaa välittömästi.
Kerro meille, jos voit varata osan arvokkaasta ajasta bla-bla-blaa.
Kaikki parhaat,
Jonkinlainen käsky
Melkein poistin sen heti, mutta tajunnan reunalla tunsin tuskallisen, kiusallisen tunteen, että se ei oikeasti näyttää kuitenkin viralliselta kirjeeltä ilmeisesti, että vastaanottaja erehtyi, koska en käyttänyt Bigtablea.
Mutta se oli outoa.
Loppupäivän mietin vuorotellen mikrokeittiössä töitä ja millaista hainlihaa kokeilla, joista ainakin kolme oli tarpeeksi lähellä osumaan istuimeltani tarkasti kohdistetulla keksiheitolla, mutta ajatus kirjoittamisesta ei koskaan jättänyt minuun kasvavaa lievää ahdistusta.
He sanoivat selvästi nimeni. Ja sähköposti lähetettiin minun sähköpostiosoitteeseen, ei jonkun muun, eikä se ole kopio: tai piilokopio:. Sävy on hyvin henkilökohtainen ja selkeä. Ehkä tämä on jonkinlainen virhe?
Lopulta uteliaisuus voitti minut ja menin katsomaan Borg-konsolia heidän mainitsemassaan datakeskuksessa.
Ja tietysti minulla oli BigTable-tallennustila hallinnassa. Anteeksi, mitä? Katsoin sen sisältöä, ja vau! Se tuli Codelabin inkubaattorista, jossa istuin ensimmäisen viikon aikana Googlessa kesäkuussa 2005. Codelab pakotti sinut ajamaan Bigtablea kirjoittamaan arvoja sinne, enkä ilmeisesti koskaan sulkenut tallennustilaa sen jälkeen. Se toimi edelleen, vaikka yli kaksi vuotta oli kulunut.
Tässä tarinassa on useita huomionarvoisia puolia. Ensinnäkin Bigtablen työ oli niin merkityksetöntä Googlen mittakaavassa, että vain kaksi vuotta myöhemmin kukaan huomasi ylimääräisen tallennustilan, ja vain siksi, että binaariversio oli vanhentunut. Vertailun vuoksi olen joskus harkinnut käyttöä nettipelilleni. Tuolloin tämä palvelu maksoi noin 16 000 dollaria vuodessa. tyhjä Bigtable GCP:llä. En väitä, että he huijaavat sinua, mutta minun mielestäni se on paljon rahaa tyhjästä vitun tietokannasta.
Toinen huomionarvoinen näkökohta on, että varastointi toimii edelleen kahden vuoden jälkeen. MITÄ VITTUU? Datakeskukset tulevat ja menevät; ne kokevat katkoksia, niille tehdään määräaikaishuolto, ne muuttuvat jatkuvasti. Laitteita päivitetään, kytkimiä vaihdetaan, kaikkea parannetaan jatkuvasti. Kuinka helvetissä he pystyivät pitämään ohjelmani käynnissä kahden vuoden ajan kaikilla näillä muutoksilla? Tämä saattaa tuntua vaatimattomalta saavutukselta vuonna 2020, mutta vuosina 2005-2007 se oli varsin vaikuttava.
Ja mikä ihmeellisin puoli on, että ulkopuolinen suunnittelutiimi jossain toisessa osavaltiossa lähestyy minua, pienen, melkein tyhjän Bigtable-esineen omistajaa, jolla on nolla liikennettä kahden viime vuoden aikana - ja tarjoamme apua sen päivittämiseen.
Kiitin heitä, poistin tallennustilan ja elämä jatkui normaalisti. Mutta kolmetoista vuotta myöhemmin ajattelen edelleen tuota kirjettä. Koska joskus saan samanlaisia sähköposteja Google Cloudista. Ne näyttävät tältä:
Hyvä Google Cloud -käyttäjä
Muistaakseni lopetamme [olennainen palvelu, jota käytät] -palvelun elokuusta 2020 alkaen, minkä jälkeen et voi päivittää esiintymiäsi. Suosittelemme päivittämään uusimpaan versioon, joka on beta-testauksessa, jossa ei ole dokumentaatiota, ei siirtopolkua ja joka on vanhentunut ystävällisellä avullamme.
Olemme sitoutuneet varmistamaan, että tällä muutoksella on mahdollisimman vähän vaikutusta kaikkiin Google Cloud -alustan käyttäjiin.
Parhaita kavereita ikuisesti,
Google Cloud Platform
Mutta en melkein koskaan lue tällaisia kirjeitä, koska ne itse asiassa sanovat:
Arvoisa vastaanottaja,
Mene helvettiin. Vittu, vittu, vittu. Jätä kaikki tekemäsi, koska sillä ei ole väliä. Tärkeintä on aikamme. Hukkaamme aikaa ja rahaa paskamme ylläpitämiseen ja olemme kyllästyneitä siihen, joten emme tue sitä enää. Joten lopeta vitun suunnitelmasi ja ala kaivaa paskaa dokumentaatiotamme, kerjäämään foorumeita, ja muuten, uusi paskamme on täysin erilaista kuin vanha paska, koska sotsimme tämän suunnittelun aika pahasti, heh, mutta se on sinun juttusi. ongelma, ei meidän.
Pyrimme edelleen varmistamaan, että kaikki kehitystyösi muuttuvat käyttökelvottomiksi vuoden sisällä.
Ole hyvä ja lähde vittuun
Google Cloud Platform
Ja tosiasia on, että saan tällaisia kirjeitä noin kerran kuukaudessa. Tätä tapahtuu niin usein ja niin jatkuvasti, että ne väistämättä työnnetty pois minut GCP:stä pilventorjuntaleirille. En enää suostu olemaan riippuvainen heidän omasta kehityksestään, koska itse asiassa devopsien on helpompi ylläpitää avoimen lähdekoodin järjestelmää paljaalla virtuaalikoneella kuin yrittää pysyä Googlen mukana sen "vanhentuneiden" tuotteiden sulkemiskäytännössä.
Ennen kuin palaan Google Cloudiin, koska edes lähellä ei kritisoi niitä, katsotaanpa yrityksen suorituskykyä joillakin muilla alueilla. Googlen insinöörit ovat ylpeitä ohjelmistosuunnittelustaan, ja juuri tämä aiheuttaa ongelmia. Ylpeys on ansa varomattomille, ja se on saanut monet Googlen työntekijät ajattelemaan, että heidän päätöksensä ovat aina oikeita ja että oikeassa oleminen (jonkin epämääräisen sumean määritelmän mukaan) on tärkeämpää kuin asiakkaista välittäminen.
Annan satunnaisia esimerkkejä muista suurista projekteista Googlen ulkopuolella, mutta toivon, että näet tämän kaavan kaikkialla. Se on seuraava: taaksepäin yhteensopivuus pitää järjestelmät elossa ja ajan tasalla vuosikymmeniä.
Taaksepäin yhteensopivuus on kaikkien menestyksekkäiden järjestelmien suunnittelun tavoite avoin käyttö eli toteutettu avoimella lähdekoodilla ja/tai avoimilla standardeilla. Minusta tuntuu, että sanon jotain liian ilmeistä, että kaikki ovat jopa epämukavia, mutta ei. Tämä on poliittinen kysymys, joten esimerkkejä kaivataan.
Ensimmäinen järjestelmä, jonka valitsen, on vanhin: GNU Emacs, joka on eräänlainen hybridi Windows Notepadin, käyttöjärjestelmäytimen ja kansainvälisen avaruusaseman välillä. Sitä on hieman vaikea selittää, mutta pähkinänkuoressa Emacs on alusta, joka luotiin vuonna 1976 (kyllä, melkein puoli vuosisataa sitten) ohjelmointiin, joka tekee sinusta tuottavamman, mutta naamioituu tekstieditoriksi.
Käytän Emacsia joka päivä. Kyllä, käytän myös IntelliJ:tä päivittäin, se on kasvanut tehokkaaksi työkalualustaksi. Mutta laajennusten kirjoittaminen IntelliJ:lle on paljon kunnianhimoisempi ja monimutkaisempi tehtävä kuin laajennusten kirjoittaminen Emacsille. Ja mikä tärkeintä, kaikki Emacsille kirjoitettu säilytetään iäti.
Käytän edelleen ohjelmistoa, jonka kirjoitin Emacsille vuonna 1995. Ja olen varma, että joku käyttää Emacsille kirjoitettuja moduuleja 80-luvun puolivälissä, ellei aikaisemmin. Ne saattavat vaatia vähän säätämistä ajoittain, mutta tämä on todella harvinaista. En tiedä mitään, mitä olen koskaan kirjoittanut Emacsille (ja olen kirjoittanut paljon), joka olisi vaatinut uudelleenarkkitehtuuria.
Emacsissa on toiminto nimeltä make-obsolete vanhentuneille entiteeteille. Emacsin terminologia perustietokonekonsepteille (kuten mitä "ikkuna" on) eroaa usein alan käytännöistä, koska Emacs esitteli ne kauan sitten. Tämä on tyypillinen vaara niille, jotka ovat aikaansa edellä: kaikki ehdot ovat vääriä. Mutta Emacsilla on deprecation-käsite, jota heidän ammattikielellään kutsutaan vanhentuneisuus.
Mutta Emacsin maailmassa näyttää olevan erilainen toimiva määritelmä. Erilainen taustafilosofia, jos haluat.
Emacsin maailmassa (ja monilla muilla alueilla, joita käsittelemme alla) vanhentunut API-tila tarkoittaa periaatteessa: "Sinun ei todellakaan pitäisi käyttää tätä lähestymistapaa, koska vaikka se toimii, se kärsii erilaisista puutteista, jotka lista tästä. Mutta loppujen lopuksi se on sinun valintasi."
Googlen maailmassa vanhentuminen tarkoittaa, että "rikomme sitoumuksemme sinua kohtaan." Tämä on totta. Tätä se pohjimmiltaan tarkoittaa. Tämä tarkoittaa, että he pakottavat sinut säännöllisesti tehdä työtä, ehkä paljon työtä rangaistuksena siitä, että uskot niihin : Meillä on paras ohjelmisto. Nopein! Teet kaiken ohjeiden mukaan, käynnistät sovelluksesi tai palvelusi ja sitten bam, vuoden tai kahden kuluttua se hajoaa.
Se on kuin myyisi käytettyä autoa, joka varmasti hajoaa 1500 km:n jälkeen.
Nämä ovat kaksi täysin erilaista "vanhentumisen" filosofista määritelmää. Googlen hajun määritelmä . En usko tätä itse asiassa suunniteltu vanheneminen samassa mielessä kuin Apple. Mutta Google aikoo ehdottomasti katkaista ohjelmasi kiertokulkusuunnassa. Tiedän tämän, koska työskentelin siellä ohjelmistosuunnittelijana yli 12 vuotta. Heillä on epämääräiset sisäiset ohjeet siitä, kuinka paljon taaksepäin yhteensopivuutta tulee noudattaa, mutta se on viime kädessä jokaisen yksittäisen tiimin tai palvelun oma asia. Yritys- tai suunnittelutason suosituksia ei ole, ja rohkein suositus vanhenemissykleihin liittyen on "yritä antaa asiakkaille 6–12 kuukautta päivitysaikaa ennen koko järjestelmän rikkomista".
Ongelma on paljon suurempi kuin he ajattelevat, ja se jatkuu vielä vuosia, koska asiakaspalvelu ei ole heidän DNA:ssaan. Tästä lisää alla.
Tässä vaiheessa aion tehdä rohkean lausunnon, että Emacs menestyy suuressa määrin ja tasaisesti pohjimmiltaan koska he ottavat taaksepäin yhteensopivuuden niin vakavasti. Itse asiassa tämä on artikkelimme teesi. Onnistuneet, pitkäikäiset avoimet järjestelmät ovat menestyksensä velkaa mikroyhteisöille, jotka ovat asuneet niiden ympärillä vuosikymmeniä laajennuksia/laajennuksia. Tämä on ekosysteemi. Olen jo puhunut alustojen luonteesta ja niiden tärkeydestä ja siitä, että Google ei ole koskaan koko yrityshistoriansa aikana ymmärtänyt, mitä menestyvän avoimen alustan luomisessa Androidin tai Chromen ulkopuolelle kuuluu.
Itse asiassa minun pitäisi mainita Android lyhyesti, koska luultavasti ajattelet sitä.
Ensinnäkin Android ei ole Google. Heillä ei ole melkein mitään yhteistä keskenään. Android on yritys, jonka Google osti heinäkuussa 2005, yritys sai toimia enemmän tai vähemmän itsenäisesti ja on itse asiassa pysynyt suurelta osin koskemattomana välivuosina. Android on pahamaineinen teknologiapino ja yhtä pahamaineinen piikikäs organisaatio. Kuten eräs Googlen työntekijä sanoi: "Et voi vain kirjautua Androidiin."
Edellisessä artikkelissa keskustelin siitä, kuinka huonoja jotkin Androidin varhaiset suunnittelupäätökset olivat. Helvetti, kun kirjoitin tuon artikkelin, he julkaisivat paskaa nimeltä "pikasovelluksia", jotka ovat nyt (yllätys!) , ja ymmärrän, jos olit tarpeeksi tyhmä kuuntelemaan Googlea ja siirtämään sisältösi näihin pikasovelluksiin.
Mutta tässä on ero, merkittävä ero, joka on se, että Android-ihmiset todella ymmärtävät, kuinka tärkeitä alustat ovat, he yrittävät parhaansa pitääkseen vanhat Android-sovellukset toiminnassa. Itse asiassa heidän pyrkimyksensä säilyttää taaksepäin yhteensopivuus ovat niin äärimmäisiä, että jopa minä lyhyen työjaksoni aikana Android-divisioonassa muutama vuosi sitten huomasin yrittäväni saada heidät luopumaan joidenkin vanhimpien laitteiden ja sovellusliittymien tuesta (Olin väärässä , kuten monissa muissa menneissä ja nykyisissä asioissa. Anteeksi Android kaverit! Nyt kun olen käynyt Indonesiassa, ymmärrän miksi tarvitsemme niitä).
Android-ihmiset ajavat taaksepäin yhteensopivuuden lähes käsittämättömiin äärimmäisyyksiin ja keräävät valtavia määriä vanhoja teknisiä velkoja järjestelmiinsä ja työkaluketjuihinsa. Voi luoja, sinun pitäisi nähdä joitain hulluja asioita, joita heidän on tehtävä rakennusjärjestelmässään, kaikki yhteensopivuuden nimissä.
Myönnän tästä Androidille halutun "You're Not Google" -palkinnon. He eivät todellakaan halua tulla Googleksi, joka ei osaa luoda kestäviä alustoja, vaan Androidiksi hän tietää, kuinka tehdä se. Ja niin Google on erittäin älykäs yhdessä suhteessa: antaa ihmisten tehdä asioita omalla tavallaan Androidissa.
Androidin pikasovellukset olivat kuitenkin melko typerä idea. Ja tiedätkö miksi? Koska he vaativat kirjoita ja suunnittele sovelluksesi uudelleen! On kuin ihmiset vain kirjoittaisivat uudelleen kaksi miljoonaa hakemusta. Luulen, että Instant Apps oli jonkun Googlen työntekijän idea.
Mutta siinä on ero. Taaksepäin yhteensopivuus maksaa korkeat kustannukset. Android kantaa itse näiden kustannusten taakan, kun taas Google vaatii, että taakka on kannettava olet, maksava asiakas.
Voit nähdä Androidin sitoutumisen taaksepäin yhteensopivuuteen sen sovellusliittymissä. Kun neljä tai viisi eri alijärjestelmää tekevät kirjaimellisesti samaa asiaa, se on varma merkki siitä, että ytimenä on sitoutuminen taaksepäin yhteensopivuuteen. Mikä alustojen maailmassa on synonyymi sitoutumiselle asiakkaisiisi ja markkinoihisi.
Googlen suurin ongelma tässä on heidän ylpeytensä suunnitteluhygieniastaan. He eivät pidä siitä, kun on monia eri tapoja tehdä sama asia, kun vanhat, vähemmän toivottavat tavat ovat uusien, hienompien tapojen vieressä. Se lisää järjestelmän uusien oppimiskäyrää, se lisää vanhojen sovellusliittymien ylläpidon taakkaa, se hidastaa uusien ominaisuuksien nopeutta, ja pääsynti on, että se ei ole kaunis. Google – kuten Lady Ascot Tim Burtonin Liisa ihmemaassa:
Lady Ascot:
- Alice, tiedätkö mitä pelkään eniten?
- Aristokratian rappeutuminen?
- Pelkäsin, että olisin rumia lastenlapsia.
Ymmärtääksemme kauniin ja käytännöllisen välisen kompromissin, katsotaanpa kolmatta menestyvää alustaa (Emacsin ja Androidin jälkeen) ja katsotaan kuinka se toimii: itse Java.
Javassa on paljon vanhentuneita sovellusliittymiä. Deprecation on erittäin suosittu Java-ohjelmoijien keskuudessa, jopa suositumpi kuin useimmissa ohjelmointikielissä. Java itse, ydinkieli ja kirjastot poistavat jatkuvasti API:ita.
Otetaan vain yksi tuhansista esimerkeistä, pidetään vanhentuneena. Se on vanhentunut Java 1.2:n julkaisun jälkeen joulukuussa 1998. Siitä on kulunut 22 vuotta, kun tämä poistettiin käytöstä.
Mutta todellinen koodini tuotannossa tappaa edelleen säikeitä joka päivä. Onko se sinun mielestäsi todella hyvä? Ehdottomasti! Tarkoitan tietysti, jos kirjoittaisin koodin uudelleen tänään, toteuttaisin sen eri tavalla. Mutta pelini koodi, joka on tehnyt satoja tuhansia ihmisiä onnelliseksi viimeisen kahden vuosikymmenen aikana, on kirjoitettu toiminnolla, joka sulkee liian kauan roikkuvat viestiketjut, ja minä ei ole koskaan tarvinnut vaihtaa. Tunnen järjestelmäni paremmin kuin kukaan muu, minulla on kirjaimellisesti 25 vuoden kokemus sen kanssa työskentelystä tuotannossa, ja voin sanoa varmasti: minun tapauksessani näiden tiettyjen työntekijäketjujen sulkeminen on täysin harmittomia. Tämän koodin uudelleenkirjoittaminen ei ole ajan ja vaivan arvoista, ja kiitos Larry Ellisonille (luultavasti), ettei Oracle pakottanut minua kirjoittamaan sitä uudelleen.
Oracle varmaan ymmärtää myös alustoja. Kuka tietää.
Todisteita löytyy kaikkialta Java-sovellusliittymistä, jotka ovat täynnä vanhenemisen aaltoja, kuten kanjonin jäätikön viivoja. Löydät helposti viisi tai kuusi erilaista näppäimistön navigointihallintaa (KeyboardFocusManager) Java Swing -kirjastosta. On itse asiassa vaikea löytää Java-sovellusliittymää, joka ei ole vanhentunut. Mutta toimivat silti! Uskon, että Java-tiimi todella poistaa API:n vain, jos käyttöliittymä aiheuttaa räikeän tietoturvaongelman.
Tässä on asia, ihmiset: Me ohjelmistokehittäjät olemme kaikki hyvin kiireisiä, ja jokaisella ohjelmistoalueella kohtaamme kilpailevia vaihtoehtoja. Kielen X ohjelmoijat harkitsevat milloin tahansa kielen Y mahdollisena korvaajana. Ai, etkö usko minua? Haluatko kutsua sitä Swiftiksi? Kuten kaikki muuttavat Swiftiin, eikä kukaan hylkää sitä, eikö niin? Vau, kuinka vähän sinä tiedät. Yritykset laskevat kahden mobiilikehitystiimin (iOS ja Android) kustannuksia – ja ne alkavat ymmärtää, että hauskoilla nimillä, kuten Flutter ja React Native, monialustaiset kehitysjärjestelmät todella toimivat ja niitä voidaan käyttää pienentämään niiden kokoa. mobiilitiimit kahdesti tai päinvastoin tehdä niistä kaksi kertaa tuottavampia. Pelissä on oikeaa rahaa. Kyllä, kompromisseja on, mutta toisaalta rahaa.
Oletetaan hypoteettisesti, että Apple otti typerästi Guido van Rossumin vihjeen ja julisti, että Swift 6.0 on taaksepäin yhteensopimaton Swift 5.0:n kanssa, aivan kuten Python 3 ei ole yhteensopiva Python 2:n kanssa.
Kerroin tämän tarinan luultavasti noin kymmenen vuotta sitten, mutta noin viisitoista vuotta sitten menin O'Reilly's Foo Campille Guidon kanssa, istuin teltassa Paul Grahamin ja joukon isoja laukauksia. Istuimme helteessä ja odotimme Larry Pagen lentävän ulos henkilökohtaisella helikopterillaan, kun Guido huudahti noin "Python 3000" -aluksella, jonka hän nimesi sen mukaan, kuinka monta vuotta kesti ennen kuin kaikki muuttavat sinne. Kysyimme häneltä jatkuvasti, miksi hän rikkoi yhteensopivuuden, ja hän vastasi: "Unicode." Ja kysyimme, jos meidän pitäisi kirjoittaa koodimme uudelleen, mitä muita etuja näkisimme? Ja hän vastasi "Joooooooooooooouuuuuuuuniiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiinum.
Jos asennat Google Cloud Platform SDK:n ("gcloud"), saat seuraavan ilmoituksen:
Arvoisa vastaanottaja,
Haluamme muistuttaa, että Python 2:n tuki on poistettu käytöstä, joten vittuun
… ja niin edelleen. Elämän kiertokulku.
Mutta pointti on, että jokaisella kehittäjällä on valinta. Ja jos pakotat heidät kirjoittamaan koodia uudelleen tarpeeksi usein, he saattavat ajatella muut vaihtoehtoja. He eivät ole panttivankejasi, vaikka kuinka paljon haluaisit heidän olevan. He ovat vieraitasi. Python on edelleen erittäin suosittu ohjelmointikieli, mutta vittu, Python 3(000) loi sellaisen sotkun itsessään, yhteisöissään ja yhteisöjensä käyttäjien keskuudessa, että seurauksia ei ole selvitetty viiteentoista vuoteen.
Kuinka monta Python-ohjelmaa on kirjoitettu uudelleen Go:ssa (tai Rubyssa tai muussa vaihtoehdossa) tämän taaksepäin yhteensopimattomuuden vuoksi? Kuinka paljon uutta ohjelmistoa on kirjoitettu jossain muussa kuin Pythonissa, vaikka se voisi olla Pythonilla kirjoitettuna, jos Guido ei olisi polttanut koko kylää? Vaikea sanoa, mutta Python on selvästi kärsinyt. Se on valtava sotku ja kaikki häviävät.
Oletetaan siis, että Apple ottaa ohjeen Guidolta ja katkaisee yhteensopivuuden. Mitä luulet seuraavaksi tapahtuvan? No, ehkä 80-90% kehittäjistä kirjoittaa ohjelmistonsa uudelleen, jos mahdollista. Toisin sanoen 10-20 % käyttäjäkunnasta siirtyy automaattisesti jollekin kilpailevalle kielelle, kuten Flutterille.
Tee tämä useita kertoja, niin menetät puolet käyttäjäkunnastasi. Kuten urheilussa, myös ohjelmointimaailmassa nykymuodolla on väliä. kaikki. Jokainen, joka menettää puolet käyttäjistään viidessä vuodessa, katsotaan Big Fat Loseriksi. Sinun täytyy olla trendikäs alustojen maailmassa. Mutta tämä on paikka, jossa vanhempien versioiden tukematta jättäminen pilaa sinut ajan myötä. Koska joka kerta kun pääset eroon joistakin kehittäjistä, (a) menetät heidät ikuisesti, koska he ovat vihaisia sinulle sopimuksen rikkomisesta, ja (b) annat ne kilpailijoillesi.
Ironista kyllä, autin Googlea kehittymään sellaiseksi primadonnaksi, joka jättää huomioimatta taaksepäin yhteensopivuuden, kun loin Grokin, lähdekoodin analysointi- ja ymmärrysjärjestelmän, jonka avulla itse koodin automatisointi ja instrumentointi on helppoa – samanlainen kuin IDE, mutta pilvipalvelu tallentaa tähän. toteutuneet esitykset kaikista miljardeista Googlen lähdekoodiriveistä suuressa tietovarastossa.
Grok tarjosi Googlen työntekijöille tehokkaan kehyksen automatisoitujen uudelleenjärjestelyjen suorittamiseen koko koodikannassa (kirjaimellisesti kaikkialla Googlessa). Järjestelmä ei laske vain alkupään riippuvuuksiasi (joista olet riippuvainen), vaan myös alavirtaan (jotka ovat sinun päätettävissäsi), joten kun vaihdat sovellusliittymiä, tiedät kaikki, joita rikot! Tällä tavalla, kun teet muutoksia, voit varmistaa, että jokainen API-käyttäjäsi on päivittänyt uuteen versioon, ja todellisuudessa, usein heidän kirjoittamansa Rosie-työkalun avulla, voit automatisoida prosessin täysin.
Tämän ansiosta Googlen koodikanta voi olla sisäisesti lähes yliluonnollisen puhdas, sillä nämä robottipalvelijat kiipeilevät ympäri taloa ja siivoavat automaattisesti kaiken, jos he nimesivät SomeDespicablyLongFunctionName uudelleen SomeDespicablyLongMethodNameksi, koska joku päätti sen olevan ruma lapsenlapsi ja hänen on nukutettava.
Ja suoraan sanottuna, se toimii melko hyvin Googlelle... sisäisesti. Tarkoitan, kyllä, Googlen Go-yhteisö nauraa Googlen Java-yhteisön kanssa, koska heillä on tapana tehdä jatkuvaa uudelleenkäsittelyä. Jos käynnistät jotain uudelleen N kertaa, se tarkoittaa, että et vain sotkenut sen N-1 kertaa, vaan jonkin ajan kuluttua käy melko selväksi, että luultavasti sekoitit sen myös N:nnellä yrittämällä. Mutta yleisesti ottaen he pysyvät kaiken tämän hälinän yläpuolella ja pitävät koodin "puhtaana".
Ongelma alkaa, kun he yrittävät pakottaa tämän asenteen pilviasiakkailleen ja muiden sovellusliittymien käyttäjille.
Olen esitellyt sinulle vähän Emacsia, Androidia ja Javaa; Katsotaanpa uusinta menestyvää pitkäikäistä alustaa: itse Webiä. Voitteko kuvitella kuinka monta iteraatiota HTTP on käynyt läpi vuoden 1995 jälkeen, kun käytimme vilkkuvia tageja? ja "rakenteilla"-kuvakkeet verkkosivuilla.
Mutta toimii silti! Ja nämä sivut toimivat edelleen! Kyllä, kaverit, selaimet ovat taaksepäin yhteensopivuuden maailmanmestareita. Chrome on toinen esimerkki harvinaisesta Googlen alustasta, jonka päät on kierretty oikein, ja kuten saatat arvata, Chrome toimii tehokkaasti hiekkalaatikkoyrityksenä, joka on erillään muusta Googlesta.
Haluan myös kiittää ystäviämme käyttöjärjestelmien kehittäjistä: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD jne., jotka ovat tehneet niin hienosta työstä taaksepäin yhteensopivuuden suhteen menestyneillä alustoillaan (Apple saa parhaimmillaan C:n haittapuoli on, että ne rikkovat kaiken jatkuvasti ilman hyvää syytä, mutta jotenkin yhteisö kiertää sen jokaisen julkaisun yhteydessä, eivätkä OS X -säiliöt ole vieläkään täysin vanhentuneita... vielä).
Mutta odota, sanot. Emmekö vertaa omenoita appelsiineihin – erilliset ohjelmistojärjestelmät yhdessä koneessa, kuten Emacs/JDK/Android/Chrome, verrattuna monipalvelinjärjestelmiin ja API:ihin, kuten pilvipalveluihin?
No, twiittasin tästä eilen, mutta Larry Wallin (ohjelmointikielen Perl luoja - noin per.) tyyliin "sucks/rules" -periaatteella etsin sanan. vanhentunut Googlen ja Amazonin kehittäjäsivustoilla. Ja vaikka AWS:llä on satoja kertaa enemmän palvelutarjontaa kuin GCP, Googlen kehittäjädokumentaatio mainitsee käytöstäpoiston noin seitsemän kertaa useammin.
Jos joku Googlesta lukee tätä, hän on luultavasti valmis ottamaan esiin Donald Trumpin kaltaisia kaavioita, jotka osoittavat, että he todella tekevät kaiken oikein ja että minun ei pitäisi tehdä epäreiluja vertailuja, kuten "sanan vanhentunut mainintojen määrä vs. palvelujen määrä""
Mutta kaikkien näiden vuosien jälkeen Google Cloud on edelleen palvelu nro 3 (en ole koskaan kirjoittanut artikkelia epäonnistuneesta yrityksestä tulla numero 2:ksi), mutta jos sisäpiiriläisiä on uskoa, on olemassa joitakin huolenaiheita, jotka saattavat pian pudota. Nro 4.
Minulla ei ole mitään pakottavia perusteita väitöskirjani "todistamiseksi". Minulla on vain värikkäitä esimerkkejä, joita olen kerännyt yli 30 vuoden aikana kehittäjänä. Olen jo maininnut tämän ongelman syvästi filosofisen luonteen; jollain tapaa se on politisoitunut kehittäjäyhteisöissä. Jotkut uskovat sen luojat alustojen pitäisi välittää yhteensopivuudesta, kun taas toiset ajattelevat, että tämä on huolenaihe käyttäjille (kehittäjät itse). Yksi kahdesta. Eikö se todellakin ole poliittinen kysymys, kun päätämme, kenen pitäisi vastata yhteisten ongelmien kustannuksista?
Tämä on siis politiikkaa. Ja puheeseeni tulee luultavasti vihaisia vastauksia.
miten käyttäjä Google Cloud Platform ja AWS-käyttäjänä kaksi vuotta (työskennellessäni Grabille) voin sanoa, että Amazonin ja Googlen filosofioiden välillä on valtava ero prioriteettien suhteen. En kehitä aktiivisesti AWS:ää, joten en tiedä kovin hyvin, kuinka usein he poistavat vanhoja API:ita. Mutta epäillään, että tätä ei tapahdu läheskään yhtä usein kuin Googlessa. Ja uskon todella, että tämä jatkuvan kiistan ja turhautumisen lähde GCP:ssä on yksi suurimmista tekijöistä, jotka hidastavat alustan kehitystä.
Tiedän, etten maininnut konkreettisia esimerkkejä GCP-järjestelmistä, joita ei enää tueta. Voin sanoa, että melkein kaikki mitä olen käyttänyt verkoista (vanhimmasta VPC:hen) tallennustilaan (Cloud SQL v1-v2), Firebaseen (nyt Firestore täysin erilaisella API:lla), App Engineen (älkäämme edes aloittako) , pilvipäätepisteet Cloud Endpoint ja jopa... En tiedä - ehdottomasti kaikki tämä pakotti sinut kirjoittamaan koodin uudelleen enintään 2-3 vuoden kuluttua, eivätkä he koskaan automatisoineet siirtoa puolestasi ja usein . Ihan kuin niin olisi pitänyt olla.
Ja joka kerta kun katson AWS:ää, kysyn itseltäni, miksi ihmeessä käytän edelleen GCP:tä. He eivät selvästikään tarvitse asiakkaita. He tarvitsevat покупатели. Ymmärrätkö eron? Anna minun selittää.
Google Cloud on , jossa ihmiset ehdottavat ohjelmistoratkaisujaan ja välttääkseen tyhjän ravintolaefektin, heidän oli täytettävä se ehdotuksilla, joten he tekivät sopimuksen Bitnami-nimisen yrityksen kanssa luodakseen joukon ratkaisuja, jotka otetaan käyttöön "yhdellä napsautuksella" tai pitäisi Kirjoitan sen itse "ratkaisuiksi", koska ne eivät ratkaise mitään. Ne ovat yksinkertaisesti valintaruutuja, markkinoinnin täyteaineita, eikä Google ole koskaan välittänyt siitä, toimiiko jokin työkalu todella. Tunnen tuotepäälliköitä, jotka ovat olleet kuljettajan paikalla, ja voin vakuuttaa, etteivät nämä ihmiset välitä.
Otetaan esimerkiksi oletettavasti "yhden napsautuksen" käyttöönottoratkaisu. . Olin kuoliaaksi Google Cloud SQL -juhlista, joten aloin miettiä oman Percona-klusterin rakentamista vaihtoehtona. Ja tällä kertaa Google näytti tehneen hyvää työtä, he aikoivat säästää minulta aikaa ja vaivaa yhdellä napin painalluksella!
Hienoa, mennään. Seurataan linkkiä ja klikataan tätä painiketta. Valitse "Kyllä" hyväksyäksesi kaikki oletusasetukset ja ottaaksesi klusterin käyttöön Google-pilviprojektissasi. Haha, se ei toimi. Mikään näistä paskasta ei toimi. Työkalua ei koskaan testattu ja se alkoi mätää heti ensimmäisestä minuutista lähtien, enkä ihmettelisi, jos yli puolet "ratkaisuista" olisi yhden napsautuksen käyttöönottoja (nyt ymmärrämme miksi lainaukset) yleensä ei toimi. Tämä on ehdottoman toivotonta pimeyttä, johon on parempi olla menemättä.
Mutta Google on oikeassa halunsa voit käyttää niitä. He haluavat sinun ostanut. Heille se on kauppaa. He eivät halua mitään tuki. Se ei ole osa Googlen DNA:ta. Kyllä, insinöörit tukevat toisiaan, kuten tarinani Bigtablen kanssa osoittaa. Mutta tavallisten ihmisten tuotteissa ja palveluissa he aina olivat armottomia sisällä , joka ei täytä kannattavuuden rimaa, vaikka sillä olisi miljoonia käyttäjiä.
Ja tämä on todellinen haaste GCP:lle, koska tämä on DNA kaikkien pilvipalvelujen takana. He eivät yritä tukea mitään; On hyvin tunnettua, että he kieltäytyvät isännöimästä (hallittuna palveluna) mitään kolmannen osapuolen ohjelmistoja siihen asti kun, kunnes AWS tekee saman ja rakentaa menestyvän liiketoiminnan sen ympärille ja kun asiakkaat kirjaimellisesti vaativat samaa. Googlen saaminen tukemaan jotakin vaatii kuitenkin jonkin verran vaivaa.
Tämä tukikulttuurin puute yhdistettynä "rikotaan ja tehdään kauniimpi" -mentaliteetti vie kehittäjät vieraanvaraiseksi.
Ja se ei ole hyvä asia, jos haluat rakentaa pitkäikäisen alustan.
Google, herää, vittu. Nyt on vuosi 2020. Olet silti häviämässä. On aika katsoa terävästi peiliin ja vastata, haluatko todella jatkaa pilviliiketoiminnassa.
Jos sitten haluat jäädä lopeta kaiken rikkominen. Kaverit, olette rikkaita. Me kehittäjät emme. Joten kun on kyse siitä, kuka kantaa yhteensopivuuden taakan, sinun on otettava se itsellesi. Ei meille.
Koska siellä on ainakin kolme muuta todella hyvää pilviä. He viittoivat.
Ja nyt siirryn korjaamaan kaikki rikkinäiset järjestelmäni. Eh.
Ensi kertaan!
PS-päivitys luettuasi joitain tämän artikkelin keskusteluja (keskustelut ovat mahtavia, btw). Firebase-tukea ei ole lopetettu, enkä ole tietoinen suunnitelmista. Heillä on kuitenkin ikävä suoratoistovirhe, joka saa Java-asiakasohjelman pysähtymään App Enginessä. Yksi heidän insinööristään auttoi minua ratkaisemaan tämän ongelman, kun olin töissä Googlella, mutta he eivät koskaan korjanneet vikaa, joten minulla on huono ratkaisu, kun minun on käynnistettävä GAE-sovellus uudelleen joka päivä. Ja niin se on ollut neljä vuotta! Heillä on nyt Firestore. Siihen siirtyminen vaatii paljon työtä, koska se on täysin erilainen järjestelmä, eikä Firebase-virhettä koskaan korjata. Mitä johtopäätöstä voidaan vetää? Voit saada apua jos työskentelet yrityksessä. Olen luultavasti ainoa, joka käyttää Firebasea GAE:ssä, koska kirjaan alle 100 avainta 100-prosenttisesti alkuperäiseen sovellukseen ja se lakkaa toimimasta muutaman päivän välein tunnetun virheen vuoksi. Mitä voin sanoa muuta kuin käyttää sitä omalla vastuullasi. Vaihdan Redisiin.
Olen myös nähnyt joidenkin kokeneempien AWS-käyttäjien sanovan, että AWS ei yleensä koskaan lopeta minkään palvelun tukemista, ja SimpleDB on hyvä esimerkki. Oletukseni siitä, että AWS:llä ei ole samaa tukisairautta kuin Googlella, näyttävät olevan perusteltuja.
Lisäksi huomasin, että 20 päivää sitten Google App Engine -tiimi rikkoi tärkeän Go-kirjaston isännöinnin ja sulki GAE-sovelluksen yhdeltä Go-kehittäjistä. Se oli todella typerää.
Lopuksi, olen kuullut Googlen työntekijöiden jo keskustelevan tästä asiasta ja olevan yleisesti samaa mieltä kanssani (love you guys!). Mutta he näyttävät ajattelevan, että ongelma on ratkaisematon, koska Googlen kulttuurissa ei koskaan ollut oikeaa kannustinrakennetta. Ajattelin, että olisi hyvä varata hetki keskustellakseni aivan uskomattomasta kokemuksesta, jonka sain työskennellä AWS-insinöörien kanssa työskennellessäni Grabissa. Jonain päivänä tulevaisuudessa, toivottavasti!
Ja kyllä, vuonna 2005 heillä oli erityyppistä hainlihaa rakennuksen 43 jättiläisbuffetissa, ja suosikkini oli vasarahain liha. Vuoteen 2006 mennessä Larry ja Sergei pääsivät kuitenkin eroon kaikista epäterveellisistä välipaloista. Joten Bigtable-tarinassa vuonna 2007 ei todellakaan ollut haita, ja minä petin sinut.
Kun katsoin pilvi Bigtablea neljä vuotta sitten (anna tai ota), hinta oli tässä. Se näyttää nyt hieman laskeneen, mutta se on silti hirveän paljon tyhjälle tietovarastolle, varsinkin kun ensimmäinen tarinani osoittaa, kuinka merkityksetön tyhjä suuri taulukko on heidän mittakaavassaan.
Anteeksi, että loukkasin Apple-yhteisöä, enkä sano mitään mukavaa Microsoftista jne. Olet kunnossa, arvostan todella kaikkea keskustelua, jota tämä artikkeli on synnyttänyt! Mutta joskus sinun täytyy tehdä aaltoja aloittaaksesi keskustelun, tiedätkö?
Kiitos kun luit.
Päivitys 2, 19.08.2020. Raita !
Päivitys 3, 31.08.2020. Minuun otti yhteyttä Googlen insinööri Cloud Marketplacessa, joka osoittautui vanhaksi ystäväni. Hän halusi selvittää, miksi C2D ei toiminut, ja lopulta tajusimme, että se johtui siitä, että olin rakentanut verkkoni vuosia sitten, ja C2D ei toiminut vanhoissa verkoissa, koska aliverkkoparametri puuttui niiden malleista. Mielestäni potentiaalisten GCP-käyttäjien on parasta varmistaa, että he tuntevat tarpeeksi Googlen insinöörejä...
Lähde: will.com