Cholera Google, nie chciałem znowu blogować. Mam tak wiele do zrobienia. Blogowanie wymaga czasu, energii i kreatywności, które mogłabym dobrze wykorzystać: moje książki, , moja gra i tak dalej. Ale tak mnie wkurzyłeś, że muszę to napisać.
Więc miejmy to już za sobą.
Zacznę od krótkiej, ale pouczającej historii z początków mojej pracy w Google. Wiem, że ostatnio mówiłem wiele złego o Google, ale denerwuje mnie, gdy moja własna firma regularnie podejmuje niekompetentne decyzje biznesowe. Jednocześnie musimy dać z siebie wszystko: wewnętrzna infrastruktura Google jest naprawdę niezwykła, można śmiało powiedzieć, że nie ma dziś nic lepszego. Założyciele Google byli znacznie lepszymi inżynierami niż ja kiedykolwiek będę, a ta historia tylko to potwierdza.
Najpierw trochę tła: Google ma technologię przechowywania danych zwaną . Było to niezwykłe osiągnięcie techniczne, jedno z pierwszych (jeśli nie pierwsze) „nieskończenie skalowalnego” magazynu klucz-wartość (K/V): w zasadzie początek NoSQL. Obecnie Bigtable nadal radzi sobie dobrze w dość zatłoczonym magazynie K/V, ale wtedy (2005) był niesamowicie fajny.
Zabawną rzeczą związaną z Bigtable jest to, że posiadał on obiekty wewnętrznej płaszczyzny kontrolnej (w ramach implementacji) zwane serwerami tabletowymi, z dużymi indeksami, które w pewnym momencie stały się wąskim gardłem podczas skalowania systemu. Inżynierowie Bigtable zastanawiali się, jak wdrożyć skalowalność i nagle zdali sobie sprawę, że mogliby zastąpić serwery tabletów innymi pamięciami masowymi Bigtable. Zatem Bigtable jest częścią implementacji Bigtable. Te magazyny znajdują się na wszystkich poziomach.
Kolejnym interesującym szczegółem jest to, że na jakiś czas Bigtable stał się popularny i wszechobecny w Google, a każdy zespół miał własne repozytorium. Dlatego na jednym z piątkowych spotkań Larry Page mimochodem zapytał: „Dlaczego mamy więcej niż jeden Bigtable? Dlaczego nie tylko jeden?” Teoretycznie jedna pamięć powinna wystarczyć na wszystkie potrzeby Google w zakresie przechowywania. Oczywiście nigdy nie korzystano z jednego tylko rozwiązania ze względów praktycznych (np. konsekwencji potencjalnej awarii), ale teoria była interesująca. Jedno repozytorium dla całego Wszechświata (Swoją drogą, czy ktoś wie, czy Amazon zrobił to ze swoim Sable?)
Tak czy inaczej, oto moja historia.
Pracowałem wtedy w Google nieco ponad dwa lata i pewnego dnia otrzymałem e-mail od zespołu inżynierów Bigtable o następującej treści:
Drogi Steve'ie,
Witamy w zespole Bigtable. Chcielibyśmy poinformować Cię, że w [nazwa centrum danych] używasz bardzo, bardzo starego pliku binarnego Bigtable. Ta wersja nie jest już obsługiwana i chcemy pomóc Ci w uaktualnieniu do najnowszej wersji.
Daj mi znać, jeśli możesz zaplanować trochę czasu na wspólną pracę nad tą kwestią.
Wszystkiego najlepszego,
Команда Bigtable
W Google dostajesz dużo poczty, więc na pierwszy rzut oka czytam coś takiego:
Drogi Odbiorcy,
Witam z jakiegoś zespołu. Chcemy to przekazać bla bla bla bla. Bla bla bla bla i bla bla bla od razu.
Daj nam znać, jeśli możesz zaplanować trochę swojego cennego czasu na bla bla bla.
Wszystkiego najlepszego,
Jakiś rodzaj polecenia
Prawie od razu to usunąłem, jednak na granicy świadomości poczułem bolesne, dokuczliwe uczucie, że to właśnie to nie do końca choć wygląda na list formalny oczywiście, że odbiorca się pomylił, bo nie korzystałem z Bigtable.
Ale to było dziwne.
Resztę dnia spędziłem na przemian myśląc o pracy i jakiego mięsa rekina spróbować w mikrokuchni, z czego co najmniej trzy były na tyle blisko, że mogłem trafić z miejsca celnym rzutem ciastkiem, ale myśl o pisaniu nigdy nie pozostawiła mnie z rosnącym uczuciem lekkiego niepokoju.
Wyraźnie podali moje imię. E-mail został wysłany na mój adres e-mail, a nie na czyjś adres e-mail i nie jest to DW: ani BCC:. Ton jest bardzo osobisty i wyraźny. Może to jest jakiś błąd?
W końcu ciekawość zwyciężyła i poszedłem obejrzeć konsolę Borg we wspomnianym data center.
I oczywiście zarządzałem pamięcią masową BigTable. Co, proszę? Spojrzałam na jego zawartość i wow! Pochodzi z inkubatora Codelab, w którym pracowałem podczas pierwszego tygodnia pracy w Google w czerwcu 2005 roku. Codelab zmusił Cię do uruchomienia Bigtable w celu zapisania tam niektórych wartości i najwyraźniej nigdy potem nie zamknąłem magazynu. Mimo upływu ponad dwóch lat nadal działał.
Ta historia ma kilka godnych uwagi aspektów. Po pierwsze, dzieło Bigtable było na tyle znikome w skali Google, że dopiero dwa lata później ktoś zauważył dodatkową pamięć i to tylko dlatego, że wersja binarna była przestarzała. Dla porównania kiedyś rozważałem użycie do mojej gry online. W tamtym czasie usługa ta kosztowała około 16 000 dolarów rocznie. pusty Bigtable na GCP. Nie twierdzę, że cię oszukują, ale moim osobistym zdaniem to dużo pieniędzy jak na pustą, pieprzoną bazę danych.
Kolejnym aspektem godnym uwagi jest to, że przechowywanie nadal pracuje po dwóch latach. WTF? Centra danych przychodzą i odchodzą; doświadczają przestojów, przechodzą planową konserwację, cały czas się zmieniają. Sprzęt jest aktualizowany, przełączniki wymieniane, wszystko jest stale ulepszane. Jak, do cholery, udało im się utrzymać mój program przez dwa lata, mimo tych wszystkich zmian? W 2020 roku może się to wydawać skromnym osiągnięciem, ale w latach 2005-2007 było naprawdę imponujące.
A najcudowniejsze jest to, że podchodzi do mnie zewnętrzny zespół inżynierów z innego stanu, właściciel jakiejś małej, prawie pustej instancji Bigtable, który ma zerowy ruch przez ostatnie dwa lata - i oferują pomoc w jego aktualizacji.
Podziękowałem im, usunąłem pamięć i życie toczyło się dalej jak zwykle. Ale trzynaście lat później wciąż myślę o tym liście. Ponieważ czasami otrzymuję podobne e-maile z Google Cloud. Wyglądają tak:
Drogi użytkowniku Google Cloud,
Przypominamy, że od sierpnia 2020 r. zakończymy świadczenie usługi [podstawowa usługa, z której korzystasz], po czym nie będzie już możliwości aktualizacji swoich instancji. Zalecamy aktualizację do najnowszej wersji, która jest w fazie testów beta, nie posiada dokumentacji, nie ma ścieżki migracji i jest wcześniej nieaktualna dzięki naszej uprzejmej pomocy.
Dokładamy wszelkich starań, aby ta zmiana miała minimalny wpływ na wszystkich użytkowników platformy Google Cloud.
Najlepsi przyjaciele na zawsze,
Platforma chmurowa Google
Ale prawie nigdy nie czytam takich listów, bo tak naprawdę mówią:
Drogi Odbiorcy,
Idź do diabła. Pieprz się, pierdol się, pierdol się. Porzuć wszystko, co robisz, bo to nie ma znaczenia. Liczy się nasz czas. Marnujemy czas i pieniądze na utrzymywanie naszego badziewia i jesteśmy tym zmęczeni, więc nie będziemy już tego wspierać. Więc daj sobie spokój ze swoimi pieprzonymi planami i zacznij grzebać w naszej chujowej dokumentacji, błagając o resztki na forach, a swoją drogą to nasze nowe gówno jest zupełnie inne niż stare, bo nieźle schrzaniliśmy ten projekt, heh, ale to twoja sprawa problem, nie nasz.
Nieustannie dokładamy wszelkich starań, aby wszystkie Twoje rozwiązania stały się bezużyteczne w ciągu jednego roku.
Proszę, spierdalaj
Platforma chmurowa Google
A faktem jest, że takie listy otrzymuję mniej więcej raz w miesiącu. Dzieje się tak często i stale, że jest to nieuniknione odepchnięty mnie z GCP do obozu przeciw chmurom. Nie zgadzam się już na poleganie na ich autorskich rozwiązaniach, ponieważ devopsom faktycznie łatwiej jest utrzymać system open source na gołej maszynie wirtualnej, niż próbować dotrzymać kroku Google w jego polityce zamykania „przestarzałych” produktów.
Zanim wrócę do Google Cloud, ponieważ I całkiem blisko nie skończyliśmy ich krytykować, przyjrzyjmy się wynikom firmy w innych obszarach. Inżynierowie Google są dumni ze swojej dyscypliny inżynierii oprogramowania i to właśnie powoduje problemy. Duma jest pułapką na nieostrożnych i doprowadziła wielu pracowników Google do myślenia, że ich decyzje są zawsze słuszne i że bycie słusznym (według jakiejś niejasnej, niejasnej definicji) jest ważniejsze niż troska o klientów.
Podam kilka przypadkowych przykładów z innych dużych projektów spoza Google, ale mam nadzieję, że wszędzie widać ten schemat. Jest następująco: kompatybilność wsteczna utrzymuje systemy przy życiu i aktualności przez dziesięciolecia.
Kompatybilność wsteczna jest celem projektowym wszystkich udanych systemów zaprojektowanych dla otwarty wykorzystania, to znaczy zaimplementowane przy użyciu otwartego kodu źródłowego i/lub otwartych standardów. Mam wrażenie, że powiedziałem coś zbyt oczywistego, że wszyscy poczują się nawet niekomfortowo, ale nie. Jest to kwestia polityczna, dlatego potrzebne są przykłady.
Pierwszy system, który wybiorę, będzie najstarszy: GNU Emacs, będący swego rodzaju hybrydą pomiędzy Notatnikiem Windows, jądrem systemu operacyjnego i Międzynarodową Stacją Kosmiczną. Trochę trudno to wyjaśnić, ale w skrócie Emacs to platforma stworzona w 1976 roku (tak, prawie pół wieku temu) do programowania zwiększającego produktywność, ale udająca edytor tekstu.
Na co dzień używam Emacsa. Tak, ja też codziennie korzystam z IntelliJ, stał się on potężną platformą narzędziową. Jednak pisanie rozszerzeń dla IntelliJ jest zadaniem znacznie bardziej ambitnym i złożonym niż pisanie rozszerzeń dla Emacsa. A co ważniejsze, wszystko, co napisano dla Emacsa, zostaje zachowane na zawsze.
Nadal używam oprogramowania, które napisałem dla Emacsa w 1995 roku. Jestem pewien, że ktoś używa modułów napisanych dla Emacsa w połowie lat 80., jeśli nie wcześniej. Od czasu do czasu mogą wymagać drobnych poprawek, ale jest to naprawdę rzadkie. Nie znam niczego, co kiedykolwiek napisałem dla Emacsa (a napisałem dużo), co wymagałoby przebudowy architektury.
Emacs ma funkcję zwaną make-obsolete dla przestarzałych jednostek. Terminologia Emacsa dotycząca podstawowych pojęć komputerowych (takich jak „okno”) często różni się od konwencji branżowych, ponieważ Emacs wprowadził je dawno temu. Jest to typowe niebezpieczeństwo dla tych, którzy wyprzedzają swoją epokę: wszystkie Twoje warunki są nieprawidłowe. Ale Emacs ma koncepcję przestarzałości, która w ich żargonie nazywa się starzenie się.
Wydaje się jednak, że w świecie Emacsa istnieje inna robocza definicja. Inna podstawowa filozofia, jeśli wolisz.
W świecie Emacsa (i wielu innych obszarach, które omówimy poniżej) status przestarzałego interfejsu API w zasadzie oznacza: „Naprawdę nie powinieneś używać tego podejścia, ponieważ chociaż działa, ma różne niedociągnięcia, o których będziemy lista tutaj. Ale ostatecznie to twój wybór.”
W świecie Google bycie przestarzałym oznacza: „Naruszamy nasze zobowiązania wobec Ciebie”. To prawda. To właśnie zasadniczo oznacza. Oznacza to, że będą cię zmuszać regularnie wykonać jakąś pracę, być może dużo pracy, jako karę za wiarę w nie : Mamy najlepsze oprogramowanie. Najszybszy! Robisz wszystko według instrukcji, uruchamiasz aplikację lub usługę, a potem bam, po roku, dwóch, psuje się.
To jak sprzedawać używany samochód, który na pewno zepsuje się po 1500 km.
Są to dwie zupełnie różne filozoficzne definicje „starzenia się”. Definicja zapachu według Google . Nie wierzę w to w rzeczywistości planowane starzenie się w tym samym sensie, co Apple. Ale Google zdecydowanie planuje przerwać Twoje programy w okrężny sposób. Wiem to, bo pracowałem tam jako inżynier oprogramowania przez ponad 12 lat. Mają niejasne wewnętrzne wytyczne dotyczące tego, w jakim stopniu należy przestrzegać kompatybilności wstecznej, ale ostatecznie zależy to od indywidualnego zespołu lub usługi. Nie ma zaleceń na poziomie przedsiębiorstwa ani na poziomie inżynieryjnym, a najodważniejszą rekomendacją dotyczącą cykli starzenia się jest „spróbuj dać klientom 6–12 miesięcy na aktualizację, zanim zepsują cały system”.
Problem jest znacznie większy, niż im się wydaje i będzie trwał przez wiele lat, ponieważ dbałość o klienta nie jest w ich DNA. Więcej na ten temat poniżej.
W tym miejscu postawię odważne stwierdzenie, że Emacs odniósł sukces w dużym i równym stopniu przeważnie ponieważ tak poważnie traktują kompatybilność wsteczną. Właściwie taka jest teza naszego artykułu. Skuteczne, długowieczne systemy otwarte zawdzięczają swój sukces mikrospołecznościom, które żyją wokół nich od dziesięcioleci rozszerzenia/wtyczki. To jest ekosystem. Mówiłem już o naturze platform i ich znaczeniu oraz o tym, że Google nigdy w całej swojej historii nie rozumiał, co składa się na stworzenie udanej otwartej platformy poza Androidem i Chrome.
Właściwie powinienem wspomnieć krótko o Androidzie, ponieważ prawdopodobnie o nim myślisz.
Po pierwsze, Android to nie Google. Nie mają ze sobą prawie nic wspólnego. Android to firma, która została kupiona przez Google w lipcu 2005 roku. Firma mogła działać mniej więcej autonomicznie i tak naprawdę pozostała w dużej mierze nietknięta przez te lata. Android to notoryczny stos technologii i równie osławiona, kłująca organizacja. Jak ujął to jeden z pracowników Google: „Nie możesz po prostu zalogować się do Androida”.
W poprzednim artykule omawiałem, jak złe były niektóre wczesne decyzje projektowe Androida. Cholera, kiedy pisałem ten artykuł, wypuszczali bzdury zwane „aplikacjami błyskawicznymi”, które teraz (niespodzianka!) i współczuję, jeśli byłeś na tyle głupi, aby słuchać Google i przenosić swoje treści do tych aplikacji błyskawicznych.
Ale jest tu różnica, znacząca różnica, polegająca na tym, że użytkownicy Androida naprawdę rozumieją, jak ważne są platformy, starają się, jak mogą, aby stare aplikacje na Androida działały. W rzeczywistości ich wysiłki na rzecz utrzymania kompatybilności wstecznej są tak ekstremalne, że nawet ja, podczas mojej krótkiej pracy w dziale Androida kilka lat temu, próbowałem ich przekonać, aby porzucili wsparcie dla niektórych najstarszych urządzeń i interfejsów API (myliłem się , podobnie jak wiele innych rzeczy w przeszłości i teraźniejszości. Przepraszam, chłopaki z Androidem! Teraz, gdy byłem w Indonezji, rozumiem, dlaczego ich potrzebujemy).
Użytkownicy Androida przesuwają wsteczną kompatybilność do niemal niewyobrażalnych skrajności, gromadząc ogromne ilości starszego długu technicznego w swoich systemach i zestawach narzędzi. O mój Boże, powinieneś zobaczyć kilka szalonych rzeczy, które muszą zrobić w swoim systemie kompilacji, a wszystko to w imię kompatybilności.
Za to przyznaję Androidowi prestiżową nagrodę „You’re Not Google”. Tak naprawdę nie chcą stać się Googlem, który nie wie, jak tworzyć trwałe platformy, ale Androidem wie, jak to zrobić. Dlatego Google jest bardzo mądry pod jednym względem: pozwala ludziom robić rzeczy na swój własny sposób na Androidzie.
Jednak aplikacje błyskawiczne na Androida były dość głupim pomysłem. A wiesz dlaczego? Bo żądali przepisać i przeprojektować swoją aplikację! To tak, jakby ludzie po prostu przepisali dwa miliony aplikacji. Zgaduję, że aplikacje błyskawiczne to pomysł jakiegoś Googlera.
Ale jest różnica. Kompatybilność wsteczna wiąże się z wysokimi kosztami. Sam Android ponosi ciężar tych kosztów, podczas gdy Google nalega, aby ten ciężar poniósł ty, płacący klient.
Zaangażowanie Androida w kompatybilność wsteczną widać w jego interfejsach API. Kiedy masz cztery lub pięć różnych podsystemów wykonujących dosłownie to samo, jest to pewny znak, że w centrum uwagi leży zapewnienie kompatybilności wstecznej. Co w świecie platform jest równoznaczne z zaangażowaniem wobec Twoich klientów i Twojego rynku.
Głównym problemem Google jest tutaj duma z higieny inżynieryjnej. Nie podoba im się, gdy istnieje wiele różnych sposobów zrobienia tego samego, a stare, mniej pożądane sposoby sąsiadują z nowymi, bardziej wymyślnymi sposobami. Wydłuża to czas nauki dla osób nowych w systemie, zwiększa obciążenie związane z utrzymaniem starszych interfejsów API, spowalnia szybkość nowych funkcji, a głównym grzechem jest to, że nie jest ładny. Google – jak Lady Ascot z Alicji w Krainie Czarów Tima Burtona:
Pani Ascot:
- Alicja, wiesz, czego boję się najbardziej?
- Upadek arystokracji?
- Bałem się, że to zrobię brzydkie wnuki.
Aby zrozumieć kompromis między pięknem a praktycznością, przyjrzyjmy się trzeciej udanej platformie (po Emacsie i Androidzie) i zobaczmy, jak to działa: sama Java.
Java ma wiele przestarzałych interfejsów API. Wycofywanie jest bardzo popularne wśród programistów Java, nawet bardziej popularne niż w większości języków programowania. Sama Java, język podstawowy i biblioteki stale wycofują interfejsy API.
Weźmy tylko jeden z tysięcy przykładów, uznane za przestarzałe. Jest ona przestarzała od czasu wydania wersji Java 1.2 w grudniu 1998 r. Minęły 22 lata, odkąd uznano to za przestarzałe.
Ale mój rzeczywisty kod w produkcji nadal zabija wątki każdego dnia. Naprawdę myślisz, że to dobrze? Absolutnie! Mam na myśli oczywiście, że gdybym dzisiaj miał przepisać kod, zaimplementowałbym go inaczej. Ale kod mojej gry, która w ciągu ostatnich dwudziestu lat uszczęśliwiła setki tysięcy ludzi, został napisany z funkcją zamykania zbyt długich wątków, a ja nigdy nie musiałem tego zmieniać. Znam swój system lepiej niż ktokolwiek inny, mam dosłownie 25 lat doświadczenia w pracy z nim na produkcji i mogę powiedzieć z całą pewnością: w moim przypadku zamknięcie tych konkretnych wątków roboczych jest całkowicie Bezwartościowy. Przepisanie tego kodu nie jest warte czasu i wysiłku i dziękuję Larry'emu Ellisonowi (prawdopodobnie), że Oracle nie zmusił mnie do przepisania go.
Oracle prawdopodobnie rozumie również platformy. Kto wie.
Dowody można znaleźć w podstawowych interfejsach API języka Java, które są przepełnione falami starzenia, niczym linie lodowca w kanionie. W bibliotece Java Swing można łatwo znaleźć pięć lub sześć różnych menedżerów nawigacji za pomocą klawiatury (KeyboardFocusManager). Właściwie trudno jest znaleźć interfejs API Java, który nie jest przestarzały. Ale nadal działają! Myślę, że zespół Java naprawdę usunie interfejs API tylko wtedy, gdy interfejs będzie stwarzał rażące problemy związane z bezpieczeństwem.
Rzecz w tym, ludzie: my, programiści, jesteśmy bardzo zajęci i w każdym obszarze oprogramowania mamy do czynienia z konkurencyjnymi alternatywami. W dowolnym momencie programiści języka X rozważają język Y jako możliwy zamiennik. Och, nie wierzysz mi? Chcesz to nazwać Swiftem? To tak, jakby wszyscy migrowali do Swifta i nikt go nie porzuca, prawda? Ojej, jak mało wiesz. Firmy liczą koszty podwójnych zespołów programistów mobilnych (iOS i Android) – i zaczynają zdawać sobie sprawę, że te wieloplatformowe systemy programistyczne o śmiesznych nazwach, takich jak Flutter i React Native, faktycznie działają i można je wykorzystać do zmniejszenia rozmiaru ich zespoły mobilne dwa razy lub odwrotnie, zwiększ ich produktywność dwukrotnie. W grę wchodzą prawdziwe pieniądze. Tak, są kompromisy, ale z drugiej strony pieniądze.
Załóżmy hipotetycznie, że Apple głupio wziął przykład z Guido van Rossuma i oświadczył, że Swift 6.0 jest wstecznie niekompatybilny ze Swift 5.0, podobnie jak Python 3 jest niekompatybilny z Pythonem 2.
Prawdopodobnie opowiedziałem tę historię jakieś dziesięć lat temu, ale jakieś piętnaście lat temu pojechałem z Guido do O'Reilly's Foo Camp, siedziałem w namiocie z Paulem Grahamem i grupą ważniaków. Siedzieliśmy w upale, czekając, aż Larry Page odleci swoim osobistym helikopterem, podczas gdy Guido brzęczał o „Pythonie 3000”, którego nazwał na cześć liczby lat, jakie zajęłaby wszystkim migracja tam. Ciągle pytaliśmy go, dlaczego łamie kompatybilność, a on odpowiedział: „Unicode”. I zapytaliśmy, gdybyśmy musieli przepisać nasz kod, jakie inne korzyści bylibyśmy świadkami? A on odpowiedział: „Tuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu”.
Jeśli zainstalujesz pakiet SDK Google Cloud Platform („gcloud”), otrzymasz następujące powiadomienie:
Drogi Odbiorcy,
Chcielibyśmy przypomnieć, że obsługa Pythona 2 jest przestarzała, więc spierdalaj
… i tak dalej. Koło życia.
Ale chodzi o to, że każdy programista ma wybór. A jeśli zmusisz ich do częstego przepisywania kodu, mogą o tym pomyśleć inny opcje. Nie są twoimi zakładnikami, bez względu na to, jak bardzo byś tego chciał. Oni są twoimi gośćmi. Python jest nadal bardzo popularnym językiem programowania, ale cholera, Python 3(000) stworzył taki bałagan sam w sobie, w swoich społecznościach i wśród użytkowników swoich społeczności, że konsekwencje nie zostały wyjaśnione przez piętnaście lat.
Ile programów w języku Python zostało przepisanych w Go (lub Ruby lub innej alternatywie) z powodu tej niezgodności wstecznej? Ile nowego oprogramowania napisano w czymś innym niż Python, mimo że możliwe napisany w Pythonie, gdyby Guido nie spalił całej wioski? Trudno powiedzieć, ale Python wyraźnie ucierpiał. To ogromny bałagan i wszyscy tracą.
Powiedzmy, że Apple bierze przykład od Guido i przerywa kompatybilność. Jak myślisz, co będzie dalej? Cóż, może 80-90% programistów przepisze swoje oprogramowanie, jeśli to możliwe. Innymi słowy, 10-20% bazy użytkowników automatycznie przechodzi na jakiś konkurencyjny język, taki jak Flutter.
Zrób to kilka razy, a stracisz połowę bazy użytkowników. Podobnie jak w sporcie, w świecie programowania liczy się także obecna forma. wszystko. Każdy, kto straci połowę użytkowników w ciągu pięciu lat, zostanie uznany za wielkiego przegranego. Musisz być modny w świecie platform. Ale w tym przypadku brak obsługi starszych wersji z czasem Cię zrujnuje. Ponieważ za każdym razem, gdy pozbywasz się niektórych programistów, (a) tracisz ich na zawsze, ponieważ są na ciebie źli za złamanie umowy i (b) oddajesz ich konkurencji.
Jak na ironię, pomogłem także Google stać się primadonną, która ignoruje kompatybilność wsteczną, kiedy stworzyłem Grok, system analizy i zrozumienia kodu źródłowego, który ułatwia automatyzację i instrumentację samego kodu - podobnie do IDE, ale tutaj przechowuje usługi w chmurze zmaterializowane reprezentacje wszystkich miliardów linii kodu źródłowego Google w dużej hurtowni danych.
Grok zapewnił pracownikom Google potężną platformę do wykonywania automatycznych refaktoryzacji w całej bazie kodu (dosłownie w całym Google). System oblicza nie tylko Twoje zależności od źródła (od których zależysz), ale także malejąco (które zależą od Ciebie), więc kiedy zmieniasz interfejsy API, wiesz, kogo łamiesz! W ten sposób, wprowadzając zmiany, możesz zweryfikować, czy każdy konsument Twojego API zaktualizował się do nowej wersji, a w rzeczywistości często dzięki napisanemu przez nich narzędziu Rosie możesz całkowicie zautomatyzować proces.
Dzięki temu baza kodów Google może być wewnętrznie niemal nadnaturalnie czysta, ponieważ te roboty-sługi krzątają się po domu i automatycznie sprzątają wszystko, jeśli zmienią nazwę SomeDespicablyLongFunctionName na SomeDespicablyLongMethodName, ponieważ ktoś zdecydował, że to brzydki wnuk i jego trzeba uśpić.
I szczerze mówiąc, działa to całkiem nieźle dla Google... wewnętrznie. To znaczy, tak, społeczność Go w Google naprawdę śmieje się ze społeczności Java w Google ze względu na ich zwyczaj ciągłej refaktoryzacji. Jeśli zrestartujesz coś N razy, oznacza to, że nie tylko schrzaniłeś sprawę N-1 razy, ale po pewnym czasie staje się całkiem jasne, że prawdopodobnie schrzaniłeś to również przy N-tej próbie. Ale ogólnie rzecz biorąc, pozostają ponad tym całym zamieszaniem i utrzymują kod w „czystości”.
Problem zaczyna się, gdy próbują narzucić takie podejście swoim klientom w chmurze i użytkownikom innych API.
Zapoznałem Cię trochę z Emacsem, Androidem i Javą; spójrzmy na najnowszą, odnoszącą sukcesy, długoletnią platformę: samą sieć. Czy możesz sobie wyobrazić, ile iteracji HTTP przeszedł od 1995 roku, kiedy używaliśmy migających tagów? oraz ikony „W budowie” na stronach internetowych.
Ale to nadal działa! I te strony nadal działają! Tak, chłopaki, przeglądarki są mistrzami świata w kompatybilności wstecznej. Chrome to kolejny przykład rzadkiej platformy Google, która ma dobrze zakręcone głowy i, jak można się domyślić, Chrome skutecznie działa jako firma działająca w piaskownicy, odrębna od reszty Google.
Chcę także podziękować naszym przyjaciołom z branży twórców systemów operacyjnych: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD itp., za wykonanie tak wspaniałej pracy w zakresie kompatybilności wstecznej na swoich odnoszących sukcesy platformach (Apple dostaje co najwyżej C za The wadą jest to, że cały czas wszystko psują bez dobrego powodu, ale jakoś społeczność radzi sobie z tym przy każdym wydaniu, a kontenery OS X wciąż nie są całkowicie przestarzałe... jeszcze).
Ale poczekaj, mówisz. Czy nie porównujemy jabłek z pomarańczami – samodzielnych systemów oprogramowania na jednej maszynie, takich jak Emacs/JDK/Android/Chrome, z systemami wieloserwerowymi i interfejsami API, takimi jak usługi w chmurze?
No cóż, pisałem o tym wczoraj na Twitterze, ale w stylu Larry'ego Walla (twórcy języka programowania Perl - ok. per.) na zasadzie "sucks/regules" wyszukałem słowo przestarzałe w witrynach programistycznych Google i Amazon. I chociaż AWS tak ma setki razy więcej ofert usług niż GCP, dokumentacja Google dla programistów wspomina o wycofaniu usług około siedem razy częściej.
Jeśli ktoś w Google to czyta, prawdopodobnie jest gotowy wyciągnąć wykresy w stylu Donalda Trumpa pokazujące, że faktycznie robią wszystko dobrze i że nie powinienem dokonywać nieuczciwych porównań typu „liczba wzmianek słowa przestarzałe w porównaniu do liczba usług" "
Ale po tych wszystkich latach Google Cloud nadal jest usługą nr 3 (nigdy nie pisałem artykułu o nieudanej próbie zajęcia pozycji nr 2), ale jeśli wierzyć wtajemniczonym, istnieją pewne obawy, że wkrótce mogą spaść do Nr 4.
Nie mam żadnych przekonujących argumentów, żeby „udowodnić” moją tezę. Jedyne, co mam, to kolorowe przykłady, które zgromadziłem przez 30 lat pracy jako programista. Wspomniałem już o głęboko filozoficznym charakterze tego problemu; w pewnym sensie jest to upolitycznione w społecznościach programistów. Niektórzy w to wierzą twórcy platformy powinny dbać o kompatybilność, podczas gdy inni uważają, że jest to problem użytkowników (sami programiści). Jeden z dwóch. Czy w istocie nie jest to kwestia polityczna, kiedy decydujemy, kto powinien ponosić koszty wspólnych problemów?
To jest więc polityka. I prawdopodobnie pojawią się gniewne reakcje na moje przemówienie.
jak użytkownik Google Cloud Platform i jako użytkownik AWS od dwóch lat (pracując w Grab) mogę powiedzieć, że filozofia Amazona i Google'a jest ogromna, jeśli chodzi o priorytety. Nie rozwijam się aktywnie na AWS, więc nie wiem zbyt dobrze, jak często usuwają stare interfejsy API. Istnieją jednak podejrzenia, że nie zdarza się to tak często, jak w Google. Naprawdę wierzę, że to źródło ciągłych kontrowersji i frustracji w GCP jest jednym z największych czynników hamujących rozwój platformy.
Wiem, że nie podałem konkretnych przykładów systemów GCP, które nie są już wspierane. Mogę powiedzieć, że prawie wszystko, z czego korzystałem, od sieci (od najstarszych po VPC) po przechowywanie (Cloud SQL v1-v2), Firebase (teraz Firestore z zupełnie innym API), App Engine (nawet nie zaczynajmy) , punkty końcowe w chmurze Cloud Endpoint i do... Nie wiem - absolutnie to wszystko zmusili Cię do przepisania kodu po maksymalnie 2-3 latach i nigdy nie zautomatyzowali migracji za Ciebie, a często . Jakby tak miało być.
I za każdym razem, gdy patrzę na AWS, zadaję sobie pytanie, dlaczego do cholery wciąż jestem na GCP. Najwyraźniej nie potrzebują klientów. Oni potrzebują kupujący. Czy rozumiesz różnicę? Pozwól mi wyjaśnić.
Google Cloud ma , gdzie ludzie proponują swoje rozwiązania programowe i aby uniknąć efektu pustej restauracji, musieli wypełnić ją kilkoma propozycjami, więc zlecili firmie Bitnami stworzenie zestawu rozwiązań, które można wdrożyć „jednym kliknięciem” lub które powinny Sam piszę to „rozwiązania”, ponieważ one nie rozwiązują żadnej cholernej rzeczy. Istnieją po prostu jako pola wyboru, wypełniacze marketingowe, a Google nigdy nie dbało o to, czy którekolwiek z narzędzi faktycznie działa. Znam menedżerów produktu, którzy zasiadali za sterami i mogę zapewnić, że tych ludzi to nie obchodzi.
Weźmy na przykład rozwiązanie wdrożeniowe rzekomo „jednym kliknięciem”. . Miałem już dość szaleństw związanych z Google Cloud SQL, więc zacząłem szukać alternatywy dla zbudowania własnego klastra Percona. I tym razem wydawało się, że Google wykonał dobrą robotę, jednym kliknięciem zaoszczędziło mi trochę czasu i wysiłku!
No świetnie, chodźmy. Przejdźmy do linku i kliknij ten przycisk. Wybierz „Tak”, aby zaakceptować wszystkie ustawienia domyślne i wdrożyć klaster w projekcie Google Cloud. Haha, to nie działa. Nic z tego badziewia nie działa. Narzędzie nigdy nie było testowane i zaczęło gnić od pierwszej minuty i nie zdziwiłbym się, gdyby ponad połowa „rozwiązań” to wdrożenia jednym kliknięciem (teraz rozumiemy, dlaczego cytaty) ogólnie nie działa. To zupełnie beznadziejna ciemność, do której lepiej nie wchodzić.
Ale Google ma rację popędy ci z nich korzystać. Chcą, żebyś to zrobił kupiony. Dla nich to transakcja. Oni nic nie chcą wsparcie. To nie jest część DNA Google. Tak, inżynierowie wspierają się nawzajem, o czym świadczy moja historia z Bigtable. Ale w produktach i usługach dla zwykłych ludzi zawsze byli bezwzględni , który nie spełnia wymagań dotyczących rentowności, nawet jeśli ma miliony użytkowników.
Stanowi to prawdziwe wyzwanie dla GCP, ponieważ takie jest DNA wszystkich ofert chmurowych. Nie próbują niczego wspierać; Powszechnie wiadomo, że odmawiają hostowania (jako usługi zarządzanej) jakiegokolwiek oprogramowania stron trzecich aż do, dopóki AWS nie zrobi tego samego i nie zbuduje wokół tego odnoszącego sukcesy biznesu, a klienci dosłownie będą wymagać tego samego. Jednak nakłonienie Google do obsługi czegoś wymaga pewnego wysiłku.
Ten brak kultury wsparcia w połączeniu z mentalnością „zburzmy to, żeby było piękniej”, zniechęca programistów.
A to nie jest dobre, jeśli chcesz zbudować trwałą platformę.
Google, obudź się, do cholery. Teraz jest rok 2020. Nadal przegrywasz. Czas spojrzeć w lustro i odpowiedzieć sobie, czy na pewno chcesz pozostać w biznesie chmurowym.
Jeśli chcesz zostać to przestań wszystko niszczyć. Chłopaki, jesteście bogaci. My, programiści, nie. Jeśli więc chodzi o to, kto poniesie ciężar zapewnienia zgodności, musisz wziąć go na siebie. Nie dla nas.
Bo są jeszcze co najmniej trzy naprawdę dobre chmury. Wzywają.
A teraz przejdę dalej, aby naprawić wszystkie moje zepsute systemy. Ech.
Do następnego razu!
PS Aktualizacja po przeczytaniu niektórych dyskusji na temat tego artykułu (dyskusje są świetne, przy okazji). Wsparcie dla Firebase nie zostało przerwane i nie mam żadnych planów, o których wiem. Mają jednak nieprzyjemny błąd przesyłania strumieniowego, który powoduje zatrzymanie klienta Java w App Engine. Jeden z ich inżynierów pomógł mi rozwiązać ten problem, kiedy pracowałem w Google, ale tak naprawdę nigdy nie naprawili błędu, więc mam kiepskie rozwiązanie polegające na codziennym ponownym uruchamianiu aplikacji GAE. I tak już od czterech lat! Mają teraz Firestore. Migracja do niego zajmie dużo pracy, ponieważ jest to zupełnie inny system, a błąd Firebase nigdy nie zostanie naprawiony. Jaki wniosek można wyciągnąć? Możesz uzyskać pomoc jeśli pracujesz w firmie. Prawdopodobnie jestem jedyną osobą, która korzysta z Firebase na GAE, ponieważ loguję mniej niż 100 kluczy w aplikacji w 100% natywnej i przestaje ona działać co kilka dni z powodu znanego błędu. Co mogę powiedzieć poza tym, że używasz go na własne ryzyko. Przechodzę na Redis.
Widziałem też, jak niektórzy bardziej doświadczeni użytkownicy AWS twierdzili, że AWS zwykle nigdy nie przestaje wspierać żadnych usług, a SimpleDB jest tego doskonałym przykładem. Moje przypuszczenia, że AWS nie ma takiej samej choroby końca wsparcia jak Google, wydają się uzasadnione.
Dodatkowo zauważyłem, że 20 dni temu zespół Google App Engine przerwał hosting krytycznej biblioteki Go, zamykając aplikację GAE jednego z głównych programistów Go. To było naprawdę głupie.
Wreszcie słyszałem, jak pracownicy Google omawiali już tę kwestię i ogólnie się ze mną zgadzali (kocham was!). Wydaje się jednak, że uważają, że problemu nie da się rozwiązać, ponieważ kultura Google nigdy nie miała odpowiedniej struktury motywacyjnej. Pomyślałem, że dobrze byłoby poświęcić trochę czasu na omówienie absolutnie niesamowitego doświadczenia, jakie zdobyłem podczas pracy z inżynierami AWS podczas pracy w Grab. Mam nadzieję, że kiedyś w przyszłości!
I tak, w 2005 roku w gigantycznym bufecie w budynku 43 serwowano różne rodzaje mięsa rekina, a moim ulubionym było mięso rekina młotowatego. Jednak do 2006 roku Larry i Sergei pozbyli się wszelkich niezdrowych przekąsek. Więc podczas historii Bigtable w 2007 roku naprawdę nie było rekinów i oszukałem cię.
Kiedy cztery lata temu patrzyłem na chmurę Bigtable (daj lub weź), to właśnie tutaj były koszty. Wydaje się, że teraz nieco spadło, ale to wciąż strasznie dużo jak na pustą hurtownię danych, zwłaszcza że moja pierwsza historia pokazuje, jak nieistotna jest pusta duża tabela w ich skali.
Przepraszam, że uraziłem społeczność Apple i nie powiedziałem nic miłego o Microsoft itp. Wszystko w porządku, naprawdę doceniam całą dyskusję, którą wywołał ten artykuł! Ale czasami trzeba trochę pomachać, żeby rozpocząć dyskusję, wiesz?
Dziękuje za przeczytanie.
Aktualizacja 2, 19.08.2020. Naszywka !
Aktualizacja 3, 31.08.2020. Skontaktował się ze mną inżynier Google z Cloud Marketplace, który okazał się moim starym znajomym. Chciał dowiedzieć się, dlaczego C2D nie działa, i w końcu doszliśmy do wniosku, że dzieje się tak dlatego, że zbudowałem swoją sieć wiele lat temu, a C2D nie działało w starszych sieciach, ponieważ w ich szablonach brakowało parametru podsieci. Myślę, że najlepiej będzie, jeśli potencjalni użytkownicy GCP upewnią się, że znają wystarczającą liczbę inżynierów w Google…
Źródło: www.habr.com