A fenébe a Google, nem akartam újra blogolni. Annyi dolgom van. A blogírás időt, energiát és kreativitást igényel, amit jól tudnék hasznosítani: a könyveim, , a játékom és így tovább. De annyira felbosszantottál, hogy ezt le kell írnom.
Szóval fejezzük be ezt.
Hadd kezdjem egy rövid, de tanulságos történettel abból az időszakból, amikor elkezdtem dolgozni a Google-nál. Tudom, hogy az utóbbi időben sok rosszat mondtam a Google-ról, de felháborít, amikor a saját cégem rendszeresen hozzá nem értő üzleti döntéseket hoz. Ugyanakkor meg kell adnunk a magáét: a Google belső infrastruktúrája valóban rendkívüli, bátran kijelenthetjük, hogy ma nincs jobb. A Google alapítói sokkal jobb mérnökök voltak, mint én valaha is leszek, és ez a történet csak megerősíti ezt a tényt.
Először is egy kis háttér: a Google-nak van egy adattárolási technológiája, az úgynevezett . Figyelemre méltó technikai vívmány volt, az egyik első (ha nem az első) „végtelenül skálázható” kulcsérték tároló (K/V): lényegében a NoSQL kezdete. Manapság a Bigtable még mindig jól teljesít a meglehetősen zsúfolt K/V tárhelyen, de akkoriban (2005) elképesztően menő volt.
A Bigtable egyik viccessége, hogy voltak belső vezérlősík objektumaik (az implementáció részeként), úgynevezett tablet szerverek, nagy indexekkel, és valamikor szűk keresztmetszetgé váltak a rendszer méretezésekor. A Bigtable mérnökei azon gondolkodtak, hogyan valósítsák meg a méretezhetőséget, és hirtelen rájöttek, hogy lecserélhetik a táblagép-szervereket más Bigtable-tárolókra. Tehát a Bigtable része a Bigtable megvalósításának. Ezek a tárolóhelyek minden szinten rendelkezésre állnak.
Egy másik érdekes részlet, hogy a Bigtable egy ideig népszerűvé és mindenütt jelen volt a Google-on belül, minden csapatnak megvolt a saját tárháza. Így hát az egyik pénteki találkozón Larry Page mellékesen megkérdezte: „Miért van egynél több Bigtable? Miért nem csak egyet?” Elméletileg egy tárhelynek elegendőnek kell lennie a Google összes tárhelyszükségletének kielégítésére. Persze gyakorlati fejlesztési okokból (például egy esetleges kudarc következményei miatt) soha nem csak egyhez mentek, de az elmélet érdekes volt. Egy tárhely az egész Univerzum számára (Egyébként tudja valaki, hogy az Amazon megtette-e ezt a Sable-jával?)
Na mindegy, itt az én történetem.
Abban az időben alig több mint két éve dolgoztam a Google-nál, és egy nap kaptam egy e-mailt a Bigtable mérnöki csapatától, amely a következőképpen szólt:
Kedves Steve!
Üdvözlet a Bigtable csapatától. Szeretnénk tájékoztatni, hogy az [adatközpont neve] webhelyen egy nagyon-nagyon régi Bigtable bináris fájlt használ. Ez a verzió már nem támogatott, és szeretnénk segíteni a legújabb verzióra való frissítésben.
Kérem, tudassa velem, ha tud időt szakítani a probléma megoldására.
Minden jót,
Bigtable csapat
A Google-on rengeteg levelet kapsz, így első pillantásra valami ilyesmit olvastam:
Tisztelt Címzett!
Üdvözlet valamelyik csapattól. Azt akarjuk közölni, hogy bla bla bla bla bla. Bla bla bla bla bla, és bla bla bla azonnal.
Kérjük, tudassa velünk, ha értékes idejét beoszthatja bla-bla-bla-ra.
Minden jót,
Valamiféle parancs
Majdnem azonnal töröltem, de a tudatom szélén fájdalmas, kínos érzésem támadt. nem egészen de úgy néz ki, mint egy hivatalos levél nyilvánvalóan, hogy a címzett tévedett, mert nem használtam a Bigtable-t.
De furcsa volt.
A nap hátralévő részében felváltva a munkán gondolkodtam, és hogy milyen cápahúst próbáljak ki a mikrokonyhában, amiből legalább három elég közel volt ahhoz, hogy egy jól irányzott kekszdobással eltaláljak a helyemről, de a Az írás gondolata soha nem hagyott bennem egyre növekvő enyhe szorongást.
Egyértelműen mondták a nevemet. És az e-mailt az én e-mail címemre küldték, nem valaki másé, és ez nem cc: vagy bcc:. A hangnem nagyon személyes és világos. Lehet, hogy ez valami hiba?
Végül úrrá lett rajtam a kíváncsiság, és megnéztem a Borg konzolt az általuk említett adatközpontban.
És természetesen kezeltem a BigTable tárhelyet. Bocsánat, micsoda? Megnéztem a tartalmát, és wow! Abból a Codelab inkubátorból származott, amelyben ültem a Google-nál töltött első hetem alatt 2005 júniusában. A Codelab arra kényszerítette, hogy futtasd a Bigtable-t, hogy írj oda néhány értéket, és láthatóan ezután sem zártam be a tárolót. Még mindig működött, bár több mint két év telt el.
Ennek a történetnek több figyelemre méltó aspektusa is van. Először is, a Bigtable munkája olyan jelentéktelen volt a Google méretéhez képest, hogy csak két évvel később vette észre valaki a plusz tárhelyet, és csak azért, mert a bináris verziója elavult volt. Összehasonlításképpen egyszer fontolóra vettem a használatát az online játékomhoz. Abban az időben ez a szolgáltatás körülbelül 16 000 dollárba került évente. ürítse Bigtable a GCP-n. Nem azt mondom, hogy átvernek, de személyes véleményem szerint ez sok pénz egy üres kibaszott adatbázisért.
Egy másik figyelemre méltó szempont, hogy a tárolás két év után is dolgozik. WTF? Az adatközpontok jönnek és mennek; leállásokat tapasztalnak, ütemezett karbantartáson esnek át, folyamatosan változnak. Hardverfrissítés, kapcsolók cseréje, mindent folyamatosan fejlesztenek. Hogy a fenébe tudták fenntartani a programomat két évig ezekkel a változtatásokkal? Ez 2020-ban szerény eredménynek tűnhet, de 2005-2007-ben egészen lenyűgöző volt.
És a legcsodálatosabb szempont az, hogy egy külső mérnökcsapat egy másik államban keres meg engem, a Bigtable néhány apró, szinte üres példányának tulajdonosát, aki nulla forgalom az elmúlt két évben – és segítséget kínálnak a frissítéshez.
Megköszöntem, kitöröltem a tárhelyet, és az élet a megszokott módon ment tovább. De tizenhárom évvel később még mindig arra a levélre gondolok. Mert néha kapok hasonló e-maileket a Google Cloudtól. Így néznek ki:
Kedves Google Cloud-felhasználó!
Emlékeztetőül: 2020 augusztusától megszüntetjük az [az Ön által használt alapvető szolgáltatás] szolgáltatást, amely után nem tudja frissíteni a példányait. Javasoljuk, hogy frissítsen a legújabb verzióra, amely béta tesztelés alatt áll, nincs dokumentációja, nincs migrációs útvonala és kedves segítségünkkel korábban is elavult.
Elkötelezettek vagyunk amellett, hogy ez a változás minimális hatással legyen a Google Cloud platform minden felhasználójára.
Legjobb barátok örökké,
Google Cloud Platform
De szinte soha nem olvasok ilyen leveleket, mert valójában azt mondják:
Tisztelt Címzett!
Menj a pokolba. Bassza meg, baszd meg, baszd meg. Hagyj fel mindent, amit csinálsz, mert nem számít. A mi időnk számít. Időt és pénzt pazarolunk a vacak fenntartására, és belefáradtunk, így nem fogjuk tovább támogatni. Szóval hagyd fel a kibaszott terveidet, és kezdj el ásni a szar dokumentációnkat, töredékekért könyörögni a fórumokon, és mellesleg, az új szarunk teljesen más, mint a régi szar, mert elég csúnyán elrontottuk ezt a tervet, he, de ez a te dolgod. probléma, nem a miénk.
Továbbra is törekszünk arra, hogy minden fejlesztése egy éven belül használhatatlanná váljon.
Légy szíves baszd meg
Google Cloud Platform
És tény, hogy kb havonta egyszer kapok ilyen leveleket. Ez olyan gyakran és folyamatosan történik, hogy elkerülhetetlenül eltolta engem a GCP-től a felhőellenes táborba. Már nem vállalom, hogy a saját fejlesztéseiktől függjek, mert valójában a devopsoknak könnyebb nyílt forráskódú rendszert fenntartani egy puszta virtuális gépen, mint megpróbálni lépést tartani a Google-vel az „elavult” termékek bezárására vonatkozó politikájával.
Mielőtt visszatérnék a Google Cloudhoz, mert akár közel is Ha nem kritizáljuk őket, nézzük meg a cég teljesítményét néhány más területen. A Google mérnökei büszkék szoftvermérnöki tudományukra, és ez az, ami valójában problémákat okoz. A büszkeség csapda az óvatlanok számára, és sok Google-alkalmazott azt gondolta, hogy döntéseik mindig helyesek, és hogy helyesnek lenni (bizonyos homályos meghatározás szerint) fontosabb, mint az ügyfelekkel való törődés.
Mondok néhány véletlenszerű példát más, a Google-on kívüli nagy projektekből, de remélem, mindenhol ezt a mintát látod. Ez a következő: A visszamenőleges kompatibilitás évtizedekig életben és naprakészen tartja a rendszereket.
A visszamenőleges kompatibilitás az összes sikeres rendszer tervezési célja nyílt használata, azaz nyílt forráskóddal és/vagy nyílt szabványokkal valósított meg. Úgy érzem, hogy valami túl nyilvánvalót mondok, ami mindenkinek még kényelmetlenül is érzi magát, de nem. Ez politikai kérdés, ezért példákra van szükség.
Az első rendszer, amelyet választok, a legrégebbi: a GNU Emacs, amely egyfajta hibrid a Windows Jegyzettömb, az operációs rendszer kernel és a Nemzetközi Űrállomás között. Kicsit nehéz megmagyarázni, de dióhéjban, az Emacs egy platform, amelyet 1976-ban (igen, majdnem fél évszázaddal ezelőtt) hoztak létre programozásra, hogy hatékonyabb legyen, de szövegszerkesztőnek álcázva magát.
Minden nap használom az Emacs-ot. Igen, én is minden nap használom az IntelliJ-t, már önmagában is egy erőteljes szerszámozási platformmá nőtte ki magát. De az IntelliJ bővítmények írása sokkal ambiciózusabb és összetettebb feladat, mint az Emacs bővítmények írása. És ami még fontosabb, minden, ami az Emacs számára íródott, megmarad örökké.
Még mindig azt a szoftvert használom, amelyet 1995-ben írtam az Emacs számára. És biztos vagyok benne, hogy valaki Emacs-re írt modulokat használ a 80-as évek közepén, ha nem korábban. Időnként szükség lehet egy kis módosításra, de ez valóban meglehetősen ritka. Nem tudok olyanról, amit valaha is írtam az Emacs-nak (és írtam is sokat), ami újraépítést igényelt volna.
Az Emacs rendelkezik egy make-obsolete nevű funkcióval az elavult entitásokhoz. Az Emacs terminológiája az alapvető számítógépes fogalmakra (például mi az "ablak") gyakran eltér az ipari konvencióktól, mivel az Emacs már régen bevezette őket. Ez tipikus veszély azok számára, akik megelőzik korukat: minden kifejezése helytelen. De az Emacs-nek van egy fogalma az értékvesztésről, amit a szakzsargonjukban úgy hívnak avulás.
De az Emacs világában úgy tűnik, hogy más működő meghatározás létezik. Egy másik mögöttes filozófia, ha úgy tetszik.
Az Emacs világában (és sok más területen, amelyekkel alább foglalkozunk) az elavult API-státusz alapvetően azt jelenti: "Nem szabad ezt a megközelítést használnia, mert bár működik, különféle hiányosságokkal küzd, amelyek lista itt. De a nap végén ez a te döntésed."
A Google világában az elavultság azt jelenti: "Megszegjük az Ön iránti elkötelezettségünket." Ez igaz. Ez lényegében ezt jelenti. Ez azt jelenti, hogy kényszerítenek rendszeresen végezzen munkát, talán sok munkát, büntetésül azért, mert hisz bennük : Nálunk van a legjobb szoftver. A leggyorsabb! Mindent az utasítások szerint csinálsz, elindítod az alkalmazásodat vagy szolgáltatásodat, majd bam, egy-két év múlva elromlik.
Mintha egy használt autót adnának el, ami 1500 km után biztosan tönkremegy.
Ez az „elavulás” két teljesen különböző filozófiai meghatározása. A Google szagdefiníciója . Ezt nem hiszem el tulajdonképpen tervezett elavulás, ugyanolyan értelemben, mint az Apple. De a Google határozottan azt tervezi, hogy megtöri a programjait, körkörös módon. Ezt azért tudom, mert több mint 12 évig dolgoztam ott szoftvermérnökként. Homályos belső irányelveik vannak arra vonatkozóan, hogy mennyit kell követni a visszafelé kompatibilitást, de ez végső soron minden egyes csapaton vagy szolgáltatáson múlik. Nincsenek vállalati vagy mérnöki szintű ajánlások, és a legmerészebb ajánlás az elavulási ciklusok tekintetében az, hogy „próbáljon meg az ügyfeleknek 6-12 hónapot adni a frissítésre, mielőtt a teljes rendszerüket felbontják”.
A probléma sokkal nagyobb, mint gondolják, és még évekig fennáll, mert az ügyfélszolgálat nem szerepel a DNS-ükben. Erről bővebben alább.
Ezen a ponton merészen kijelentem, hogy az Emacs nagymértékben és egyenletesen sikeres többnyire mert olyan komolyan veszik a visszafelé kompatibilitást. Valójában ez a cikkünk tézise. A sikeres, hosszú életű nyílt rendszerek sikerüket a körülöttük évtizedek óta élő mikroközösségeknek köszönhetik bővítmények/bővítmények. Ez az ökoszisztéma. Már beszéltem a platformok természetéről és fontosságukról, valamint arról, hogy a Google vállalati története során soha nem értette meg, hogy mit jelent egy sikeres nyílt platform létrehozása az Androidon vagy a Chrome-on kívül.
Valójában röviden meg kell említenem az Androidot, mert valószínűleg erre gondol.
Először is, Az Android nem a Google. Szinte semmi közük nincs egymáshoz. Az Android egy olyan cég, amelyet a Google 2005 júliusában vásárolt meg, a vállalat többé-kevésbé önállóan működhetett, és az elmúlt években gyakorlatilag érintetlen maradt. Az Android egy hírhedt technológiai halom, és egy hasonlóan hírhedt szúrós szervezet. Ahogy az egyik Google-alkalmazott fogalmazott: „Nem lehet csak úgy bejelentkezni az Androidba.”
Egy korábbi cikkben arról beszéltem, hogy milyen rosszak voltak az Android korai tervezési döntései. A fenébe, amikor azt a cikket írtam, "azonnali alkalmazásoknak" nevezett szarakat dobtak ki, amelyek most (meglepetés!) , és együttérzek, ha elég hülye voltál ahhoz, hogy a Google-t hallgatd, és áthelyezd a tartalmaid ezekbe az azonnali alkalmazásokba.
De van itt egy különbség, egy jelentős különbség, ami az, hogy az androidosok igazán értik a platformok fontosságát, mindent megtesznek azért, hogy a régi Android-alkalmazások működjenek. Valójában a visszamenőleges kompatibilitás fenntartására irányuló erőfeszítéseik olyan szélsőségesek, hogy néhány évvel ezelőtt az Android részlegnél töltött rövid idő alatt még én is azon kaptam magam, hogy megpróbálom meggyőzni őket arról, hogy mondják le a legrégebbi eszközök és API-k támogatását (tévedtem , mint sok más dologban a múltban és a jelenben. Elnézést Android srácok! Most, hogy Indonéziában jártam, megértem, miért van szükségünk rájuk).
Az Android-emberek szinte elképzelhetetlen végletekig tolják a visszafelé kompatibilitást, hatalmas mennyiségű örökölt technikai adósságot halmozva fel rendszereikben és eszközláncaikban. Ó, istenem, látnia kell néhány őrült dolgot, amit a build rendszerükben kell csinálniuk, mindezt a kompatibilitás nevében.
Ezért odaítélem az Androidnak a hőn áhított „You're Not Google” díjat. Nagyon nem a tartós platformok létrehozását nem tudó Google akarnak lenni, hanem az Android tudja, hogyan kell csinálni. A Google tehát egy tekintetben nagyon okos: lehetővé teszi az embereknek, hogy a maguk módján intézzék a dolgokat Androidon.
Az azonnali alkalmazások Androidra azonban elég hülye ötlet volt. És tudod miért? Mert követelték írja át és tervezze újra az alkalmazást! Mintha az emberek egyszerűen átírnának kétmillió kérelmet. Azt hiszem, az Instant Apps valami Google-alkalmazás volt.
De van különbség. A visszamenőleges kompatibilitás magas költségekkel jár. Az Android maga viseli ezeknek a költségeknek a terhét, míg a Google ragaszkodik a terhek viseléséhez te vagy, fizető ügyfél.
Az API-kban láthatja az Android elkötelezettségét a visszafelé kompatibilitás iránt. Ha négy vagy öt különböző alrendszerrel rendelkezik, amelyek szó szerint ugyanazt a dolgot csinálják, az biztos jele annak, hogy a lényeg a visszafelé kompatibilitás iránti elkötelezettség. Ami a platformok világában az ügyfelek és a piac iránti elkötelezettség szinonimája.
A Google fő problémája itt az, hogy büszke a mérnöki higiéniájára. Nem szeretik, ha ugyanazt a dolgot sokféleképpen lehet megtenni, a régi, kevésbé kívánatos módok mellett az új, felkapottabb módszerek. Növeli a tanulási görbét azoknak, akik újak a rendszerben, növeli az örökölt API-k karbantartásának terhét, lelassítja az új funkciók sebességét, és a fő bűn az, hogy nem szép. Google – mint Lady Ascot Tim Burton Alice in Wonderland című filmjéből:
Lady Ascot:
- Alice, tudod, mitől félek a legjobban?
- Az arisztokrácia hanyatlása?
- Féltem, hogy lesz csúnya unokák.
A szép és praktikus közötti kompromisszum megértéséhez vessünk egy pillantást a harmadik sikeres platformra (az Emacs és az Android után), és nézzük meg, hogyan működik: magát a Java-t.
A Java sok elavult API-val rendelkezik. Az elavulás nagyon népszerű a Java programozók körében, még a legtöbb programozási nyelvnél is népszerűbb. Maga a Java, az alapnyelv és a könyvtárak folyamatosan elavulják az API-kat.
Hogy csak egyet vegyek a több ezer példa közül, elavultnak tekinthető. A Java 1.2 1998 decemberi megjelenése óta elavulttá vált. 22 év telt el azóta, hogy ez megszűnt.
De a tényleges kódom a gyártásban még mindig szálakat öl minden nap. Tényleg azt hiszed, hogy ez jó? Teljesen! Úgy értem persze, ha ma átírnám a kódot, akkor másképp valósítanám meg. De a játékom kódja, amely több százezer embert tett boldoggá az elmúlt két évtizedben, olyan funkcióval van megírva, amely lezárja a túl sokáig lógó szálakat, és én soha nem kellett változtatni rajta. Mindenkinél jobban ismerem a rendszeremet, szó szerint 25 éves tapasztalatom van vele a termelésben, és biztosan állíthatom: az én esetemben ezeknek a konkrét munkásszálaknak a lezárása teljes. ártalmatlan. Nem éri meg az időt és az erőfeszítést ennek a kódnak az átírása, és köszönöm Larry Ellisonnak (valószínűleg), hogy az Oracle nem kényszerített az újraírásra.
Az Oracle valószínűleg megérti a platformokat is. Ki tudja.
Bizonyítékok találhatók az alapvető Java API-kban, amelyek tele vannak az elavulás hullámaival, mint a gleccser vonalai egy kanyonban. A Java Swing könyvtárban könnyedén találhat öt vagy hat különböző billentyűzet-navigációs kezelőt (KeyboardFocusManager). Valójában nehéz olyan Java API-t találni, amely nem elavult. De még működnek! Úgy gondolom, hogy a Java csapat csak akkor távolít el igazán egy API-t, ha az interfész szembetűnő biztonsági problémát jelent.
Itt van a helyzet, emberek: Mi, szoftverfejlesztők mindannyian nagyon elfoglaltak vagyunk, és a szoftverek minden területén versengő alternatívákkal kell szembenéznünk. Az X nyelv programozói bármikor fontolgatják az Y nyelv lehetséges helyettesítését. Ó, nem hiszel nekem? Swiftnek akarod hívni? Például mindenki a Swiftre vándorol, és senki sem hagyja el, igaz? Hú, milyen keveset tudsz. A vállalatok számolják a kettős mobilfejlesztői csapatok (iOS és Android) költségeit – és kezdik rájönni, hogy azok a többplatformos fejlesztőrendszerek vicces nevekkel, mint a Flutter és a React Native, valóban működnek, és csökkenteni lehet velük a mobil csapatok kétszeresét, vagy éppen ellenkezőleg, kétszer termelékenyebbé teszik őket. Valódi pénz forog kockán. Igen, vannak kompromisszumok, de másrészt pénz.
Tegyük fel hipotetikusan, hogy az Apple ostoba módon Guido van Rossum jelzését vette át, és kijelentette, hogy a Swift 6.0 visszafelé nem kompatibilis a Swift 5.0-val, ugyanúgy, mint a Python 3 nem kompatibilis a Python 2-vel.
Valószínűleg tíz évvel ezelőtt meséltem el ezt a történetet, de körülbelül tizenöt évvel ezelőtt elmentem az O'Reilly's Foo Camp-be Guidóval, egy sátorban ültem Paul Grahammel és egy csomó nagy lövéssel. Ültünk a rekkenő hőségben, és vártuk, hogy Larry Page kirepüljön a személyes helikopterével, miközben Guido a „Python 3000”-ről drukkolt, amelyet arról nevezett el, hogy hány év kell ahhoz, hogy mindenki odavándoroljon. Folyamatosan kérdeztük tőle, hogy miért sérti meg a kompatibilitást, és azt válaszolta: „Unicode”. És megkérdeztük, ha át kellene írnunk a kódunkat, milyen előnyöket látnánk még? Ő pedig azt válaszolta: "Júúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúúú."
Ha telepíti a Google Cloud Platform SDK-t („gcloud”), a következő értesítést fogja kapni:
Tisztelt Címzett!
Szeretnénk emlékeztetni, hogy a Python 2 támogatása megszűnt, szóval a francba
… stb. Az élet körforgása.
De a lényeg az, hogy minden fejlesztőnek van választása. És ha elég gyakran kényszeríted őket arra, hogy újraírják a kódot, elgondolkodhatnak más lehetőségek. Nem a te túszaid, bármennyire is szeretnéd, hogy legyenek. Ők a vendégeid. A Python még mindig nagyon népszerű programozási nyelv, de a fenébe is, a Python 3(000) akkora zűrzavart hozott létre önmagában, a közösségeiben és a közösségeinek felhasználói körében, hogy tizenöt éve nem tisztázták a következményeket.
Hány Python-programot írtak át Go-ban (vagy Ruby-ban vagy más alternatívában) ennek a visszafelé inkompatibilitásnak köszönhetően? Mennyi új szoftvert írtak a Pythonon kívül másba, bár az lehetne Python nyelven írva, ha Guido nem égette volna fel az egész falut? Nehéz megmondani, de a Python egyértelműen szenvedett. Óriási a káosz, és mindenki veszít.
Tehát tegyük fel, hogy az Apple átveszi Guidó jelzését, és megszakítja a kompatibilitást. Szerinted mi lesz ezután? Nos, lehet, hogy a fejlesztők 80-90%-a átírja a szoftverét, ha lehetséges. Más szóval, a felhasználói bázis 10-20%-a automatikusan valamilyen versengő nyelvre, például a Flutterre megy.
Csináld ezt többször, és elveszíted felhasználói bázisod felét. Ahogy a sportban, úgy a programozás világában is számít az aktuális forma. всё. Aki öt éven belül elveszíti felhasználóinak felét, azt Big Fat Losernek tekintik. trendinek kell lenned a platformok világában. De ez az, ahol a régebbi verziók támogatásának hiánya idővel tönkreteszi. Mert minden alkalommal, amikor megszabadulsz néhány fejlesztőtől, (a) örökre elveszíted őket, mert haragszanak rád, amiért megszegted a szerződést, és (b) odaadod őket a versenytársaidnak.
Ironikus módon abban is segítettem a Google-t, hogy a visszafelé kompatibilitást figyelmen kívül hagyó primadonnává váljon, amikor létrehoztam a Grokot, egy forráskódelemző és -megértési rendszert, amely megkönnyíti a kód automatizálását és műszerezését – hasonlóan egy IDE-hez, de itt a felhőszolgáltatás tárolja. a Google forráskód milliárdnyi sorának egy nagy adattárházban való megjelenítése.
A Grok hatékony keretrendszert biztosított a Google dolgozóinak az automatizált átalakítások végrehajtásához a teljes kódbázisukon (szó szerint a Google-on keresztül). A rendszer nem csak az upstream függőségeit (amelyektől függ), hanem azt is kiszámítja ereszkedő (ami rajtad múlik), így amikor API-kat váltasz, mindenkit ismersz, akit megszegsz! Így a változtatások során ellenőrizheti, hogy az API minden fogyasztója frissített-e az új verzióra, és a valóságban gyakran az általuk írt Rosie eszközzel teljesen automatizálhatja a folyamatot.
Ez lehetővé teszi, hogy a Google kódbázisa belülről szinte természetfölötti tiszta legyen, mivel ezek a robotszolgák sürgölődnek a házban, és automatikusan mindent kitakarítanak, ha a SomeDespicablyLongFunctionName-et átnevezték SomeDespicablyLongMethodName-re, mert valaki úgy döntött, hogy egy csúnya unoka, és el kell altatni.
És őszintén szólva elég jól működik a Google számára... belsőleg. Úgy értem, igen, a Google Go közössége jót nevet a Google Java közösségén a folyamatos újrafeldolgozási szokásuk miatt. Ha N-szer újraindítasz valamit, az azt jelenti, hogy nem csak N-1-szer csavartad el, de egy idő után eléggé világossá válik, hogy valószínűleg az N-edik próbálkozásnál is elcseszted. De összességében ők maradnak ezen a felhajtáson túl, és „tisztán” tartják a kódot.
A probléma akkor kezdődik, amikor megpróbálják ezt a hozzáállást rákényszeríteni a felhőkliensekre és más API-k felhasználóira.
Bemutattam egy kicsit az Emacs-t, az Androidot és a Java-t; lássuk a legújabb sikeres, hosszú életű platformot: magát a webet. El tudja képzelni, hány iteráción ment keresztül a HTTP 1995 óta, amikor villogó címkéket használtunk? és "Felépítés alatt" ikonok a weboldalakon.
De attól még működik! És ezek az oldalak még mindig működnek! Igen, srácok, a böngészők világbajnokok a visszafelé kompatibilitás terén. A Chrome egy másik példa arra a ritka Google-platformra, amelyen jól fel van csavarozva a feje, és ahogy azt sejteni lehetett, a Chrome gyakorlatilag a Google többi részétől elkülönülő homokozó cégként működik.
Szeretnék köszönetet mondani operációs rendszerfejlesztő barátainknak is: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD stb., hogy ilyen nagyszerű munkát végeztek a visszafelé kompatibilitás terén sikeres platformjaikon (az Apple a legjobb esetben is C-t kap hátulütője, hogy minden jó ok nélkül állandóan eltörnek, de valahogy minden kiadásnál megkerüli a közösség, és az OS X konténerek még mindig nem avultak el teljesen... még).
De várj, mondod. Nem hasonlítjuk össze az almát a narancsokkal – önálló szoftverrendszereket egyetlen gépen, mint például az Emacs/JDK/Android/Chrome, szemben a többkiszolgálós rendszerekkel és API-kkal, mint a felhőszolgáltatások?
Nos, tegnap csiripeltem erről, de Larry Wall (a Perl programozási nyelv megalkotója - kb. per.) stílusában a "szívás/szabályok" elven megnéztem a szót. elavult a Google és az Amazon fejlesztői oldalain. És bár az AWS-nek van száz A Google fejlesztői dokumentációja körülbelül hétszer gyakrabban említi az elavulást, mint a GCP.
Ha valaki a Google-nál olvassa ezt, valószínűleg készen áll Donald Trump-stílusú grafikonok előhúzására, amelyek azt mutatják, hogy valójában mindent jól csinálnak, és nem szabad tisztességtelen összehasonlításokat végeznem, például "az elavult szó említésének száma versus szolgáltatások száma" "
De ennyi év után is a Google Cloud a 3. számú szolgáltatás (soha nem írtam cikket a sikertelen próbálkozásról, hogy a 2. helyre kerüljek), de ha hinni lehet a bennfenteseknek, vannak aggályok, amelyek hamarosan visszaeshetnek. 4. sz.
Nincsenek nyomós érveim a tézisem "bizonyítására". Csak azok a színes példáim vannak, amelyeket 30 év alatt gyűjtöttem össze fejlesztőként. Már említettem e probléma mélyen filozófiai természetét; bizonyos szempontból átpolitizálódik a fejlesztői közösségekben. Vannak, akik ezt hiszik alkotók a platformoknak törődniük kell a kompatibilitással, míg mások szerint ez aggodalomra ad okot felhasználók (maguk a fejlesztők). Kettőből egy. Valóban, nem politikai kérdés, amikor eldöntjük, ki viselje a közös problémák költségeit?
Szóval ez a politika. És valószínűleg dühös válaszok lesznek a beszédemre.
Mint használó A Google Cloud Platform, és két éve AWS-felhasználóként (amikor a Grabnál dolgoztam) elmondhatom, hogy óriási különbség van az Amazon és a Google filozófiája között, ami a prioritásokat illeti. Nem fejlesztek aktívan AWS-en, ezért nem tudom nagyon jól, milyen gyakran távolítják el a régi API-kat. De van egy gyanú, hogy ez közel sem fordul elő olyan gyakran, mint a Google-nál. És őszintén hiszem, hogy a GCP-vel kapcsolatos állandó viták és frusztráció forrása az egyik legnagyobb tényező a platform fejlesztésében.
Tudom, hogy nem említettem konkrét példákat a már nem támogatott GCP-rendszerekre. Elmondhatom, hogy szinte mindent, amit használtam, a hálózatoktól (a legrégebbiektől a VPC-ig) a tárolókig (Cloud SQL v1-v2), a Firebase-ig (most Firestore teljesen más API-val), az App Engine-ig (ne is kezdjük) , felhő végpontok Cloud Endpoint és legfeljebb... Nem tudom - abszolút mindezt maximum 2-3 év után kényszerítették átírni a kódot, és soha nem automatizálták helyetted a migrációt, sőt gyakran . Mintha ennek így kellett volna lennie.
És minden alkalommal, amikor megnézem az AWS-t, felteszem magamnak a kérdést, hogy mi a fenéért vagyok még mindig GCP-n. Nyilván nincs szükségük ügyfelekre. Szükségük van vevők. Érted a különbséget? Hadd magyarázzam.
A Google Cloud rendelkezik , ahol az emberek felajánlják szoftveres megoldásaikat, és az üres étterem effektus elkerülése érdekében néhány javaslattal kellett feltölteni, ezért szerződést kötöttek a Bitnami nevű céggel egy csomó olyan megoldás létrehozására, amelyeket „egy kattintással” telepítenek. Magam írom, hogy „megoldások”, mert ezek rohadtul nem oldanak meg. Egyszerűen jelölőnégyzetként, marketingkitöltőként léteznek, és a Google soha nem törődött azzal, hogy valamelyik eszköz valóban működik-e. Ismerek termékmenedzsereket, akik a vezetőülésben ültek, és biztosíthatom, hogy ezek az emberek nem törődnek vele.
Vegyünk például egy állítólagos „egykattintásos” telepítési megoldást. . Halálra betegedtem a Google Cloud SQL-szenvedélyektől, ezért elkezdtem alternatívaként saját Percona-fürt felépítésén gondolkodni. És ezúttal úgy tűnt, hogy a Google jó munkát végzett, egy gombnyomással időt és fáradságot takarítanak meg!
Hát remek, menjünk. Kövessük a linket, és kattintsunk erre a gombra. Válassza az „Igen” lehetőséget az összes alapértelmezett beállítás elfogadásához, és a fürt telepítéséhez a Google felhőprojektjében. Haha, nem megy. Ezek a baromságok egyike sem működik. Az eszközt soha nem tesztelték, és az első perctől kezdve rohadni kezdett, és nem lepődnék meg, ha a "megoldások" több mint fele egykattintásos telepítés lenne (most már értjük, miért az idézetek) általában nem működik. Ez egy teljesen reménytelen sötétség, ahová jobb nem belépni.
De a Google-nek igaza van sürgeti hogy használd őket. Azt akarják, hogy tedd vásárolt. Számukra ez egy tranzakció. Nem akarnak semmit támogatás. Nem része a Google DNS-ének. Igen, a mérnökök támogatják egymást, amint azt a Bigtable-tal folytatott történetem is bizonyítja. A hétköznapi embereknek szánt termékekben és szolgáltatásokban viszont igen mindig könyörtelenek voltak benne , amely még akkor sem éri el a jövedelmezőségi lécet, ha több millió felhasználója van.
Ez pedig igazi kihívást jelent a GCP számára, mert ez a DNS az összes felhőajánlat mögött. Nem próbálnak támogatni semmit; Köztudott, hogy megtagadják harmadik féltől származó szoftverek fogadását (felügyelt szolgáltatásként). amíg, amíg az AWS nem teszi ugyanezt, és sikeres üzletet nem épít köré, és amikor az ügyfelek szó szerint ugyanazt követelik. Azonban némi erőfeszítésre van szükség ahhoz, hogy a Google támogasson valamit.
A támogatási kultúra hiánya, a „törjük, hogy szebb legyen” mentalitással párosulva elidegeníti a fejlesztőket.
És ez nem jó dolog, ha hosszú életű platformot akarunk építeni.
Google, ébredj, a fenébe. Most 2020 van. Még mindig veszít. Ideje alaposan tükörbe nézni, és megválaszolni, hogy valóban a felhőszakmában akar-e maradni.
Ha maradni akar, akkor ne törj fel mindent. Srácok, gazdagok vagytok. Mi, fejlesztők, nem. Tehát amikor arról van szó, hogy ki viseli a kompatibilitás terhét, akkor ezt magadra kell vállalnod. Nem nekünk.
Mert van még legalább három igazán jó felhő. Integetnek.
És most folytatom az összes meghibásodott rendszerem javítását. Eh.
A következő alkalomig!
PS Frissítés a cikk néhány vitájának elolvasása után (a viták nagyszerűek, btw). A Firebase támogatása nem szűnt meg, és nincsenek olyan tervek, amelyekről tudomásom szerint. Van azonban egy csúnya adatfolyam-hibájuk, ami miatt a Java kliens leáll az App Engine-ben. Az egyik mérnökük segített megoldani ezt a problémát, amikor a Google-nál dolgoztam, de valójában soha nem javították ki a hibát, így van egy vacak megoldásom, hogy minden nap újra kell indítanom a GAE alkalmazást. És ez így van négy éve! Most Firestore-juk van. Nagyon sok munkába fog kerülni az átállás, mivel ez egy teljesen más rendszer, és a Firebase hibája soha nem lesz javítva. Milyen következtetést lehet levonni? Kaphatsz segítséget ha egy cégben dolgozik. Valószínűleg én vagyok az egyetlen, aki a Firebase-t használja a GAE-n, mert 100-nál kevesebb kulcsot naplózok egy 100%-ban natív alkalmazásban, és néhány naponta leáll egy ismert hiba miatt. Mit mondhatnék mást, mint hogy saját felelősségére használja. Váltok Redisre.
Azt is láttam, hogy néhány tapasztaltabb AWS-felhasználó azt mondta, hogy az AWS rendszerint soha nem hagyja abba a szolgáltatások támogatását, és a SimpleDB jó példa erre. Jogosnak tűnnek azon feltételezéseim, hogy az AWS-nek nem ugyanaz a vége a támogatási betegség, mint a Google-nak.
Ezenkívül észrevettem, hogy 20 nappal ezelőtt a Google App Engine csapata megszakította egy kritikus Go-könyvtár tárhelyszolgáltatását, és leállította a Go egyik fő fejlesztőjének GAE-alkalmazását. Tényleg hülyeség volt.
Végül, hallottam, hogy a Google-alkalmazottak már megvitatták ezt a kérdést, és általában egyetértenek velem (szeretlek, srácok!). De úgy tűnik, hogy a probléma megoldhatatlan, mert a Google kultúrájában soha nem volt megfelelő ösztönző struktúra. Úgy gondoltam, jó lenne egy kis időt szánni arra, hogy megvitassuk azt az elképesztő élményt, amelyet az AWS mérnökeivel való együttműködés során szereztem, miközben a Grabnál dolgoztam. Egyszer a jövőben, remélem!
És igen, 2005-ben a 43-as épület óriási büféjében különféle cápahúsok voltak, és a kedvencem a pörölycápahús volt. 2006-ra azonban Larry és Szergej megszabadult minden egészségtelen falattól. Tehát a 2007-es Bigtable sztori alatt tényleg nem voltak cápák, és én megtévesztelek benneteket.
Amikor négy évvel ezelőtt a cloud Bigtable-t néztem (adni vagy venni), ez volt az, ahol a költségek voltak. Úgy tűnik, most egy kicsit visszaesett, de ez még mindig rettenetesen sok egy üres adattárház számára, főleg mivel az első történetem megmutatja, mennyire jelentéktelen egy üres nagy táblázat az ő méretükhöz képest.
Elnézést, hogy megsértettem az Apple közösségét, és nem mondok semmi szépet a Microsoftról stb. Rendben van, nagyon nagyra értékelem a cikk által kiváltott vitákat! De néha egy kicsit hullámokat kell keltenie ahhoz, hogy vitát indítson, tudod?
Köszönöm, hogy elolvasta.
2. frissítés, 19.08.2020. Csík !
Frissítés 3, 31.08.2020. Megkeresett a Cloud Marketplace egyik Google-mérnöke, akiről kiderült, hogy régi barátom. Azt akarta kideríteni, hogy a C2D miért nem működik, és végül rájöttünk, hogy ez azért van, mert évekkel ezelőtt építettem a hálózatomat, és a C2D nem működött a régi hálózatokon, mert az alhálózati paraméter hiányzott a sablonokból. Szerintem az a legjobb, ha a potenciális GCP-felhasználók megbizonyosodnak arról, hogy elegendő mérnököt ismernek a Google-nál...
Forrás: will.com