Prokleti Google, nisam želio ponovo blogati. Imam toliko toga da uradim. Bloganje zahtijeva vrijeme, energiju i kreativnost, što bih mogao dobro iskoristiti: moje knjige, , moja igra i tako dalje. Ali dovoljno si me naljutio da moram ovo da napišem.
Pa da završimo sa ovim.
Dozvolite mi da počnem s kratkom, ali poučnom pričom od kada sam prvi put počeo raditi u Googleu. Znam da sam u posljednje vrijeme govorio mnogo loših stvari o Google-u, ali me uznemiruje kada moja vlastita kompanija redovno donosi nekompetentne poslovne odluke. U isto vrijeme, moramo odati i zasluge: Google-ova interna infrastruktura je zaista izvanredna, slobodno se može reći da danas nema ništa bolje. Osnivači Gugla bili su mnogo bolji inženjeri nego što ću ja ikada biti, a ova priča samo potvrđuje tu činjenicu.
Prvo, malo pozadine: Google ima tehnologiju za skladištenje podataka tzv . Bilo je to izvanredno tehničko dostignuće, jedno od prvih (ako ne i prvih) "beskonačno skalabilnih" ključ/vrijednost skladišta (K/V): u suštini početak NoSQL-a. Ovih dana Bigtable se još uvijek dobro snalazi u prilično pretrpanom K/V skladišnom prostoru, ali u to vrijeme (2005.) bilo je neverovatno cool.
Jedna smiješna stvar u vezi s Bigtableom je da su imali interne kontrolne ravni objekte (kao dio implementacije) zvane tablet serveri, sa velikim indeksima, i u nekom trenutku su postali usko grlo prilikom skaliranja sistema. Bigtable inženjeri su se zbunjivali oko toga kako implementirati skalabilnost i odjednom su shvatili da mogu zamijeniti tablet servere drugim Bigtable skladištima. Dakle, Bigtable je dio implementacije Bigtablea. Ovi skladišni prostori postoje na svim nivoima.
Još jedan zanimljiv detalj je da je Bigtable neko vrijeme postao popularan i sveprisutan unutar Googlea, sa svakim timom koji je imao svoje spremište. Tako je na jednom od sastanaka u petak Larry Page usputno upitao: „Zašto imamo više od jednog Bigtablea? Zašto ne samo jedan?” U teoriji, jedna pohrana bi trebala biti dovoljna za sve Googleove potrebe za pohranom. Naravno, nikada nisu otišli samo na jedan iz praktičnih razvojnih razloga (poput posljedica potencijalnog neuspjeha), ali teorija je bila zanimljiva. Jedno spremište za cijeli Univerzum (Usput, da li neko zna da li je Amazon ovo uradio sa svojim Sableom?)
U svakom slučaju, evo moje priče.
U to vrijeme radio sam u Googleu nešto više od dvije godine i jednog dana sam dobio e-mail od Bigtable inženjerskog tima koji je izgledao ovako:
Dragi Steve,
Pozdrav od Bigtable tima. Želimo da vas obavijestimo da u [naziv centra podataka] koristite vrlo, vrlo staru binarnu datoteku Bigtable. Ova verzija više nije podržana i želimo vam pomoći da nadogradite na najnoviju verziju.
Obavijestite me ako možete zakazati neko vrijeme za zajednički rad na ovom pitanju.
Sve najbolje,
Bigtable Team
Na Guglu dobijate dosta mailova, pa sam na prvi pogled pročitao nešto ovako:
Poštovani primalac,
Pozdrav od neke ekipe. Želimo da komuniciramo to bla bla bla bla bla. Bla bla bla bla bla bla, i bla bla bla odmah.
Obavijestite nas ako možete zakazati nešto od svog dragocjenog vremena za bla bla bla.
Sve najbolje,
Neka vrsta komande
Skoro da sam ga odmah izbrisao, ali sam na rubu svijesti osjetio bolan, mučan osjećaj da ne baš ipak izgleda kao formalno pismo očigledno, da je primalac pogriješio jer nisam koristio Bigtable.
Ali bilo je čudno.
Ostatak dana sam proveo naizmjenično razmišljajući o poslu i o tome kakvo meso ajkule da probam u mikro-kuhinji, od kojih su barem tri bile dovoljno blizu da pogode sa svog mjesta dobro namjernim bacanjem keksa, ali pomisao na pisanje nikada me nije ostavila sa rastućim osjećajem blage anksioznosti.
Jasno su rekli moje ime. I e-mail je poslan na moju adresu e-pošte, a ne na nečiju drugu, i nije cc: ili bcc:. Ton je vrlo ličan i jasan. Možda je ovo neka greška?
Konačno, znatiželja me je nadvladala i otišao sam da pogledam Borg konzolu u data centru koji su spomenuli.
I naravno, imao sam BigTable skladište pod upravljanjem. Izvini, šta? Pogledao sam njegov sadržaj i vau! Bilo je to iz Codelab inkubatora u kojem sam sjedio tokom moje prve sedmice u Googleu u junu 2005. Codelab vas je natjerao da pokrenete Bigtable da tamo upišete neke vrijednosti, a nakon toga očigledno nikada nisam zatvorio skladište. I dalje je radio iako je prošlo više od dvije godine.
Postoji nekoliko značajnih aspekata ove priče. Prvo, rad Bigtablea je bio toliko beznačajan na Googleovoj skali da je samo dvije godine kasnije neko primijetio dodatni prostor za skladištenje, i to samo zato što je verzija binarne datoteke bila zastarjela. Poređenja radi, jednom sam razmišljao o upotrebi za moju onlajn igru. U to vrijeme ova usluga je koštala oko 16 dolara godišnje. prazan Bigtable na GCP. Ne kažem da vas varaju, ali po mom ličnom mišljenju, to je mnogo novca za praznu jebenu bazu podataka.
Još jedan aspekt vrijedan pažnje je skladištenje i dalje radi nakon dvije godine. WTF? Data centri dolaze i odlaze; doživljavaju prekide, prolaze kroz planirano održavanje, stalno se mijenjaju. Hardver se ažurira, prekidači se mijenjaju, sve se stalno poboljšava. Kako su dovraga uspjeli održati moj program u radu dvije godine sa svim ovim promjenama? Ovo može izgledati kao skromno postignuće u 2020. godini, ali u periodu 2005-2007. bilo je prilično impresivno.
A najdivniji aspekt je to što mi prilazi vanjski inženjerski tim u nekoj drugoj državi, vlasniku neke malene, gotovo prazne instance Bigtablea, koji ima nula prometa u posljednje dvije godine - i nudimo pomoć za ažuriranje.
Zahvalio sam im se, izbrisao skladište i život se nastavio uobičajeno. Ali trinaest godina kasnije, i dalje razmišljam o tom pismu. Jer ponekad primam slične e-poruke od Google Clouda. izgledaju ovako:
Poštovani korisniče Google Clouda,
Podsjećamo, ukinut ćemo uslugu [osnovna usluga koju koristite] od avgusta 2020., nakon čega nećete moći nadograditi svoje instance. Preporučujemo nadogradnju na najnoviju verziju, koja je u beta testiranju, nema dokumentaciju, nema putanju migracije i prethodno je zastarjela uz našu ljubaznu pomoć.
Posvećeni smo osiguranju da ova promjena ima minimalan uticaj na sve korisnike Google Cloud platforme.
Najbolji prijatelji zauvijek,
Google Cloud platforma
Ali skoro nikad ne čitam takva pisma, jer ono što oni zapravo kažu je:
Poštovani primalac,
Idi u pakao. Jebi se, jebi se, jebi se. Odbacite sve što radite jer nije važno. Ono što je važno je naše vrijeme. Gubimo vrijeme i novac održavajući naše sranje i umorni smo od toga pa ga više nećemo podržavati. Zato prestanite sa svojim jebenim planovima i počnite kopati po našoj usranoj dokumentaciji, moliti za beleške po forumima, a usput, naše novo sranje je potpuno drugačije od starog, jer smo ovaj dizajn jako zeznuli, heh, ali to je tvoje problem, ne naš.
Nastavljamo da činimo napore da osiguramo da svi vaši objekti postanu neupotrebljivi u roku od jedne godine.
Molim te, odjebi
Google Cloud platforma
A činjenica je da ovakva pisma dobijam otprilike jednom mjesečno. To se dešava tako često i tako stalno da su neizbežno odgurnuo ja od GCP do kampa protiv oblaka. Više se ne slažem da ovisim o njihovom vlasničkom razvoju, jer je u stvari lakše za devops da održavaju sistem otvorenog koda na goloj virtuelnoj mašini nego da pokušavaju da drže korak sa Googleom sa njegovom politikom zatvaranja „zastarelih“ proizvoda.
Prije nego se vratim na Google Cloud jer ja nije ni blizu da ih ne kritikujemo, pogledajmo performanse kompanije u nekim drugim oblastima. Google inženjeri se ponose svojom disciplinom softverskog inženjeringa, a to je ono što zapravo uzrokuje probleme. Ponos je zamka za neoprezne i mnoge zaposlenike Googlea je naveo da misle da su njihove odluke uvijek ispravne i da je biti u pravu (po nekoj nejasnoj nejasnoj definiciji) važnije od brige o klijentima.
Navest ću neke nasumične primjere iz drugih velikih projekata izvan Google-a, ali nadam se da ćete svuda vidjeti ovaj obrazac. To je kako slijedi: kompatibilnost unazad održava sisteme živim i ažuriranim decenijama.
Kompatibilnost unatrag je cilj dizajna svih uspješnih sistema za koje su dizajnirani open koristiti, odnosno implementirati sa otvorenim izvornim kodom i/ili otvorenim standardima. Osećam se kao da govorim nešto previše očigledno da je svima čak i neprijatno, ali ne. Ovo je političko pitanje, pa su potrebni primjeri.
Prvi sistem koji ću izabrati je najstariji: GNU Emacs, koji je svojevrsni hibrid između Windows Notepad-a, jezgra OS-a i Međunarodne svemirske stanice. Malo je teško objasniti, ali ukratko, Emacs je platforma kreirana 1976. godine (da, prije skoro pola stoljeća) za programiranje kako bi vas učinio produktivnijim, ali maskiran kao uređivač teksta.
Koristim Emacs svaki dan. Da, također koristim IntelliJ svaki dan, on je izrastao u moćnu platformu za alate. Ali pisanje ekstenzija za IntelliJ je mnogo ambiciozniji i složeniji zadatak od pisanja ekstenzija za Emacs. I što je još važnije, sve što je napisano za Emacs je sačuvano zauvijek.
Još uvijek koristim softver koji sam napisao za Emacs 1995. godine. I siguran sam da neko koristi module napisane za Emacs sredinom 80-ih, ako ne i ranije. Možda će s vremena na vrijeme biti potrebno malo prilagođavanja, ali to je zaista prilično rijetko. Ne znam ništa što sam ikada napisao za Emacs (a napisao sam mnogo) što bi zahtijevalo re-arhitekturu.
Emacs ima funkciju koja se zove make-obsolete za zastarjele entitete. Emacs terminologija za fundamentalne kompjuterske koncepte (kao što je "prozor") često se razlikuje od industrijskih konvencija jer ih je Emacs uveo davno. Ovo je tipična opasnost za one koji su ispred svog vremena: svi vaši uslovi su netačni. Ali Emacs ima koncept odricanja, koji se u njihovom žargonu zove zastarelost.
Ali u svijetu Emacs-a izgleda da postoji drugačija radna definicija. Drugačija temeljna filozofija, ako hoćete.
U svijetu Emacsa (i u mnogim drugim područjima, koje ćemo pokriti u nastavku), zastarjeli status API-ja u osnovi znači: „Stvarno ne biste trebali koristiti ovaj pristup, jer dok radi, pati od raznih nedostataka koje ćemo popis ovdje. Ali na kraju dana, to je vaš izbor."
U Googleovom svijetu, biti zastarjeli znači: "Kršimo našu obavezu prema vama." Istina je. To u suštini znači. To znači da će te prisiliti redovno uradite neki posao, možda i dosta posla, kao kaznu što verujete u njih : Imamo najbolji softver. Najbrzi! Radiš sve po uputstvu, pokreneš svoju aplikaciju ili servis, a onda bam, nakon godinu-dvije se pokvari.
To je kao da prodajete polovni auto koji ce se sigurno pokvariti nakon 1500 km.
Ovo su dvije potpuno različite filozofske definicije “zastarjelosti”. Googleova definicija mirisa . Ne vjerujem u ovo zapravo planirano zastarjelo u istom smislu kao i Apple. Ali Google definitivno planira da razbije vaše programe, na zaobilazni način. Znam to jer sam tamo radio kao softverski inženjer više od 12 godina. Imaju nejasne interne smjernice o tome koliko treba slijediti kompatibilnost unatrag, ali to je na kraju na svakom pojedinačnom timu ili usluzi. Ne postoje preporuke na nivou preduzeća ili inženjeringa, a najhrabrija preporuka u pogledu ciklusa zastarelosti je „pokušajte da date kupcima 6-12 meseci za nadogradnju pre nego što razbiju čitav sistem“.
Problem je mnogo veći nego što oni misle, i trajat će godinama koje dolaze jer briga o korisnicima nije u njihovom DNK. Više o tome u nastavku.
U ovom trenutku ću dati hrabru izjavu da je Emacs uspješan u velikoj mjeri i ujednačen uglavnom jer tako ozbiljno shvataju kompatibilnost unatrag. Zapravo, ovo je teza našeg članka. Uspješni, dugovječni otvoreni sistemi duguju svoj uspjeh mikrozajednicama koje žive oko njih decenijama ekstenzije/dodaci. Ovo je ekosistem. Već sam govorio o prirodi platformi i o tome koliko su one važne, kao io tome kako Google nikada u cijeloj svojoj korporativnoj istoriji nije shvatio šta ide u stvaranje uspješne otvorene platforme izvan Androida ili Chromea.
Zapravo, trebao bih ukratko spomenuti Android jer vjerovatno razmišljate o tome.
Pre svega, Android nije Google. Oni nemaju skoro ništa zajedničko jedno s drugim. Android je kompanija koju je kupio Google u julu 2005. godine, kompaniji je bilo dozvoljeno da radi manje-više autonomno i u stvari je ostala uglavnom netaknuta u godinama koje su bile među njima. Android je ozloglašeni tehnološki skup i jednako ozloglašena bodljikava organizacija. Kao što je rekao jedan Googleov radnik, "Ne možete se samo prijaviti na Android."
U prethodnom članku, raspravljao sam o tome koliko su neke od ranih odluka o dizajnu Androida bile loše. Dovraga, kada sam napisao taj članak, izbacivali su sranje zvano "instant aplikacije" koje su sada (iznenađenje!) , i suosjećam ako ste bili dovoljno glupi da slušate Google i premjestite svoj sadržaj u ove instant aplikacije.
Ali ovdje postoji razlika, značajna razlika, a to je da ljudi na Androidu zaista razumiju koliko su platforme važne, daju sve od sebe da stare Android aplikacije nastave raditi. Zapravo, njihovi napori da održe kompatibilnost unatrag toliko su ekstremni da sam čak i ja, tokom svog kratkog boravka u odjelu za Android prije nekoliko godina, našao sebe kako pokušavam da ih uvjerim da odustanu od podrške za neke od najstarijih uređaja i API-ja (pogriješio sam , kao što je bilo u mnogim drugim stvarima u prošlosti i sadašnjosti. Izvinite Android momci! Sada kada sam bio u Indoneziji, razumijem zašto su nam potrebni).
Ljudi Androida potiskuju kompatibilnost unatrag do gotovo nezamislivih ekstrema, gomilajući ogromne količine naslijeđenog tehničkog duga u svojim sistemima i lancima alata. O moj Bože, trebali biste vidjeti neke od ludih stvari koje moraju učiniti u svom sistemu izgradnje, sve u ime kompatibilnosti.
Za ovo dodeljujem Androidu cenjenu nagradu "You're Not Google". Oni zaista ne žele da postanu Google, koji ne zna da kreira trajne platforme, već Android zna, kako uraditi. I tako je Google veoma pametan u jednom pogledu: dozvoljava ljudima da rade stvari na svoj način na Androidu.
Međutim, instant aplikacije za Android bile su prilično glupa ideja. A znate li zašto? Zato što su zahtevali prepišite i redizajnirajte svoju aplikaciju! Kao da će ljudi jednostavno prepisati dva miliona aplikacija. Pretpostavljam da su Instant aplikacije ideja nekog Google-ovca.
Ali postoji razlika. Povratna kompatibilnost ima visoku cijenu. Sam Android snosi teret ovih troškova, dok Google insistira da se teret snosi ti si, klijent koji plaća.
Možete vidjeti Androidovo opredjeljenje za kompatibilnost unatrag u njegovim API-jima. Kada imate četiri ili pet različitih podsistema koji rade bukvalno istu stvar, to je siguran znak da postoji posvećenost kompatibilnosti unatrag u srži. Što je u svijetu platformi sinonim za posvećenost vašim klijentima i vašem tržištu.
Guglov glavni problem ovdje je njihov ponos na svoju inženjersku higijenu. Ne vole kada postoji mnogo različitih načina da se uradi ista stvar, pri čemu stari, manje poželjni načini stoje pored novih, otmjenijih načina. Povećava krivulju učenja za one koji su novi u sistemu, povećava teret održavanja zastarjelih API-ja, usporava brzinu novih funkcija, a kardinalni grijeh je što nije lijepo. Google - poput Lady Ascot iz Alise u zemlji čuda Tima Burtona:
Lady Ascot:
- Alis, znaš li čega se najviše bojim?
- Propadanje aristokratije?
- Plašio sam se da ću ružni unuci.
Da bismo razumjeli kompromis između lijepog i praktičnog, pogledajmo treću uspješnu platformu (nakon Emacsa i Androida) i vidimo kako ona funkcionira: sama Java.
Java ima mnogo zastarjelih API-ja. Zastarelost je veoma popularna među Java programerima, čak popularnija nego u većini programskih jezika. Sama Java, jezgro jezika i biblioteke konstantno odbijaju API-je.
Da uzmem samo jedan od hiljada primjera, smatra zastarjelim. Zastario je od objavljivanja Jave 1.2 u decembru 1998. godine. Prošle su 22 godine otkako je ovo zastarjelo.
Ali moj stvarni kod u proizvodnji još uvijek ubija niti svaki dan. Da li stvarno mislite da je to dobro? Apsolutno! Mislim, naravno, ako bih danas prepisao kod, implementirao bih ga drugačije. Ali kod za moju igru, koja je usrećila stotine hiljada ljudi u protekle dvije decenije, napisan je s funkcijom zatvaranja niti koje predugo vise, a ja nikada nije morao da ga menjam. Poznajem svoj sistem bolje od bilo koga, imam bukvalno 25 godina iskustva u radu s njim u proizvodnji i mogu sa sigurnošću reći: u mom slučaju je potpuno zatvaranje ovih specifičnih radničkih niti bezopasan. Nije vrijedno vremena i truda da se prepiše ovaj kod, i hvala Larry Ellisonu (vjerovatno) što me Oracle nije prisilio da ga prepišem.
Oracle vjerovatno razumije i platforme. Ko zna.
Dokazi se mogu naći u osnovnim Java API-jima, koji su prožeti talasima zastarelosti, poput linija glečera u kanjonu. U Java Swing biblioteci lako možete pronaći pet ili šest različitih menadžera za navigaciju tastature (KeyboardFocusManager). Zapravo je teško pronaći Java API koji nije zastario. Ali i dalje rade! Mislim da će Java tim istinski ukloniti API samo ako sučelje predstavlja očigledan sigurnosni problem.
Evo u čemu je stvar, ljudi: svi mi programeri softvera smo veoma zaposleni i u svakoj oblasti softvera suočeni smo sa konkurentnim alternativama. U svakom trenutku, programeri u jeziku X razmatraju jezik Y kao moguću zamjenu. Oh, ne veruješ mi? Želite li ga zvati Swift? Kao, svi migriraju na Swift i niko ga ne napušta, zar ne? Vau, kako malo znaš. Kompanije broje troškove dvostrukih mobilnih razvojnih timova (iOS i Android) - i počinju shvaćati da ti krosplatformski razvojni sistemi sa smiješnim imenima poput Flutter i React Native zapravo rade i mogu se koristiti za smanjenje veličine njihovih mobilni timovi dvaput ili, obrnuto, čine ih dvostruko produktivnijima. U igri je pravi novac. Da, postoje kompromisi, ali, s druge strane, novac.
Pretpostavimo hipotetički da je Apple glupo uzeo znak od Guida van Rossuma i izjavio da je Swift 6.0 unatrag nekompatibilan sa Swiftom 5.0, slično kao što je Python 3 nekompatibilan sa Pythonom 2.
Vjerovatno sam ispričao ovu priču prije desetak godina, ali prije petnaestak godina otišao sam u O'Reilly's Foo Camp sa Gvidom, sjedio u šatoru s Paulom Grahamom i gomilom velikih igrača. Sedeli smo na vrelini čekajući da Lari Pejdž odleti svojim ličnim helikopterom, dok je Gvido brbljao o „Python 3000“, koji je nazvao po broju godina koje će svima trebati da migriraju tamo. Stalno smo ga pitali zašto narušava kompatibilnost, a on je odgovorio: “Unicode”. I pitali smo, ako bismo morali da prepišemo naš kod, koje bismo druge prednosti videli? I on je odgovorio "yoooooooooooooouuuuuuuniiiiiiicooooooooode."
Ako instalirate Google Cloud Platform SDK (“gcloud”), dobit ćete sljedeće obavještenje:
Poštovani primalac,
Željeli bismo vas podsjetiti da je podrška za Python 2 zastarjela, pa jebite se
… i tako dalje. Krug života.
Ali poenta je da svaki programer ima izbor. A ako ih natjerate da dovoljno često prepisuju kod, mogli bi razmisliti o tome drugi opcije. Oni nisu vaši taoci, bez obzira koliko biste željeli da to budu. Oni su vaši gosti. Python je i dalje veoma popularan programski jezik, ali dovraga, Python 3(000) je napravio takav nered u sebi, u svojim zajednicama i među korisnicima svojih zajednica da se posljedice nisu raščistile već petnaest godina.
Koliko je Python programa prepisano u Go (ili Ruby, ili nekoj drugoj alternativi) zbog ove nekompatibilnosti unazad? Koliko je novog softvera napisano u nečemu drugom osim Pythonu, iako je može biti napisano na Pythonu, da Guido nije spalio cijelo selo? Teško je reći, ali Python je očigledno patio. Veliki je nered i svi gube.
Dakle, recimo da Apple uzima uzor od Guida i prekida kompatibilnost. Šta mislite da će se sljedeće dogoditi? Pa, možda će 80-90% programera prepisati svoj softver ako je moguće. Drugim riječima, 10-20% korisničke baze automatski ide na neki konkurentski jezik, kao što je Flutter.
Uradite ovo više puta i izgubit ćete polovinu svoje korisničke baze. Kao iu sportu, u svijetu programiranja bitna je i trenutna forma. sve. Svako ko izgubi polovinu korisnika za pet godina smatraće se velikim gubitnikom masti. Morate biti u trendu u svijetu platformi. Ali ovo je mjesto gdje će vas nepodržavanje starijih verzija s vremenom uništiti. Jer svaki put kada se riješite nekih programera, vi (a) ih zauvijek izgubite jer su ljuti na vas što ste prekršili ugovor, i (b) ih poklanjate svojim konkurentima.
Ironično, pomogao sam i Google-u da postane takva primadona koja zanemaruje kompatibilnost unatrag kada sam kreirao Grok, sistem za analizu i razumijevanje izvornog koda koji olakšava automatizaciju i instrumentaciju samog koda - slično IDE-u, ali ovdje servisi u oblaku pohranjuju materijalizovane reprezentacije svih milijardi linija Googleovog izvornog koda u velikom skladištu podataka.
Grok je zaposlenima u Guglu pružio moćan okvir za izvođenje automatiziranog refaktoriranja u cijeloj njihovoj bazi kodova (bukvalno u cijelom Googleu). Sistem izračunava ne samo vaše uzvodne zavisnosti (od kojih zavisite), već i silazno (koje su na vama) tako da kada promijenite API-je znate sve koje kršite! Na ovaj način, kada izvršite promjene, možete provjeriti da li je svaki korisnik vašeg API-ja ažuriran na novu verziju, a u stvarnosti, često s Rosie alatom koji su napisali, možete potpuno automatizirati proces.
Ovo omogućava da Googleova baza kodova bude interno gotovo natprirodno čista, jer imaju ove robotske sluge koji se šuljaju po kući i automatski čiste sve ako preimenuju SomeDespicablyLongFunctionName u SomeDespicablyLongMethodName jer je neko odlučio da je to ružno unuče i da ga treba uspavati.
I iskreno, radi prilično dobro za Google... interno. Mislim, da, Go zajednica u Google-u se dobro nasmijala sa Java zajednicom u Google-u zbog njihove navike kontinuiranog prepravljanja. Ako ponovo pokrenete nešto N puta, to znači da ne samo da ste to zeznuli N-1 puta, već nakon nekog vremena postaje prilično jasno da ste to vjerovatno zeznuli i u N-om pokušaju. Ali, uglavnom, ostaju iznad sve ove gužve i drže kod „čistim“.
Problem počinje kada pokušaju da nametnu ovakav stav svojim klijentima u oblaku i korisnicima drugih API-ja.
Upoznao sam vas malo sa Emacs-om, Androidom i Javom; pogledajmo najnoviju uspješnu dugovječnu platformu: sam Web. Možete li zamisliti kroz koliko je iteracija HTTP prošao od 1995. kada smo koristili bljeskajuće oznake? i ikone "U izradi" na web stranicama.
Ali i dalje radi! I ove stranice još uvijek rade! Da, momci, pretraživači su svjetski prvaci u kompatibilnosti unatrag. Chrome je još jedan primjer rijetke Google platforme kojoj su glave ispravno zeznute, i kao što ste mogli pretpostaviti, Chrome efektivno djeluje kao zaštićena kompanija odvojena od ostatka Googlea.
Takođe želim da se zahvalim našim prijateljima u programerima operativnih sistema: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, itd., što su uradili tako sjajan posao kompatibilnosti unazad na svojim uspešnim platformama (Apple dobija C u najboljem slučaju sa The Nedostatak je što sve razbijaju sve vrijeme bez dobrog razloga, ali nekako zajednica to zaobilazi sa svakim izdanjem, a OS X kontejneri još uvijek nisu potpuno zastarjeli... još).
Ali čekajte, kažete. Zar ne poredimo jabuke sa narandžama - samostalne softverske sisteme na jednoj mašini kao što je Emacs/JDK/Android/Chrome naspram sistema sa više servera i API-ja kao što su usluge u oblaku?
Pa, juče sam tvitovao o ovome, ali u stilu Larryja Walla (tvorca programskog jezika Perl - cca. per.) po principu "sranje/pravila" sam potražio riječ zastarelo na Google i Amazon web stranicama za programere. I mada AWS ima stotine puta više ponuda usluga od GCP-a, Googleova dokumentacija za programere spominje zastarjelost oko sedam puta češće.
Ako iko u Googleu ovo čita, vjerovatno je spreman da izvuče grafikone u stilu Donalda Trumpa koji pokazuju da zapravo rade sve kako treba i da ne bih trebao praviti nepravedna poređenja poput "broja spominjanja riječi zastarjelo u odnosu na broj usluga" "
Ali nakon svih ovih godina, Google Cloud je i dalje servis broj 3 (nikada nisam napisao članak o neuspjelom pokušaju da postanem broj 2), ali ako je vjerovati insajderima, postoje neke zabrinutosti na koje bi se uskoro mogli obratiti br. 4.
Nemam uvjerljive argumente da "dokažem" svoju tezu. Sve što imam su šareni primjeri koje sam prikupio tokom 30 godina kao programer. Već sam spomenuo duboko filozofsku prirodu ovog problema; na neki način je politizirano u zajednicama programera. Neki vjeruju u to kreatori platforme bi trebale brinuti o kompatibilnosti, dok drugi misle da je to problem korisnici (sami programeri). Jedan od dva. Zaista, zar nije političko pitanje kada odlučujemo ko će snositi troškove zajedničkih problema?
Dakle, ovo je politika. I vjerovatno će biti ljutitih odgovora na moj govor.
Kako korisnik Google Cloud Platform, a kao korisnik AWS-a već dvije godine (dok sam radio za Grab), mogu reći da postoji ogromna razlika između Amazonove i Googleove filozofije kada su u pitanju prioriteti. Ne razvijam se aktivno na AWS-u, tako da ne znam koliko često uklanjaju stare API-je. Ali postoji sumnja da se to ne dešava ni približno tako često kao kod Google-a. I zaista vjerujem da je ovaj izvor stalnih kontroverzi i frustracija u GCP-u jedan od najvećih faktora koji koče razvoj platforme.
Znam da nisam naveo konkretne primjere GCP sistema koji više nisu podržani. Mogu reći da skoro sve što sam koristio, od mreža (od najstarijih do VPC) do pohrane (Cloud SQL v1-v2), Firebasea (sada Firestore s potpuno drugačijim API-jem), App Engine (da ne počinjemo) , cloud endpoints Cloud Endpoint i do... Ne znam - apsolutno sve ovo prisilili su vas da prepišete kod nakon maksimalno 2-3 godine, a nikad vam nisu automatizirali migraciju, a često . Kao da je tako trebalo da bude.
I svaki put kad pogledam AWS, pitam se zašto sam dovraga još uvijek na GCP-u. Očigledno im ne trebaju klijenti. Trebaju im kupiteli. Shvaćate li razliku? Dopusti mi da objasnim.
Google Cloud ima , gde ljudi predlažu svoja softverska rešenja, a da bi izbegli efekat praznog restorana, morali su da ga popune nekim predlozima, pa su ugovorili sa kompanijom Bitnami da kreiraju gomilu rešenja koja se postavljaju „jednim klikom“, ili bi trebalo Sam to pišem "rješenja", jer ovo ne rješava ništa. Oni jednostavno postoje kao potvrdni okviri, kao marketinški dodatak, a Google nikada nije mario da li neki od alata zaista radi. Poznajem menadžere proizvoda koji su bili na vozačkom mjestu, i uvjeravam vas da te ljude nije briga.
Uzmimo, na primjer, rješenje za implementaciju navodno „jedan klik“. . Bio sam bolestan na smrt od Google Cloud SQL smicalica, pa sam počeo da tražim izgradnju vlastitog Percona klastera kao alternativu. I ovaj put se činilo da je Google uradio dobar posao, uštedeće mi malo vremena i truda jednim klikom!
Pa super, idemo. Slijedite vezu i kliknite na ovo dugme. Odaberite "Da" da prihvatite sve zadane postavke i implementirate klaster u svoj Google cloud projekat. Haha, ne radi. Ništa od ovog sranja ne radi. Alat nikada nije testiran i počeo je da truli od prve minute, i ne bi me iznenadilo da je više od polovine "rješenja" implementacija jednim klikom (sada razumijemo zašto su navodnici) uopšte ne radi. Ovo je apsolutno beznadežan mrak, u koji je bolje ne ulaziti.
Ali Google je u pravu podstiče da ih koristite. Oni to žele kupio. Za njih je to transakcija. Oni ne žele ništa podrška. To nije dio Googleovog DNK. Da, inženjeri podržavaju jedni druge, o čemu svjedoči moja priča sa Bigtableom. Ali u proizvodima i uslugama za obične ljude uvek bili nemilosrdni unutra , koji ne zadovoljava granice profitabilnosti čak i ako ima milione korisnika.
A ovo predstavlja pravi izazov za GCP jer je to DNK iza svih ponuda u oblaku. Oni ne pokušavaju da podrže bilo šta; Dobro je poznato da odbijaju da hostuju (kao upravljani servis) bilo koji softver treće strane do, sve dok AWS ne učini isto i oko toga izgradi uspješan posao, i kada kupci doslovno zahtijevaju isto. Međutim, potrebno je malo truda da se Google nešto podrži.
Ovaj nedostatak kulture podrške, zajedno sa mentalitetom „razbijmo ga da bude lepši“, otuđuje programere.
A to nije dobro ako želite da izgradite dugovečnu platformu.
Guglaj, probudi se, prokletstvo. Sada je 2020. Još uvijek gubiš. Vreme je da se dobro pogledate u ogledalo i odgovorite da li zaista želite da ostanete u poslu sa oblakom.
Ako želiš da ostaneš onda prestani sve lomiti. Ljudi, vi ste bogati. Mi programeri ne radimo. Dakle, kada je u pitanju ko će preuzeti teret kompatibilnosti, morate to preuzeti na sebe. Ne za nas.
Jer postoje još najmanje tri stvarno dobra oblaka. Oni zovu.
A sada ću preći na popravku svih mojih pokvarenih sistema. Eh.
Do sljedećeg puta!
PS Ažurirajte nakon čitanja nekih rasprava o ovom članku (diskusije su odlične, btw). Firebase podrška nije prekinuta i nema nikakvih planova za koje sam upoznat. Međutim, oni imaju gadnu grešku u strimingu koja uzrokuje zaustavljanje Java klijenta u App Engine-u. Jedan od njihovih inženjera mi je pomogao da riješim ovaj problem, kada sam radio u Google-u, ali zapravo nikada nisu ispravili grešku, tako da imam usrano rješenje da moram ponovo pokretati GAE aplikaciju svaki dan. I tako je već četiri godine! Sada imaju Firestore. Biće potrebno dosta posla da se pređe na njega jer je to potpuno drugačiji sistem i Firebase greška nikada neće biti ispravljena. Kakav zaključak se može izvući? Možete dobiti pomoć ako radite u kompaniji. Vjerojatno sam jedini koji koristi Firebase na GAE-u jer bilježim manje od 100 ključeva u 100% izvornoj aplikaciji i prestaje raditi svakih nekoliko dana zbog poznatog buga. Šta reći osim da ga koristite na vlastitu odgovornost. Prelazim na Redis.
Vidio sam i neke iskusnije AWS korisnike kako kažu da AWS obično nikada ne prestaje podržavati bilo koju uslugu, a SimpleDB je odličan primjer. Čini se da su moje pretpostavke da AWS nema isti kraj bolesti podrške kao Google, opravdane.
Osim toga, primijetio sam da je prije 20 dana tim Google App Engine-a prekinuo hosting kritične Go biblioteke, ugasio GAE aplikaciju od jednog od ključnih Go programera. Bilo je stvarno glupo.
Konačno, čuo sam da Googleovi već raspravljaju o ovom pitanju i generalno se slažu sa mnom (volim vas!). Ali izgleda da misle da je problem nerešiv jer Guglova kultura nikada nije imala pravu strukturu podsticaja. Mislio sam da bi bilo dobro odvojiti malo vremena za razgovor o apsolutno neverovatnom iskustvu koje sam imao radeći sa AWS inženjerima dok sam radio u Grabu. Jednog dana u budućnosti, nadam se!
I da, 2005. godine su imali različite vrste mesa ajkule na divovskom bifeu u zgradi 43, a moje omiljeno je bilo meso ajkule čekićara. Međutim, do 2006. godine, Larry i Sergei su se riješili svih nezdravih grickalica. Dakle, tokom priče o Bigtableu 2007. zaista nije bilo ajkula i ja sam vas prevario.
Kada sam pre četiri godine pogledao oblak Bigtable (dajte ili uzmite), ovo je bio trošak. Čini se da je sada malo pao, ali to je još uvijek užasno puno za prazno skladište podataka, pogotovo jer moja prva priča pokazuje koliko je prazan veliki sto beznačajan u njihovoj mjeri.
Oprostite što sam uvrijedio Apple zajednicu i nisam rekao ništa lijepo o Microsoftu itd. U redu ste, zaista cijenim svu diskusiju koju je ovaj članak stvorio! Ali ponekad je potrebno malo zamahnuti da biste započeli diskusiju, znate?
Hvala na čitanju.
Ažuriranje 2, 19.08.2020. Stripe !
Ažuriranje 3, 31.08.2020. Kontaktirao me je Google inženjer na Cloud Marketplace-u za koji se ispostavilo da je moj stari prijatelj. Želio je da shvati zašto C2D ne radi, a mi smo na kraju shvatili da je to zato što sam izgradio svoju mrežu prije mnogo godina, a C2D nije radio na starim mrežama jer je parametar podmreže nedostajao u njihovim predlošcima. Mislim da je za potencijalne korisnike GCP-a najbolje da se uvjere da poznaju dovoljno inženjera u Googleu...
izvor: www.habr.com