Ferdomd Google, ik woe net wer blogge. Ik haw safolle te dwaan. Bloggen kostet tiid, enerzjy en kreativiteit, wat ik goed brûke koe: myn boeken, , myn spultsje ensafuorthinne. Mar do hast my genôch pissearre dat ik dit skriuwe moat.
Dat litte wy dit ôfmeitsje.
Lit my begjinne mei in koart, mar learsum ferhaal fan doe't ik foar it earst begon te wurkjen by Google. Ik wit dat ik de lêste tiid in protte minne dingen oer Google haw sein, mar it makket my oerstjoer as myn eigen bedriuw geregeldwei inkompetinte saaklike besluten nimt. Tagelyk moatte wy it syn rjocht jaan: de ynterne ynfrastruktuer fan Google is wirklik bûtengewoan, it is feilich te sizzen dat d'r hjoed neat better is. De oprjochters fan Google wiene folle bettere yngenieurs dan ik ea sil wêze, en dit ferhaal befêstiget allinich dat feit.
Earst, in bytsje eftergrûn: Google hat in technology foar gegevensopslach neamd . It wie in opmerklike technyske prestaasje, ien fan 'e earste (as net de earste) "ûneinich skalberbere" kaai-wearde winkel (K / V): yn wêzen it begjin fan NoSQL. Dizze dagen docht Bigtable it noch goed yn 'e nochal fol K / V opslachromte, mar op' e tiid (2005) wie it geweldich cool.
Ien grappich ding oer Bigtable is dat se hie ynterne kontrôle fleantúch foarwerpen (as ûnderdiel fan de ymplemintaasje) neamd tablet tsjinners, mei grutte yndeksen, en op in stuit se wurden in knelpunt doe't skaalfergrutting fan it systeem. Bigtable-yngenieurs wiene fernuvere oer hoe't skalberens ymplementearje, en realisearre ynienen dat se tabletservers kinne ferfange troch oare Bigtable-opslach. Dat Bigtable is diel fan 'e Bigtable-ymplemintaasje. Dizze opslachfoarsjenningen binne der op alle nivo's.
In oar nijsgjirrich detail is dat Bigtable in skoft populêr waard en oeral binnen Google, mei elk team in eigen repository. Dus op ien fan 'e freedsgearkomsten frege Larry Page yn it foarbygean terloops: "Wêrom hawwe wy mear dan ien Bigtable? Wêrom net ien?" Yn teory soe ien opslach genôch wêze moatte foar alle opslachbehoeften fan Google. Fansels gongen se noait nei ien foar praktyske ûntwikkelingsredenen (lykas de gefolgen fan in potinsjele mislearring), mar de teory wie ynteressant. Ien repository foar it hiele universum (Trouwens, wit immen oft Amazon dit dien hat mei har Sable?)
Hoe dan ek, hjir is myn ferhaal.
Op dat stuit wurke ik krekt mear as twa jier by Google, en op in dei krige ik in e-post fan it Bigtable-technykteam dat sa gie:
Beste Steve,
Hallo fan it Bigtable team. Wy wolle jo ynformearje dat jo by [datacenternamme] in heul, heul âlde Bigtable-binêr brûke. Dizze ferzje wurdt net mear stipe en wy wolle jo helpe bywurkje nei de lêste ferzje.
Lit my asjebleaft witte as jo wat tiid kinne plannen om gear te wurkjen oan dit probleem.
It bêste,
Bigtable Team
Op Google krije jo in protte post, dus op it earste each lies ik soksawat:
Beste ûntfanger,
Hallo fan guon team. Wy wolle dat blah blah blah blah blah kommunisearje. Blah blah blah blah blah, en blah blah blah fuortendaliks.
Lit it ús asjebleaft witte as jo in pear fan jo kostbere tiid kinne planne foar blah blah blah.
It bêste,
In soarte fan kommando
Ik haw it hast fuort fuorthelle, mar oan 'e râne fan myn bewustwêzen fielde ik in pynlik, gnyske gefoel dat it net krekt liket wol in formele brief fansels, dat de ûntfanger fersin wie omdat ik Bigtable net brûkte.
Mar it wie nuver.
Ik ha de rest fan de dei ôfwikseljend neitocht oer wurk en wat foar haaienfleis te besykjen yn de mikrokeuken, wêrfan op syn minst trije ticht genôch wiene om mei in goed rjochte smyt fan in biskuit fan myn stoel ôf te slaan, mar de tocht oan skriuwen hat my noait ferlitten mei in tanimmend gefoel milde eangst.
Se seine dúdlik myn namme. En de e-mail waard stjoerd nei myn e-mailadres, net in oar syn, en it is net cc: of bcc:. De toan is heul persoanlik en dúdlik. Miskien is dit in soarte fan flater?
Uteinlik krige de nijsgjirrigens it oer my en ik gong nei de Borg-konsole te sjen yn it datasintrum dat se neamden.
En fansels hie ik BigTable-opslach ûnder behear. It spyt my, wat? Ik seach nei de ynhâld, en wow! It wie fan 'e Codelab-incubator wêryn ik yn myn earste wike by Google yn juny 2005 siet. Codelab twong jo om Bigtable út te fieren om dêr wat wearden te skriuwen, en ik ha de opslach blykber noait dêrnei sluten. It wurke noch, ek al wiene mear as twa jier ferrûn.
D'r binne ferskate opmerklike aspekten oan dit ferhaal. As earste wie it wurk fan Bigtable sa ûnbelangryk op 'e skaal fan Google dat allinich twa jier letter ien de ekstra opslach opmurken, en allinich om't de ferzje fan' e binêr ferâldere wie. Foar fergeliking haw ik ienris tocht om te brûken foar myn online game. Op it stuit koste dizze tsjinst sawat $ 16 yn 't jier. leech Bigtable op GCP. Ik sis net dat se jo oplichtsje, mar yn myn persoanlike miening is dat in soad jild foar in lege ferdomme databank.
In oar opmerklik aspekt is dat de opslach noch wurkje nei twa jier. WTF? Datasintra komme en gean; se ûnderfine ûnderbrekkings, se ûndergeane pland ûnderhâld, se feroarje hieltyd. Hardware wurdt bywurke, skeakels wurde wiksele, alles wurdt hieltyd ferbettere. Hoe koene se myn programma twa jier rinnend hâlde mei al dizze feroarings? Dit kin lykje as in beskieden prestaasje yn 2020, mar yn 2005-2007 wie it frij yndrukwekkend.
En it meast prachtige aspekt is dat in bûten yngenieurteam yn in oare steat my benaderet, de eigner fan in lyts, hast lege eksimplaar fan Bigtable, dy't hat nul ferkear foar de ôfrûne twa jier - en biede help om it te aktualisearjen.
Ik betanke harren, wiske de opslach, en it libben gie troch as gewoanlik. Mar trettjin jier letter tink ik noch oer dy brief. Want soms krij ik ferlykbere e-mails fan Google Cloud. Se sjogge der sa út:
Beste Google Cloud-brûker,
As herinnering sille wy de tsjinst [essensjele tsjinst dy't jo brûke] beëinigje fanôf augustus 2020, wêrnei't jo jo eksimplaren net kinne opwurdearje. Wy riede oan om te upgrade nei de lêste ferzje, dy't yn beta-testen is, gjin dokumintaasje hat, gjin migraasjepaad en earder ferâldere is mei ús freonlike help.
Wy sette ús yn om te soargjen dat dizze feroaring minimale ynfloed hat op alle brûkers fan it Google Cloud-platfoarm.
Freonen foar altyd,
Google Cloud Platfoarm
Mar sokke brieven lês ik hast noait, want wat se eins sizze is:
Beste ûntfanger,
Flean op. Fuck dy, fuck dy, fuck dy. Drop alles wat jo dogge, want it makket neat út. It giet om ús tiid. Wy fergrieme tiid en jild mei it ûnderhâlden fan ús stront en wy binne der nocht fan, dus wy sille it net mear stypje. Dus stopje mei jo ferdomme plannen en begjinne te graven troch ús skitterjende dokumintaasje, smeekje om kladsjes op 'e foarums, en trouwens, ús nije stront is folslein oars fan' e âlde stront, om't wy dit ûntwerp aardich ferfongen hawwe, he, mar dat is jo probleem, net ús.
Wy bliuwe ynspanningen dwaan om te soargjen dat al jo ûntwikkelingen binnen ien jier ûnbrûkber wurde.
Asjebleaft neukje
Google Cloud Platfoarm
En feit is dat ik sa'n XNUMX kear yn de moanne sokke brieven krij. Dit bart sa faak en sa konstant dat se ûnûntkomber fuortstutsen my fan GCP nei it anty-wolkkamp. Ik bin it net mear iens om ôfhinklik te wêzen fan har proprietêre ûntjouwings, om't it feitlik makliker is foar devops om in iepen boarne-systeem te behâlden op in bleate firtuele masine dan om te besykjen om Google by te hâlden mei har belied om "ferâldere" produkten te sluten.
Foardat ik weromgean nei Google Cloud, om't ik by lange nei net net dien mei krityk op har, litte wy sjen nei de prestaasjes fan it bedriuw op guon oare gebieten. Google-yngenieurs binne grutsk op har disipline foar software-engineering, en dit is wat eins problemen feroarsaket. Grutskens is in trap foar de ûnfoarsichtige, en it hat in protte Google-meiwurkers laat tinken dat har besluten altyd rjocht binne en dat rjocht wêze (troch wat vage fuzzy definysje) wichtiger is dan soarch oer klanten.
Ik sil wat willekeurige foarbylden jaan fan oare grutte projekten bûten Google, mar ik hoopje dat jo dit patroan oeral sjogge. It is as folget: efterkompatibiliteit hâldt systemen libben en aktueel foar tsientallen jierren.
Efterútkompatibiliteit is it ûntwerpdoel fan alle suksesfolle systemen ûntworpen foar iepenje gebrûk, dat is, ymplementearre mei iepen boarne koade en / of iepen noarmen. Ik fiel dat ik wat te dúdlik sis dat elkenien sels ûngemaklik is, mar nee. Dit is in politike kwestje, dus foarbylden binne nedich.
It earste systeem dat ik sil kieze is it âldste: GNU Emacs, dat in soarte fan hybride is tusken Windows Notepad, de OS-kernel, en it International Space Station. It is in bytsje lestich te ferklearjen, mar yn in notedop, Emacs is in platfoarm makke yn 1976 (ja, hast in heale ieu lyn) foar programmearring om jo produktiver te meitsjen, mar ferklaaid as tekstbewurker.
Ik brûk Emacs elke dei. Ja, ik brûk ek IntelliJ elke dei, it is útgroeid ta in krêftich arkplatfoarm op himsels. Mar it skriuwen fan tafoegings foar IntelliJ is in folle mear ambisjeuze en komplekse taak dan it skriuwen fan tafoegings foar Emacs. En noch wichtiger, alles skreaun foar Emacs wurdt bewarre bleaun ivich.
Ik brûk noch altyd de software dy't ik yn 1995 foar Emacs skreau. En ik bin der wis fan dat immen brûkt modules skreaun foar Emacs yn 'e midden fan' e jierren '80, as net earder. Se kinne fan tiid ta tiid in bytsje oanpassing nedich wêze, mar dit is echt frij seldsum. Ik wit net fan wat ik haw ea skreaun foar Emacs (en ik haw skreaun in protte) dat easke in re-arsjitektuer.
Emacs hat in funksje neamd make-ferâldere foar ferâldere entiteiten. Emacs-terminology foar fûnemintele kompjûterbegripen (lykas wat in "finster" is) ferskilt faak fan yndustrykonvinsjes, om't Emacs se in lange tiid lyn yntrodusearre. Dit is in typysk gefaar foar dyjingen dy't har tiid foarút binne: al jo betingsten binne ferkeard. Mar Emacs hat wol in konsept fan ôfskriuwing, dat yn har jargon hjit ferâldering.
Mar yn 'e Emacs-wrâld liket d'r in oare wurkdefinysje te wêzen. In oare ûnderlizzende filosofy, as jo wolle.
Yn 'e wrâld fan Emacs (en yn in protte oare gebieten, dy't wy hjirûnder sille dekke), betsjut de ôfskreaune API-status yn prinsipe: "Jo moatte dizze oanpak echt net brûke, want wylst it wurket, hat it te lijen fan ferskate tekoarten dat wy sille list hjir. Mar oan 'e ein fan 'e dei is it jo kar."
Yn 'e wrâld fan Google betsjut ferâldere wêzen: "Wy binne yn striid mei ús ynset foar jo." Dit is wier. Dit is wat it yn wêzen betsjut. Dit betsjut dat se jo twinge regelmjittich dwaan wat wurk, faaks in protte wurk, as straf foar it leauwen yn harren : Wy hawwe de bêste software. De fluchste! Jo dogge alles neffens de ynstruksjes, starte jo applikaasje of tsjinst, en dan bam, nei in jier as twa brekt it.
It is as it ferkeapjen fan in brûkte auto dy't nei 1500 km definityf stikken sil.
Dit binne twa folslein ferskillende filosofyske definysjes fan "ferâldering." Google's definysje fan geur . Ik leau dit net yn feite plande ferâldering yn deselde betsjutting as Apple. Mar Google is perfoarst fan plan om jo programma's op in rûnwei manier te brekken. Ik wit dit om't ik dêr mear as 12 jier wurke as software-yngenieur. Se hawwe vage ynterne rjochtlinen oer hoefolle efterút kompatibiliteit moat wurde folge, mar it is úteinlik oan elk yndividuele team of tsjinst. D'r binne gjin oanbefellingen op ûndernimmings- of technyknivo, en de fetste oanbefelling yn termen fan ferâlderingssyklusen is "besykje klanten 6-12 moannen te jaan om te upgrade foardat se har heule systeem brekke."
It probleem is folle grutter dan se tinke, en it sil noch jierren oanhâlde om't klantsoarch net yn har DNA is. Mear oer dit hjirûnder.
Op dit punt sil ik in fette ferklearring meitsje dat Emacs foar in grut part suksesfol is en sels yn prinsipe om't se efterútkompatibiliteit sa serieus nimme. Eins is dit de proefskrift fan ús artikel. Súksesfolle, lange libbene iepen systemen hawwe har sukses te tankjen oan 'e mikromienskippen dy't al tsientallen jierren om har hinne libje tafoegings / plugins. Dit is it ekosysteem. Ik haw al praat oer de aard fan platfoarms en hoe wichtich se binne, en hoe't Google noait yn har heule bedriuwsskiednis begrepen hat wat der yn giet om in suksesfolle iepen platfoarm bûten Android of Chrome te meitsjen.
Eigentlik moat ik Android koart neame, om't jo der wierskynlik oer tinke.
Earst, Android is net Google. Se hawwe hast neat mei elkoar. Android is in bedriuw dat yn july 2005 troch Google oankocht is, it bedriuw mocht min of mear autonoom operearje en is yndie yn de tuskenlizzende jierren foar in grut part ûnoantaaste bleaun. Android is in beruchte tech-stapel en in like beruchte stekke organisaasje. As ien Googler it sei, "Jo kinne net gewoan ynlogge op Android."
Yn in earder artikel haw ik besprutsen hoe min guon fan 'e iere ûntwerpbeslissingen fan Android wiene. Heck, doe't ik dat artikel skreau, rôlen se stront út neamd "instant apps" dy't no binne (ferrassing!) , en ik meilibje as jo wiene dom genôch om te harkjen nei Google en ferpleatse jo ynhâld nei dizze instant apps.
Mar d'r is hjir in ferskil, in signifikant ferskil, dat is dat de Android-minsken echt begripe hoe wichtich platfoarms binne, se besykje har bêst om âlde Android-apps wurkje te hâlden. Yn feite binne har ynspanningen om efterútkompatibiliteit te behâlden sa ekstreem dat sels ik, tidens myn koarte stint by de Android-divyzje in pear jier lyn, mysels fûn besykje se te oertsjûgjen om stipe foar guon fan 'e âldste apparaten en API's te fallen (ik wie ferkeard , lykas yn in protte oare dingen ferline en hjoed. Sorry Android guys! No't ik yn Yndoneezje west bin, begryp ik wêrom't wy se nedich hawwe).
De Android-minsken drukke efterút kompatibiliteit oant hast ûnfoarstelbere ekstremen, en stapelje massive hoemannichten legacy technyske skulden op yn har systemen en toolchains. Oh myn god, jo moatte wat fan 'e gekke dingen sjen dy't se moatte dwaan yn har bousysteem, allegear yn' e namme fan kompatibiliteit.
Hjirfoar gun ik Android de begeerde priis "Jo binne net Google". Se wolle echt net Google wurde, dy't net wit hoe't se duorsume platfoarms meitsje, mar Android wit, Hoe it te dwaan. En dus is Google yn ien opsicht heul tûk: minsken tastean dingen op har eigen manier te dwaan op Android.
Instant apps foar Android wiene lykwols in aardich dom idee. En witte jo wêrom? Om't se easke herskriuwe en opnij ûntwerpe jo applikaasje! It is as sille minsken gewoan twa miljoen oanfragen oerskriuwe. Ik tink dat Instant Apps it idee fan guon Googlers wie.
Mar der is in ferskil. Efterút kompatibiliteit komt foar hege kosten. Android sels draacht de lêst fan dizze kosten, wylst Google derop stiet dat de lêst droegen wurdt you, beteljende klant.
Вы можете увидеть приверженность Android обратной совместимости в её API-интерфейсах. Когда у вас четыре или пять различных подсистем для выполнения буквально одного и того же, это верный признак, что в основе лежит приверженность обратной совместимости. Что в мире платформ является синонимом приверженности вашим клиентам и вашему рынку.
It wichtichste probleem fan Google hjir is har grutskens op har technykhygiëne. Se fine it net leuk as der in protte ferskillende manieren binne om itselde te dwaan, mei de âlde, minder winsklike manieren dy't njonken de nije, fanciere manieren sitte. It fergruttet de learkurve foar dy nije yn it systeem, it fergruttet de lêst fan it behâld fan legacy API's, it fertraagt de snelheid fan nije funksjes, en de kardinale sûnde is dat it net moai is. Google - lykas Lady Ascot fan Tim Burton's Alice in Wonderland:
Lady Ascot:
- Alice, witsto wêr't ik it meast bang foar bin?
- De delgong fan 'e aristokrasy?
- Ik wie bang dat ik it soe hawwe некрасивые внуки.
Om de kompromis tusken moai en praktysk te begripen, litte wy ris nei it tredde suksesfolle platfoarm (nei Emacs en Android) sjen en sjen hoe't it wurket: Java sels.
Java hat in protte ferâldere API's. Deprecation is tige populêr ûnder Java-programmeurs, noch populêrder dan yn de measte programmeartalen. Java sels, de kearntaal, en de bibleteken ferneatigje API's konstant.
Om mar ien fan tûzenen foarbylden te nimmen, beskôge ferâldere. It is ôfkard sûnt de frijlitting fan Java 1.2 yn desimber 1998. It is 22 jier lyn dat dit ôfskaft waard.
Mar myn eigentlike koade yn produksje is noch hieltyd deadzjen fan triedden elke dei. Fynsto dat echt goed? Absolút! Ik bedoel, fansels, as ik hjoed de koade soe opnij skriuwe, soe ik it oars útfiere. Mar de koade foar myn spultsje, dy't de ôfrûne twa desennia hûnderttûzenen minsken lokkich makke hat, is skreaun mei in funksje om triedden te sluten dy't te lang hingje, en ik hie it nea feroarje moatten. Ik ken myn systeem better as elkenien, ik haw letterlik 25 jier ûnderfining mei it wurkjen mei it yn produksje, en ik kin mei wissichheid sizze: yn myn gefal is it sluten fan dizze spesifike wurktrieden folslein ûnskuldich. It is de tiid en muoite net wurdich om dizze koade te herskriuwen, en tankje Larry Ellison (wierskynlik) dat Oracle my net twong om it oer te skriuwen.
Oracle begrypt wierskynlik ek platfoarms. Wa wit.
Bewiis kin fûn wurde yn 'e kearn Java API's, dy't besunige binne mei weagen fan ferâldering, lykas de linen fan in gletsjer yn in canyon. Jo kinne maklik fiif of seis ferskillende toetseboerdnavigaasjebehearders (KeyboardFocusManager) fine yn 'e Java Swing-bibleteek. It is eins lestich om in Java API te finen dy't net is ôfret. Mar se wurkje noch! Ik tink dat it Java-team allinich in API wirklik sil fuortsmite as de ynterface in skriklik feiligensprobleem foarmet.
Hjir is it ding, minsken: wy software-ûntwikkelders binne allegear heul drok, en yn elk gebiet fan software wurde wy konfrontearre mei konkurrearjende alternativen. Op elts momint beskôgje programmeurs yn taal X taal Y as in mooglike ferfanging. Och, jo leauwe my net? Wolle jo it Swift neame? Lykas, elkenien migreart nei Swift en gjinien ferlit it, krekt? Wow, hoe min witsto. Bedriuwen telle de kosten fan teams foar dûbele mobile ûntwikkeling (iOS en Android) - en se begjinne te realisearjen dat dy cross-platform ûntwikkelingssystemen mei grappige nammen lykas Flutter en React Native eins wurkje en kinne wurde brûkt om de grutte fan har te ferminderjen. mobile teams twa kear of, oarsom, meitsje se twa kear sa produktyf. Der stiet echt jild op it spul. Ja, d'r binne kompromissen, mar oan 'e oare kant jild.
Litte wy hypotetysk oannimme dat Apple dwaas in oanwizing naam fan Guido van Rossum en ferklearre dat Swift 6.0 efterút ynkompatibel is mei Swift 5.0, lykas Python 3 ynkompatibel is mei Python 2.
Ik haw dit ferhaal wierskynlik sa'n tsien jier lyn ferteld, mar sa'n fyftjin jier lyn gie ik mei Guido nei O'Reilly's Foo Camp, siet yn in tinte mei Paul Graham en in bulte grutte skots. Wy sieten yn 'e sweljende waarmte te wachtsjen op Larry Page om yn syn persoanlike helikopter út te fleanen, wylst Guido dronken oer "Python 3000", dy't hy neamde nei it oantal jierren dat it soe nimme foar elkenien om dêr te migrearjen. Wy fregen him hieltyd wêrom't hy de kompatibiliteit brekke, en hy antwurde: "Unicode." En wy fregen, as wy ús koade moatte herskriuwe, hokker oare foardielen soene wy sjogge? En hy antwurde "Yoooooooooooooouuuuuuuniiiiiiiicooooooooode."
As jo de Google Cloud Platform SDK ("gcloud") ynstalleare, krije jo de folgjende notifikaasje:
Beste ûntfanger,
Wy wolle jo deroan herinnerje dat stipe foar Python 2 is ôfkard, dus fuck dy
… ensafuorthinne. Circle of life.
Mar it punt is dat elke ûntwikkelder in kar hat. En as jo twinge se te herskriuwen koade faak genôch, se miskien tinke oer oaren opsjes. Se binne net jo gizelders, nettsjinsteande hoefolle jo wolle dat se binne. Se binne jo gasten. Python is noch altyd in tige populêre programmeartaal, mar ferdomme, Python 3(000) hat op himsels, yn syn mienskippen en by de brûkers fan syn mienskippen sa'n rommel makke dat de gefolgen al fyftjin jier net opheldere binne.
Сколько программ Python было переписано на Go (или Ruby, или какой-то другой альтернативе) из-за этой обратной несовместимости? Сколько нового программного обеспечения было написано на чём-то другом, кроме Python, хотя оно koe wêze skreaun yn Python, as Guido net it hiele doarp ôfbaarnd hie? It is dreech om te sizzen, mar Python hat dúdlik te lijen. It is in grutte puinhoop en elkenien ferliest.
Litte wy dus sizze dat Apple in oanwizing nimt fan Guido en de kompatibiliteit brekt. Wat tinksto sil barre? No, miskien sille 80-90% fan ûntwikkelders har software as mooglik oerskriuwe. Mei oare wurden, 10-20% fan 'e brûkersbasis giet automatysk nei guon konkurrearjende taal, lykas Flutter.
Doch dit meardere kearen en jo sille de helte fan jo brûkersbasis ferlieze. Krekt as yn de sport is yn de wrâld fan programmearring ek de hjoeddeiske foarm fan belang. alles. Elkenien dy't de helte fan har brûkers yn fiif jier ferliest, wurdt beskôge as in Big Fat Loser. Jo moatte trendy wêze yn 'e wrâld fan platfoarms. Mar dit is wêr't it net stypjen fan âldere ferzjes jo oer de tiid ferneatigje. Om't elke kear as jo guon ûntwikkelders kwytreitsje, (a) ferlieze jo se foar altyd om't se lilk binne op jo foar it brekken fan it kontrakt, en (b) jouwe se fuort oan jo konkurrinten.
Iroanysk, ik holp Google ek sa'n prima donna te wurden dy't efterútkompatibiliteit negeart doe't ik Grok makke, in boarnekoade-analyze- en begrypsysteem dat it maklik makket om de koade sels te automatisearjen en te ynstrumintearjen - fergelykber mei in IDE, mar hjir bewarret de wolktsjinst materialisearre foarstellings fan alle miljarden rigels fan Google boarnekoade yn in grut data warehouse.
Grok joech Googlers in krêftich ramt foar it útfieren fan automatisearre refactorings oer har heule koadebase (letterlik troch Google). It systeem berekkent net allinnich jo upstream ôfhinklikens (dêr't jo ôfhinklik binne), mar ek delgeande (dy't oan jo binne), dus as jo API's feroarje, kenne jo elkenien dy't jo brekke! Op dizze manier, as jo wizigingen meitsje, kinne jo ferifiearje dat elke konsumint fan jo API hat bywurke nei de nije ferzje, en yn werklikheid, faaks mei it Rosie-ark dat se skreaun hawwe, kinne jo it proses folslein automatisearje.
Hjirmei kin de koadebasis fan Google yntern hast boppenatuerlik skjin wêze, om't se dizze robotyske tsjinstfeinten om it hûs hinne rinne en alles automatysk skjinmeitsje as se SomeDespicablyLongFunctionName omdoopt hawwe nei SomeDespicablyLongMethodName, om't immen besleat dat it in ûnsjoch pakesizzer wie en syn behoeften yn 'e sliep brocht wurde.
En earlik sein, it wurket aardich goed foar Google ... yntern. Ik bedoel, ja, de Go-mienskip by Google hat in goeie laitsje mei de Java-mienskip by Google fanwegen har gewoante fan trochgeande refactoring. As jo wat N kear op 'e nij begjinne, betsjut dat dat jo it net allinich N-1 kear hawwe geschroefd, mar nei in skoftke wurdt it frij dúdlik dat jo it wierskynlik ek op 'e N-de besykjen hawwe. Mar, yn 't algemien, bliuwe se boppe al dit gedoe en hâlde de koade "skjin".
It probleem begjint as se besykje dizze hâlding op te lizzen op har wolkkliïnten en brûkers fan oare API's.
Ik haw jo in bytsje yntrodusearre oan Emacs, Android en Java; lit ús sjen nei it lêste súksesfolle platfoarm mei lang libben: it web sels. Kinne jo jo yntinke hoefolle iteraasjes HTTP sûnt 1995 trochmakke is doe't wy flitsende tags brûkten? en "Under Construction" ikoanen op websiden.
Mar it wurket noch! En dizze siden wurkje noch! Ja, jonges, browsers binne de wrâldkampioenen yn efterkompatibiliteit. Chrome is in oar foarbyld fan it seldsume Google-platfoarm dat har koppen korrekt hat geschroefd, en lykas jo miskien hawwe rieden, wurket Chrome effektyf as in sânboxbedriuw apart fan 'e rest fan Google.
Ik wol ek ús freonen yn 'e bestjoeringssysteemûntwikkelders betankje: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, ensfh., foar it dwaan fan sa'n geweldige baan fan efterútkompatibiliteit op har suksesfolle platfoarms (Apple krijt op syn bêst in C mei The neidiel is dat se alles altyd brekke sûnder goede reden, mar op ien of oare manier komt de mienskip der omhinne mei elke release, en OS X-konteners binne noch net folslein ferâldere ... noch).
Mar wachtsje, sizze jo. Fergelykje wy appels net mei sinaasappels - standalone softwaresystemen op ien masine lykas Emacs/JDK/Android/Chrome fersus multi-serversystemen en API's lykas wolktsjinsten?
No ja, hjir twittere ik juster oer, mar yn de styl fan Larry Wall (makker fan de programmeartaal Perl - ca. per.) op it prinsipe fan "sûget/regels" socht ik it wurd op ferwurde op 'e Google- en Amazon-ûntwikkelderssiden. En hoewol AWS hat hûnderten kear mear tsjinstoanbod dan GCP, Google's ûntwikkeldersdokumintaasje neamt ôfskriuwing sawat sân kear faker.
As immen by Google dit lêst, binne se wierskynlik ree om diagrammen yn 'e Donald Trump-styl út te lûken dy't sjen litte dat se eins alles goed dogge, en dat ik gjin ûnearlike fergelikingen moat meitsje lykas "oantal fermeldings fan it wurd ferâldere fersus oantal tsjinsten" "
Mar nei al dizze jierren is Google Cloud noch altyd de tsjinst nûmer 3 (ik haw noait in artikel skreaun oer it mislearre besykjen om nûmer 2 te wurden), mar as ynsiders te leauwen binne, binne d'r wat soargen dat se gau nei falle kinne. Nûmer 4.
Ik haw gjin twingende arguminten om myn proefskrift te "bewizen". Alles wat ik haw binne de kleurige foarbylden dy't ik mear as 30 jier haw sammele as ûntwikkelder. Ik haw al neamd de djip filosofyske aard fan dit probleem; op guon manieren wurdt it politisearre yn ûntwikkeldersmienskippen. Guon leauwe dat skeppers platfoarms moatte soargje foar kompatibiliteit, wylst oaren tinke dat dit in soarch is brûkers (de ûntwikkelders sels). Ien fan de twa. Ja, is it net in polityk probleem as wy beslute wa't de kosten fan mienskiplike problemen drage moat?
Dat is dus polityk. En der sille nei alle gedachten lilke reaksjes op myn taspraak.
Hoe brûker Google Cloud Platform, en as in AWS-brûker foar twa jier (wylst wurkje foar Grab), kin ik sizze dat d'r in enoarm ferskil is tusken Amazon en Google's filosofyen as it giet om prioriteiten. Ik ûntwikkelje net aktyf op AWS, dus ik wit net sa goed hoe faak se âlde API's fuortsmite. Mar der is in fermoeden dat dit net sa faak bart as by Google. En ik leau wirklik dat dizze boarne fan konstante kontroversje en frustraasje yn GCP ien fan 'e grutste faktoaren is dy't de ûntwikkeling fan it platfoarm tsjinhâlde.
Ik wit dat ik gjin spesifike foarbylden neamde fan GCP-systemen dy't net mear wurde stipe. Ik kin sizze dat hast alles wat ik haw brûkt, fan netwurken (fan de âldste oant VPC) oant opslach (Cloud SQL v1-v2), Firebase (no Firestore mei in folslein oare API), App Engine (lite wy net iens begjinne) , Cloud Endpoints Cloud Endpoint en oant... Ik wit it net - absolút dit alles twongen jo om de koade nei in maksimum fan 2-3 jier oer te skriuwen, en se automatisearre de migraasje noait foar jo, en faaks . As soe it sa wêze moatten.
En elke kear as ik nei AWS sjoch, freegje ik mysels ôf wêrom't ik yn 'e hel noch op GCP bin. Se hawwe dúdlik gjin kliïnten nedich. Se hawwe nedich покупатели. Begripe jo it ferskil? Lit my it útlizze.
Google Cloud hat , wêr't minsken har software-oplossings foarstelle, en om it lege restaurant-effekt te foarkommen, moasten se it mei guon foarstellen folje, sadat se kontrakteare mei in bedriuw mei de namme Bitnami om in bosk oplossingen te meitsjen dy't wurde ynset mei "ien klik", of moatte Ik skriuw it sels "oplossingen", om't dizze gjin ferdomde ding oplosse. Se besteane gewoan as karfakjes, as marketingfiller, en Google hat it noait skele oft ien fan 'e ark eins wurket. Ik ken produktbehearders dy't yn 'e sjauffeursstoel west hawwe, en ik kin jo fersekerje dat dizze minsken it net skele.
Nim, bygelyks, in saneamde "ien-klik" ynset oplossing. . Ik wie siik ta dea fan Google Cloud SQL shenanigans, dus ik begon te sjen nei it bouwen fan myn eigen Percona-kluster as alternatyf. En dizze kear like Google in goed wurk dien te hawwen, se soene my wat tiid en muoite besparje mei de klik op in knop!
Geweldich, litte wy gean. Litte wy de keppeling folgje en klikje op dizze knop. Selektearje "Ja" om yn te stimmen mei alle standertynstellingen en ynsette it kluster yn jo Google-wolkprojekt. Haha, it wurket net. Gjin fan dizze crap wurket. It ark waard nea hifke en it begon te rotten fan 'e earste minút, en it soe my net fernuverje as mear as de helte fan' e "oplossings" ien-klik-ynset binne (no begripe wy wêrom de quotes) yn algemien wurket net. Dit is perfoarst hopeleaze tsjuster, wêr't it better is net yn te gean.
Mar Google hat gelyk stimulearret jo om se te brûken. Se wolle dat jo kocht. Foar harren is it in transaksje. Se wolle neat stypje. It is gjin diel fan Google's DNA. Ja, yngenieurs stypje inoar, sa docht bliken út myn ferhaal mei Bigtable. Mar yn produkten en tsjinsten foar gewoane minsken se altyd wiene ûnferbidlik yn , dy't net foldocht oan 'e bar foar profitabiliteit sels as it miljoenen brûkers hat.
En dit presintearret in echte útdaging foar GCP, om't dit it DNA is efter alle wolkoffers. Se besykje neat te stypjen; It is bekend dat se wegerje om software fan tredden te hostjen (as in beheare tsjinst). oant, oant AWS docht itselde en bout in súksesfol bedriuw om it, en as klanten letterlik easkje itselde. It duorret lykwols wat muoite om Google wat te stypjen.
Dit gebrek oan stipekultuer, keppele mei de mentaliteit "litte wy it brekke om it moaier te meitsjen", ferfrjemde ûntwikkelders.
En dat is net in goede saak as jo in platfoarm bouwe wolle mei in lange libbensdoer.
Google, wekker wurde, ferdomme. It is no 2020. Jo ferlieze noch. It is tiid om in hurde blik yn 'e spegel te nimmen en te beantwurdzjen oft jo wirklik yn' e wolkbedriuw wolle bliuwe.
As jo dan bliuwe wolle stopje alles te brekken. Jonges, jim binne ryk. Wy ûntwikkelders net. Dus as it giet om wa't de lêst fan kompatibiliteit sil drage, moatte jo it op josels nimme. Net foar ús.
Want der binne noch wol trije echt goede wolken. Se winkje.
En no sil ik trochgean om al myn brutsen systemen te reparearjen. Eh.
Oant de oare kear!
PS Update nei it lêzen fan guon fan 'e diskusjes oer dit artikel (de diskusjes binne geweldich, btw). Firebase-stipe is net stopset en d'r binne gjin plannen wêrfan ik my bewust bin. Se hawwe lykwols in ferfelende streaming-bug dy't feroarsaket dat de Java-kliïnt yn App Engine stoppet. Ien fan har yngenieurs holp my dit probleem op te lossen, doe't ik by Google wurke. En sa is it al fjouwer jier! Se hawwe no Firestore. It sil in protte wurk nimme om der nei te migrearjen, om't it in folslein oar systeem is en de Firebase-bug sil nea wurde reparearre. Hokker konklúzje kin lutsen wurde? Jo kinne help krije as jo wurkje yn in bedriuw. Ik bin wierskynlik de iennichste dy't Firebase op GAE brûkt, om't ik minder dan 100 kaaien oanmelde yn in 100% native app en it stopet mei wurkjen elke pear dagen fanwegen in bekende bug. Wat kin ik oars sizze as it op jo eigen risiko brûke. Ik gean oer nei Redis.
Ik haw ek wat mear erfarne AWS-brûkers sjoen sizze dat AWS normaal noait ophâldt mei it stypjen fan tsjinsten, en SimpleDB is in geweldich foarbyld. Myn oannames dat AWS net itselde ein fan stipesykte hat as Google liket te rjochtfeardigjen.
Derneist merkte ik op dat 20 dagen lyn it Google App Engine-team de hosting fan in krityske Go-bibleteek bruts, en in GAE-applikaasje fan ien fan 'e kearn Go-ûntwikkelders ôfslute. It wie echt dom.
Uteinlik haw ik Googlers al heard oer dit probleem en oer it algemien mei my iens (hâld fan jim!). Mar se lykje te tinken dat it probleem ûnoplosber is, om't de kultuer fan Google noait de juste stimulânsstruktuer hie. Ik tocht dat it goed wêze soe om wat tiid te nimmen om de absolút geweldige ûnderfining te besprekken dy't ik wurke mei AWS-yngenieurs wylst ik by Grab wurke. Ienris yn 'e takomst, hoopje ik!
En ja, yn 2005 hiene se ferskate soarten haai fleis op it reus buffet yn gebou 43, en myn favoryt wie it hammerhead shark fleis. Lykwols, yn 2006, Larry en Sergei kwytrekke fan alle ûnsûne snacks. Dus tidens it Bigtable-ferhaal yn 2007 wiene d'r echt gjin haaien en ik ferrifele dy.
Doe't ik fjouwer jier lyn nei wolk Bigtable seach (jouwe of nimme), dit is wêr't de kosten wiene. It liket no in bytsje sakke te wêzen, mar dat is noch altyd in soad foar in leech datapakhús, foaral om't myn earste ferhaal lit sjen hoe ûngemaklik in lege grutte tafel is op har skaal.
Sorry foar it misledigjen fan de Apple-mienskip en net sizze neat moais oer Microsoft ensfh Jo binne goed, ik wurdearje echt alle diskusje dit artikel hat generearre! Mar soms moatte jo in bytsje weagen meitsje om in diskusje te begjinnen, witsto?
Tank foar it lêzen.
Update 2, 19.08.2020/XNUMX/XNUMX. Streep !
Update 3/31.08.2020/2. Ik waard kontakt opnommen troch in Google-yngenieur by Cloud Marketplace dy't in âlde freon fan my bliek te wêzen. Hy woe útfine wêrom't C2D wurke net, en wy úteinlik betocht dat it wie omdat ik hie boud myn netwurk jierren lyn, en CXNUMXD wurke net op legacy netwurken omdat de subnet parameter wie mist yn harren sjabloanen. Ik tink dat it it bêste is foar potensjele GCP-brûkers om te soargjen dat se genôch yngenieurs by Google kenne ...
Boarne: www.habr.com