Google madarikatua, ez nuen berriro blogik egin nahi. Asko daukat egiteko. Blogak denbora, energia eta sormena eskatzen ditu, eta hori ondo aprobetxa nezake: nire liburuak, , nire jokoa eta abar. Baina nahikoa haserretu nauzu hau idatzi behar dudalako.
Beraz, amaitu dezagun hau.
Ea Google-n lanean hasi nintzeneko istorio labur baina hezigarri batekin hasteko. Badakit azkenaldian Google-ri buruz gauza txar asko esaten ari naizela, baina atsekabetzen nau nire enpresak aldizka negozio-erabaki ezgaiak hartzen dituenean. Horrekin batera, dagokiona eman behar diogu: Googleren barne azpiegitura benetan apartekoa da, gaur egun hoberik ez dagoela esan daiteke. Google-ren sortzaileak ni izango naizen baino askoz ingeniari hobeak izan ziren, eta istorio honek egia hori berresten du.
Lehenik eta behin, aurrekari txiki bat: Google-k datuak biltegiratzeko teknologia bat du . Lorpen tekniko nabarmena izan zen, lehen (lehena ez bada) gako-balioen biltegia (K/V) "infinituki eskalagarria" bat: funtsean NoSQLren hasiera. Egunotan Bigtablek ondo funtzionatzen du K/V biltegiratze espazio nahiko jendetsuan, baina garai hartan (2005) izugarri polita zen.
Bigtableri buruzko gauza dibertigarri bat zera da: tableta zerbitzariak izeneko barne kontrol-planoko objektuak zituztela (inplementazioaren zati gisa), indize handiekin, eta noizbait sistema eskalatzerakoan botila-lepo bihurtu zirela. Bigtableko ingeniariak eskalagarritasuna nola inplementatu galdetzen ari ziren, eta bat-batean konturatu ziren tablet-zerbitzariak beste Bigtable biltegiratze batzuekin ordezka zitezkeela. Beraz, Bigtable Bigtable ezarpenaren parte da. Biltegiratze horiek maila guztietan daude.
Beste xehetasun interesgarri bat da denbora batez Bigtable ezaguna eta nonahikoa izan zela Google-n, talde bakoitzak bere biltegi bat zuela. Beraz, ostiraleko bileretako batean, Larry Pagek kasualitatez galdetu zuen: βZergatik dugu Bigtable bat baino gehiago? Zergatik ez bakarra?" Teorian, biltegiratze bakarra nahikoa izan beharko litzateke Google-ren biltegiratze-behar guztietarako. Jakina, ez ziren inoiz bakar batera joan garapen arrazoi praktikoengatik (balizko porrot baten ondorioengatik, esaterako), baina teoria interesgarria zen. Unibertso osorako biltegi bat (Bide batez, inork ba al daki Amazonek bere Sablerekin hau egin zuen?)
Dena den, hona hemen nire istorioa.
Garai hartan, bi urte pasatxo zeramatzan Googlen lanean, eta egun batean, Bigtableko ingeniaritza taldearen mezu elektroniko bat jaso nuen, honela zebilena:
Steve maitea,
Kaixo Bigtable taldearen partetik. Jakinarazi nahi dizugu [datu-zentroaren izena]-n oso-oso zaharra den Bigtable bitar bat erabiltzen ari zarela. Bertsio hau jada ez da onartzen eta azken bertsiora eguneratzen lagundu nahi dizugu.
Mesedez, esan iezadazu gai honi buruz elkarrekin lan egiteko denboraren bat antolatu dezakezun.
Onena,
Bigtable taldea
Googlen posta asko jasotzen duzu, beraz, lehen begiratuan honelako zerbait irakurri dut:
Hartzaile agurgarria,
Kaixo talde batzuen partetik. Hori helarazi nahi dugu bla bla bla bla bla. Bla bla bla bla bla bla, eta bla bla bla berehala.
Mesedez, jakinarazi iezaguzu zure denbora preziatua planifika dezakezun bla bla bla.
Onena,
Agindu moduko bat
Ia berehala ezabatu nuen, baina nire kontzientziaren ertzean sentsazio mingarri eta nazkagarri bat sentitu nuen. ez benetan gutun formal bat dirudi, baina jakina, hartzailea oker zegoela Bigtable ez nuelako erabili.
Baina arraroa zen.
Egun osoa txandaka lanean eta zer marrazo-haragia probatu mikro-sukaldean pentsatzen eman nuen, horietatik hiru gutxienez gertu zeuden nire eserlekutik gaileta ondo zuzenduta jotzeko, baina idaztea pentsatzeak ez dit inoiz gero eta handiagoa den antsietate sentimendurik utzi.
Argi esan zuten nire izena. Eta posta elektronikoa nire helbide elektronikora bidali zen, ez beste norbaitena, eta ez da cc: edo bcc:. Tonua oso pertsonala eta argia da. Agian hau akatsen bat da?
Azkenik, jakin-minak mendean hartu ninduen eta aipatu zuten datu zentroko Borg kontsolara begiratzera joan nintzen.
Eta, jakina, BigTable biltegia kudeatzen nuen. Barkatu, zer? Bere edukiari begiratu nion, eta ba! 2005eko ekainean Googlen egin nuen lehen astean eserita egon nintzen Codelab inkubagailukoa zen. Codelab-ek Bigtable exekutatzera behartu zintuen balio batzuk idaztera han, eta itxuraz ez nuen inoiz biltegiratzea itxi ondoren. Bi urte baino gehiago pasa ziren arren lanean jarraitzen zuen.
Istorio honetan hainbat alderdi aipagarri daude. Lehenik eta behin, Bigtable-ren lana hain zen hutsala Google-ren eskalan, non bi urte beranduago inork biltegiratze gehigarriaz ohartu baitzen, eta bitarren bertsioa zaharkituta zegoelako bakarrik. Konparazio baterako, behin erabiltzea pentsatu nuen nire online jokorako. Garai hartan, zerbitzu honek urtean 16 $ gutxi gorabehera balio zuen. hustu Bigtable GCP-n. Ez dut esaten iruzur egiten dizutenik, baina nire iritzi pertsonalean, hori diru asko da putzu datu base huts baterako.
Beste alderdi aipagarri bat biltegiratzea da oraindik bi urteren ondoren lanean. WTF? Datu zentroak joan eta etorri; etenaldiak izaten dituzte, programatutako mantentze-lanak egiten dituzte, etengabe aldatzen dira. Hardwarea eguneratzen da, etengailuak trukatzen dira, dena etengabe hobetzen ari da. Nola demontre lortu zuten nire programa bi urtez martxan mantentzea aldaketa horiekin guztiekin? 2020an lorpen xumea dirudi, baina 2005-2007an nahiko ikusgarria izan zen.
Eta alderdirik zoragarriena da beste egoera batean kanpoko ingeniaritza talde bat hurbiltzen zaituela, Bigtable-ren instantzia txiki eta ia huts baten jabea, zeina zero trafikoa azken bi urteetan, eta eguneratzeko laguntza eskaintzen ari dira.
Eskerrak eman nizkion, biltegiratzea ezabatu nuen eta bizitzak ohi bezala jarraitu zuen. Baina hamahiru urte geroago, oraindik ere gutun horretan pentsatzen dut. Batzuetan Google Cloud-etik antzeko mezuak jasotzen ditudalako. Honela itxura dute:
Google Cloud erabiltzaile agurgarria,
Oroigarri gisa, [erabiltzen duzun ezinbesteko zerbitzua] zerbitzua etengo dugu 2020ko abuztutik aurrera, eta ondoren ezin izango dituzu zure instantziak berritu. Azken bertsiora eguneratzea gomendatzen dugu, beta proban dagoena, ez du dokumentaziorik, ez migrazio biderik eta aldez aurretik zaharkituta dago gure laguntzarekin.
Aldaketa honek Google Cloud plataformako erabiltzaile guztiengan eragin minimoa izan dezan bermatzeko konpromisoa hartu dugu.
Lagun onena betiko,
Google Cloud Platform
Baina ez ditut ia inoiz horrelako gutunak irakurtzen, haiek esaten dutena zera eta:
Hartzaile agurgarria,
Pikutara joan. Izorratu, izorratu, izorratu. Utzi egiten duzun guztia ez duelako axola. Garrantzitsuena gure denbora da. Denbora eta dirua alferrik galtzen dugu gure kaskarrak mantentzen eta nekatuta gaude, beraz, ez dugu gehiago onartzen. Beraz, utzi zure plan madarikatuak eta hasi gure dokumentazio kakatsuan arakatzen, foroetan txatarra eske, eta, bide batez, gure kaka berria antzinako kakatik guztiz ezberdina da, diseinu hau nahiko gaizki izorratu dugulako, je, baina hori da zurea. arazoa, ez gurea.
Ahaleginak egiten jarraitzen dugu urtebeteko epean zure garapen guztiak erabilezinak izan daitezen.
Izorratu mesedez
Google Cloud Platform
Eta kontua da hilabetean behin jasotzen ditudala halako gutunak. Hau maiz eta hain etengabe gertatzen da, ezinbestean urrundu ni GCPtik hodeien aurkako kanpamendura. Jada ez nago ados haien jabedun garapenen menpe egotea, izan ere, devopek errazagoa baita kode irekiko sistema bat makina birtual hutsean mantentzea Google-rekin produktu "zaharkituak" ixteko politikarekin jarraitzen saiatzea baino.
Google Cloud-era itzuli aurretik, nik hurbil ere ez Kritikatzeko amaitu gabe, ikus ditzagun konpainiaren jarduna beste zenbait arlotan. Google-ren ingeniariek beren software-ingeniaritza diziplinaz harro daude, eta hori da benetan arazoak sortzen dituena. Harrotasuna kontugabeentzat tranpa bat da, eta Google-ko langile asko pentsatzera eraman ditu bere erabakiak beti zuzenak direla eta zuzena izatea (definizio lauso lauso batzuen arabera) bezeroak zaintzea baino garrantzitsuagoa dela.
Google-tik kanpoko beste proiektu handi batzuetako ausazko adibide batzuk emango ditut, baina eredu hau nonahi ikustea espero dut. Honela da: Atzerako bateragarritasunak sistemak bizirik eta eguneratuta mantentzen ditu hamarkadetan zehar.
Atzerako bateragarritasuna diseinatutako sistema arrakastatsu guztien diseinu-helburua da open erabiltzea, hau da, kode irekiarekin eta/edo estandar irekiekin inplementatua. Denak ere deseroso daudela esaten ari naizela iruditzen zait, baina ez. Hau arazo politikoa da, beraz, adibideak behar dira.
Aukeratuko dudan lehen sistema zaharrena da: GNU Emacs, Windows Notepad, OS kernelaren eta Nazioarteko Espazio Estazioaren arteko hibrido modukoa dena. Zaila da azaltzea, baina laburbilduz, Emacs 1976an (bai, duela ia mende erdi) sorturiko plataforma bat da, zu produktiboagoa izan dadin programatzeko, baina testu-editore gisa mozorrotuta.
Emacs egunero erabiltzen dut. Bai, IntelliJ ere erabiltzen dut egunero, tresna-plataforma indartsua bihurtu da berez. Baina IntelliJ-rako luzapenak idaztea Emacs-erako luzapenak idaztea baino lan anbiziotsuagoa eta konplexuagoa da. Eta are garrantzitsuagoa dena, Emacs-erako idatzitako guztia gordetzen da betiko.
Oraindik 1995ean Emacs-erako idatzi nuen softwarea erabiltzen dut. Eta ziur nago norbait Emacserako idatzitako moduluak erabiltzen ari dela 80ko hamarkadaren erdialdean, lehenago ez bada. Baliteke noizean behin doikuntza pixka bat behar izatea, baina hori oso arraroa da. Ez dakit Emacserako idatzi dudan ezer (eta asko idatzi dut) ber-arkitektura bat behar duenik.
Emacs-ek make-obsolete izeneko funtzioa du zaharkitutako entitateentzat. Emacs-en oinarrizko ordenagailu-kontzeptuetarako terminologia (adibidez, "leihoa" zer den) askotan industria-konbentzioetatik desberdina da, Emacsek aspaldi aurkeztu zituelako. Arrisku arrunta da garaia aurreratu dutenentzat: zure baldintza guztiak okerrak dira. Baina Emacsek badu zaharkitze-kontzeptu bat, bere jergoan deitzen dena zaharkitzea.
Baina Emacs munduan badirudi beste lan definizio bat dagoela. Azpiko beste filosofia bat, nahi baduzu.
Emacs-en munduan (eta behean landuko ditugun beste hainbat arlotan), zaharkitutako APIaren egoerak hauxe esan nahi du funtsean: "Ez zenuke planteamendu hau erabili behar, funtzionatzen duen bitartean, hainbat gabezia dituelako. zerrenda hemen. Baina azkenean, zure aukera da".
Google-ren munduan, zaharkituta egoteak esan nahi du "zurekin dugun konpromisoa urratzen ari gara". Hau egia da. Hau da funtsean esan nahi duena. Horrek esan nahi du behartuko zaituztela aldizka lan batzuk egin, lan asko akaso, haietan sinestea zigor gisa : Software onena dugu. Azkarrena! Dena argibideen arabera egiten duzu, zure aplikazioa edo zerbitzua abiarazi eta gero bam, urtebete edo bi igaro ondoren apurtzen da.
1500 km egin ondoren behin betiko matxuratuko den auto erabili bat saltzea bezala da.
Hauek "zaharkitzearen" bi definizio filosofiko guztiz desberdinak dira. Google-ren usaimenaren definizioa . Ez dut hau sinesten Izan ere zaharkitze planifikatua Appleren zentzu berean. Baina, zalantzarik gabe, zure programak hausteko asmoa du Googlek, modu biribil batean. Badakit hori han 12 urte baino gehiagoz software ingeniari gisa lan egin nuelako. Barne jarraibide lausoak dituzte zenbateko atzerako bateragarritasuna jarraitu behar den, baina azken finean talde edo zerbitzu bakoitzaren esku dago. Ez dago enpresa edo ingeniaritza-mailako gomendiorik, eta zaharkitze-zikloei dagokienez gomendiorik ausartena "saia zaitez bezeroei 6-12 hilabete berritzeko sistema osoa apurtu aurretik ematen".
Arazoa uste baino askoz handiagoa da, eta datozen urteetan iraungo du, bezeroen arreta ez dagoelako euren DNAn. Honi buruz gehiago behean.
Puntu honetan, Emacs-ek neurri handi batean eta berdintsu arrakasta duela dioen adierazpen ausarta egingo dut gehienbat atzerako bateragarritasuna oso serio hartzen dutelako. Egia esan, hau da gure artikuluaren tesia. Iraupen luzeko sistema ireki arrakastatsuek beren arrakasta hamarkadetan zehar haien inguruan bizi izan diren mikrokomunitateei zor die. luzapenak/pluginak. Hau da ekosistema. Dagoeneko hitz egin dut plataformen izaeraz eta zein garrantzitsuak diren, eta nola Google-k ez du inoiz ulertu bere historia korporatibo osoan zer gertatzen den Android edo Chrometik kanpo plataforma ireki arrakastatsu bat sortzean.
Egia esan, Android laburki aipatu beharko nuke, ziurrenik pentsatzen ari zarelako.
Lehenik eta behin, Android ez da Google. Ez dute ia ezer komunean elkarren artean. Android 2005eko uztailean Google-k erosi zuen enpresa bat da, konpainiari gutxi gorabehera modu autonomoan jarduteko baimena eman zion eta, hain zuzen ere, neurri handi batean ukitu gabe geratu da tarteko urteetan. Android pila teknologiko entzutetsua da eta erakunde bitxi bezain ezaguna da. Googler batek esan zuenez, "Ezin duzu Android-en sartu besterik ez".
Aurreko artikulu batean, Androiden diseinuaren hasierako erabaki batzuk zein txarrak izan ziren eztabaidatu nuen. Arraioa, artikulu hori idatzi nuenean "berehalako aplikazioak" izeneko kaskarrak kaleratzen ari ziren eta orain (sorpresa!) , eta onartzen dut Google-ri entzuteko eta zure edukia berehalako aplikazio hauetara eramateko ergelak izan bazinete.
Baina hemen ezberdintasun bat dago, alde nabarmena, hau da, Android-eko jendeak benetan ulertzen duela plataformak zein garrantzitsuak diren, ahal duten guztia saiatzen dela Android-eko aplikazio zaharrak funtzionatzen jarraitzeko. Izan ere, atzerako bateragarritasuna mantentzeko egiten dituzten ahaleginak hain dira muturrekoak, non ni ere, duela urte batzuk Android dibisioan egin nuen denboraldi laburrean, gailu eta API zaharrenetako batzuen laguntza kentzeko konbentzitzen saiatzen nintzen (oker nengoen. , iraganeko eta oraingo beste gauza askotan bezala. Barkatu Android mutilak! Orain Indonesian egon naizenez, ulertzen dut zergatik behar ditugun).
Android-ek atzerantz bateragarritasuna ia imajinaezineko muturretara bultzatzen du, ondare-zor tekniko handia pilatuz beren sistemetan eta tresna-kateetan. Ai ene jainkoa, ikusi beharko zenuke beren eraikuntza-sisteman egin behar dituzten gauza zoro batzuk, guztiak bateragarritasunaren izenean.
Horregatik, "Zu ez zara Google" sari preziatua ematen diot Androidi. Benetan ez dute Google bihurtu nahi, ez daki plataforma iraunkorrak sortzen, Android baizik He daki, nola egin. Beraz, Google oso adimentsu ari da alderdi batean: jendeari Android-en gauzak bere erara egiteko aukera ematea.
Hala ere, Androiderako berehalako aplikazioak nahiko ideia ergelak ziren. Eta ba al dakizu zergatik? eskatzen zutelako berridatzi eta birdiseinatu zure aplikazioa! Jendeak bi milioi aplikazio berridatziko balu bezala da. Instant Apps Googler batzuen ideia izan zela uste dut.
Baina badago aldea. Atzerako bateragarritasuna kostu handia dakar. Androidek berak bere gain hartzen du kostu horien zama, eta Googlek, berriz, zama bere gain hartu behar duela zu zara, bezero ordaintzailea.
Android-ek atzerako bateragarritasunarekin duen konpromisoa ikus dezakezu bere APIetan. Lauzpabost azpisistema desberdin literalki gauza bera egiten dituzunean, oinarrian atzerako bateragarritasunaren aldeko konpromisoa dagoela seinale segurua da. Plataformen munduan zure bezeroekiko eta zure merkatuarekiko konpromisoaren sinonimoa dena.
Google-ren arazo nagusia hemen bere ingeniaritza-higienearekiko harrotasuna da. Ez zaie gustatzen gauza bera egiteko modu ezberdin asko daudenean, modu zaharrak, ez hain desiragarriak, modu berri eta dotoreen ondoan eserita. Sisteman berri direnentzat ikaskuntza-kurba areagotzen du, ondare APIak mantentzearen zama areagotzen du, funtzio berrien abiadura moteltzen du eta pekatu nagusia ez da polita. Google - Tim Burtonen Alice in Wonderland filmeko Lady Ascot bezala:
Lady Ascot:
- Alice, ba al dakizu zerri beldurra dudan gehien?
- Aristokraziaren gainbehera?
- Izango nuen beldur nintzen biloba itsusiak.
Ederren eta praktikoaren arteko trukea ulertzeko, ikus diezaiogun hirugarren plataforma arrakastatsuari (Emacs eta Androiden ondoren) eta ikus dezagun nola funtzionatzen duen: Java bera.
Java-k API zaharkitu asko ditu. Zaharkitzea oso ezaguna da Java programatzaileen artean, are ezagunagoa programazio-lengoaia gehienetan baino. Java bera, oinarrizko lengoaia eta liburutegiak etengabe zaharkitzen ari dira APIak.
Milaka adibideetako bat bakarrik hartzeko, zaharkitutzat jotzen da. 1.2ko abenduan Java 1998 kaleratu zenetik zaharkituta dago. 22 urte igaro dira hau zaharkituta geratu zenetik.
Baina nire benetako kodea produkzioan oraindik hariak hiltzen ari da egunero. Benetan uste duzu hori ona dela? Erabat! Esan nahi dut, noski, gaur kodea berridatziko banu, beste modu batera ezarriko nuke. Baina nire jokoaren kodea, azken bi hamarkadetan ehunka milaka pertsona zoriontsu egin dituena, luzeegi zintzilik dauden hariak ixteko funtzio batekin idatzita dago, eta nik inoiz aldatu behar izan. Nire sistema inork baino hobeto ezagutzen dut, 25 urteko esperientzia dut literalki produkzioan lanean, eta ziur esan dezaket: nire kasuan, langileen hari zehatz hauek ixtea guztiz da. kaltegabea. Ez du merezi kode hau berridazteko denbora eta ahaleginak, eta eskerrak eman Larry Ellisoni (ziurrenik) Oracle-k ez ninduela behartu berriro idaztera.
Oracle-k seguruenik plataformak ere ulertzen ditu. Nork daki.
Ebidentzia oinarrizko Java APIetan aurki daiteke, zaharkitze-uhinez josita daudenak, arroil bateko glaziar baten lerroak bezala. Erraz aurki ditzakezu bost edo sei teklatu-nabigazio-kudeatzaile (KeyboardFocusManager) Java Swing liburutegian. Egia esan, zaila da zaharkituta ez dagoen Java API bat aurkitzea. Baina oraindik funtzionatzen dute! Uste dut Java taldeak API bat benetan kenduko duela interfazeak segurtasun arazo nabarmena badu.
Hona hemen gauza, lagunok: software garatzaileok oso lanpetuta gaude, eta softwarearen arlo guztietan alternatiba lehiakorren aurrean gaude. Une bakoitzean, X hizkuntzako programatzaileek Y hizkuntza ordezko posibletzat hartzen dute. Ai, ez didazu sinesten? Swift deitu nahi al diozu? Esaterako, denak Swift-era migratzen ari dira eta inork ez du abandonatzen, ezta? Aupa, zein gutxi dakizun. Enpresek mugikorren garapen talde bikoitzen kostuak zenbatzen ari dira (iOS eta Android), eta konturatzen hasi dira Flutter eta React Native bezalako izen dibertigarriak dituzten plataforma anitzeko garapen sistema horiek benetan funtzionatzen dutela eta haien tamaina murrizteko erabil daitezkeela. talde mugikorrak bi aldiz edo, alderantziz, bi aldiz produktiboagoak izatea. Benetako dirua dago jokoan. Bai, badaude konpromisoak, baina, bestetik, dirua.
Demagun hipotetikoki Applek Guido van Rossum-en seinalea hartu zuela eta Swift 6.0 atzerantz bateraezina dela Swift 5.0-rekin, Python 3 Python 2-rekin bateraezina den bezala.
Seguruenik, duela hamar bat urte kontatu nuen istorio hau, baina duela hamabost bat urte O'Reilly's Foo Camp-era joan nintzen Guidorekin, kanpin-denda batean eserita Paul Graham-ekin eta jaurtitzaile pila bat. Bero itogarrian eserita egon ginen Larry Pagek bere helikoptero pertsonalean hegan egiteko zain, Guidok "Python 3000"-ri buruz drona egiten zuen bitartean, denek hara migratzeko behar izango zituzten urte kopuruaren arabera izendatu zuen. Guk etengabe galdetzen genion zergatik hausten zuen bateragarritasuna, eta erantzun zigun: "Unicode". Eta galdetu genuen, gure kodea berridatzi beharko bagenu, zein beste onura ikusiko genituzke? Eta hark erantzun zuen: "Yoooooooooooooooooooooooooooooooooooooooooo".
Google Cloud Platform SDK ("gcloud") instalatzen baduzu, jakinarazpen hau jasoko duzu:
Hartzaile agurgarria,
Gogorarazi nahi dizugu Python 2rako euskarria zaharkituta dagoela, beraz, izorratu
β¦ eta abar. Bizitzaren zirkulua.
Baina kontua da garatzaile bakoitzak aukera bat duela. Eta kodea nahikoa maiz berridaztera behartzen badituzu, baliteke pentsatzea beste aukerak. Ez dira zure bahituak, nahi dituzunak izan daitezen. Zure gonbidatuak dira. Python programazio-lengoaia oso ezaguna da oraindik, baina alajaina, Python 3(000)-k halako nahaspila sortu zuen bere baitan, bere komunitateetan eta bere komunitateetako erabiltzaileen artean, ondorioak hamabost urtez argitu gabe egon direla.
Zenbat Python programa berridatzi dira Go-n (edo Ruby-n edo beste alternatibaren batean) atzerako bateraezintasun hori dela eta? Zenbat software berri idatzi den Python ez den beste zerbaitetan, nahiz eta izan liteke Pythonez idatzia, Guidok herri osoa erre ez balu? Zaila da esatea, baina Pythonek argi eta garbi sufritu du. Nahaspila handia da eta denek galtzen dute.
Beraz, demagun Applek Guido-ren seinale bat hartzen duela eta bateragarritasuna hausten duela. Zer uste duzu gertatuko dela gero? Beno, agian garatzaileen % 80-90ek beren softwarea berridatziko dute ahal izanez gero. Beste era batera esanda, erabiltzaile-basearen % 10-20 automatikoki lehiakide diren hizkuntza batera doa, Flutter adibidez.
Egin hau hainbat aldiz eta zure erabiltzaile-basearen erdia galduko duzu. Kiroletan bezala, programazioaren munduan ere gaur egungo formak garrantzia du. Π²ΡΡ. Bost urtean erabiltzaileen erdia galtzen duen edonork Big Fat Losertzat hartuko da. Modan egon behar zara plataformen munduan. Baina hemen bertsio zaharragoak ez onartzeak denborarekin hondatuko zaitu. Garatzaile batzuk kentzen dituzun bakoitzean (a) betiko galtzen dituzu kontratua hausteagatik haserre daudelako, eta (b) zure lehiakideei oparitu.
Ironikoki, Google-ri ere lagundu nion atzerantz bateragarritasuna alde batera uzten duen prima donna bihurtzen Grok sortu nuenean, iturburu-kodea aztertzeko eta ulertzeko sistema bat, kodea bera automatizatzea eta instrumentatzea errazten duena - IDE baten antzekoa, baina hemen hodeiko zerbitzuak gordetzen ditu. Google iturburu-kodearen milaka milioi lerroen irudikapenak gauzatu zituen datu biltegi handi batean.
Grok-ek Google-koei marko indartsu bat eskaini zien beren kode-base osoan birfaktorizazio automatizatuak egiteko (literalki Google osoan). Sistemak zure upstream mendekotasunak ez ezik (hori menpeko zaren), baita ere kalkulatzen ditu jaisten (zure esku dago), beraz, APIak aldatzen dituzunean apurtzen ari zaren guztiak ezagutzen dituzu! Horrela, aldaketak egiten dituzunean, zure APIaren kontsumitzaile guztiak bertsio berrira eguneratu direla egiaztatu dezakezu eta, egia esan, askotan idatzi duten Rosie tresnarekin, prozesua guztiz automatizatu dezakezu.
Honi esker, Google-ren kode-basea barrutik ia naturaz gaindiko garbia izan daiteke, zerbitzari robotiko hauek etxetik bueltaka dabiltza eta dena automatikoki garbitzen dute SomeDespicablyLongFunctionName SomeDespicablyLongMethodName izena jarriz gero, norbaitek biloba itsusi bat zela eta bere lotan jarri behar zuela erabaki zuelako.
Eta egia esan, Google-ri nahiko ondo funtzionatzen du... barnean. Esan nahi dut, bai, Google-ko Go komunitateak barre ona egiten duela Google-ko Java komunitatearekin, etengabe birfaktorizatzeko ohitura dutelako. Zerbait N aldiz berrabiarazten baduzu, horrek esan nahi du N-1 aldiz izorratu ez duzula bakarrik, baina pixka bat igaro ondoren nahiko argi geratzen da ziurrenik N. saiakeran ere izorratu duzula. Baina, oro har, zalaparta honen gainetik jarraitzen dute eta kodea "garbi" mantentzen dute.
Arazoa hodeiko bezeroei eta beste API batzuen erabiltzaileei jarrera hori inposatzen saiatzen direnean hasten da.
Emacs, Android eta Java apur bat aurkeztu dizkizut; ikus ditzagun iraupen luzeko azken plataforma arrakastatsua: Weba bera. Imajinatzen al duzu zenbat iterazio egin dituen HTTP-k 1995etik etiketa keinukariak erabili genituenetik? eta "Eraikitzen" ikonoak web orrietan.
Baina oraindik funtzionatzen du! Eta orri hauek lanean jarraitzen dute! Bai, mutilak, nabigatzaileak dira atzerako bateragarritasunean munduko txapeldunak. Chrome buruak behar bezala izorratuta dituen Google plataforma arraroaren beste adibide bat da, eta igarri zenezakeen bezala, Chrome-k Google-ren gainontzeko enpresatik bereizita dagoen sandbox gisa funtzionatzen du.
Eskerrak eman nahi dizkiet sistema eragileetako garatzaileetako gure lagunei: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etab., beren plataforma arrakastatsuetan atzerako bateragarritasun lan bikaina egiteagatik (Apple-k C bat lortzen du, onenean, The-rekin). alde txarra da denbora guztian dena apurtzen dutela arrazoirik gabe, baina nolabait komunitateak kaleratze bakoitzean inguratzen du, eta OS X edukiontziak oraindik ez daude guztiz zaharkituta... oraindik).
Baina itxaron, diozu. Ez al gara sagarrak laranjarekin alderatzen - Emacs/JDK/Android/Chrome bezalako software sistema autonomoak makina bakarrean zerbitzari anitzeko sistemak eta hodeiko zerbitzuak bezalako APIak?
Tira, atzo txiokatu nuen honi buruz, baina Larry Wall-en estiloan (Perl programazio-lengoaiaren sortzailea - gutxi gorabehera) "sucks/arauak" printzipioaren arabera bilatu nuen hitza. zaharkitua Google eta Amazon garatzaileen guneetan. Eta AWSk badu ere ehunka GCP baino zerbitzu-eskaintza bider gehiago, Google-ren garatzaileen dokumentazioan zaharkitzea zazpi aldiz gehiagotan aipatzen da.
Google-n inor hau irakurtzen ari bada, ziurrenik prest egongo da Donald Trumpen estiloko taulak ateratzeko, benetan dena ondo egiten ari dela erakusten dutenak, eta ez nukeela konparazio bidegaberik egin behar "zaharkitutako hitzaren aipamen kopuruaren kontrako". zerbitzu kopurua" "
Baina urte guzti hauen ondoren, Google Cloud oraindik 3. zenbakia da zerbitzua (inoiz ez nuen artikulurik idatzi 2. zenbakia izateko saiakera hutsari buruz), baina barrukoei sinistu behar bazaie, kezka batzuk daude laster eror zitezkeen. 4. zenbakia.
Ez daukat argudio sinesgarririk nire tesia "frogatzeko". Dudan bakarra garatzaile gisa 30 urtean pilatu ditudan adibide koloretsuak dira. Lehen aipatu dut arazo honen izaera filosofiko sakona; nolabait politizatuta dago garatzaileen komunitateetan. Batzuek hori uste dute sortzaileak plataformek bateragarritasunaz arduratu beharko lukete, beste batzuek, berriz, hori kezka bat dela uste dute erabiltzaile (garatzaileak beraiek). Bitik bat. Izan ere, ez al da arazo politikoa arazo komunen kostuak nork bere gain hartu behar dituen erabakitzen dugunean?
Beraz, hau politika da. Eta seguruenik erantzun haserreak izango dira nire hitzaldian.
Bezala erabiltzaileak Google Cloud Platform, eta bi urtez AWS erabiltzaile gisa (Grab-en lan egiten duen bitartean), esan dezaket Amazon eta Google-ren filosofien artean alde handia dagoela lehentasunei dagokienez. Ez naiz aktiboki garatzen AWS-n, beraz, ez dakit oso ondo zenbat aldiz kentzen dituzten API zaharrak. Baina susmoa dago hori ez dela Google-n bezain maiz gertatzen. Eta benetan uste dut GCPren etengabeko eztabaida eta frustrazio iturri hori plataformaren garapena oztopatzen duen faktore handienetako bat dela.
Badakit ez ditudala jada onartzen ez diren GCP sistemen adibide zehatzik izendatu. Esan dezaket erabili dudan ia guztia, sareetatik (zaharrenetatik VPCra) biltegiratzeraino (Cloud SQL v1-v2), Firebase (orain Firestore API guztiz desberdinarekin), App Engine (ez gaitezen hasi ere egiten) , cloud endpoints Cloud Endpoint eta gehienez... Ez dakit - guztiz hau guztia Gehienez 2-3 urte igaro ondoren kodea berridaztera behartu zaituzte, eta inoiz ez dizute migrazioa automatizatu, eta askotan . Hala izan behar balitz bezala.
Eta AWS-ra begiratzen dudan bakoitzean, zergatik demontre nagoen oraindik GCP-n galdetzen diot neure buruari. Argi dago ez dutela bezerorik behar. Haiek behar dute ΠΏΠΎΠΊΡΠΏΠ°ΡΠ΅Π»ΠΈ. Ulertzen al duzu aldea? Utzidazu azaltzen.
Google Cloud ditu , non jendeak bere software irtenbideak proposatzen ditu, eta jatetxe hutsaren efektua saihesteko, proposamen batzuekin bete behar zuten, beraz, Bitnami izeneko enpresa batekin kontratatu zuten "klik batekin" zabaltzen diren soluzio mordoa sortzeko, edo behar luketen. Nik neuk idazten dut "konponbideak", hauek ez baitute gauza madarikaturik konpontzen. Markatze-lauki gisa existitzen dira, marketin-betegarri gisa, eta Google-ri ez zaio inoiz axola tresnaren batek benetan funtzionatzen duen ala ez. Ezagutzen ditut gidariaren aulkian egon diren produktuen kudeatzaileak, eta ziur diezazuket pertsona horiei berdin zaiela.
Har dezagun, adibidez, ustez "klik bakarreko" hedapen irtenbide bat. . Gaixotuta nengoen Google Cloud SQL-ren iruzurrengatik, beraz, nire Percona cluster-a alternatiba gisa eraikitzen hasi nintzen. Eta oraingoan Googlek lan ona egin zuela zirudien, denbora eta esfortzua aurreztuko zidaten botoi baten klik eginez!
Beno bikaina, goazen. Jarrai dezagun esteka eta egin klik botoi honetan. Hautatu "Bai" ezarpen lehenetsi guztiak onartzeko eta klusterra zure Google hodeiko proiektuan inplementatzeko. Haha, ez du funtzionatzen. Zalantza hauetako batek ere ez du funtzionatzen. Tresna ez zen inoiz probatu eta lehenengo minututik usteltzen hasi zen, eta ez ninduke harrituko "irtenbideen" erdia baino gehiago klik bakarreko inplementazioak badira (orain ulertzen dugu zergatik dauden komatxoak) oro har ez dabil. Hau guztiz itxaropenik gabeko iluntasuna da, non hobe den ez sartzea.
Baina Googlek arrazoi du insta haiek erabiltzeko. Zuk nahi dute erosi. Haientzat transakzio bat da. Ez dute ezer nahi laguntza. Ez da Googleren DNAren parte. Bai, ingeniariek elkarri laguntzen diote, Bigtable-rekin dudan istorioak erakusten duenez. Baina jende arruntentzako produktu eta zerbitzuetan beti errukigabeak ziren , milioika erabiltzaile izan arren errentagarritasunaren muga betetzen ez duena.
Eta honek benetako erronka bat dakar GCPrentzat, hori baita hodeiko eskaintza guztien atzean dagoen DNA. Ez dira ezer onartzen saiatzen; Jakina da hirugarrenen edozein software ostatzeari (kudeatutako zerbitzu gisa) uko egiten diotela arte, AWS-k gauza bera egin eta bere inguruan negozio arrakastatsu bat eraiki arte, eta bezeroek literalki gauza bera eskatzen dutenean. Hala ere, ahalegin batzuk behar dira Google-k zerbait onar dezan.
Laguntza-kultura falta honek, βapurtu dezagun ederrago egitekoβ mentalitatearekin batera, garatzaileak alienatzen ditu.
Eta hori ez da gauza ona iraupen luzeko plataforma bat eraiki nahi baduzu.
Google, esnatu, alajaina. 2020a da orain. Oraindik galtzen ari zara. Ispiluari gogor begiratu eta hodeiko negozioan jarraitu nahi duzun erantzuteko garaia da.
Egon nahi baduzu, orduan utzi dena haustea. Mutilak, aberatsak zarete. Garatzaileok ez. Beraz, bateragarritasunaren zama nork bere gain hartuko duen jakiteko, zure gain hartu behar duzu. Ez guretzat.
Gutxienez hiru hodei oso on gehiago daudelako. Keinu egiten dute.
Eta orain hautsitako sistema guztiak konpontzera pasatuko naiz. Eh.
Hurrengorarte!
PS Eguneratu artikulu honi buruzko eztabaida batzuk irakurri ondoren (eztabaidak bikainak dira, btw). Firebase laguntza ez da eten eta ez dago ezagutzen dudan planik. Hala ere, streaming akats gaizto bat dute eta horrek Java bezeroa App Engine-n gelditzea eragiten du. Haien ingeniari batek arazo hau konpontzen lagundu zidan, Googlen lan egin nuenean, baina ez dute inoiz akatsa konpondu, beraz, GAE aplikazioa egunero berrabiarazi behar izatearen konponbide txarra daukat. Eta horrela izan da lau urtez! Orain Firestore dute. Lan handia beharko du bertara migratzeko sistema guztiz desberdina baita eta Firebase akatsa ez baita inoiz konponduko. Zein ondorio atera daiteke? Laguntza lor dezakezu enpresa batean lan egiten baduzu. Seguruenik, Firebase GAE-n erabiltzen duen bakarra naiz, %100 jatorrizko aplikazio batean 100 gako baino gutxiago erregistratzen ditudalako eta egun pare bat behin funtzionatzeari uzten diolako akats ezagun baten ondorioz. Zer esan dezaket zure ardurapean erabiltzea baino. Redisera aldatzen ari naiz.
AWSko erabiltzaile esperientziadun batzuk ere ikusi ditut esaten AWS-k normalean ez duela inoiz zerbitzurik onartzen, eta SimpleDB adibide bikaina da. Nire hipotesiak AWS-k ez duela Google-ren laguntza-gaixotasun amaiera bera justifikatuta dagoela dirudi.
Gainera, duela 20 egun Google App Engine taldeak Go liburutegi kritiko baten ostalaritza hautsi zuela ohartu nintzen, eta Go garatzaile nagusietako GAE aplikazio bat itxi zuen. Benetan astakeria izan zen.
Azkenik, Google-koak entzun ditut dagoeneko gai honi buruz eztabaidatzen eta, oro har, nirekin ados daudela (maite zaituztet!). Baina badirudi arazoa konpontzezina dela uste dutela Googleren kulturak inoiz ez zuelako pizgarri egitura egokirik. Grab-en lan egiten nuen bitartean AWSko ingeniariekin lan egin nuen esperientzia guztiz harrigarriaz eztabaidatzeko denbora pixka bat hartzea ona izango zela pentsatu nuen. Etorkizunean noizbait, espero dut!
Eta bai, 2005ean marrazo haragi mota desberdinak izan zituzten 43. eraikineko buffet erraldoian, eta nire gogokoena mailu-marrazo haragia zen. Hala eta guztiz ere, 2006rako, Larry eta Sergei osasungaitzezko mokadu guztiak kendu zituzten. Beraz, 2007an Bigtable istorioan ez zegoen benetan marrazorik eta engainatu zintudan.
Duela lau urte hodei Bigtableri begiratu nionean (eman edo hartu), hemen zegoen kostua. Badirudi orain pixka bat jaitsi dela, baina hori oraindik izugarria da datu biltegi huts batentzat, batez ere nire lehenengo istorioak erakusten duelako zein garrantzirik ez duen mahai handi huts bat haien eskalan.
Barkatu Apple komunitatea iraintzeagatik eta Microsoft-i buruz ezer polita ez esateagatik. Ondo zaude, benetan eskertzen dut artikulu honek sortu duen eztabaida guztia! Baina batzuetan olatuak egin behar dituzu eztabaida bat hasteko, badakizu?
Eskerrik asko irakurtzeagatik.
Eguneraketa 2, 19.08.2020/XNUMX/XNUMX. Marra !
Eguneraketa 3, 31.08.2020/2/2. Cloud Marketplace-ko Google ingeniari batekin jarri nintzen harremanetan eta nire lagun zaharra izan zen. CXNUMXD-k zergatik ez zuen funtzionatzen asmatu nahi zuen, eta azkenean konturatu ginen nire sarea duela urte eraiki nuelako izan zela, eta CXNUMXD-k ez zuen sare zaharretan lan egiten, beren txantiloietan azpisare-parametroa falta zelako. Uste dut onena dela GCP erabiltzaile potentzialentzat Google-n nahikoa ingeniari ezagutzen dituztela ziurtatzea...
Iturria: www.habr.com