Doamne, Google, nu voiam să mai scriu din nou pe blog. Am atât de multe de făcut. Bloggingul necesită timp, energie și creativitate, pe care aș putea să le folosesc mai bine: cărțile mele, , jocul meu și așa mai departe. Dar m-ai făcut destul de supărat și va trebui să scriu despre asta.
Așa că hai să punem capăt acestei probleme.
Am să încep cu o mică, dar instructivă poveste din vremurile când abia începeam să lucrez la Google. Știu că am vorbit mult rău despre Google în ultima vreme, dar mă deranjează când compania mea natală ia constant decizii de afaceri incompetentă. Totuși, trebuie să recunoaștem: infrastructura internă a Google este cu adevărat excepțională, se poate spune cu tărie că astăzi nu există nimic mai bun. Fondatorii Google au fost ingineri mult mai buni decât voi deveni vreodată și această poveste doar confirmă acest fapt.
În primul rând, puțin context: Google are o tehnologie de stocare a datelor numită . Aceasta a fost o realizare tehnică minunată, una dintre primele (dacă nu chiar prima) „magazin de date” „infinit scalabil” (key-value store, K/V): practic, începutul NoSQL. În zilele noastre, Bigtable își menține o poziție bună într-un spațiu destul de aglomerat de stocare K/V, dar în acele vremuri (2005) a fost pur și simplu incredibil.
Un detaliu amuzant despre Bigtable este că aveau obiecte interne de control (ca parte a implementării) numite servere tablet, cu indici mari, iar într-un anumit moment au devenit un punct de congestie în scalarea sistemului. Inginerii Bigtable se gândeau cum să realizeze scalabilitatea și, dintr-o dată, și-au dat seama că pot înlocui serverele tablet cu alte depozite Bigtable. Așa că Bigtable este o parte a implementării Bigtable. Aceste depozite sunt prezente la toate nivelurile.
O altă detaliu interesant este că, pentru o vreme, Bigtable a devenit popular și omniprezent în cadrul Google, iar fiecare echipă avea propriul său depozit. Așadar, la una dintre întâlnirile de vineri, Larry Page a întrebat cu nonșalanță: „De ce avem mai mult de un Bigtable? De ce nu ne putem descurca doar cu unul?” Teoretic, un singur depozit ar fi trebuit să fie suficient pentru toate nevoile de stocare ale Google. Desigur, din motive practice de dezvoltare, nu au trecut niciodată doar la unul (de exemplu, consecințele unui potențial eșec), dar teoria era interesantă. Un depozit pentru întreaga Univers.între timp, cineva știe, a făcut Amazon ceva similar cu Sable-ul său?)
Așa sau altfel, iată povestea mea.
La acea vreme, lucram la Google de puțin peste doi ani, și într-o zi am primit un email de la echipa de inginerie Bigtable, aproximativ de acest conținut:
Stimate Steve,
Salutări de la echipa Bigtable. Vrem să vă informăm că în centrul de date [numele centrului de date] utilizați un fișier binar Bigtable foarte, foarte vechi. Această versiune nu mai este suportată, și dorim să vă ajutăm să treceți la ultima versiune.
Vă rugăm să ne anunțați dacă puteți programa puțin timp pentru a colabora pe această problemă.
Toate cele bune,
Echipa Bigtable
La Google, primești multe emailuri, așa că, la prima vedere, l-am citit aproximativ așa:
Stimate destinatar,
Salutări de la o echipă oarecare. Vrem să vă informăm că bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, și bla-bla-bla imediat.
Vă rugăm să ne faceți cunoscut dacă puteți programa o parte din timpul dumneavoastră prețios pentru bla-bla-bla.
Toate cele bune,
O echipă oarecare
Am fost pe punctul de a-l șterge imediat, dar la limita conștiinței am simțit o senzație apăsătoare că aceasta nu este chiar asemănătoare cu o scrisoare formală, deși evident, că m-am înșelat cu privire la destinatar, pentru că eu nu foloseam Bigtable.
Dar a fost ciudat.
Restul zilei m-am gândit alternativ la muncă și la ce tip de carne de rechin să încerc în micro-bucătărie, dintre care cel puțin trei erau suficient de aproape pentru a ajunge cu o aruncare precisă de biscuit, dar gândul la email nu m-a părăsit, lăsându-mă cu un sentiment tot mai crescând de anxietate ușoară.
Ei clar mi-au pronunțat numele. Și scrisoarea a fost trimisă la adresa mea de email, nu la altcineva, și nu este cc: sau bcc:. Tonul este foarte personal și clar. Poate că este o formulă de greșeală?
În sfârșit, curiozitatea a câștigat și am mers să văd consola Borg în centrul de date pe care l-au menționat.
Și, desigur, ieșirea mea era stocarea BigTable. Ce? Am aruncat o privire asupra conținutului său și - uimitor! Era din incubatorul Codelab, unde am fost în prima săptămână de lucru la Google în iunie 2005. Codelab te obliga să rulezi Bigtable pentru a înregistra câteva valori, iar eu, se pare, nu am închis stocarea după aceea. Încă funcționa, deși trecuseră mai mult de doi ani.
Această poveste are câteva aspecte notabile. În primul rând, funcționarea Bigtable a fost atât de nesemnificativă în cadrul Google, încât a fost observată o stocare în plus abia după doi ani, și asta doar pentru că versiunea binarului era învechită. Ca o compunere, odată am considerat utilizarea pentru jocul meu online. Atunci, acest serviciu costa aproximativ 16.000 de dolari pe an pentru o stocare goală Bigtable pe GCP. Nu spun că te înșală, dar, din punctul meu de vedere, sunt mulți bani pentru o bază de date complet inutilă.
Un alt aspect remarcabil este că stocarea încă funcționa după doi ani. Ce naiba? Centrele de date vin și pleacă; ele suferă de întreruperi, au întreținere programată, se schimbă constant. Hardware-ul se actualizează, comutatoarele se mută, totul este mereu îmbunătățit. Cum, naiba, au reușit să păstreze programul meu în funcțiune timp de doi ani, având în vedere toate aceste modificări? Ar putea părea o realizare modestă în 2020, dar în 2005-2007 a fost destul de impresionant.
Și cel mai remarcabil aspect este că o echipă de inginerie externă dintr-un alt stat se adresează mie, proprietarului unei micuțe, practic goale instanțe de Bigtable, care are trafic zero în ultimii doi ani - și îmi oferă ajutor pentru a o actualiza.
Le-am mulțumit, am șters stocarea și viața și-a urmat cursul. Dar treisprezece ani mai târziu, mă gândesc încă la această scrisoare. Pentru că uneori primesc scrisori similare de la Google Cloud. Arată așa:
Stimate utilizator Google Cloud,
Vă reamintim că vom opri suportul pentru serviciul [важный сервис, который вы используете] începând cu august 2020, după care nu veți putea să vă actualizați instanțele. Vă recomandăm să treceți la cea mai recentă versiune, care este în faza de testare beta, nu are nicio documentație, nicio cale de migrare și care a expirat deja cu ajutorul nostru amabil.
Ne străduim ca această modificare să aibă un impact minim asupra tuturor utilizatorilor platformei Google Cloud.
Prietenii cei mai buni pentru totdeauna,
Platforma de cloud Google
Dar aproape că nu citesc astfel de scrisori, pentru că, de fapt, acestea spun următoarele:
Stimate destinatar,
Du-te dracului. Du-te, du-te, du-te. Lasă tot ce faci, pentru că nu contează. Ce contează este timpul nostru. Ne investim timpul și banii pentru a susține mizeria noastră și suntem sătui de asta, așa că nu o vom susține mai departe. Așa că lasă planurile tale de rahat și începe să sapi în documentația noastră jalnică, cerșind resturi pe forumuri, și, apropo, mizeria noastră nouă este complet diferită de mizeria veche, pentru că am stricat acest design destul de rău, hehe, dar e problema ta, nu a noastră.
Continuăm să ne străduim pentru ca toate dezvoltările tale să devină inutilizabile în decurs de un an.
Te rog, du-te-n drac!
Platforma de cloud Google
Și, în realitate, primesc astfel de scrisori cam o dată pe lună. Este atât de frecvent și constant încât inevitabil m-a îndepărtat de GCP în tabăra opozanților cloud-ului. Nu mai sunt de acord să depind de dezvoltările lor proprietare, pentru că, de fapt, un devops îi este mai ușor să întreține un sistem cu sursă deschisă pe o mașină virtuală pură decât să încerce să țină pasul cu Google și politica sa de închidere a produselor „devenite învechite”.
Înainte de a reveni la Google Cloud, pentru că eu chiar pe aproape nu m-au oprit din a-i critica, să vedem cum lucrează compania în alte domenii. Inginerii Google se mândresc cu disciplina lor în dezvoltarea software-ului, iar asta este ceea ce cauzează de fapt probleme. Mândria este o capcană pentru cei neatenți, făcându-i pe mulți angajați Google să creadă că deciziile lor sunt întotdeauna corecte și că corectitudinea (conform unei definiții neclare) este mai importantă decât îngrijorarea pentru clienți.
Voi da câteva exemple arbitrare din alte mari proiecte din afara Google, dar sper că veți vedea acest șablon peste tot. Esența este următoarea: compatibilitatea inversă susține supraviețuirea și relevanța sistemelor de-a lungul decadelor.
Compatibilitatea inversă este un obiectiv de design pentru toate sistemele de succes destinate utilizării deschise, adică implementate cu sursă deschisă și/sau pe standarde deschise. Simt că spun ceva prea evident, care este incomod pentru toată lumea, dar nu este. Aceasta este o problemă politică, așa că avem nevoie de exemple. Primul sistem pe care îl voi alege este cel mai vechi: GNU Emacs, un fel de hibrid între Notepad-ul Windows, nucleul OS și Stația Spațială Internațională. Este puțin complicat de explicat, dar, pe scurt, Emacs este o platformă creată în 1976 (da, aproape jumătate de secol în urmă) pentru programare, pentru a-ți spori productivitatea, dar se maschează ca un editor de text.
Folosesc Emacs în fiecare zi. Da, folosesc și IntelliJ în fiecare zi, care s-a transformat deja într-o platformă de instrumente puternică. Dar scrierea extensiilor pentru IntelliJ este o sarcină mult mai ambițioasă și mai complicată decât scrierea extensiilor pentru Emacs. Și, ceea ce este și mai important, tot ce este scris pentru Emacs rămâne
veșnic Încă folosesc software-ul pe care l-am scris pentru Emacs încă din 1995. Și sunt sigur că cineva folosește module scrise pentru Emacs în anii '80, dacă nu mai devreme. Din când în când, acestea pot necesita ajustări minore, dar se întâmplă cu adevărat rar. Nu știu nimic din ceea ce am scris vreodată pentru Emacs (și am scris mult) pentru care a fost necesară reconstruirea arhitecturii..
Încă folosesc software-ul pe care l-am scris pentru Emacs în 1995. Și sunt sigur că cineva folosește module scrise pentru Emacs în mijlocul anilor '80, dacă nu chiar mai devreme. Din când în când, acestea pot necesita o ajustare minoră, dar asta se întâmplă cu adevărat foarte rar. Nu știu nimic din ceea ce am scris vreodată pentru Emacs (iar eu am scris multe) care să necesite o restructurare arhitecturală.
În Emacs există o funcție numită make-obsolete pentru entitățile învechite. Terminologia Emacs pentru conceptele fundamentale ale computerului (de exemplu, ce este un „fereastră”) adesea diferă de convențiile din industrie, deoarece Emacs le-a introdus cu mult timp în urmă. Aceasta este o capcană tipică pentru cei care au fost cu un pas înaintea timpului lor: toate termenii voștri sunt inexacti. Dar în Emacs există cu adevărat un concept de devalorizare, care în jargonul lor se numește devalorizare.
Dar în lumea Emacs, pare să existe o altă definiție operativă. O altă filozofie fundamentală, dacă doriți.
În lumea Emacs (și în multe alte domenii pe care le vom explora mai jos), statutul API-urilor învechite înseamnă în principal: „Nu ar trebui să folosiți această abordare, deoarece, deși funcționează, suferă de diverse deficiențe pe care le vom enumera aici. Dar, în cele din urmă, este alegerea voastră”.
În lumea Google, statutul produselor învechite înseamnă: „Încălcăm angajamentele față de voi”. Chiar așa este. Aceasta este, de fapt, ce înseamnă. Asta înseamnă că vă vor obliga să faceți în mod regulat unele sarcini, poate chiar multe, ca o pedeapsă pentru că ați avut încredere în : noi avem cel mai bun software. Cel mai rapid! Faceți tot ce vă spune instrucțiunea, lansați aplicația sau serviciul vostru, iar apoi — bum, după un an sau doi se strică.
Este ca și cum ai vinde o mașină second-hand care se va strica cu siguranță după 1500 km.
Acestea sunt două definiții filozofice complet diferite ale „devalorizării”. Definiția Google miroase a . Nu cred că este vorba de de fapt devalorizare planificată în același sens ca la Apple. Dar Google intenționează cu siguranță să întrerupă programele voastre, pe o cale ocolitoare. Știu asta, deoarece am lucrat acolo ca inginer de software timp de peste 12 ani. Au linii directoare vagi interne cu privire la măsura în care trebuie să respecte compatibilitatea înapoi, dar în cele din urmă depinde de fiecare echipă sau serviciu în parte. Nu există recomandări la nivel corporativ sau ingineresc, iar cea mai îndrăzneață recomandare în ceea ce privește ciclurile de devalorizare este „încercați să oferiți clienților 6-12 luni pentru actualizare, înainte de a le strica întregul sistem”.
Problema este mult mai serioasă decât cred ei și va persista încă mulți ani, deoarece îngrijirea clienților nu face parte din ADN-ul lor. Mai multe detalii despre acest subiect mai jos.
Pentru moment, mă pregătesc să fac o afirmație îndrăzneață, că Emacs este, într-o mare măsură, de succes și chiar în principal datorită faptului că ei iau foarte în serios compatibilitatea înapoi. De fapt, acesta este teza articolului nostru. Sistemele deschise de succes, care durează ani, își datorează succesul microsocietății care a trăit zeci de ani în jurul extensiilor/plug-in-urilor. Aceasta constituie ecosistemul. Am discutat deja despre natura platformelor și cât de importante sunt acestea, precum și despre cât de mult Google nu a înțeles niciodată în toată istoria sa corporativă ce înseamnă să creezi o platformă deschisă de succes, în afară de Android sau Chrome.
De fapt, trebuie să menționez pe scurt Android, pentru că sunt sigur că te-ai gândit la el.
În primul rând, Android nu este Google. Ele nu au aproape nimic în comun între ele. Android este o companie care a fost cumpărată de Google în iulie 2005, iar acestei companii i s-a permis să funcționeze mai mult sau mai puțin autonom și, de fapt, a rămas într-o mare măsură neatinsă de-a lungul anilor. Android este un stivă tehnică renumită și la fel de bine o organizație cu spini. Așa cum a spus un angajat Google, „nu poți pur și simplu să intri în Android”.
Într-unul dintre articolele anterioare, am discutat deja despre cât de proaste au fost unele dintre deciziile de design timpurii ale Android. Doamne, când am scris acel articol, ei desfășurau o prostie numită „aplicații instant”, care acum (surpriză!) , și îmi pare rău dacă ai fost suficient de prost ca să asculți Google și să-ți muți conținutul în aceste aplicații instant.
Dar aici există o diferență, o diferență semnificativă, și anume că oamenii de la Android înțeleg cu adevărat cât de importante sunt platformele, depun eforturi constante pentru a menține funcționalitatea aplicațiilor Android mai vechi. De fapt, eforturile lor de a menține compatibilitatea înapoi sunt atât de extreme încât chiar și eu, în timpul petrecerii unui scurt timp în secțiunea Android acum câțiva ani, am descoperit că încercam să-i conving să renunțe la suportul pentru unele dintre cele mai vechi dispozitive și API-uri (am greșit, ca în multe alte privințe atât în trecut, cât și în prezent. Îmi pare rău, echipa Android! Acum, după ce am fost în Indonezia, înțeleg de ce sunt atât de necesari).
Oamenii de la Android mențin compatibilitatea inversă până la limite aproape de neimaginat, ceea ce creează o cantitate imensă de datorii tehnice în sistemele și lanțurile lor de instrumente. Oh, ai fi văzut unele lucruri ciudate pe care trebuie să le facă în sistemul lor de construcție, și toate acestea în numele compatibilității.
Pentru asta, ofer Android trofeul dorit „Tu nu ești Google”. Ei chiar nu vor să devină Google, care nu știe să creeze platforme durabile, iar Android știe cum să o facă. cunoaște,, de aceea Google se comportă foarte înțelept într-un anumit sens: le permite oamenilor din Android să facă totul așa cum doresc.
Cu toate acestea, aplicațiile instantanee pentru Android au fost o idee destul de prostească. Și știi de ce? Pentru că acestea necesitau să-ți rescrii și să-ți reproiectezi aplicația! De parcă oamenii ar lua pur și simplu și ar rescrie două milioane de aplicații. Presupun că aplicațiile instantanee au fost ideea unui angajat Google.
Dar aici există o diferență. Compatibilitatea inversă vine cu costuri mari. Android își asumă acest cost, în timp ce Google insistă ca această povară să fie purtată dumneavoastră, clientul plătit.
Poți vedea angajamentul Android față de compatibilitatea inversă în API-urile sale. Când ai patru sau cinci subsisteme diferite pentru a realiza practic același lucru, este un semn cert că angajamentul față de compatibilitate este la baza acestuia. Ceva care în lumea platformelor este sinonim cu angajamentul față de clienții tăi și față de piața ta.
Problema principală a Google aici este mândria lor în ceea ce privește igiena ingineriei. Nu le place atunci când există multe moduri diferite de a face același lucru, iar metodele mai vechi, mai puțin dorite, stau alături de cele noi, mai sofisticate. Aceasta crește curba de învățare pentru începătorii din sistem, crește povara suportului pentru API-urile învechite, încetinesc viteza funcțiilor noi, iar principalul păcat – este că nu arată bine. Google este precum Lady Escot din „Alice în Țara Minunilor” lui Tim Burton:
Lady Escot:
– Alice, știi ce mă tem cel mai mult?
– De decăderea aristocrației?
– M-am temut că voi avea nepoți urâți.
Pentru a înțelege compromisurile între frumos și practic, să ne uităm la a treia platformă de succes (după Emacs și Android) și să vedem cum funcționează: Java însăși.
În Java există o mulțime de API-uri învechite. Obsolescența este foarte populară printre programatorii Java, chiar mai populară decât în majoritatea limbajelor de programare. În Java însăși, limbajul de bază și bibliotecile, API-urile sunt în mod constant învechite.
Dacă luăm doar unul dintre cele o mie de exemple, este considerată învechită. A fost învechită încă de la lansarea Java 1.2 în decembrie 1998. Au trecut 22 de ani de când aceasta a fost învechită.
Dar codul meu real în producție tot încă închide fire în fiecare zi. Este bine? Absolut! Adică, bineînțeles, dacă aș rescrie codul astăzi, aș implementa asta diferit. Dar codul jocului meu, care în ultimele două decenii a făcut fericiți sute de mii de oameni, este scris cu funcția de închidere a firelor care rămân prea mult timp, și eu nu a trebuit niciodată să-l schimb. Cunosc sistemul meu mai bine decât toată lumea, am literalmente 25 de ani de experiență lucrând la el în producție, și pot spune cu exactitate: în cazul meu, închiderea acestor fire de lucru specifice este complet inofensivă. Nu merită să pierd timp și energie pentru a rescrie acest cod, iar lauda lui Larry Ellison (probabil) că Oracle nu m-a forțat să-l rescriu.
Probabil, Oracle știe și ea despre platforme. Cine știe.
Puteți găsi dovezi în toate API-urile Java principale, care sunt străbătute de valuri de depășire, asemănătoare cu liniile unui ghețar în canion. În biblioteca Java Swing, este ușor de găsit cinci sau șase diferiți manageri pentru navigația cu tastatura (KeyboardFocusManager). Este într-adevăr greu să găsești un API Java care să nu fie depășit. Dar ele încă funcționează! Cred că echipa Java va elimina cu adevărat API-uri doar atunci când interfața va provoca o problemă de securitate flagrantă.
Iată care este problema, oameni buni: noi, dezvoltatorii de software, suntem toți foarte ocupați și, în fiecare domeniu al software-ului, ne confruntăm cu alternative concurente. În orice moment dat, programatorii în limbajul X consideră limbajul Y ca o posibilă înlocuire. Oh, nu mă credeți? Vrei să numești Swift? Cum că toată lumea migrează spre Swift și nimeni nu renunță la el, corect? Wow, cât de puțin știți. Companiile iau în considerare costurile echipelor mobile duale (iOS și Android) – și încep să înțeleagă că aceste sisteme de dezvoltare multiplatformă cu nume amuzante, cum ar fi Flutter și React Native, chiar funcționează, și cu ajutorul lor pot reduce dimensiunile echipelor lor mobile la jumătate sau, din contră, le pot face de două ori mai productive. Aici sunt implicați bani reali. Da, există compromisuri, dar, pe de altă parte, bani.
Să presupunem ipotetic că Apple, dintr-o prostie, a luat exemplul lui Guido van Rossum și a anunțat că Swift 6.0 nu este compatibil înapoi cu Swift 5.0, în mare parte cum Python 3 nu este compatibil cu Python 2.
Probabil că am povestit această poveste acum zece ani, dar acum cincisprezece ani am fost la tabăra O’Reilly Foo Camp cu Guido, am stat într-un cort cu Paul Graham și o mulțime de oameni importanți. Stăteam în căldură sufocantă și așteptam ca Larry Page să zboare cu elicopterul lui privat, iar Guido murmura monoton despre "Python 3000", care a fost numit așa pentru anii de care va fi nevoie pentru a face toți migrarea. Între timp, tot timpul întrebam de ce încalcă compatibilitatea, iar el răspundea: “Unicode”. Și întrebam, dacă va trebui să rescriem codul nostru, ce alte avantaje vom observa? Și el răspundea “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
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 expirat, așa că ați fost lăsați balta.
… și așa mai departe. Ciclul vieții.
Dar, de fapt, fiecare dezvoltator are de ales. Și dacă îi forțezi să-și rescrie codul destul de des, s-ar putea să ia în considerare și alte altele opțiuni. Ei nu sunt captivi ai voștri, oricât de mult v-ați dori. Ei sunt oaspeții voștri. Python rămâne un limbaj de programare foarte popular, dar, Dumnezeule, Python 3(000) a creat atât de mult haos în comunitățile sale și în rândul utilizatorilor acestor comunități, încât consecințele nu pot fi reparate de cincisprezece ani.
Câte programe Python au fost rescrise în Go (sau Ruby, sau o altă alternativă) din cauza acestei incompatibilități înapoi? Câte software-uri noi au fost scrise în altceva decât Python, deși ar fi putut fi scrise în Python, dacă Guido nu ar fi dat foc întregului sat? Este greu de spus, dar Python a avut clar de suferit. E un haos uriaș și toată lumea are de pierdut.
Așadar, să presupunem că Apple urmează exemplul lui Guido și încalcă compatibilitatea. Ce credeți că se va întâmpla apoi? Ei bine, poate 80-90% dintre dezvoltatori își vor rescrie software-ul, dacă vor putea. Cu alte cuvinte, 10-20% din baza de utilizatori va pleca automat către un alt limbaj concurent, cum ar fi Flutter.
Faceți asta de câteva ori – și veți pierde jumătate din baza de utilizatori. La fel ca în sport, forma actuală contează și în lumea programării. totOricine pierde jumătate din utilizatori în cinci ani va fi considerat o MARE EȘEC. Trebuie să fiți la curent cu tendințele din lumea platformelor. Dar tocmai aici, renunțarea la suportul versiunilor vechi vă va aduce sfârșitul. Pentru că de fiecare dată când vă îndepărtați de unii dezvoltatori, (a) îi pierdeți pentru totdeauna, deoarece sunt supărați pe voi pentru încălcarea contractului, și (b) îi oferiți competitorilor voștri.
Ironia face că eu însumi am ajutat Google să devină o astfel de primadonă care ignoră compatibilitatea înapoi, când am creat Grok, un sistem de analiză și înțelegere a codului sursă, care facilitează automatizarea și echiparea instrumentelor bazate pe codul însuși – seamănă cu un IDE, dar aici serviciul cloud stochează viziuni materializate ale tuturor miliardelor de linii de cod sursă Google într-un mare depozit de date.
Grok a oferit o bază puternică celor de la Google pentru a efectua refactoring automatizat în întreaga bază de cod (literalmente în tot Google). Sistemul calculează nu doar dependențele voastre ascendente (de care depindeți), ci și descendente (care depind de voi), așa că atunci când schimbați API-ul, știți pe toți cei pe care îi afectați! Astfel, când faceți modificări, puteți verifica că fiecare consumator al API-ului vostru s-a actualizat la noua versiune, iar în realitate, adesea cu ajutorul instrumentului Rosie, pe care l-au scris, puteți automatiza complet procesul.
Aceasta permite ca baza de cod a Google să fie interioară aproape supranatural de "curată", deoarece au acești servitori robotizați care hoinăresc prin casă și curăță automat totul, dacă au redenumit SomeDespicablyLongFunctionName în SomeDespicablyLongMethodName, pentru că cineva a decis că este un nepot urât și trebuie să fie uscat.
Și, sincer, funcționează destul de bine pentru Google... în interior. Adică, da, comunitatea Go din Google râde prietenos de comunitatea Java din Google din cauza obiceiului lor de a face refactoring constant. Dacă pompați ceva de N ori, înseamnă că nu doar că ați stricat-o de N-1 ori, ci, după un timp, devine evident că probabil ați stricat-o și cu a N-a încercare. Dar, în mare parte, ei rămân deasupra acestei agitații și mențin codul "curat".
Problemele încep atunci când încearcă să impună o astfel de atitudine clienților lor din cloud și utilizatorilor altor API-uri.
V-am familiarizat puțin cu Emacs, Android și Java; haideți să ne uităm la ultima platformă de succes de lungă durată: Web-ul însuși. Îți poți imagina prin câte iterații a trecut HTTP din 1995, când foloseam etichete clipește <blink> și iconițe "În dezvoltare" pe paginile web.
Dar totul funcționează! Și aceste pagini funcționează încă! Da, băieți, browserele sunt campioni mondiali în ceea ce privește compatibilitatea retroactivă. Chrome este un alt exemplu rar de platformă Google, unde șuruburile sunt bine fixate, iar, cum ați ghicit, Chrome acționează eficient ca o companie izolată, separat de restul Google.
Vreau să le mulțumesc și prietenilor noștri din rândul dezvoltatorilor de sisteme de operare: Windows, Linux, NU APPLE TE ROG APPLE, FreeBSD și altele, pentru munca lor considerabilă în ceea ce privește compatibilitatea retroactivă pe platformele lor de succes (Apple merită cel mult un 3 cu minus, deoarece strică totul fără o cauză justificată, însă comunitatea reușește cumva să facă față acestei situații cu fiecare lansare, iar până acum containerele cu OS X nu sunt încă complet depășite... încă).
Dar așteaptă, vei spune. Nu comparăm cumva mere cu portocale - sisteme software autonome pe un singur aparat, precum Emacs/JDK/Android/Chrome, cu sisteme multi-server și API-uri, așa cum există în serviciile cloud?
Ei bine, am scris despre asta ieri pe Twitter, dar în stilul lui Larry Wall (creatorul limbajului de programare Perl - n. red.) pe principiul "fail/awesome" am căutat cuvântul este deprecated pe site-urile pentru dezvoltatori Google și Amazon. Și deși AWS are de sute de ori mai multe servicii decât GCP, documentația pentru dezvoltatori Google menționează obsolescența de aproximativ șapte ori mai des.
Dacă cineva de la Google citește asta, cu siguranță sunt pregătiți să scoată diagrame, arătând în stilul lui Donald Trump, că fac într-adevăr totul corect și că nu ar trebui să fac comparații nedrepte, cum ar fi "numărul de mențiuni ale cuvântului deprecated în raport cu numărul de servicii".
Dar, după atâția ani, Google Cloud rămâne în continuare serviciul nr. 3 (nu am scris articolul despre încercarea eșuată de a deveni nr. 2), dar dacă ne luăm după insiideri, există unele temeri că s-ar putea să cadă curând pe locul 4.
Nu am argumente solide pentru a "demonstra" teza mea. Tot ce am sunt exemple colorate pe care le-am adunat în cei 30 de ani de muncă ca dezvoltator. Am menționat deja natura profund filosofică a acestei probleme; într-un anumit sens, este politizată în comunitățile dezvoltatorilor. Unii cred că creatorii platformelor ar trebui să se preocupe de compatibilitate, în timp ce alții cred că aceasta este responsabilitatea utilizatorii (dezvoltatorilor înșiși). Una din două. Și, într-adevăr, nu este o întrebare politică atunci când decidem cine ar trebui să suporte costurile pentru problemele comune?
Deci este o chestiune politică. Și cu siguranță vor exista reacții furioase la declarația mea.
Cum utilizator Platforma cloud Google, precum și utilizator AWS timp de doi ani (lucrând la compania Grab), pot spune că există o diferență uriașă între filosofiiile Amazon și Google când vine vorba de priorități. Nu dezvolt activ pe AWS, așa că nu știu foarte bine cât de des elimină API-urile vechi. Dar bănuiesc că acest lucru nu se întâmplă atât de des ca în Google. Și cred sincer că această sursă constantă de dispute și dezamăgiri în GCP este unul dintre cei mai mari factori care împiedică dezvoltarea platformei.
Știu că nu am menționat exemple specifice de sisteme GCP ale căror suport a fost întrerupt. Pot spune că practic tot ce am folosit, de la rețele (de la cele mai vechi până la VPC) până la stocare (Cloud SQL v1-v2), Firebase (acum Firestore cu un API complet diferit), App Engine (să nu începem), endpoint-uri cloud Cloud Endpoint și până la… nu știu — absolut tot acest lucru m-a obligat să rescriu codul maximum la fiecare 2-3 ani, și niciodată nu au automatizat migrarea pentru tine, iar adesea . Parcă așa trebuia să fie.
Și de fiecare dată când mă uit la AWS, mă întreb de ce naiba mai sunt pe GCP. Clar, nu au nevoie de clienți. Au nevoie de cumpărători. Înțelegi diferența? Permite-mi să explic.
Google Cloud are , unde oamenii își oferă soluțiile software, iar pentru a evita efectul unui restaurant gol, trebuia să fie umplut cu unele oferte, așa că au încheiat un contract cu compania Bitnami pentru a crea o mulțime de soluții care se desfășoară „cu un singur clic”, sau trebuie să scriu „soluții” eu însumi, pentru că acestea nu rezolvă nimic. Ele există pur și simplu ca niște mărci de verificare, ca un umplutură de marketing, iar Google nu i-a păsat niciodată dacă vreunul dintre instrumente funcționează de fapt. Cunoaștem manageri de produs care au fost la volan și pot să te asigur că acestor oameni nu le pasă.
Să luăm, de exemplu, soluția de desfășurare care se spune că este „cu un singur clic” . Sunt sătul de trucurile Google Cloud SQL, așa că am început să consider ca alternativă crearea propriului cluster Percona. Și de data aceasta, Google pare că a făcut un lucru bun, plănuiau să-mi economisească un pic de timp și efort cu o apăsare de buton!
Bine, haideți să începem. Accesăm linkul și apăsăm acest buton. Alegem „Da” pentru a accepta toate opțiunile implicite și pentru a desfășura clustra în proiectul nostru Google Cloud. Haha, nu funcționează. Nimic din toată această nebunie nu funcționează. Instrumentul nu a fost niciodată testat și a început să se degradeze din prima clipă, și nu mă va surprinde dacă mai mult de jumătate din „soluțiile” de desfășurare cu un singur clic (acum înțelegem de ce între ghilimele) sunt doar iluzorii. în general nu funcționează. Este o întunecare absolută, mai bine să nu intri.
Dar Google chiar îi îndeamnă să folosești produsele lor. Ei vor ca tu să le cumpări.. Pentru ei, este o tranzacție. Nu vor să mai ofere nimic susține. Nu face parte din ADN-ul Google. Da, inginerii se susțin reciproc, dovadă stă povestea mea cu Bigtable. Dar în produsele și serviciile pentru utilizatorii obișnuiți, au fost întotdeauna necruțători în , care nu îndeplinește standardul de rentabilitate, chiar dacă are milioane de utilizatori.
Și aceasta reprezintă o problemă reală pentru GCP, deoarece acest ADN stă la baza tuturor ofertelor cloud. Nu au capacitatea de a susține ceva; știm bine că refuză să găzduiască (ca serviciu gestionat) orice software terț până când, până când AWS nu face la fel și nu își construiește în jur un business de succes, și când clienții cer cu adevărat același lucru. Totuși, trebuie să depui eforturi pentru a-i face pe Google să susțină ceva.
Aceasta absență a unei culturi de suport, împreună cu principiul „hai să distrugem pentru a face mai frumos”, îi alienază de dezvoltatori.
Și aceasta nu este foarte bună dacă vrei să construiești o platformă durabilă.
Google, trezește-te, dracului. Este anul 2020. Încă ești pe cale de a pierde. E timpul să te uiți cu atenție în oglindă și să răspunzi dacă chiar vrei să rămâi în afacerea cloud.
Dacă vrei să rămâi, atunci oprește-te din a mai distruge.Băieți, sunteți bogați. Noi, dezvoltatorii, nu suntem. Așadar, când vine vorba de cine să își asume povara compatibilității, trebuie să vă asumați voi. Nu noi.
Pentru că mai sunt cel puțin trei adevărate cloud-uri foarte bune. Ele se arată tentante.
Acum, voi continua să repar toate sistemele mele stricate. Ah.
Până data viitoare!
P. S. Actualizare după citirea unor discuții despre acest articol (discuțiile sunt, de altfel, excelente). Suportul pentru Firebase nu a fost oprit și nu există planuri de care să știu. Totuși, au o eroare neplăcută de streaming care face ca clientul Java să se oprească în App Engine. Unul dintre inginerii lor m-a ajutat să fac față acestei probleme, când lucram la Google, dar ei nu au remediat niciodată cu adevărat bug-ul, așa că am o soluție proastă: trebuie să repornesc aplicația GAE în fiecare zi. Așa este de patru ani! Acum au Firestore. Va fi mult de muncit pentru a migra la aceasta, deoarece este un sistem complet diferit, iar eroarea Firebase nu va fi niciodată corectată. Ce concluzie putem trasa? Poți primi ajutor, dacă lucrezi într-o companie. Probabil că sunt singurul care folosește Firebase pe GAE, pentru că înregistrez mai puțin de 100 de chei într-o aplicație 100% nativă, iar aceasta se oprește la fiecare câteva zile din cauza unei erori cunoscute. Ce să mai spun, decât că trebuie să-l folosești pe riscul tău. Eu voi trece la Redis.
De asemenea, am văzut cum unii utilizatori mai experimentați AWS afirmau că AWS, de obicei, nu oprește suportul pentru niciun serviciu, iar SimpleDB este un exemplu excelent. Presupunerile mele că AWS nu suferă de problema opririi suportului, așa cum o face Google, par a fi justificate.
În plus, am observat că acum 20 de zile echipa Google App Engine a stricat hostingul unei biblioteci critice Go, închizând aplicația GAE de unul dintre dezvoltatorii principali Go. Chiar a fost o alegere proastă.
În cele din urmă, am auzit că oamenii de la Google discută deja această problemă și în general sunt de acord cu mine (vă iubesc, băieți!). Dar se pare că consideră problema nerezolvabilă, deoarece în cultura Google nu a existat niciodată o structură corectă de stimulente. Cred că ar fi bine să-mi fac timp să discut despre experiența absolut uimitoare de a lucra cu inginerii AWS, când am lucrat la compania Grab. Poate în viitor, sper!
Și da, în 2005, aveau cu adevărat diferite tipuri de carne de rechin pe un imens bufet suedez în clădirea 43, iar mie mi-a plăcut cel mai mult carnea de rechin cu cap plat. Totuși, până în 2006, Larry și Sergey au scăpat de toate gustările nesănătoase. Așa că în timpul poveștii cu Bigtable, în 2007, nu au existat rechini și v-am mințit în mod subversiv.
Când am privit Bigtable în cloud acum patru ani (plus-minus), costul era exact așa. Se pare că acum a scăzut puțin, dar tot este enorm pentru un depozit de date gol, mai ales având în vedere că prima mea poveste arată cât de insignifiantă este o mare tabelă goală în scalarea lor.
Îmi pare rău pentru că am ofensez comunitatea Apple și că nu am spus nimic bun despre Microsoft și așa mai departe. Aveți dreptate, apreciez foarte mult toate discuțiile pe care le-a generat acest articol! Dar uneori trebuie să facem puțin valuri pentru a porni o discuție, nu-i așa?
Mulțumesc pentru lectură.
Actualizare 2, 19.08.2020. Stripe !
Actualizare 3, 31.08.2020. Un inginer Google din Cloud Marketplace m-a contactat, care s-a dovedit a fi un vechi prieten. Vrea să afle de ce C2D nu funcționează și, în final, am descoperit că motivul era că am creat rețeaua mea cu câțiva ani în urmă, iar C2D nu funcționează în rețelele învechite din cauza lipsei parametrului subnet în șabloanele lor. Cred că utilizatorii potențiali ai GCP ar trebui să se asigure că au ingineri familiarizați în Google…
Sursa: habr.com
