Prokleti Google, nisam htio ponovo blogovati. Imam toliko toga za obaviti. Za bloganje su potrebni vrijeme, energija i kreativnost, koje bih mogao dobro iskoristiti: moje knjige, , moja igra i tako dalje. Ali dovoljno si me naljutio da moram ovo napisati.
Pa završimo s ovim.
Dopustite mi da počnem s kratkom, ali poučnom pričom iz vremena kad sam tek počeo raditi u Googleu. Znam da sam u zadnje vrijeme govorio mnogo loših stvari o Googleu, ali me uzrujava kada moja tvrtka redovito donosi nekompetentne poslovne odluke. Istovremeno, moramo mu odati priznanje: Googleova interna infrastruktura je zaista izvanredna, slobodno se može reći da danas nema ništa bolje. Osnivači Googlea bili su puno bolji inženjeri nego što ću ja ikada biti, a ova priča samo potvrđuje tu činjenicu.
Prvo, malo pozadine: Google ima tehnologiju pohrane podataka tzv . Bilo je to izvanredno tehničko postignuće, jedna od prvih (ako ne i prva) "beskonačno skalabilne" pohrane ključ-vrijednosti (K/V): u biti početak NoSQL-a. Ovih se dana Bigtable još uvijek dobro snalazi u prilično pretrpanom K/V skladišnom prostoru, ali u to je vrijeme (2005.) bilo nevjerojatno cool.
Jedna smiješna stvar u vezi s Bigtableom je da su imali objekte unutarnje kontrolne ravnine (kao dio implementacije) koji su se zvali tablet poslužitelji, s velikim indeksima, i u nekom su trenutku postali usko grlo pri skaliranju sustava. Inženjeri Bigtablea razmišljali su o tome kako implementirati skalabilnost i odjednom su shvatili da mogu zamijeniti tablet poslužitelje drugim Bigtable pohranama. Dakle, Bigtable je dio Bigtable implementacije. Ovi skladišni objekti postoje na svim razinama.
Još jedan zanimljiv detalj je da je Bigtable na neko vrijeme postao popularan i sveprisutan unutar Googlea, pri čemu je svaki tim imao svoj repozitorij. 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 trebala bi biti dovoljna za sve Googleove potrebe za pohranom. Naravno, nikada nisu išli samo na jedan iz praktičnih razvojnih razloga (kao što su posljedice potencijalnog neuspjeha), ali teorija je bila zanimljiva. Jedno spremište za cijeli svemir (Usput, zna li netko je li Amazon ovo napravio sa svojim Sableom?)
Uglavnom, evo moje priče.
U to sam vrijeme radio u Googleu nešto više od dvije godine i jednog sam dana primio e-poruku od Bigtable inženjerskog tima koja je glasila otprilike ovako:
Dragi Steve,
Pozdrav od Bigtable tima. Željeli bismo vas obavijestiti da u [naziv podatkovnog centra] koristite vrlo, vrlo staru binarnu datoteku Bigtable. Ova verzija više nije podržana i želimo vam pomoći da nadogradite na najnoviju verziju.
Recite mi ako možete dogovoriti vrijeme za zajednički rad na ovom problemu.
Sve najbolje,
Bigtable Tim
Na Googleu dobijete puno mailova, pa sam na prvi pogled pročitao nešto ovako:
Poštovani primatelju,
Pozdrav od neke ekipe. Želimo komunicirati taj bla bla bla bla bla. Bla bla bla bla bla bla, i bla bla bla odmah.
Javite nam ako možete odvojiti dio svog dragocjenog vremena za bla bla bla.
Sve najbolje,
Neka vrsta zapovijedi
Gotovo sam ga odmah izbrisao, ali na rubu svijesti osjetio sam bolan, mučan osjećaj da ne baš ipak izgleda kao službeno pismo očito, da je primatelj pogriješio jer nisam koristio Bigtable.
Ali bilo je čudno.
Ostatak dana proveo sam naizmjence razmišljajući o poslu i kakvo meso morskog psa probati u mikrokuhinji, od kojih su barem tri bila dovoljno blizu da ih pogodim sa sjedala dobro naciljanim bacanjem keksa, ali pomisao na pisanje nikad me nije ostavljala s rastućim osjećajem blage tjeskobe.
Jasno su rekli moje ime. I e-pošta je poslana na moju e-adresu, a ne na tuđu, i nije cc: ili bcc:. Ton je vrlo osoban i jasan. Možda je ovo neka greška?
Napokon me savladala znatiželja i otišao sam pogledati Borg konzolu u data centar koji su spominjali.
I naravno, imao sam BigTable pohranu pod upravljanjem. Žao mi je, što? Pogledao sam njegov sadržaj i vau! Bio je to iz inkubatora Codelab u kojem sam sjedio tijekom svog prvog tjedna u Googleu u lipnju 2005. Codelab vas je natjerao da pokrenete Bigtable da tamo upišete neke vrijednosti, a ja očito nakon toga nikada nisam zatvorio pohranu. I dalje je radio iako je prošlo više od dvije godine.
Nekoliko je aspekata vrijednih pažnje ove priče. Prvo, posao Bigtablea bio je toliko beznačajan u Googleovoj mjeri da je samo dvije godine kasnije itko primijetio dodatnu pohranu, i to samo zato što je verzija binarne datoteke bila zastarjela. Za usporedbu, jednom sam razmišljao o korištenju za moju online igru. U to je vrijeme ova usluga koštala otprilike 16 dolara godišnje. isprazniti Bigtable na GCP-u. Ne kažem da vas varaju, ali po mom osobnom mišljenju, to je puno novca za praznu jebenu bazu podataka.
Još jedan aspekt vrijedan pažnje je pohrana i dalje radi nakon dvije godine. WTF? Podatkovni centri dolaze i odlaze; doživljavaju prekide, podvrgavaju se planiranom održavanju, mijenjaju se cijelo vrijeme. Hardver se ažurira, prekidači se mijenjaju, sve se stalno poboljšava. Kako su, dovraga, uspjeli održati moj program aktivan dvije godine sa svim tim promjenama? Ovo se može činiti kao skromno postignuće u 2020., ali u razdoblju 2005.-2007. bilo je prilično impresivno.
A najdivniji aspekt je da mi pristupi vanjski inženjerski tim u nekoj drugoj državi, vlasnik neke malene, gotovo prazne instance Bigtablea, koji ima nula prometa u posljednje dvije godine - i nude pomoć za njegovo ažuriranje.
Zahvalio sam im, izbrisao pohranu i život je nastavio kao i obično. Ali trinaest godina kasnije, još uvijek razmišljam o tom pismu. Zato što ponekad primam slične e-poruke od Google Clouda. Izgledaju ovako:
Poštovani korisniče Google Clouda,
Kao podsjetnik, ukinut ćemo uslugu [osnovna usluga koju koristite] od kolovoza 2020., nakon čega nećete moći nadograditi svoje instance. Preporučamo nadogradnju na najnoviju verziju, koja je u beta testiranju, nema dokumentaciju, nema migracijski put i unaprijed je zastarjela uz našu ljubaznu pomoć.
Predani smo tome da ova promjena ima minimalan utjecaj na sve korisnike platforme Google Cloud.
Najbolji prijatelji zauvijek,
Google Cloud Platform
Ali ja gotovo nikada ne čitam takva pisma, jer ono što zapravo kažu je:
Poštovani primatelju,
Idi k vragu. Jebi se, jebi se, jebi se. Odbaci sve što radiš jer to nije važno. Ono što je bitno je naše vrijeme. Gubimo vrijeme i novac na održavanje našeg sranja i umorni smo od toga pa ga više nećemo podržavati. Zato odustani od svojih jebenih planova i počni kopati po našoj usranoj dokumentaciji, moleći za bilješke na forumima, i usput, naše novo sranje je potpuno drugačije od starog sranja, jer smo gadno zeznuli ovaj dizajn, heh, ali to je tvoje problem, ne naš.
Nastavljamo ulagati napore kako bismo osigurali da svi vaši razvoji postanu neupotrebljivi u roku od jedne godine.
Molim te odjebi
Google Cloud Platform
A činjenica je da takva pisma dobivam otprilike jednom mjesečno. To se događa tako često i tako stalno da oni neizbježno odgurnuti ja iz GCP-a u anti-cloud kamp. Ne pristajem više ovisiti o njihovom vlasničkom razvoju, jer je devopsima zapravo lakše održavati sustav otvorenog koda na golom virtualnom stroju nego pokušavati držati korak s Googleom s njegovom politikom zatvaranja "zastarjelih" proizvoda.
Prije nego što se vratim na Google Cloud jer ja Nije ni blizu nismo završili s kritiziranjem, pogledajmo učinak tvrtke u nekim drugim područjima. Googleovi inženjeri ponose se svojom disciplinom softverskog inženjeringa, a to je ono što zapravo uzrokuje probleme. Ponos je zamka za neoprezne i naveo je mnoge Googleove zaposlenike da misle da su njihove odluke uvijek ispravne i da je biti u pravu (prema nekoj nejasnoj nejasnoj definiciji) važnije od brige za klijente.
Navest ću neke nasumične primjere iz drugih velikih projekata izvan Googlea, ali nadam se da ovaj obrazac vidite posvuda. To je kako slijedi: kompatibilnost unatrag održava sustave živima i ažuriranima desetljećima.
Kompatibilnost unatrag cilj je dizajna svih uspješnih sustava dizajniranih za otvoreno koristiti, odnosno implementirati s otvorenim kodom i/ili otvorenim standardima. Osjećam se kao da govorim nešto previše očito da je svima čak i neugodno, ali ne. Ovo je političko pitanje, pa su potrebni primjeri.
Prvi sustav koji ću izabrati je najstariji: GNU Emacs, koji je svojevrsni hibrid između Windows Notepada, jezgre OS-a i Međunarodne svemirske postaje. Malo je teško objasniti, ali ukratko, Emacs je platforma stvorena 1976. (da, prije gotovo pola stoljeća) za programiranje koje vas čini produktivnijim, ali pod maskom uređivača teksta.
Koristim Emacs svaki dan. Da, također koristim IntelliJ svaki dan, izrastao je u moćnu alatnu platformu sam po sebi. Ali pisanje proširenja za IntelliJ mnogo je ambiciozniji i složeniji zadatak od pisanja proširenja za Emacs. I što je još važnije, sve što je napisano za Emacs je sačuvano vječito.
Još uvijek koristim softver koji sam napisao za Emacs 1995. I siguran sam da netko koristi module napisane za Emacs sredinom 80-ih, ako ne i ranije. Možda će ih s vremena na vrijeme trebati malo prilagoditi, ali to je stvarno rijetko. Ne znam ništa što sam ikada napisao za Emacs (a napisao sam puno) što je zahtijevalo re-arhitekturu.
Emacs ima funkciju koja se zove make-obsolete za zastarjele entitete. Emacsova terminologija za temeljne računalne koncepte (kao što je "prozor") često se razlikuje od industrijskih konvencija jer ih je Emacs uveo prije mnogo vremena. Ovo je tipična opasnost za one koji su ispred svog vremena: svi vaši pojmovi su netočni. Ali Emacs ima koncept odbacivanja, što se u njihovom žargonu zove zastarjelost.
Ali čini se da u svijetu Emacsa postoji drugačija radna definicija. Drugačija temeljna filozofija, ako hoćete.
U svijetu Emacsa (i u mnogim drugim područjima, koja ćemo pokriti u nastavku), status zastarjelog API-ja u osnovi znači: "Stvarno ne biste trebali koristiti ovaj pristup, jer iako radi, pati od raznih nedostataka koje ćemo popis ovdje. Ali na kraju dana, to je vaš izbor."
U Googleovom svijetu biti zastario znači: "Prekršili smo svoju obvezu prema vama." To je istina. To je ono što to u biti znači. To znači da će vas prisiliti regularno raditi nešto, možda puno raditi, kao kaznu što vjerujete u njih : Imamo najbolji softver. Najbrži! Napraviš sve po uputama, pokreneš svoju aplikaciju ili uslugu i onda bam, nakon godinu-dvije pokvari.
To je kao da prodajete rabljeni auto koji će se sigurno pokvariti nakon 1500 km.
Ovo su dvije potpuno različite filozofske definicije "zastarjelosti". Googleova definicija mirisa . Ne vjerujem u ovo u stvari planirano zastarijevanje u istom smislu kao i Apple. Ali Google definitivno planira razbiti vaše programe, zaobilaznim putem. Znam to jer sam tamo radio kao softverski inženjer više od 12 godina. Imaju nejasne interne smjernice o tome koliko se treba pridržavati kompatibilnosti unazad, ali to u konačnici ovisi o svakom pojedinačnom timu ili usluzi. Ne postoje preporuke na razini poduzeća ili inženjerstva, a najhrabrija preporuka u pogledu ciklusa zastarjelosti je "pokušajte dati korisnicima 6-12 mjeseci za nadogradnju prije nego što pokvare cijeli sustav."
Problem je mnogo veći nego što misle i trajat će godinama jer briga za klijente nije u njihovom DNK. Više o tome u nastavku.
U ovom ću trenutku dati hrabru izjavu da je Emacs uspješan u velikoj mjeri, čak i čak u osnovi jer tako ozbiljno shvaćaju kompatibilnost sa prethodnim verzijama. Zapravo, ovo je teza našeg članka. Uspješni, dugovječni otvoreni sustavi duguju svoj uspjeh mikrozajednicama koje žive oko njih desetljećima proširenja/dodaci. Ovo je ekosustav. Već sam govorio o prirodi platformi io njihovoj važnosti, te o tome kako Google nikada u cijeloj svojoj korporativnoj povijesti nije razumio što ide u stvaranje uspješne otvorene platforme izvan Androida ili Chromea.
Zapravo, trebao bih nakratko spomenuti Android jer vjerojatno razmišljate o njemu.
Kao prvo, Android nije Google. Nemaju gotovo ništa zajedničko jedno s drugim. Android je tvrtka koju je kupio Google u srpnju 2005., tvrtki je bilo dopušteno da radi više-manje autonomno i zapravo je ostala uglavnom netaknuta u godinama koje su uslijedile. Android je notorna tehnološka skupina i jednako zloglasna škakljiva organizacija. Kao što je jedan zaposlenik Googlea rekao: "Ne možete se samo prijaviti na Android."
U prethodnom sam članku raspravljao o tome koliko su loše bile neke od ranih Androidovih dizajnerskih odluka. Dovraga, kad sam napisao taj članak, izbacivali su sranje pod nazivom "instant aplikacije" koje su sada (iznenađenje!) , i suosjećam ako ste bili dovoljno glupi da poslušate Google i premjestite svoj sadržaj u ove instant aplikacije.
Ali ovdje postoji razlika, značajna razlika, a to je da Android ljudi stvarno razumiju koliko su platforme važne, daju sve od sebe da stare Android aplikacije rade. Zapravo, njihovi napori da održe kompatibilnost unatrag toliko su ekstremni da sam se čak i ja, tijekom svog kratkog angažmana u Android odjelu prije nekoliko godina, našao kako ih pokušavam uvjeriti da odbace podršku 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. Žao mi je Android momci! Sad kad sam bio u Indoneziji, razumijem zašto ih trebamo).
Ljudi koji se bave Androidom guraju kompatibilnost unatrag do gotovo nezamislivih krajnosti, gomilajući ogromne količine naslijeđenog tehničkog duga u svojim sustavima i lancima alata. O moj Bože, trebali biste vidjeti neke od ludih stvari koje moraju učiniti u svom sustavu izrade, a sve u ime kompatibilnosti.
Zbog toga dodjeljujem Androidu željnu nagradu "Ti nisi Google". Oni zapravo ne žele postati Google, koji ne zna stvarati trajne platforme, nego Android zna, kako to učiniti. I tako je Google vrlo pametan u jednom pogledu: dopušta 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 zahtijevali prepravite i redizajnirajte svoju aplikaciju! Kao da će ljudi jednostavno prepisati dva milijuna prijava. Pretpostavljam da su Instant Apps ideja nekog Googlera.
Ali postoji razlika. Kompatibilnost unatrag ima visoku cijenu. Sam Android snosi teret tih troškova, dok Google inzistira da taj teret snosi ti si, klijent koji plaća.
Možete vidjeti Androidovu predanost kompatibilnosti s prethodnim verzijama u njegovim API-jima. Kada imate četiri ili pet različitih podsustava koji rade doslovno istu stvar, to je siguran znak da postoji predanost kompatibilnosti unatrag u srži. Što je u svijetu platformi sinonim za predanost vašim klijentima i vašem tržištu.
Googleov glavni problem ovdje je njihov ponos svojom inženjerskom higijenom. Ne sviđa im se kada postoji mnogo različitih načina da se učini ista stvar, a stari, manje poželjni načini stoje pored novih, otmjenijih načina. Povećava krivulju učenja za one koji su novi u sustavu, povećava teret održavanja naslijeđenih API-ja, usporava brzinu novih značajki, a najveći je grijeh što nije lijep. Google - poput Lady Ascot iz Alice u zemlji čudesa Tima Burtona:
Lady Ascot:
- Alice, znaš li čega se najviše bojim?
- Propadanje aristokracije?
- Bojao sam se da ću ružne unuke.
Da bismo razumjeli kompromis između lijepog i praktičnog, pogledajmo treću uspješnu platformu (nakon Emacsa i Androida) i vidimo kako radi: samu Javu.
Java ima puno zastarjelih API-ja. Deprecation je vrlo popularan među Java programerima, čak popularniji nego u većini programskih jezika. Sama Java, temeljni jezik i biblioteke stalno odbacuju API-je.
Uzmimo samo jedan od tisuća primjera, smatrati zastarjelim. Zastarjela je od izdanja Jave 1.2 u prosincu 1998. Prošle su 22 godine otkako je ovo zastarjelo.
Ali moj stvarni kod u proizvodnji i dalje ubija niti svaki dan. Stvarno misliš da je to dobro? Apsolutno! Mislim, naravno, da bih danas ponovno napisao kod, implementirao bih ga drugačije. Ali kod za moju igru, koja je usrećila stotine tisuća ljudi u posljednja dva desetljeća, napisan je s funkcijom zatvaranja niti koje predugo vise, a ja nikad ga nisam morao mijenjati. Poznajem svoj sustav bolje od bilo koga, imam doslovno 25 godina iskustva rada s njim u proizvodnji i mogu sa sigurnošću reći: u mom slučaju zatvaranje ovih specifičnih niti radnika je potpuno bezvrijedan. Nije vrijedno vremena i truda ponovno pisati ovaj kod i hvala Larryju Ellisonu (vjerojatno) što me Oracle nije prisilio da ga ponovno napišem.
Oracle vjerojatno također razumije platforme. Tko zna.
Dokazi se mogu pronaći kroz osnovne Java API-je, koji su prožeti valovima zastarjelosti, poput linija ledenjaka u kanjonu. Možete lako pronaći pet ili šest različitih upravitelja navigacije tipkovnicom (KeyboardFocusManager) u biblioteci Java Swing. Zapravo je teško pronaći Java API koji nije zastario. Ali oni i dalje rade! Mislim da će Java tim uistinu ukloniti API samo ako sučelje predstavlja očigledan sigurnosni problem.
Ljudi, evo o čemu je riječ: svi mi, programeri softvera, jako smo zaposleni i u svakom području softvera suočeni smo s konkurentskim alternativama. U bilo kojem trenutku, programeri u jeziku X razmatraju jezik Y kao moguću zamjenu. Oh, ne vjeruješ mi? Želite li ga nazvati Swift? Kao, svi migriraju na Swift i nitko ga ne napušta, zar ne? Wow, kako malo znaš. Tvrtke računaju troškove dvostrukih mobilnih razvojnih timova (iOS i Android) - i počinju shvaćati da ti razvojni sustavi na više platformi sa smiješnim imenima kao što su Flutter i React Native zapravo rade i da se mogu koristiti za smanjenje veličine njihovih mobilne timove dvostruko ili, obrnuto, učiniti ih dvostruko produktivnijima. Pravi je novac u igri. Da, ima kompromisa, ali, s druge strane, novca.
Hipotetski pretpostavimo da je Apple glupo uzeo primjer od Guida van Rossuma i izjavio da je Swift 6.0 unatrag nekompatibilan sa Swiftom 5.0, baš kao što je Python 3 nekompatibilan s Python 2.
Vjerojatno sam ovu priču ispričao prije desetak godina, ali prije petnaestak godina otišao sam u O'Reillyjev Foo Camp s Guidom, sjedio u šatoru s Paulom Grahamom i hrpom velikih faca. Sjedili smo na vrućini i čekali da Larry Page odleti u svom osobnom helikopteru dok je Guido brbljao o "Python 3000", koji je nazvao po broju godina koje će trebati da svi migriraju tamo. Stalno smo ga pitali zašto krši kompatibilnost, a on je odgovorio: "Unicode." I pitali smo, ako bismo morali ponovno napisati naš kod, koje bismo druge koristi vidjeli? A on je odgovorio "Jooooooooooooooouuuuuuuniiiiiiicoooooooooooooooooooooo."
Ako instalirate Google Cloud Platform SDK ("gcloud"), primit ćete sljedeću obavijest:
Poštovani primatelju,
Željeli bismo vas podsjetiti da je podrška za Python 2 zastarjela, pa se jebite
… i tako dalje. Krug života.
Ali poanta je da svaki programer ima izbor. A ako ih prisilite da dovoljno često prepisuju kod, mogli bi razmisliti drugi opcije. Oni nisu vaši taoci, ma koliko vi to željeli. Oni su vaši gosti. Python je i dalje vrlo popularan programski jezik, ali, kvragu, Python 3(000) napravio je takav nered u sebi, u svojim zajednicama i među korisnicima svojih zajednica da se posljedice ne raščišćavaju već petnaest godina.
Koliko je Python programa prepisano u Go (ili Ruby ili neku drugu alternativu) zbog ove nekompatibilnosti unatrag? Koliko je novog softvera napisano na nečemu što nije Python, iako je može biti napisano u Pythonu, da Guido nije spalio cijelo selo? Teško je reći, ali Python je očito patio. To je veliki nered i svi gube.
Pa recimo da se Apple ugleda na Guida i prekine kompatibilnost. Što mislite da će se sljedeće dogoditi? Pa, možda će 80-90% programera ponovno napisati svoj softver ako je moguće. Drugim riječima, 10-20% korisničke baze automatski odlazi na neki konkurentski jezik, poput Fluttera.
Učinite to više puta i izgubit ćete pola svoje baze korisnika. Kao i u sportu, iu svijetu programiranja bitna je trenutna forma. всё. Svatko tko izgubi polovicu svojih korisnika u pet godina smatrat će se Big Fat Loserom. Morate biti u trendu u svijetu platformi. Ali ovdje će vas nepodržavanje starijih verzija s vremenom uništiti. Zato što svaki put kad se riješite nekih programera, vi (a) ih zauvijek gubite jer su ljuti na vas jer ste prekršili ugovor, i (b) dajete ih svojim konkurentima.
Ironično, također sam pomogao Googleu da postane takva primadona koja zanemaruje kompatibilnost unatrag kada sam stvorio Grok, sustav za analizu i razumijevanje izvornog koda koji olakšava automatizaciju i instrumentiranje samog koda - slično IDE-u, ali ovdje servis u oblaku pohranjuje materijalizirani prikazi svih milijardi redaka Googleovog izvornog koda u velikom skladištu podataka.
Grok je zaposlenicima u Googleu pružio moćan okvir za izvođenje automatiziranih refaktoriranja u cijeloj njihovoj bazi koda (doslovno u cijelom Googleu). Sustav izračunava ne samo vaše uzvodne ovisnosti (o kojima ovisite), već također nizvodno (što ovisi o vama) tako da kada promijenite API-je znate sve koje razbijate! Na ovaj način, kada napravite promjene, možete provjeriti je li svaki korisnik vašeg API-ja ažuriran na novu verziju, au stvarnosti, često s alatom Rosie koji su napisali, možete potpuno automatizirati proces.
To omogućuje Googleovoj bazi kodova da interno bude gotovo nadnaravno čista, budući da imaju te robotske sluge koji se motaju po kući i automatski sve čiste ako preimenuju SomeDespicablyLongFunctionName u SomeDespicablyLongMethodName jer je netko 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 Googleu se dobro smije s Java zajednicom u Googleu zbog njihove navike kontinuiranog refaktoriranja. Ako nešto ponovno pokrenete N puta, to znači da ne samo da ste zeznuli N-1 puta, već nakon nekog vremena postaje prilično jasno da ste vjerojatno zeznuli i iz N-tog pokušaja. No, uglavnom, oni ostaju iznad sve ove galame i čuvaju šifru “čistom”.
Problem počinje kada pokušaju nametnuti ovakav stav svojim klijentima u oblaku i korisnicima drugih API-ja.
Malo sam vas upoznao s Emacsom, Androidom i Javom; pogledajmo najnoviju uspješnu dugovječnu platformu: sam web. Možete li zamisliti kroz koliko je ponavljanja HTTP prošao od 1995. kada smo koristili treptajuće oznake? i ikone "U izradi" na web stranicama.
Ali još uvijek radi! A ove stranice još uvijek rade! Da, ljudi, preglednici su svjetski prvaci u kompatibilnosti sa starijim verzijama. Chrome je još jedan primjer rijetke Googleove platforme koja ima svoje glave na pravi način, a kao što ste mogli pretpostaviti, Chrome učinkovito funkcionira kao tvrtka u sandboxu odvojena od ostatka Googlea.
Također želim zahvaliti našim prijateljima u programerima operativnih sustava: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, itd., što su obavili tako sjajan posao kompatibilnosti unazad na njihovim uspješnim platformama (Apple dobiva C u najboljem slučaju s The loša strana je što stalno kvare sve bez ikakvog dobrog razloga, ali zajednica to nekako zaobilazi sa svakim izdanjem, a OS X spremnici još uvijek nisu potpuno zastarjeli... još).
Ali čekaj, kažeš. Ne uspoređujemo li jabuke s narančama - samostalne softverske sustave na jednom stroju poput Emacs/JDK/Android/Chrome naspram sustava s više poslužitelja i API-ja poput usluga u oblaku?
Eto, jučer sam tvitao o ovome, ali sam u stilu Larryja Walla (tvorac programskog jezika Perl - cca. per.) po principu "sranje/pravila" potražio riječ obustavljeno na stranicama za razvojne programere Google i Amazon. I iako AWS ima stotine puta više ponuda usluga od GCP-a, Googleova dokumentacija za razvojne programere spominje obustavu oko sedam puta češće.
Ako netko u Googleu ovo čita, vjerojatno je spreman izvući grafikone u stilu Donalda Trumpa koji pokazuju da zapravo sve rade kako treba i da ne bih trebao praviti nepravedne usporedbe poput "broj spominjanja riječi zastarjelo u odnosu na broj usluga" "
Ali nakon svih ovih godina, Google Cloud je i dalje usluga broj 3 (nikada nisam napisao članak o neuspješnom pokušaju da postanem broj 2), ali ako je vjerovati upućenima, postoji zabrinutost da bi uskoro mogli pasti na broj 4.
Nemam nikakve uvjerljive argumente kojima bih "dokazao" svoju tezu. Sve što imam su živopisni primjeri koje sam skupio tijekom 30 godina kao programer. Već sam spomenuo duboko filozofsku prirodu ovog problema; na neki je način ispolitiziran u zajednicama programera. Neki vjeruju da stvaratelji platforme bi trebale brinuti o kompatibilnosti, dok druge smatraju da je to problem Korisnici (samih programera). Jedan od dva. Doista, nije li političko pitanje kada odlučujemo tko će snositi troškove zajedničkih problema?
Dakle, ovo je politika. I vjerojatno će biti ljutitih odgovora na moj govor.
Kao korisnik Google Cloud Platform, a kao AWS korisnik već dvije godine (dok sam radio za Grab), mogu reći da postoji velika razlika između Amazonove i Googleove filozofije kada su u pitanju prioriteti. Ne razvijam aktivno na AWS-u, pa ne znam koliko često uklanjaju stare API-je. Ali postoji sumnja da se to ne događa ni približno tako često kao u Googleu. I doista vjerujem da je ovaj izvor stalnih kontroverzi i frustracija u GCP-u jedan od najvećih čimbenika koji koče razvoj platforme.
Znam da nisam naveo konkretne primjere GCP sustava koji više nisu podržani. Mogu reći da je gotovo sve što sam koristio, od mreža (od najstarijih do VPC-a) do pohrane (Cloud SQL v1-v2), Firebase (sada Firestore s potpuno drugačijim API-jem), App Engine (da i ne počinjemo) , krajnje točke u oblaku Krajnja točka u oblaku i do... ne znam - apsolutno sve ovo prisilili su vas da ponovno napišete kod nakon najviše 2-3 godine, a nikada nisu automatizirali migraciju umjesto vas, a često . Kao da je tako trebalo biti.
I svaki put kad pogledam AWS, pitam se zašto sam dovraga još uvijek na GCP-u. Oni očito ne trebaju klijente. Što im je potrebno покупатели. Shvaćate li razliku? Dopustite da objasnim.
Google Cloud ima , gdje ljudi predlažu svoja softverska rješenja, a kako bi izbjegli efekt praznog restorana, morali su ga napuniti nekim prijedlozima, pa su sklopili ugovor s tvrtkom pod nazivom Bitnami za izradu hrpe rješenja koja se postavljaju "jednim klikom", ili bi trebala Sam pišem "rješenja", jer ona ne rješavaju ništa. Oni jednostavno postoje kao potvrdni okviri, kao marketinški dodaci, a Google nikada nije mario radi li neki od alata. Poznajem voditelje proizvoda koji su bili na vozačkom mjestu i uvjeravam vas da te ljude nije briga.
Uzmimo, na primjer, navodno rješenje za implementaciju "jednim klikom". . Nasmrt sam se razbolio od Google Cloud SQL smicalica, pa sam kao alternativu počeo tražiti izgradnju vlastitog Percona klastera. I ovaj put se činilo da je Google napravio dobar posao, uštedjet će mi malo vremena i truda jednim pritiskom na gumb!
Pa super, idemo. Slijedimo vezu i kliknimo ovaj gumb. Odaberite "Da" kako biste prihvatili sve zadane postavke i implementirali klaster u svoj Google projekt u oblaku. Haha, ne ide. Ništa od ovog sranja ne funkcionira. Alat nikada nije testiran i počeo je truliti od prve minute, a ne bi me iznenadilo da više od polovice "rješenja" budu implementacije jednim klikom (sada nam je jasno zašto navodnici) općenito Ne radi. Ovo je apsolutno beznadna tama, u koju je bolje ne ulaziti.
Ali Google je u pravu porivi da ih koristite. Oni to žele kupio. Za njih je to transakcija. Oni ne žele ništa podrška. To nije dio Googleove DNK. Da, inženjeri se međusobno podupiru, što dokazuje i moja priča s Bigtableom. Ali u proizvodima i uslugama za obične ljude oni uvijek bili nemilosrdni u , koji ne zadovoljava granice profitabilnosti čak i ako ima milijune korisnika.
A ovo predstavlja pravi izazov za GCP jer je ovo DNK iza svih ponuda u oblaku. Ne pokušavaju ništa podržati; Dobro je poznato da odbijaju ugostiti (kao upravljanu uslugu) bilo koji softver treće strane do, sve dok AWS ne učini isto i oko toga izgradi uspješan biznis, a kada kupci doslovno zahtijevaju isto. Međutim, potrebno je malo truda da se Google natjera da nešto podrži.
Ovaj nedostatak kulture podrške, zajedno s mentalitetom "slomimo ga da bude ljepši", otuđuje programere.
A to nije dobra stvar ako želite izgraditi dugovječnu platformu.
Google, probudi se, dovraga. Sada je 2020. Još uvijek gubiš. Vrijeme je da se dobro pogledate u ogledalo i odgovorite želite li doista ostati u poslu u oblaku.
Ako želiš ostati onda prestani sve razbijati. Ljudi, vi ste bogati. Mi programeri ne. Dakle, kada se radi o tome tko će snositi teret kompatibilnosti, morate ga preuzeti na sebe. Ne za nas.
Jer postoje još barem tri jako dobra oblaka. Oni pozivaju.
A sada ću nastaviti s popravljanjem svih svojih pokvarenih sustava. Eh.
Do sljedećeg puta!
PS Ažuriranje nakon čitanja nekih rasprava o ovom članku (rasprave su sjajne, btw). Podrška za Firebase nije ukinuta i ne postoje planovi za koje ja znam. Međutim, imaju gadnu pogrešku u strujanju koja uzrokuje zastoj Java klijenta u App Engineu. Jedan od njihovih inženjera pomogao mi je riješiti ovaj problem, kad sam radio u Googleu, ali nikad zapravo nisu popravili pogrešku, tako da imam usrano rješenje da moram svaki dan ponovno pokretati aplikaciju GAE. I tako već četiri godine! Sada imaju Firestore. Trebat će puno rada da se pređe na njega jer je to potpuno drugačiji sustav i Firebase bug nikada neće biti ispravljen. Kakav se zaključak može izvući? Možete dobiti pomoć ako radite u poduzeću. Vjerojatno sam jedini koji koristi Firebase na GAE-u jer bilježim manje od 100 ključeva u 100% nativnu aplikaciju i ona prestaje raditi svakih nekoliko dana zbog poznatog buga. Što mogu reći osim da ga koristite na vlastitu odgovornost. Prelazim na Redis.
Također sam vidio kako neki iskusniji korisnici AWS-a govore da AWS obično nikada ne prestaje podržavati bilo koje usluge, a SimpleDB je sjajan primjer. Čini se da su moje pretpostavke da AWS nema istu bolest kraja podrške kao Google opravdane.
Osim toga, primijetio sam da je prije 20 dana tim Google App Enginea pokvario hosting kritične Go biblioteke, isključivši GAE aplikaciju jednog od temeljnih Go programera. Bilo je stvarno glupo.
Konačno, čuo sam kako zaposlenici Googlea već raspravljaju o ovom problemu i općenito se slažu sa mnom (volim vas, ljudi!). Ali čini se da misle da je problem nerješiv jer Googleova kultura nikada nije imala pravu strukturu poticaja. Mislio sam da bi bilo dobro odvojiti malo vremena za raspravu o apsolutno nevjerojatnom iskustvu koje sam stekao radeći s AWS inženjerima dok sam radio u Grabu. Jednog dana u budućnosti, nadam se!
I da, 2005. imali su različite vrste mesa morskog psa na divovskom bifeu u zgradi 43, a meni je najdraže bilo meso morskog psa čekićara. Međutim, do 2006. Larry i Sergei su se riješili svih nezdravih grickalica. Dakle, tijekom priče o Bigtableu 2007. doista nije bilo morskih pasa i ja sam vas prevario.
Kad sam prije četiri godine gledao Bigtable u oblaku (manje ili više), tu je bila cijena. Čini se da je sada malo pao, ali to je još uvijek jako puno za prazno skladište podataka, pogotovo jer moja prva priča pokazuje koliko je prazna velika tablica beznačajna u njihovoj mjeri.
Oprostite što sam uvrijedio Apple zajednicu i nisam rekao ništa lijepo o Microsoftu itd. U redu ste, stvarno cijenim svu raspravu koju je ovaj članak pokrenuo! Ali ponekad se trebate malo pomiriti da biste započeli raspravu, znate?
Hvala na čitanju.
Ažuriranje 2, 19.08.2020. Pruga !
Ažuriranje 3, 31.08.2020. Kontaktirao me Googleov inženjer na Cloud Marketplaceu za kojeg se ispostavilo da je moj stari prijatelj. Želio je otkriti zašto C2D ne radi, a na kraju smo shvatili da je to zato što sam svoju mrežu izgradio prije mnogo godina, a C2D nije radio na naslijeđenim mrežama jer u njihovim predlošcima nedostaje parametar podmreže. Mislim da je za potencijalne korisnike GCP-a najbolje da budu sigurni da poznaju dovoljno inženjera u Googleu...
Izvor: www.habr.com