A francba, Google, nem akartam újra blogot írni. Olyan sok dolgom van. A blogolás időt, energiát és kreativitást igényel, amit hasznosan tudnék felhasználni: a könyveimhez, , a játékomhoz és így tovább. De elég mérges lettél, úgyhogy ezt le kell írnom.
Tehát vágjunk bele.
Kezdem egy rövid, de tanulságos történettel azokról az időkről, amikor csak elkezdtem dolgozni a Google-nél. Tudom, hogy mostanában sok rosszat mondtam a Google-ről, de bosszant, amikor a szülővállalatom rendszeresen hoz inkompetens üzleti döntéseket. Ugyanakkor el kell ismerni: a Google belső infrastruktúrája valóban különleges, nyugodtan állíthatjuk, hogy ma nincs jobb. A Google alapítói sokkal jobb mérnökök voltak, mint amilyen valaha leszek, és ez a történet csak megerősíti ezt a tényt.
Először egy kis háttérinformáció: a Google-nek van egy adatmentési technológiája, amit . Ez egy csodálatos technikai teljesítmény volt, az egyik első (ha nem az első) "végtelenül skálázható" kulcs-érték tároló: lényegében a NoSQL kezdete. Ma a Bigtable még mindig jól van a viszonylag zsúfolt kulcs-érték tárolók terében, de abban az időben (2005) hihetetlenül menő volt.
A Bigtable egyik vicces részlete az, hogy voltak belső vezérlőpanelek (a megvalósítás részeként) úgynevezett tablet-szerverekkel, nagy indexekkel, és egy ponton ezek lett a szűk keresztmetszet a rendszer skálázása során. A Bigtable mérnökei fejüket törve próbálták megvalósítani a skálázhatóságot, és hirtelen rájöttek, hogy a tablet-szervereket más Bigtable tárolókkal helyettesíthetik. Tehát a Bigtable a Bigtable megvalósításának része. Ezek a tárolók minden szinten ott vannak.
Egy érdekes részlet, hogy a Bigtable egy időre népszerűvé és mindenütt jelenlévők lettek a Google-nél, és minden csapatnak megvolt a maga tárolója. Ezért egy pénteki megbeszélés alkalmával Larry Page hanyagul megkérdezte: „Miért van nekünk több Bigtable? Miért nem elég egy?” Elméleti szempontból egy tárolónak elegendőnek kellett volna lennie a Google összes tárolási igényéhez. Természetesen sosem váltottak át egyetlen tárolóra a fejlesztés gyakorlati okai miatt (például a lehetséges hibák következményei), de az elmélet érdekes volt. Egy tároló az egész Univerzumnak;mellesleg, tud valaki arról, hogy az Amazon ezt tette a Sable-jével?)
Így vagy úgy, ez az én történetem.
Akkoriban két éve dolgoztam a Google-nél, és egyszer egy levelet kaptam a Bigtable mérnöki csapatától, amely körülbelül így hangzott:
Kedves Steve,
Üdvözlet a Bigtable csapatától. Szeretnénk értesíteni róla, hogy a [data center neve] adatközpontban egy nagyon régi Bigtable bináris fájlt használsz. Ez a verzió már nem támogatott, és szeretnénk segíteni neked az utolsó verzióra való áttérésben.
Kérlek, jelezd, ha tudsz időt tervezni közös munkára ezzel a kérdéssel kapcsolatban.
Minden jót,
A Bigtable csapata
A Google-nél sok e-mailt kapsz, ezért első pillantásra körülbelül így olvastam:
Kedves címzett,
Üdvözlet egy csapatból. Szeretnénk értesíteni, hogy blabla-blabla-blabla-blabla. Blabla-blabla-blabla-blabla-blabla, és blabla-blabla azonnal.
Kérlek, tudass velünk, ha tudsz időt szánni a blabla-blablára.
Minden jót,
Valamilyen csapat
Majdnem azonnal töröltem, de a tudatom határán éreztem egy nyomasztó, feszítő érzést, hogy ez nem egészen tűnik formális levélnek, bár nyilvánvaló,, hogy a címzettet eltévesztették, mert nem használtam Bigtable-t.
De ez furcsa volt.
A nap hátralévő részében felváltva gondoltam a munkámra és arra, hogy melyik cápa húsát próbáljam ki a mikro konyhában, amik közül legalább három elég közel volt ahhoz, hogy ügyes dobásokkal elérjem a helyemről, de a levél gondolata egyre nőtt feszültséggel kísérve nem hagyott el.
Nyíltan említették a nevemet. Az üzenetet az én e-mail címemre küldték, nem pedig másé, és nem is cc: vagy bcc:. A hang nagyon személyes és világos. Talán valami hiba történt?
Végre a kíváncsiságom felülkerekedett, és elmentem megnézni a Borg konzolt az adatközpontban, amelyet említettek.
És persze, nekem volt felügyeletem alatt a BigTable tároló. Mi? Megnéztem a tartalmát, és – jó ég! Az a Codelab inkubátorából származott, ahol az első munkahétem alatt voltam a Google-nél 2005 júniusában. A Codelab megkövetelte, hogy elindítsuk a Bigtable-t, hogy néhány értéket feljegyezzünk oda, és úgy tűnik, hogy egyszerűen nem zártam le a tárolót azóta. Még mindig működött, pedig több mint két év eltelt.
Ennek a történetnek van néhány figyelemre méltó aspektusa. Először is, a Bigtable működése olyan jelentéktelen volt a Google méretében, hogy csak két év elteltével vette észre valaki a felesleges tárolót, ráadásul csak azért, mert az bináris verzió elavult. Összehasonlításképpen, egyszer azon gondolkodtam, hogy használom a az online játékomhoz. Abban az időben ez a szolgáltatás körülbelül évi 16 000 dollárba került a üres Bigtable-ért a GCP-n. Nem azt mondom, hogy átvernek, de a személyes véleményem szerint ez sok pénz egy üres, fránya adatbázisért.
Egy másik figyelemre méltó aspektus az, hogy a tároló tovább működött két évig. WTF? Az adatközpontok jönnek és mennek; zavarokkal küzdenek, tervezett karbantartással foglalkoznak, folyamatosan változnak. A hardver frissül, a kapcsolók helyet cserélnek, minden állandóan fejlődik. Hogyan a frászba sikerült nekik két évig működtetni a programomat a sok változás mellett? Ez 2020-ban talán szerény teljesítménynek tűnhet, de 2005-2007 között igazán lenyűgöző volt.
És a legcsodálatosabb aspektus az, hogy egy külső mérnöki csapat egy másik államból keres meg engem, egy olyan apró, gyakorlatilag üres Bigtable példány tulajdonosát, amelynek nulla forgalma volt az utolsó két évben – és segítséget ajánlanak a frissítéshez.
Megköszöntem nekik, töröltem a tárolót, és az élet ment tovább. De tizenhárom évvel később még mindig gondolok erre a levélre. Mert néha hasonló leveleket kapok a Google Cloud-tól. Így néznek ki:
Tisztelt Google Cloud felhasználó,
Emlékeztetjük, hogy 2020 augusztusától megszüntetjük a [fontos szolgáltatás, amelyet használ] karbantartását, és ezután nem tudja frissíteni az instanciáit. Javasoljuk, hogy váltson a legújabb verzióra, amely bétatesztelés alatt áll, nincs hozzá dokumentáció, nem biztosít migrációs utat, és előre elavult a mi kedves segítségünkkel.
Célunk, hogy ez a változás a lehető legkevésbé érintse a Google Cloud platform összes felhasználóját.
Örök barátok,
Google Cloud platform
De szinte sosem olvasok ilyen leveleket, mert valójában azt mondják, hogy:
Kedves címzett,
Menj a fenébe. Menj a fenébe, menj a fenébe, menj a fenébe. Hagyd abba, amit csinálsz, mert ez nem fontos. Ami fontos, az az időnk. Időt és pénzt költünk arra, hogy fenntartsuk a szemétdombunkat, és elege van ebből, így többé nem fogjuk támogatni. Szóval dobd el a rohadék terveidet, és kezdj el kotorászni a szar dokumentációnkban, könyörögve a fórumokon a maradékért, és mellesleg az új szarunk teljesen más a régitől, mert eléggé elcseszettük ezt a dizájnt, hehe, de ez a te problémád, nem a miénk.
Még mindig azon vagyunk, hogy minden fejlesztésed egy éven belül használhatatlanná váljon.
Kérlek, menj a fenébe,
Google Cloud platform
A lényeg az, hogy havonta körülbelül egyszer kapok ilyen leveleket. Olyan gyakran és tartósan történik, hogy elkerülhetetlenül elriasztottak a GCP-től a felhők ellenfeleinek táborába. Többé nem akarok függni a saját fejlesztéseiktől, mert a DevOps-nak valójában könnyebb egy nyílt forráskódú rendszert fenntartani egy üres virtuális gépen, mint próbálni lépést tartani a Google-lal a 'elavult' termékek bezárási politikájával.
Mielőtt visszatérnék a Google Cloudhoz, mert én még közel sem nem fejezte be a kritikáját, nézzük meg a cég munkáját más területeken is. A Google mérnökei büszkék a szoftverfejlesztési fegyelmükre, de ez valójában problémákat okoz. A büszkeség csapda a figyelmetleneknek, amely miatt sok Google-alkalmazott azt gondolja, hogy döntéseik mindig helyesek, és hogy a helyesség (valamilyen meghatározatlan, homályos értelemben) fontosabb, mint az ügyfelek iránti gondoskodás.
Felhozok néhány véletlenszerű példát más nagy projektekből a Google-on kívül, de remélem, hogy mindenütt észre fogja venni ezt a mintát. A lényeg a következő: a hátrafelé kompatibilitás biztosítja a rendszerek életképességét és relevanciáját évtizedeken át.
A hátrafelé kompatibilitás az összes sikeres rendszer tervezési célja, amelyet a következők beveendőkkel terveztek: nyílt használat, azaz nyílt forráskódú és/vagy nyílt szabványok alapján megvalósították. Úgy érzem, mintha valami túl nyilvánvalót mondanék, ami másokat kényelmetlenül érinthet, de nem. Ez politikai kérdés, ezért példákra van szükség.
Az első rendszer, amit választok, a legöregebb: a GNU Emacs, egyfajta hibrid a Windows Jegyzettömb, az operációs rendszer magja és a Nemzetközi Űrállomás között. Kissé nehéz elmagyarázni, de röviden az Emacs egy platform, amelyet 1976-ban (igen, majdnem ötven éve) hoztak létre a programozás javítására, hogy növeljék a termelékenységet, de szövegszerkesztőként álcázva.
Én minden egyes nap használom az Emacst. Igen, naponta használom az IntelliJ-t is, amely már önmagában egy hatékony eszközplatformmá vált. De bővítmények írása az IntelliJ-hez sokkal ambiciózusabb és összetettebb feladat, mint az Emacs-hoz. És ami még fontosabb, minden, az Emacs-hoz írt dolog megmarad örökre.
Még mindig használom azt a szoftvert, amelyet 1995-ben írtam az Emacs számára. És biztos vagyok benne, hogy valaki az Emacs-hoz 80-as évek közepén írt modulokat is használ, ha nem még korábban. Időnként lehet, hogy apró finomhangolást igényelnek, de ez igazán elég ritka. Nem tudok semmit abból, amit valaha is írtam az Emacs-hoz (pedig sok mindent írtam), amelynek az architektúráját újra kellene építeni.
Az Emacs-ban létezik egy make-obsolete nevű funkció az elavult entitások számára. Az Emacs terminológiája az alapvető számítástechnikai fogalmakra (például mi az a „ablak”) gyakran eltér az ipari konvencióktól, mivel az Emacs nagyon régen vezette be ezeket. Ez tipikus veszély azok számára, akik megelőzték a korukat: minden kifejezésük hibás. De az Emacs-ban valóban létezik a elavultság fogalma, amelyet az ő zsargonjukban hívnak elavultság.
De az Emacs világában úgy tűnik, van egy másféle munkadefiníció. Egy másik alapvető filozófia, ha úgy tetszik.
Az Emacs világában (és sok más területen, amelyeket alább megvizsgálunk) az elavult API-k státusza alapvetően azt jelenti: „Valójában nem szabad ezt a megközelítést használnod, mert bár működik, számos hátránya van, amelyet itt felsorolunk. De végső soron a te választásod.”
A Google világában az elavult termék státusza azt jelenti: „Megszegjük veled szemben vállalt kötelezettségeinket.” Ez valóban így van. Ez lényegében azt jelenti, hogy kényszerítenek téged rendszeresen elvégezni némi munkát, lehet, hogy sok munkát, büntetésképpen azért, mert hittél a : nálunk van a legjobb szoftver. A leggyorsabb! Mindent a utasítások szerint csinálsz, elindítod az alkalmazásodat vagy szolgáltatásodat, majd puff, egy év vagy két év múlva elromlik.
Ez olyan, mintha használt autót árulnál, ami pontosan 1500 km után fog elromlani.
Ez két teljesen különböző filozófiai definíció az „elavultságra”. A Google definíciója a . Nem hiszem, hogy ez valóban tervezett elavultág ugyanúgy, mint az Apple-nél. De a Google határozottan tervezi, hogy eltöri a programjaidat, közvetett módon. Tudom ezt, mert több mint 12 évig dolgoztam ott szoftverfejlesztőként. Vannak homályos belső irányelveik, hogy meddig érdemes betartani a visszafelé kompatibilitást, de végső soron ez minden egyes csapat vagy szolgáltatás döntése. Nincsenek vállalati vagy mérnöki szintű irányelvek, a legbátorabb ajánlás a ciklusok elavulásával kapcsolatban pedig az, hogy „próbálj meg 6-12 hónapot adni az ügyfeleknek a frissítésre, mielőtt az egész rendszerüket eltöri.”
A probléma sokkal súlyosabb, mint ahogy ők gondolják, és még évekig fennmarad, mert az ügyfélkapcsolat nem része a DNS-üknek. A részletek lentebb találhatók.
Jelenleg merész állítást fogok tenni, miszerint az Emacs nagymértékben sikeres, és akár többnyire azért, mert komolyan veszik a visszafelé való kompatibilitást. Valójában ez a cikkünk tézise. A sikeres, hosszú életű nyílt rendszerek a körülöttük évtizedek óta működő mikroközösségeknek köszönhetik a sikerüket, amelyek kiterjesztések/pluginok. Ez az ökoszisztéma. Már írtam a platformok lényegéről és arról, hogy mennyire fontosak, és arról, hogy a Google soha az egész vállalati története alatt nem értette, mi szükséges egy sikeres nyílt platform létrehozásához, kivéve talán az Androidot vagy a Chrome-ot.
Valójában röviden meg kell említenem az Androidot, mert valószínűleg rá gondolt.
Először is, az Android nem a Google. Nem sok közük van egymáshoz. Az Android egy olyan cég, amelyet a Google 2005 júliusában vásárolt meg, és ennek a cégnek megengedték, hogy többé-kevésbé autonóm módon működjön, és valójában az elmúlt években nagyrészt érintetlen maradt. Az Android egy hírhedt technikai stack és ugyanígy hírhedt konfliktusos szervezet. Ahogy az egyik Google-alkalmazott mondta: "nem lehet csak úgy becsatlakozni az Androidba."
Egy korábbi cikkemben már beszéltem arról, hogy mennyire rosszak voltak az Android korai tervezési döntései. A fenébe, amikor azt a cikket írtam, éppen a "pillanatok alatt alkalmazások" nevű szörnyűséget vezették be, ami most (meglepetés!) , és sajnálom, ha elég buta voltál ahhoz, hogy hallgass a Google-re, és átkonfiguráld a tartalmadat ezekbe a pillanatok alatt alkalmazásokba.
De itt van egy különbség, egy lényeges különbség, amely abban rejlik, hogy az Android fejlesztői tényleg értik, mennyire fontosak a platformok, és mindent megtesznek, hogy megőrizzék a régi Android alkalmazások működőképességét. Valójában az erőfeszítéseik a visszafelé kompatibilitás megőrzésére olyan szélsőségesek, hogy még én is, amikor néhány éve rövid időt töltöttem az Android részlegén, azt tapasztaltam, hogy próbálom őket meggyőzni arról, hogy mondjanak le néhány a legrégebbi eszköz és API támogatásáról (tévedtem, ahogy sok más dologban a múltban és a jelenben. Elnézést kérek tőletek, Androidosok! Most, hogy jártam Indonéziában, értem, miért van szükségük ránk).
Az Android fejlesztői szinte elképzelhetetlen mértékben tartják fenn a visszafelé kompatibilitást, ami hatalmas mennyiségű elavult technikai adósságot halmoz fel a rendszereikben és eszközláncaikban. Ó, istenem, látnátok néhány őrült dolgot, amit a rendszerükben meg kell tenniük, mindezt a kompatibilitás nevében.
Ezért adom az Androidnak a tiszteletteljes „Te nem vagy Google” díjat. Tényleg nem akarnak Google-lé válni, amely nem tud tartós platformokat létrehozni, míg az Android tudja, hogyan kell ezt csinálni. Ezért a Google nagyon bölcsen viselkedik egy szempontból: lehetővé teszi az Android fejlesztőknek, hogy mindent a maguk módján csináljanak.
Ugyanakkor az Android instant alkalmazásai meglehetősen buta ötlet volt. És tudjátok miért? Mert megkövetelték az alkalmazásod újraírását és áttervezését! Mintha az emberek csak úgy átírnák a kétmillió alkalmazást. Gondolom, az instant alkalmazások valami Google-ista ötlete volt.
De itt van egy különbség. A visszafelé kompatibilitás hatalmas költségekkel jár. Az Android önmaga viseli e költségek terhét, míg a Google ragaszkodik ahhoz, hogy e terheket viseljétek ti, a fizetős ügyfelek.
Láthatjátok az Android elkötelezettségét a visszafelé kompatibilitás iránt az API-jában. Amikor négy vagy öt különböző alrendszer van az alapvetően ugyanazért a feladatért, az biztos jele, hogy a visszafelé kompatibilitás iránti elkötelezettség áll mögötte. Ami a platformok világában az ügyfelek iránti elkötelezettséggel és a piacotok iránti elkötelezettséggel egyenlő.
A Google fő problémája itt az, hogy büszkék a mérnöki higiéniájukra. Nem szeretik, ha rengeteg különböző módja van ugyanannak a dolognak, és a régi, kevésbé kívánatos módszerek közel állnak az új, furcsaabb módszerekhez. Ez növeli a tanulási görbét az új belépők számára, növeli a régi API-k támogatási terheit, lassítja az új funkciók bevezetésének ütemét, és a legfőbb bűn - hogy nem szép. A Google olyan, mint a Tim Burton által megálmodott Alice Csodaországban című film Lady Escottja:
Lady Escott:
— Alice, tudod, mi a legnagyobb félelmem?
— Az arisztokrácia hanyatlása?
— Féltem, hogy nekem csúf unokáim lesznek.
Ahhoz, hogy megértsük a szép és praktikus közötti kompromisszumot, nézzük meg a harmadik sikeres platformot (az Emacs és az Android után) és nézzük meg, hogyan működik: maga a Java.
A Javában rengeteg elavult API található. Az elavulás nagyon népszerű a Java programozók körében, még népszerűbb, mint a legtöbb programozási nyelvben. Magában a Javában, az alapnyelvben és a könyvtárakban folyamatosan történik az API-k elavulása.
Ha csak egyet veszünk a sok ezer példából, elavultnak számít. Azóta elavult, hogy a Java 1.2 1998 decemberében megjelent. 22 év telt el azóta, hogy ez elavult.
De a valódi kódom a gyakorlatban még mindig lezárja a szálakat mindennap. Jó ez? Abszolút! Arra gondolok, természetesen, ha ma újraírnám a kódot, máshogy valósítanám meg. De a játékom kódja, ami az elmúlt két évtizedben boldoggá tette számtalan embert, azt a funkciót használja, hogy a szálakat túl hosszú ideig tartja felfüggesztve, és nekem soha nem kellett megváltoztatnom. Én ismerem a rendszerem a legjobban, szinte 25 éves tapasztalatom van a gyakorlatban, és biztosan állíthatom, hogy az én esetemben ezeknek a konkrét munkaszálaknak a lezárása teljesen ártalmatlan. Nem érdemes időt és energiát pazarolni ennek a kódnak az újraírására, és köszönet Larry Ellisonnak (valószínűleg), hogy az Oracle nem kényszerített arra, hogy újra írjam.
Valószínűleg az Oracle is érti a platformokat. Ki tudja.
A bizonyítékokat szinte minden kulcsfontosságú Java API-nál találkozhatunk, amelyek a régi technológiák hullámaival vannak átszőve, mint a gleccser vonalai a kanyonban. A Java Swing könyvtárban könnyen megtalálhatók öt vagy hat különböző billentyűzet-navigációs menedzser (KeyboardFocusManager). Valójában nehéz olyan Java API-t találni, amely ne lenne elavult. De még mindig működnek! Azt hiszem, a Java csapata valóban csak akkor fogja eltávolítani az API-t, ha a felület égbekiáltó biztonsági problémát okoz.
Ez a helyzet, srácok: mi, szoftverfejlesztők, mindannyian nagyon elfoglaltak vagyunk, és a szoftver minden egyes területén versengő alternatívákkal nézünk szembe. Bármikor a programozók X nyelven Y nyelvet fontolgatják, mint lehetséges alternatívát. Ó, nem hisz nekem? Tudja meg a Swiftet? Azt mondja, mindenki migrál a Swiftra, és senki sem mond le róla, igaz? Hű, mennyire keveset tud. A cégek számolják a kettős mobilfejlesztő csapatok költségeit (iOS és Android) — és kezdik megérteni, hogy ezek a keresztnyelvű fejlesztési rendszerek, vicces nevekkel, mint a Flutter és a React Native, valóban működnek, és ezek segítségével felezhetik a mobilcsapataik méretét, vagy éppen ellenkezőleg, kétszer produktívabbá tehetik őket. Valódi pénzről van szó. Igen, vannak kibúvók, de másrészt, a pénz.
Tegyük fel hipotetikusan, hogy az Apple ostobaságból kedvet kapott Guido van Rossumtól, és bejelentette, hogy a Swift 6.0 nem lesz visszafelé kompatibilis a Swift 5.0-val, nagymértékben ahogyan a Python 3 sem kompatibilis a Python 2-vel.
Valószínűleg tíz évvel ezelőtt meséltem ezt a történetet, de tizenöt éve elmentem az O’Reilly Foo Camp táborába Guido-val, és Paul Graham-mal és egy csomó megbecsült személlyel ültem egy sátorban. Kimerítő hőségben ültünk, várva, hogy Larry Page megérkezzen a saját helikopterén, míg Guido monoton módon mormogott a "Python 3000"-ről, amelyet azzal a névvel illett, hogy mennyi időre van szükség ahhoz, hogy mindenki áttérjen. Folyamatosan kérdeztük tőle, miért sérti meg a kompatibilitást, és ő azt válaszolta: “Unicode”. És megkérdeztük, ha újra kell írni a kódunkat, akkor milyen további előnyöket fogunk tapasztalni? És ő azt mondta “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Ha telepíti a Google Cloud Platform SDK-t ("gcloud"), akkor a következő értesítést kapja:
Kedves címzett,
Szeretnénk emlékeztetni, hogy a Python 2 támogatása lejárt, szóval elmehetsz a fenébe.
… és így tovább. Az élet köre.
De a lényeg az, hogy minden fejlesztőnek van választása. És ha arra kényszeríted őket, hogy elég gyakran átírják a kódot, akkor esetleg elgondolkodnak a további lehetőségeken. Nem a te rabszolgáid ők, bármennyire is szeretnéd. Ők a vendégeid. A Python még mindig nagyon népszerű programozási nyelv, de, a francba, a Python 3(000) akkora káoszt teremtett magában, a közösségeiben és a felhasználói körében, hogy a következményeket már tizenöt éve nem tudják helyrehozni.
Hány Python programot írtak át Go-ra (vagy Rubira, vagy valamilyen más alternatívára) emiatt az visszafelé nem kompatibilitás miatt? Hány új szoftvert írtak valami más nyelven, nem pedig Pythonban, bár azt meg lehetett volna írni Pythonban, ha Guido nem égett volna fel az egész falut? Nehéz megmondani, de a Python egyértelműen sérült. Ez egy hatalmas káosz, és mindenki veszít.
Tehát tegyük fel, hogy az Apple példát vesz Guidotól, és megszegi a kompatibilitást. Mit gondolsz, mi fog következni? Nos, talán a fejlesztők 80-90%-a át fogja írni a szoftverét, ha lehetséges. Más szavakkal: a felhasználói bázis 10-20%-a automatikusan egy másik versenytárs nyelvre fog váltani, például a Flutter-re.
Tedd ezt meg néhányszor — és elveszíted a felhasználói bázisod felét. Ahogy a sportban, a programozás világában a jelenlegi forma is jelentőséggel bír. Minden, aki öt év alatt elveszíti a felhasználóinak felét, Nagy Kövér Sikertelenségnek számít. Neked naprakésznek kell lenned a platformok világában. De éppen itt a régi verziók támogatásának visszavonása fog tönkretenni. Mert minden alkalommal, amikor megszabadulsz egy részét a fejlesztőknek, (a) végleg elveszíted őket, mert dühösek lesznek rád a szerződés megszegése miatt, és (b) átadod őket a versenytársaidnak.Ironikus módon, én is segítettem a Google-nak abban, hogy olyan prima donnává váljon, amely ignorálja a visszafelé kompatibilitást, amikor megalkottam a Grok-ot, egy forráskód-elemző és megértő rendszert, amely megkönnyíti a kódra alapozott automatizálást és eszközkészletbe való integrálást - hasonlóan az IDE-hez, de itt egy felhőszolgáltatás tárolja a Google milliárd sor forráskódjáról készült materializált nézeteket egy nagy adatbázisban.
Ironikus módon, én is segítettem a Google-nak abban, hogy olyan prima donnává váljon, amely ignorálja a visszafelé kompatibilitást, amikor megalkottam a Grok-ot, egy forráskód-elemző és megértő rendszert, amely megkönnyíti a kódra alapozott automatizálást és eszközkészletbe való integrálást - hasonlóan az IDE-hez, de itt egy felhőszolgáltatás tárolja a Google milliárd sor forráskódjáról készült materializált nézeteket egy nagy adatbázisban.
A Grok biztosította a Google számára a lehetőséget, hogy automatizált refaktorálást végezzen az egész kódalapban (szó szerint az egész Google-ben). A rendszer nemcsak a felfelé irányuló függőségeket számolja ki (amelyektől függ), hanem az lefelé irányulókat (amelyek függnek tőled), így amikor API-t cserélsz, tudod, hogy kit törsz meg! Így amikor módosításokat végzel, ellenőrizheted, hogy minden API-felhasználód frissült az új verzióra, és valójában gyakran az általuk létrehozott Rosie eszközzel teljesen automatizálhatod a folyamatot.
Ez lehetővé teszi a Google kódalap számára, hogy belsőleg szinte természetfeletti "tiszta" legyen, mivel ezek a robotserv jobban pörögnek a ház körül, és automatikusan minden rendet raknak, ha átneveznek egy SomeDespicablyLongFunctionName-t egy SomeDespicablyLongMethodName-ra, mert valaki úgy döntött, hogy ez egy csúf unoka, és el kell altatni.
És őszintén szólva, ez elég jól működik a Google számára... belsőleg. Úgy értem, igen, a Google Go közösség valójában kedvesen gúnyolódik a Google Java közösségén a folyamatos refaktorálási szokásaik miatt. Ha valamit N-szer indítasz újra, akkor az azt jelenti, hogy nemcsak N-1 alkalommal elrontottad, hanem idővel egyértelművé válik, hogy valószínűleg az N-edik próbálkozással is elrontottad. De a lényeg, hogy ők ezen a zajon felül állnak, és tisztán tartják a kódot.
A problémák akkor kezdődnek, amikor ezt a mentalitást próbálják rákényszeríteni felhős ügyfeleikre és más API-k felhasználóira.
Kicsit megismertettelek az Emacsszal, az Androiddal és a Javával; nézzük meg az utolsó sikeres, hosszúéletű platformot: magát a Webet. El tudod képzelni, hány iteráción ment keresztül a HTTP 1995 óta, amikor még villogó <blink> címkéket és "Fejlesztés alatt" ikonokat használtunk a weboldalakon.
De ez még mindig működik! És ezek az oldalak még mindig működnek! Igen, gyerekek, a böngészők a világ bajnokai a visszafelé kompatibilitásban. A Chrome egy újabb példája a Google ritka platformjának, amelynek a fejei helyesen vannak csavarozva, és ahogy már kitaláltad, a Chrome hatékonyan működik, mint egy elszigetelt vállalat a többi Google-től.
Szeretném megköszönni barátainknak az operációs rendszerek között: Windows, Linux, NEM APPLE, FreeBSD és így tovább, hogy ilyen nagy munkát végeztek a visszafelé kompatibilitás terén a sikeres platformjaikon (Apple a legjobb esetben is hármast kap mínusszal, mivel folyamatosan mindent tönkretesznek tiszteletteljes ok nélkül, de valahogy a közösség minden kiadásnál megbirkózik ezzel, és a macOS konténerek még mindig nem teljesen elavultak… egyelőre).
De várj, mondhatod. Nem hasonlítunk-e almát narancsra — önálló szoftverrendszereket egy gépen, mint például Emacs/JDK/Android/Chrome, több szerveres rendszerekhez és API-hoz, mint a felhőszolgáltatásoknál?
Nos, erről tegnap írtam a Twitteren, de Larry Wall stílusában (a Perl programozási nyelv megalkotója — a fordító megjegyzése) az „szar/menő” elve alapján kerestem a szót deprecated a Google és az Amazon fejlesztői weboldalain. És bár az AWS-nek sok száz szor több szolgáltatása van, mint a GCP-nek, a Google fejlesztői dokumentációja körülbelül hétszer gyakrabban említi a használatból való kivonást.
Ha valaki a Google-től ezt olvassa, biztosan készen állnak, hogy diagramosan Donald Trump stílusában bizonyítsák, hogy valójában mindent jól csinálnak, és hogy nem szabadene igazságtalan összehasonlításokat tennem, mint például „a deprecated szó említéseinek száma a szolgáltatások számának arányában”.
De ennyi év után a Google Cloud még mindig a 3. számú szolgáltatás (még nem írtam meg a 2. helyre való sikertelen próbálkozásról szóló cikket), de ha a bennfenteseknek hihetünk, van néhány aggodalom amiatt, hogy hamarosan a 4. helyre eshetnek vissza.
Nincs meggyőző érvem, hogy "bizonyítsam" a tézisem. Ami nálam van, az csak színes példák, amiket 30 év fejlesztői munkám során gyűjtöttem. Már említettem ennek a problémának a mélyen filozófiai természetét; bizonyos értelemben politikailag motivált a fejlesztői közösségekben. Vannak, akik úgy vélik, hogy a platformok teremtőinek törődniük kell a kompatibilitással, míg mások úgy vélik, hogy ez a felhasználók (maguk a fejlesztők) gondja. Ez vagy az. És valóban, nem politikai kérdés az, amikor eldöntjük, ki viselje a közös problémák költségeit?
Szóval ez politika. És biztosan lesznek dühös válaszok a nyilatkozatomra.
Mint a felhasználó A Google felhőplatformjáról, valamint arról, hogy két évig AWS felhasználó voltam (a Grab cégnél dolgozva), elmondhatom, hogy óriási különbség van az Amazon és a Google filozófiái között, amikor a prioritásokról van szó. Nem végzek aktív fejlesztést AWS-en, így nem tudom pontosan, mennyire gyakran távolítanak el régi API-kat. De van egy sejtésem, hogy ez messze nem történik olyan gyakran, mint a Google esetében. És őszintén hiszem, hogy ennek a folyamatos viták és csalódások forrása a GCP-ben az egyik legnagyobb tényező, ami visszatartja a platform fejlődését.
Tudom, hogy nem említettem konkrét példákat a GCP rendszerekre, amelyek támogatását megszüntették. Azt tudom mondani, hogy gyakorlatilag minden, amit használtam, a hálózatok (a legrégebbiektől a VPC-ig) a tárolókig (Cloud SQL v1-v2), Firebase (most Firestore, egy teljesen más API-val), App Engine (ne is kezdjünk el erről beszélni), a Cloud Endpoint felhős végpontokig és… nem tudom - absolutely everything maximálisan 2-3 évente arra kényszerített, hogy újraírjam a kódot, és soha nem automatizálták a migrációt, és gyakran . Mintha ez így lenne rendjén.
És minden alkalommal, amikor az AWS-ra nézek, azt kérdezem magamtól, hogy mi the heck a csudát keresek még mindig a GCP-n. Nyilvánvalóan nincs szükségük ügyfelekre. Vásárlókra van szükségük vásárlókra. Érti a különbséget? Hadd magyarázzam el.
A Google Cloudnak van , ahol az emberek ajánlják a szoftvermegoldásaikat, és ahhoz, hogy elkerüljük a kihalt étterem hatását, néhány ajánlattal kellett feltölteni, ezért szerződést kötöttek a Bitnami céggel, hogy létrehozzanak egy csomó olyan megoldást, amelyeket "egy kattintással" lehet telepíteni, vagy nekem magamnak kell "megoldásokat" írni, mert ezek semmit sem oldanak meg. Csak úgy léteznek, mint jelvények, mint marketing töltelék, és a Google-t soha nem érdekelte, hogy valóban működik-e bármelyik eszköz. Ismerek termékmenedzsereket, akik a volánnál ültek, és biztosíthatom, hogy ezek az emberek nem érdekli.
Vegyünk például egy, a mágikus "egy kattintásos telepítés" ígéretével rendelkező megoldást . Halálosan unom a Google Cloud SQL trükkjeit, ezért elkezdtem alternatívaként saját Percona klaszterem létrehozását fontolgatni. És ezúttal a Google úgy tűnik, jót tett, szándékuk volt, hogy egy gombnyomással spóroljon nekem némi időt és energiát!
Nos, jól van, elkezdjük. Kattintsunk a linkre, és nyomjuk meg ezt a gombot. Válasszuk a „Igen” lehetőséget, hogy vállaljuk az alapértelmezett beállításokat, és telepítsük a klasztert a Google felhőprojektünkben. Haha, nem működik. Semmi ebből a hülyeségből nem működik. Az eszköz soha nem lett tesztelve, és az első perctől kezdve elkezdett rothadni, és nem lepődnék meg, ha a „varázslatos” (most már értjük, miért idézőjelben) telepítési megoldások több mint fele nem működik. tulajdonképpen nem működnek. Ez egy teljesen sötét hely, ahová jobb nem belépni.
De a Google egyenesen bátorít titeket, hogy használjátok őket. Azt akarják, hogy megvedd őket.. Számukra ez üzleti tranzakció. Nem akarnak semmit támogatni.. Ez nem része a Google DNS-nek. Igen, a mérnökök támogatják egymást, amit az én Bigtable történetem is bizonyít. De a hétköznapi embereknek szóló termékekben és szolgáltatásokban mindig kíméletlenek voltak bármely szolgáltatás bezárásában Ez pedig igazi problémát jelent a GCP számára, mert ez a DNS áll minden felhőajánlat mögött. Nem akarnak semmit támogatni; jól ismert, hogy nem hajlandók üzemeltetni (mint kezelt szolgáltatás) semmilyen harmadik féltől származó szoftvert
addig, amíg az AWS nem teszi meg ugyanezt, és köré nem épít sikeres üzletet, és amikor az ügyfelek szó szerint ugyanezt kívánják. Viszont bizonyos erőfeszítéseket kell tenni ahhoz, hogy a Google valamit támogasson. Ez a támogatási kultúra hiánya, együtt a „törjük össze, hogy szebbé tegyük” elvvel, eltávolítja a fejlesztőket tőlük.És ez nem nagyon jó, ha tartós platformot akarsz építeni.
Google, ébredj fel, az ördögbe! Most 2020 van. Még mindig veszítesz. Itt az ideje, hogy alaposan megnézd a tükörképét, és válaszolj arra, hogy valóban szeretnél-e a felhő üzletágban maradni.
Ha meg akarsz maradni, akkor
hagyd abba a tördelést.
Srácok, ti gazdagok vagytok. Mi, fejlesztők - nem. Tehát amikor arról van szó, hogy ki vállalja a kompatibilitás terhét, nektek kell átvállalnotok. Nem nekünk. Mert van még legalább három igazán jó felhő.Ezek vonzanak magukhoz.
Most viszont megyek tovább, hogy javítsam az összes törött rendszeremet. Hát.
A következő alkalomig!
Legközelebb találkozunk!
P. S. Frissítés, miután elolvastam néhány hozzászólást erről a cikkről (mellesleg a hozzászólások fantasztikusak). A Firebase támogatása nem szűnt meg, és nincs tudomásom olyan tervekről, amelyek ezt előirányoznák. Mindazonáltal van egy kellemetlen stream-elési hiba, ami miatt a Java kliens leáll az App Engine-en. Az egyik mérnökük segített nekem megbirkózni ezzel a problémával, amikor a Google-nál dolgoztam, de soha nem javították meg ténylegesen a hibát, ezért van egy elég körülményes megoldásom, ami miatt naponta újra kell indítanom az GAE alkalmazást. Ez már négy éve így van! Most már van Firestore is. Rengeteg munka szükséges az átköltöztetéshez, mivel ez egy teljesen más rendszer, és a Firebase hibáját soha nem fogják kijavítani. Mit lehet ebből levonni? Segítséget kaphat, ha egy cégnél dolgozik. Valószínűleg én vagyok az egyetlen, aki a Firebase-t használja az GAE-n, mert kevesebb mint 100 kulcsot írok a 100%-ban natív alkalmazásomba, és ez pár naponta leáll a jól ismert hiba miatt. Mit lehet itt mondani, kivéve hogy saját felelősségre használja. Áttérek a Redisra.
Azt is láttam, hogy egyes tapasztaltabb AWS felhasználók azt mondták, hogy az AWS általában soha nem szünteti meg a szolgáltatások támogatását, és a SimpleDB a kiváló példa erre. Az az elképzelésem, hogy az AWS-nek nincs olyan betegsége a támogatás megszüntetésével, mint a Google-nak, helytállónak tűnik.
Továbbá észrevettem, hogy 20 nappal ezelőtt a Google App Engine csapata megbénította egy kritikus Go könyvtár hosztolását, bezárva az GAE alkalmazást egy a Go fő fejlesztői közül. Tényleg elég ostobán alakult ez.
Végül hallottam, hogy a google-i mérnökök már tárgyalták ezt a kérdést, és általában egyetértenek velem (szeretlek titeket, srácok!). De úgy tűnik, hogy a problémát megoldhatatlannak tartják, mert a Google kultúrájában sosem volt megfelelő ösztönző struktúra. Úgy érzem, jó lenne némi időt szánni arra, hogy beszéljek az AWS mérnökeivel való abszolút csodálatos együttműködésről, amikor a Grabnál dolgoztam. Remélem, hogy a jövőben erre is sort keríthetünk!
Igen, 2005-ben valóban különböző fajta cápahúst szolgáltak fel a hatalmas svédasztalon a 43-as épületben, és a legjobban a kalapácsfejű cápahús ízlett. De 2006-ra Larry és Sergey megszabadultak az összes egészségtelen nasitól. Így a Bigtable története alatt 2007-ben valóban nem volt cápahús, és csúnyán átvertelek benneteket.
Amikor négy éve (plusz-mínusz) néztem a felhős Bigtable-t, az ár pontosan ilyen volt. Úgy tűnik, most egy kicsit csökkent, de még mindig borzasztóan sok egy üres adatbázisért, különösen figyelembe véve, hogy az első történetem megmutatja, mennyire lényegtelen egy üres nagy tábla az ő léptékükben.
Sajnálom, hogy megsértettem az Apple közösséget, és hogy nem mondtam semmi jót a Microsoft-ról stb. Mindannyian igazatok van, nagyon értékelem az összes diskurzust, amit ez a cikk kiváltott! De néha egy kis hullámverés szükséges, hogy megkezdődjön a beszélgetés, értitek, nem?
Köszönöm, hogy elolvastad.
Frissítés 2, 2020.08.19. Stripe !
Frissítés 3, 2020.08.31. Kapcsolatba lépett velem a Google Cloud Marketplace egyik mérnöke, aki a régi barátom volt. Ki akarta deríteni, miért nem működik a C2D, és végül kiderült: az az oka, hogy néhány éve készítettem a hálózatomat, és a C2D nem működik elavult hálózatokban a hiányzó alhálózati paraméter miatt a sablonjaikban. Azt hiszem, a leendő GCP felhasználóknak érdemes lenne megbizonyosodniuk arról, hogy elég ismerős mérnökük van a Google-nál...
Forrás: habr.com
