La naiba Google, nu am vrut să mai scriu pe blog. Am atât de multe de făcut. Blogging-ul necesită timp, energie și creativitate, pe care le-aș putea folosi: cărțile mele, , jocul meu și așa mai departe. Dar m-ai enervat suficient încât trebuie să scriu asta.
Deci, să terminăm cu asta.
Permiteți-mi să încep cu o poveste scurtă, dar instructivă, de când am început să lucrez la Google. Știu că am spus o mulțime de lucruri rele despre Google în ultima vreme, dar mă supără când propria mea companie ia în mod regulat decizii de afaceri incompetente. În același timp, trebuie să îi dăm cuvenția: infrastructura internă a Google este cu adevărat extraordinară, se poate spune cu siguranță că nu există nimic mai bun astăzi. Fondatorii Google au fost ingineri mult mai buni decât voi fi eu vreodată, iar această poveste nu face decât să confirme acest fapt.
În primul rând, un mic context: Google are o tehnologie de stocare a datelor numită . A fost o realizare tehnică remarcabilă, una dintre primele (dacă nu prima) stocare cheie-valoare „infinit scalabilă” (K/V): în esență începutul NoSQL. În aceste zile, Bigtable încă se descurcă bine în spațiul de stocare K/V destul de aglomerat, dar la acea vreme (2005) era uimitor de cool.
Un lucru amuzant despre Bigtable este că aveau obiecte din planul de control intern (ca parte a implementării) numite servere de tabletă, cu indici mari, iar la un moment dat au devenit un blocaj la scalarea sistemului. Inginerii Bigtable erau nedumeriți cu privire la modul de implementare a scalabilității și brusc și-au dat seama că ar putea înlocui serverele de tablete cu alte stocări Bigtable. Deci Bigtable face parte din implementarea Bigtable. Aceste facilități de depozitare sunt acolo la toate nivelurile.
Un alt detaliu interesant este că pentru o perioadă Bigtable a devenit popular și omniprezent în cadrul Google, fiecare echipă având propriul său depozit. Așa că, la una dintre întâlnirile de vineri, Larry Page a întrebat în treacăt cu dezinvoltură: „De ce avem mai multe Bigtable? De ce nu doar unul?” În teorie, un spațiu de stocare ar trebui să fie suficient pentru toate nevoile de stocare ale Google. Desigur, nu au mers niciodată doar la unul din motive practice de dezvoltare (cum ar fi consecințele unui potențial eșec), dar teoria a fost interesantă. Un singur depozit pentru întregul Univers (Apropo, știe cineva dacă Amazon a făcut asta cu Sable-ul lor?)
Oricum, iată povestea mea.
La acea vreme, lucram la Google de puțin peste doi ani și într-o zi am primit un e-mail de la echipa de ingineri Bigtable care mergea cam așa:
Dragă Steve,
Salutare din partea echipei Bigtable. Dorim să vă informăm că la [numele centrului de date] utilizați un binar Bigtable foarte, foarte vechi. Această versiune nu mai este acceptată și dorim să vă ajutăm să faceți upgrade la cea mai recentă versiune.
Vă rog să-mi spuneți dacă puteți programa ceva timp pentru a lucra împreună la această problemă.
Toate cele bune,
Echipa Bigtable
Pe Google primești o mulțime de e-mailuri, așa că la prima vedere am citit ceva de genul:
Stimate Destinatar,
Salutare din partea vreunei echipe. Vrem să comunicăm acel bla bla bla bla bla. Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla imediat.
Vă rugăm să ne spuneți dacă puteți programa o parte din timpul dumneavoastră prețios pentru bla, bla, bla.
Toate cele bune,
Un fel de comandă
Aproape că l-am șters imediat, dar la marginea conștiinței am simțit un sentiment dureros și sâcâitor că nu chiar arată totuși ca o scrisoare formală evident, că destinatarul s-a înșelat pentru că nu am folosit Bigtable.
Dar era ciudat.
Mi-am petrecut restul zilei, alternativ, gândindu-mă la muncă și la ce fel de carne de rechin să încerc în microbucătărie, dintre care cel puțin trei erau suficient de aproape pentru a lovi de pe scaun cu o aruncare bine țintită a unui biscuit, dar Gândul de a scrie nu mi-a lăsat niciodată un sentiment în creștere ușoară anxietate.
Mi-au spus clar numele. Și e-mailul a fost trimis la adresa mea de e-mail, nu a altcuiva și nu este cc: sau bcc:. Tonul este foarte personal și clar. Poate că aceasta este un fel de greșeală?
În cele din urmă, curiozitatea m-a învins și m-am dus să mă uit la consola Borg din centrul de date pe care l-au menționat.
Și, desigur, aveam stocarea BigTable în gestiune. Scuze, ce? M-am uitat la conținutul lui și wow! Era de la incubatorul Codelab în care am stat în prima mea săptămână la Google, în iunie 2005. Codelab v-a forțat să rulați Bigtable pentru a scrie niște valori acolo și se pare că nu am închis niciodată stocarea după aceea. Încă funcționa chiar dacă au trecut mai bine de doi ani.
Există mai multe aspecte demne de remarcat în această poveste. În primul rând, munca Bigtable a fost atât de nesemnificativă pe scara Google, încât abia doi ani mai târziu cineva a observat spațiul de stocare suplimentar și doar pentru că versiunea binarului era depășită. Pentru comparație, m-am gândit cândva să folosesc pentru jocul meu online. La acea vreme, acest serviciu costa aproximativ 16 USD pe an. gol Bigtable pe GCP. Nu spun că te înșelează, dar în opinia mea personală, sunt mulți bani pentru o bază de date goală.
Un alt aspect demn de remarcat este acela de depozitare încă lucrează după doi ani. WTF? Centrele de date vin și pleacă; se confruntă cu întreruperi, fac întreținere programată, se schimbă tot timpul. Hardware-ul este actualizat, comutatoarele sunt schimbate, totul este îmbunătățit constant. Cum naiba au putut să-mi mențină programul în funcțiune timp de doi ani cu toate aceste schimbări? Aceasta poate părea o realizare modestă în 2020, dar în 2005-2007 a fost destul de impresionant.
Iar cel mai minunat aspect este că o echipă de inginerie din afară se abordează de mine, proprietarul unei instanțe minuscule, aproape goale, de Bigtable, care a trafic zero în ultimii doi ani - și oferă ajutor pentru actualizarea acestuia.
Le-am mulțumit, am șters spațiul de stocare și viața a continuat ca de obicei. Dar treisprezece ani mai târziu, încă mă gândesc la acea scrisoare. Pentru că uneori primesc e-mailuri similare de la Google Cloud. Arata asa:
Stimate utilizator Google Cloud,
Pentru a vă reaminti, vom întrerupe serviciul [serviciul esențial pe care îl utilizați] începând cu august 2020, după care nu veți mai putea să vă actualizați instanțele. Vă recomandăm să faceți upgrade la cea mai recentă versiune, care este în testare beta, nu are documentație, nu are cale de migrare și este depășită anterior cu ajutorul nostru amabil.
Ne angajăm să ne asigurăm că această schimbare are un impact minim asupra tuturor utilizatorilor platformei Google Cloud.
Cei mai buni prieteni pentru totdeauna,
Google Cloud Platform
Dar aproape niciodată nu citesc astfel de scrisori, pentru că ceea ce spun ei de fapt este:
Stimate Destinatar,
Du-te dracu. La dracu, la dracu, la dracu'. Renunță la tot ce faci pentru că nu contează. Ceea ce contează este timpul nostru. Pierdem timp și bani întreținându-ne prostiile și ne-am săturat de asta așa că nu o vom mai susține. Așa că renunță la planurile tale și începe să cauti prin documentația noastră proastă, cerșind resturi de pe forumuri și, apropo, noul nostru rahat este complet diferit de vechiul rahat, pentru că am stricat acest design destul de prost, heh, dar asta e ta problema, nu a noastră.
Continuăm să depunem eforturi pentru a ne asigura că toate dezvoltările dvs. devin inutilizabile în decurs de un an.
Te rog la dracu
Google Cloud Platform
Și adevărul este că primesc astfel de scrisori cam o dată pe lună. Acest lucru se întâmplă atât de des și atât de constant încât ei inevitabil Respins eu de la GCP la tabăra anti-cloud. Nu mai sunt de acord să depind de dezvoltările lor de proprietate, pentru că, de fapt, este mai ușor pentru devopți să mențină un sistem open source pe o mașină virtuală goală decât să încerce să țină pasul cu Google cu politica sa de închidere a produselor „învechite”.
Înainte să mă întorc la Google Cloud, deoarece eu chiar aproape nu ați terminat să le criticăm, să ne uităm la performanța companiei în alte domenii. Inginerii Google se mândresc cu disciplina lor de inginerie software, iar aceasta este ceea ce cauzează de fapt probleme. Mândria este o capcană pentru cei neprudenți și i-a determinat pe mulți angajați Google să creadă că deciziile lor sunt întotdeauna corecte și că a avea dreptate (după o definiție vagă neclară) este mai important decât să-și pese de clienți.
Voi da câteva exemple aleatorii din alte proiecte mari din afara Google, dar sper că vedeți acest model peste tot. Este după cum urmează: Compatibilitatea inversă menține sistemele vii și actualizate timp de zeci de ani.
Compatibilitatea inversă este scopul de proiectare al tuturor sistemelor de succes pentru care sunt concepute deschis utilizare, adică implementată cu cod sursă deschisă și/sau standarde deschise. Simt că spun ceva prea evident că toată lumea este chiar inconfortabilă, dar nu. Aceasta este o problemă politică, așa că sunt necesare exemple.
Primul sistem pe care îl voi alege este cel mai vechi: GNU Emacs, care este un fel de hibrid între Windows Notepad, nucleul sistemului de operare și Stația Spațială Internațională. Este puțin greu de explicat, dar pe scurt, Emacs este o platformă creată în 1976 (da, cu aproape jumătate de secol în urmă) pentru programare pentru a vă face mai productiv, dar mascandu-vă ca un editor de text.
Folosesc Emacs în fiecare zi. Da, folosesc și IntelliJ în fiecare zi, a devenit o platformă puternică de instrumente în sine. Dar scrierea extensiilor pentru IntelliJ este o sarcină mult mai ambițioasă și complexă decât scrierea extensiilor pentru Emacs. Și mai important, tot ce este scris pentru Emacs este păstrat veșnic.
Încă folosesc software-ul pe care l-am scris pentru Emacs în 1995. Și sunt sigur că cineva folosește module scrise pentru Emacs la mijlocul anilor 80, dacă nu mai devreme. S-ar putea să necesite câteva modificări din când în când, dar acest lucru este într-adevăr destul de rar. Nu știu nimic din ce am scris vreodată pentru Emacs (și am scris multe) care a necesitat o re-arhitectură.
Emacs are o funcție numită make-obsolete pentru entitățile învechite. Terminologia Emacs pentru conceptele fundamentale de calculator (cum ar fi ce este o „fereastră”) diferă adesea de convențiile din industrie, deoarece Emacs le-a introdus cu mult timp în urmă. Acesta este un pericol tipic pentru cei care sunt înaintea timpului lor: toți termenii tăi sunt incorecți. Dar Emacs are un concept de depreciere, care în jargonul lor este numit învechire.
Dar în lumea Emacs pare să existe o altă definiție de lucru. O altă filozofie de bază, dacă vreți.
În lumea Emacs (și în multe alte domenii, pe care le vom acoperi mai jos), starea API depreciată înseamnă practic: „Nu ar trebui să utilizați această abordare, deoarece, în timp ce funcționează, suferă de diverse deficiențe pe care le vom elimina. lista aici. Dar la sfârșitul zilei, este alegerea ta.”
În lumea Google, a fi învechit înseamnă „Încălcăm angajamentul nostru față de tine”. Asta este adevărat. Aceasta este ceea ce înseamnă în esență. Asta înseamnă că te vor forța regulat fă ceva muncă, poate multă muncă, ca pedeapsă pentru că ai crezut în ele : Avem cel mai bun software. Cel mai rapid! Faceți totul conform instrucțiunilor, vă lansați aplicația sau serviciul, apoi bam, după un an sau doi se rupe.
Este ca și cum ai vinde o mașină uzată care cu siguranță se va strica după 1500 km.
Acestea sunt două definiții filozofice complet diferite ale „învechirii”. Definiția Google a mirosului . Nu cred asta de fapt uzura planificată în același sens ca Apple. Dar Google intenționează cu siguranță să vă spargă programele, într-un mod obișnuit. Știu asta pentru că am lucrat acolo ca inginer software timp de peste 12 ani. Au linii directoare interne vagi cu privire la cât de mult ar trebui urmată compatibilitatea inversă, dar în cele din urmă depinde de fiecare echipă sau serviciu în parte. Nu există recomandări la nivel de întreprindere sau de inginerie, iar cea mai îndrăzneață recomandare în ceea ce privește ciclurile de uzură este „încercați să acordați clienților 6-12 luni pentru a face upgrade înainte de a-și rupe întregul sistem”.
Problema este mult mai mare decât cred ei și va persista ani de zile, deoarece îngrijirea clienților nu este în ADN-ul lor. Mai multe despre asta mai jos.
În acest moment, voi face o declarație îndrăzneață că Emacs are succes în mare măsură și chiar fundamental pentru că ei iau foarte în serios compatibilitatea cu înapoi. De fapt, aceasta este teza articolului nostru. Sistemele deschise de succes și de lungă durată își datorează succesul microcomunităților care au trăit în jurul lor de zeci de ani extensii/plugin-uri. Acesta este ecosistemul. Am vorbit deja despre natura platformelor și cât de importante sunt acestea și despre modul în care Google nu a înțeles niciodată în întreaga sa istorie corporativă ce înseamnă crearea unei platforme deschise de succes în afara Android sau Chrome.
De fapt, ar trebui să menționez pe scurt Android pentru că probabil te gândești la asta.
În primul rând, Android nu este Google. Ei nu au aproape nimic în comun unul cu celălalt. Android este o companie care a fost achiziționată de Google în iulie 2005, companiei i s-a permis să opereze mai mult sau mai puțin autonom și, de fapt, a rămas în mare parte neatinsă în anii care au trecut. Android este o stivă de tehnologie notorie și o organizație la fel de notorie. După cum a spus un Googler, „Nu vă puteți conecta pur și simplu la Android”.
Într-un articol anterior, am discutat cât de proaste au fost unele dintre deciziile timpurii de proiectare ale Android. La naiba, când am scris acel articol, ei au lansat prostii numite „aplicații instant”, care sunt acum (surpriză!) , și simpatizez dacă ați fost suficient de prost încât să ascultați Google și să vă mutați conținutul în aceste aplicații instantanee.
Dar există o diferență aici, o diferență semnificativă, și anume că oamenii Android înțeleg cu adevărat cât de importante sunt platformele, ei încearcă tot posibilul să mențină vechile aplicații Android să funcționeze. De fapt, eforturile lor de a menține compatibilitatea inversă sunt atât de extreme încât chiar și eu, în timpul scurtei mele perioade la divizia Android, acum câțiva ani, m-am trezit încercând să-i conving să renunțe la suportul pentru unele dintre cele mai vechi dispozitive și API-uri (m-am înșelat , așa cum a fost în multe alte lucruri din trecut și din prezent. Îmi pare rău, băieți Android! Acum că am fost în Indonezia, înțeleg de ce avem nevoie de ele).
Oamenii Android împing compatibilitatea înapoi la extreme aproape inimaginabile, acumulând cantități masive de datorii tehnice moștenite în sistemele și lanțurile lor de instrumente. Doamne, ar trebui să vezi unele dintre lucrurile nebunești pe care trebuie să le facă în sistemul lor de construcție, toate în numele compatibilității.
Pentru aceasta, îi acord lui Android râvnitul premiu „Nu ești Google”. Ei chiar nu vor să devină Google, care nu știe să creeze platforme durabile, ci Android El știe, cum să o facă. Așadar, Google este foarte inteligent într-un singur aspect: le permite oamenilor să facă lucrurile în felul lor pe Android.
Cu toate acestea, aplicațiile instant pentru Android au fost o idee destul de stupidă. Și știi de ce? Pentru că au cerut rescrieți și reproiectați aplicația dvs! Este ca și cum oamenii ar rescrie pur și simplu două milioane de aplicații. Bănuiesc că Instant Apps a fost ideea unui Googler.
Dar există o diferență. Compatibilitatea anterioară are un cost ridicat. Android însuși poartă povara acestor costuri, în timp ce Google insistă ca povara să fie suportată tu ești, client plătitor.
Puteți vedea angajamentul Android față de compatibilitatea inversă în API-urile sale. Când aveți patru sau cinci subsisteme diferite care fac literalmente același lucru, este un semn sigur că există un angajament față de compatibilitatea inversă la bază. Ceea ce în lumea platformelor este sinonim cu angajamentul față de clienții tăi și de piața ta.
Principala problemă a Google aici este mândria lor în igiena lor de inginerie. Nu le place când există multe moduri diferite de a face același lucru, cu moduri vechi, mai puțin dezirabile, lângă modalitățile noi, mai fanteziste. Mărește curba de învățare pentru cei noi în sistem, crește sarcina menținerii API-urilor moștenite, încetinește viteza noilor funcții și păcatul principal este că nu este frumos. Google - ca Lady Ascot din Alice in Wonderland a lui Tim Burton:
Lady Ascot:
- Alice, știi de ce mă tem cel mai mult?
- Declinul aristocrației?
- Mi-a fost teamă că aș fi făcut-o nepoți urâți.
Pentru a înțelege compromisul dintre frumos și practic, să aruncăm o privire la a treia platformă de succes (după Emacs și Android) și să vedem cum funcționează: Java în sine.
Java are o mulțime de API-uri învechite. Deprecierea este foarte populară printre programatorii Java, chiar mai populară decât în majoritatea limbajelor de programare. Java în sine, limbajul de bază și bibliotecile depreciază constant API-urile.
Pentru a lua doar unul dintre miile de exemple, considerată învechită. A fost depreciat de la lansarea Java 1.2 în decembrie 1998. Au trecut 22 de ani de când acest lucru a fost depreciat.
Dar codul meu real în producție încă ucide fire în fiecare zi. Chiar crezi că e bine? Absolut! Adică, desigur, dacă aș rescrie codul astăzi, l-aș implementa altfel. Dar codul jocului meu, care a făcut sute de mii de oameni fericiți în ultimele două decenii, este scris cu o funcție pentru a închide firele care atârnă prea mult și eu nu a trebuit niciodată să-l schimbe. Îmi cunosc sistemul mai bine decât oricine, am literalmente 25 de ani de experiență de lucru cu el în producție și pot spune cu siguranță: în cazul meu, închiderea acestor fire de lucru specifice este complet fără valoare. Nu merită timpul și efortul de a rescrie acest cod și îi mulțumesc lui Larry Ellison (probabil) că Oracle nu m-a forțat să-l rescriu.
Probabil că Oracle înțelege și platformele. Cine ştie.
Dovezi pot fi găsite în API-urile Java de bază, care sunt pline de valuri de uzură, precum liniile unui ghețar într-un canion. Puteți găsi cu ușurință cinci sau șase manageri diferiți de navigare cu tastatură (KeyboardFocusManager) în biblioteca Java Swing. De fapt, este greu să găsești un API Java care să nu fie depreciat. Dar încă funcționează! Cred că echipa Java va elimina cu adevărat un API doar dacă interfața prezintă o problemă de securitate flagrantă.
Iată chestia, oameni buni: noi, dezvoltatorii de software, suntem cu toții foarte ocupați și în fiecare domeniu al software-ului ne confruntăm cu alternative concurente. În orice moment, programatorii din limbajul X iau în considerare limbajul Y ca un posibil înlocuitor. Oh, nu mă crezi? Vrei să-i spui Swift? De exemplu, toată lumea migrează la Swift și nimeni nu o abandonează, nu? Uau, cât de puțin știi. Companiile numără costurile echipelor de dezvoltare mobile duale (iOS și Android) - și încep să realizeze că acele sisteme de dezvoltare multiplatforme cu nume amuzante precum Flutter și React Native chiar funcționează și pot fi folosite pentru a reduce dimensiunea lor. echipele mobile de două ori sau, dimpotrivă, le fac de două ori mai productive. Sunt bani reali în joc. Da, există compromisuri, dar, pe de altă parte, bani.
Să presupunem ipotetic că Apple a luat în mod prostesc un indiciu de la Guido van Rossum și a declarat că Swift 6.0 este incompatibil cu Swift 5.0, la fel cum Python 3 este incompatibil cu Python 2.
Probabil că am spus această poveste acum vreo zece ani, dar acum vreo cincisprezece ani am fost la O'Reilly's Foo Camp cu Guido, am stat într-un cort cu Paul Graham și o grămadă de mari. Ne-am așezat în căldura înăbușitoare, așteptând ca Larry Page să zboare cu elicopterul său personal, în timp ce Guido zbura despre „Python 3000”, pe care l-a numit după numărul de ani pe care i-ar trebui tuturor să migreze acolo. L-am tot întrebat de ce încalcă compatibilitatea, iar el a răspuns: „Unicode”. Și am întrebat, dacă ar trebui să ne rescriem codul, ce alte beneficii am mai vedea? Iar el a răspuns: „Yooooooooooooooouuuuuuniiiiiiicoooooooode”.
Dacă instalați SDK-ul Google Cloud Platform ("gcloud"), veți primi următoarea notificare:
Stimate Destinatar,
Dorim să vă reamintim că suportul pentru Python 2 a fost retras, așa că la naiba
… și așa mai departe. Cercul vietii.
Dar ideea este că fiecare dezvoltator are de ales. Și dacă îi forțezi să rescrie codul suficient de des, s-ar putea gândi alte Opțiuni. Ei nu sunt ostaticii tăi, indiferent cât de mult ai vrea să fie. Ei sunt oaspeții tăi. Python este încă un limbaj de programare foarte popular, dar la naiba, Python 3(000) a creat o asemenea mizerie în sine, în comunitățile sale și printre utilizatorii comunităților sale, încât consecințele nu au fost clarificate de cincisprezece ani.
Câte programe Python au fost rescrise în Go (sau Ruby, sau altă alternativă) din cauza acestei incompatibilități inverse? Cât de mult software nou a fost scris în altceva decât Python, deși acesta ar putea fi scris în Python, dacă Guido nu ar fi ars tot satul? Este greu de spus, dar Python a suferit clar. Este o mizerie uriașă și toată lumea pierde.
Așadar, să presupunem că Apple ține cont de Guido și întrerupe compatibilitatea. Ce crezi că se va întâmpla în continuare? Ei bine, poate 80-90% dintre dezvoltatori își vor rescrie software-ul dacă este posibil. Cu alte cuvinte, 10-20% din baza de utilizatori merge automat la o limbă concurență, cum ar fi Flutter.
Faceți acest lucru de mai multe ori și veți pierde jumătate din baza de utilizatori. La fel ca în sport, în lumea programării, contează și forma actuală. toate. Oricine își pierde jumătate de utilizatori în cinci ani va fi considerat un Big Fat Loser. Trebuie să fii la modă în lumea platformelor. Dar aici nu suportarea versiunilor mai vechi vă va ruina în timp. Pentru că de fiecare dată când scapi de unii dezvoltatori, (a) îi pierzi pentru totdeauna pentru că sunt supărați pe tine pentru că ai încălcat contractul și (b) îi dai concurenților tăi.
În mod ironic, l-am ajutat și pe Google să devină o astfel de primadonă care ignoră compatibilitatea inversă atunci când am creat Grok, un sistem de analiză și înțelegere a codului sursă care face ușoară automatizarea și instrumentarea codului în sine - similar cu un IDE, dar aici se stochează serviciul cloud. a materializat reprezentări ale tuturor miliardelor de linii de cod sursă Google într-un mare depozit de date.
Grok le-a oferit angajaților Google un cadru puternic pentru efectuarea de refactorizări automate în întreaga lor bază de cod (literalmente în Google). Sistemul calculează nu numai dependențele dvs. din amonte (de care depindeți), ci și în aval (care depind de dvs.), așa că atunci când schimbați API-urile, știți pe toți cei pe care îi distrugeți! În acest fel, atunci când faci modificări, poți verifica că fiecare consumator al API-ului tău s-a actualizat la noua versiune și, în realitate, adesea cu instrumentul Rosie pe care l-au scris, poți automatiza complet procesul.
Acest lucru permite ca baza de cod Google să fie în interior aproape supranatural de curată, deoarece acești slujitori robotici se grăbesc prin casă și curăță automat totul dacă au redenumit SomeDespicablyLongFunctionName în SomeDespicablyLongMethodName, deoarece cineva a decis că este un nepot urât și trebuie să fie adormit.
Și sincer, funcționează destul de bine pentru Google... intern. Adică, da, comunitatea Go de la Google râde bine cu comunitatea Java de la Google, din cauza obiceiului lor de refactorizare continuă. Dacă reporniți ceva de N ori, înseamnă că nu numai că l-ați înșurubat de N-1 ori, dar după un timp devine destul de clar că probabil l-ați dat peste cap și la a N-a încercare. Dar, în mare, ei rămân mai presus de toată această agitație și păstrează codul „curat”.
Problema începe atunci când încearcă să impună această atitudine clienților lor cloud și utilizatorilor altor API-uri.
V-am prezentat puțin Emacs, Android și Java; să ne uităm la cea mai recentă platformă de succes de lungă durată: Web-ul însuși. Vă puteți imagina câte iterații a trecut HTTP din 1995, când am folosit etichete intermitente? și pictogramele „În construcție” pe paginile web.
Dar încă funcționează! Și aceste pagini încă funcționează! Da, băieți, browserele sunt campionii mondiali în ceea ce privește compatibilitatea inversă. Chrome este un alt exemplu de platformă Google rară care are capetele înșurubate corect și, după cum probabil ați ghicit, Chrome funcționează efectiv ca o companie cu nisip separată de restul Google.
De asemenea, vreau să le mulțumesc prietenilor noștri din dezvoltatorii de sisteme de operare: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., pentru că au făcut o treabă atât de bună de compatibilitate inversă pe platformele lor de succes (Apple primește un C în cel mai bun caz cu The dezavantajul este că sparg totul tot timpul fără un motiv întemeiat, dar cumva comunitatea ocolește cu fiecare lansare, iar containerele OS X încă nu sunt complet învechite... încă).
Dar stai, zici tu. Nu comparăm merele cu portocalele - sisteme software de sine stătătoare pe o singură mașină precum Emacs/JDK/Android/Chrome versus sisteme multi-server și API-uri precum serviciile cloud?
Ei bine, am postat pe Twitter despre asta ieri, dar în stilul lui Larry Wall (creatorul limbajului de programare Perl - aprox. per.) pe principiul „sucks/rules” am căutat cuvântul depreciată pe site-urile pentru dezvoltatori Google și Amazon. Și deși AWS are sute de de ori mai multe oferte de servicii decât GCP, documentația pentru dezvoltatori Google menționează deprecierea de aproximativ șapte ori mai des.
Dacă cineva de la Google citește asta, probabil că este gata să scoată diagrame în stilul lui Donald Trump care să arate că de fapt fac totul bine și că nu ar trebui să fac comparații nedrepte precum „numărul de mențiuni ale cuvântului depreciat versus numărul de servicii" "
Dar după toți acești ani, Google Cloud este încă serviciul nr. 3 (nu am scris niciodată un articol despre încercarea eșuată de a deveni numărul 2), dar, dacă e de crezut, există unele îngrijorări că ar putea cădea în curând la nr. 4.
Nu am niciun argument convingător pentru a-mi „demonstra” teza. Tot ce am sunt exemplele colorate pe care le-am acumulat în 30 de ani ca dezvoltator. Am menționat deja natura profund filozofică a acestei probleme; într-un fel este politizat în comunitățile de dezvoltatori. Unii cred asta creatori platformelor ar trebui să le pese de compatibilitate, în timp ce alții cred că aceasta este o preocupare utilizatori (dezvoltatorii înșiși). Unul din doi. Într-adevăr, nu este o problemă politică atunci când decidem cine ar trebui să suporte costurile problemelor comune?
Deci asta e politica. Și probabil vor exista răspunsuri supărate la discursul meu.
Ca utilizator Google Cloud Platform și ca utilizator AWS de doi ani (în timp ce lucram pentru Grab), pot spune că există o diferență uriașă între filozofiile Amazon și Google când vine vorba de priorități. Nu dezvolt în mod activ pe AWS, așa că nu știu foarte bine cât de des elimină vechile API-uri. Dar există o suspiciune că acest lucru nu se întâmplă la fel de des ca la Google. Și cred cu adevărat că această sursă de controversă și frustrare constantă în GCP este unul dintre cei mai mari factori care împiedică dezvoltarea platformei.
Știu că nu am numit exemple specifice de sisteme GCP care nu mai sunt acceptate. Pot spune că aproape tot ce am folosit, de la rețele (de la cel mai vechi la VPC) la stocare (Cloud SQL v1-v2), Firebase (acum Firestore cu un API complet diferit), App Engine (să nu începem nici măcar) , punctele finale cloud Cloud Endpoint și până la... Nu știu - absolut toate acestea v-au forțat să rescrieți codul după maximum 2-3 ani și nu au automatizat niciodată migrarea pentru dvs. și adesea . De parcă ar fi trebuit să fie așa.
Și de fiecare dată când mă uit la AWS, mă întreb de ce naiba sunt încă pe GCP. Evident, nu au nevoie de clienți. Ei au nevoie de покупатели. Înțelegi diferența? Lasă-mă să explic.
Google Cloud are , unde oamenii își propun soluțiile software, iar pentru a evita efectul de restaurant gol, au trebuit să-l umple cu niște propuneri, așa că au contractat cu o companie numită Bitnami pentru a crea o grămadă de soluții care sunt implementate cu „un singur clic”, sau ar trebui Eu însumi le scriu „soluții”, pentru că acestea nu rezolvă nimic. Ele există pur și simplu ca casete de selectare, ca umplere de marketing, iar Google nu i-a păsat niciodată dacă vreunul dintre instrumente funcționează cu adevărat. Cunosc manageri de produs care au fost pe scaunul șoferului și vă pot asigura că acestor oameni nu le pasă.
Luați, de exemplu, o soluție de implementare presupusă „cu un singur clic”. . M-am săturat de mișcarea Google Cloud SQL, așa că am început să mă uit la construirea propriului meu cluster Percona ca alternativă. Și de data aceasta Google părea să fi făcut o treabă bună, aveau de gând să-mi economisească timp și efort printr-un clic pe un buton!
Ei bine, hai să mergem. Să urmăm linkul și să facem clic pe acest buton. Selectați „Da” pentru a fi de acord cu toate setările implicite și pentru a implementa clusterul în proiectul dvs. Google cloud. Haha, nu merge. Nimic din porcăriile astea nu funcționează. Instrumentul nu a fost niciodată testat și a început să putrezească din primul minut și nu m-ar surprinde dacă mai mult de jumătate dintre „soluții” sunt implementări cu un singur clic (acum înțelegem de ce ghilimele) în general nu funcționează. Acesta este întuneric absolut fără speranță, unde este mai bine să nu intri.
Dar Google are dreptate îndeamnã tu să le folosești. Ei vor ca tu cumparat. Pentru ei este o tranzacție. Ei nu vor nimic a sustine. Nu face parte din ADN-ul Google. Da, inginerii se sprijină reciproc, așa cum demonstrează povestea mea cu Bigtable. Dar în produse și servicii pentru oamenii obișnuiți ei mereu au fost nemilos în , care nu indeplineste standardul de rentabilitate chiar daca are milioane de utilizatori.
Și aceasta reprezintă o adevărată provocare pentru GCP, deoarece acesta este ADN-ul din spatele tuturor ofertelor cloud. Ei nu încearcă să susțină nimic; Este bine cunoscut faptul că refuză să găzduiască (ca serviciu gestionat) orice software terță parte pana cand, până când AWS face același lucru și construiește o afacere de succes în jurul ei și când clienții literalmente cer același lucru. Cu toate acestea, este nevoie de un efort pentru ca Google să sprijine ceva.
Această lipsă de cultură a suportului, cuplată cu mentalitatea „să o rupem pentru a o face mai frumoasă”, îi înstrăinează pe dezvoltatori.
Și asta nu este un lucru bun dacă doriți să construiți o platformă de lungă durată.
Google, trezește-te, la naiba. Este 2020 acum. Încă pierzi. Este timpul să vă uitați cu atenție în oglindă și să răspundeți dacă doriți cu adevărat să rămâneți în domeniul cloud.
Dacă vrei să rămâi atunci nu mai sparge totul. Băieți, sunteți bogați. Noi dezvoltatorii nu. Deci, când vine vorba de cine va suporta povara compatibilității, trebuie să vă asumați. Nu pentru noi.
Pentru că mai sunt cel puțin trei nori foarte buni. Ei fac semn.
Și acum voi trece la repararea tuturor sistemelor mele defecte. Eh.
Pana data viitoare!
PS Update după ce ați citit câteva dintre discuțiile din acest articol (discuțiile sunt grozave, btw). Asistența Firebase nu a fost întreruptă și nu există planuri de care să fiu conștient. Cu toate acestea, au o eroare de streaming urâtă care face ca clientul Java să se blocheze în App Engine. Unul dintre inginerii lor m-a ajutat să rezolv această problemă, când lucram la Google, dar nu au remediat niciodată eroarea, așa că am o soluție proastă de a trebui să repornesc aplicația GAE în fiecare zi. Și așa a fost de patru ani! Acum au Firestore. Va fi nevoie de multă muncă pentru a migra la acesta, deoarece este un sistem complet diferit și eroarea Firebase nu va fi remediată niciodată. Ce concluzie se poate trage? Puteți obține ajutor dacă lucrezi într-o companie. Probabil că sunt singurul care folosește Firebase pe GAE, deoarece înregistrez mai puțin de 100 de chei într-o aplicație 100% nativă și nu mai funcționează la fiecare două zile din cauza unei erori cunoscute. Ce pot să spun în afară de a-l folosi pe propriul risc. Trec la Redis.
De asemenea, am văzut câțiva utilizatori AWS mai experimentați spunând că, de obicei, AWS nu încetează niciodată să accepte niciun serviciu, iar SimpleDB este un exemplu grozav. Ipotezele mele că AWS nu are aceeași boală de final de asistență ca și Google par să fie justificate.
În plus, am observat că acum 20 de zile, echipa Google App Engine a spart găzduirea unei biblioteci Go critice, închizând o aplicație GAE de la unul dintre dezvoltatorii de bază Go. A fost cu adevărat stupid.
În cele din urmă, i-am auzit pe Google care discută deja această problemă și, în general, sunt de acord cu mine (vă iubesc, băieți!). Dar ei par să creadă că problema este de nerezolvat, deoarece cultura Google nu a avut niciodată structura de stimulente potrivită. M-am gândit că ar fi bine să îmi iau ceva timp pentru a discuta despre experiența absolut uimitoare pe care am avut-o lucrând cu inginerii AWS în timp ce lucram la Grab. Într-o zi în viitor, sper!
Și da, în 2005 aveau diferite tipuri de carne de rechin la bufetul uriaș din clădirea 43, iar preferata mea a fost carnea de rechin-ciocan. Cu toate acestea, până în 2006, Larry și Serghei au scăpat de toate gustările nesănătoase. Deci, în timpul poveștii Bigtable din 2007, chiar nu au existat rechini și te-am înșelat.
Când m-am uitat la cloud Bigtable în urmă cu patru ani (dați sau primiți), aici a fost costul. Se pare că a scăzut puțin acum, dar asta este încă foarte mult pentru un depozit de date gol, mai ales că prima mea poveste arată cât de lipsită de importanță este o masă mare goală la scara lor.
Îmi pare rău că am jignit comunitatea Apple și nu am spus nimic frumos despre Microsoft etc. Sunteți în regulă, apreciez foarte mult toată discuția pe care a generat-o acest articol! Dar uneori trebuie să faci valuri pentru a începe o discuție, știi?
Multumesc pentru lectura.
Actualizare 2, 19.08.2020. Dunga !
Actualizare 3, 31.08.2020. Am fost contactat de un inginer Google de la Cloud Marketplace care s-a dovedit a fi un vechi prieten de-al meu. El a vrut să-și dea seama de ce C2D nu funcționează și, în cele din urmă, ne-am dat seama că asta se datora faptului că mi-am construit rețeaua cu ani în urmă, iar C2D nu lucra pe rețelele vechi, deoarece parametrul de subrețea lipsea din șabloanele lor. Cred că cel mai bine este ca utilizatorii potențiali GCP să se asigure că cunosc destui ingineri la Google...
Sursa: www.habr.com