Do cholery, Google, nie chciałem znowu pisać na blogu. Mam tyle rzeczy do zrobienia. Prowadzenie bloga wymaga czasu, energii i kreatywności, które mógłbym wykorzystać w bardziej pożyteczny sposób: na moje książki, , moją grę i tak dalej. Ale wystarczająco mnie wkurzyłeś, więc muszę to napisać.
Więc skończmy z tym.
Zacznę od krótkiej, ale pouczającej historii z czasów, gdy dopiero zaczynałem pracować w Google. Wiem, że ostatnio mówiłem dużo złego o Google, ale denerwuje mnie, gdy moja rodzima firma regularnie podejmuje niekompetentne decyzje biznesowe. Jednak należy przyznać: wewnętrzna infrastruktura Google jest naprawdę niezwykła, można śmiało powiedzieć, że dziś nie ma nic lepszego. Założyciele Google byli znacznie lepszymi inżynierami, niż kiedykolwiek będę, a ta historia tylko to potwierdza.
Najpierw trochę tła: Google ma technologię przechowywania danych pod nazwą . To było wspaniałe osiągnięcie techniczne, jedno z pierwszych (jeśli nie pierwsze) "nieskończenie skalowalne" magazyn par "klucz-wartość" (key-value store, K/V): w zasadzie początek NoSQL. Dziś Bigtable wciąż dobrze radzi sobie w dość zatłoczonym obszarze magazynów K/V, ale w tamtym czasie (2005 rok) było to niesamowicie fajne.
Jednym zabawnym szczegółem Bigtable jest to, że mieli wewnętrzne obiekty warstwy kontrolnej (jako część implementacji) zwane serwerami tabletów, z dużymi indeksami, i w pewnym momencie stały się one wąskim gardłem przy skalowaniu systemu. Inżynierowie Bigtable łamali sobie głowy, jak wdrożyć skalowalność, i nagle zdali sobie sprawę, że mogą zastąpić serwery tabletów innymi magazynami Bigtable. Tak więc Bigtable jest częścią implementacji Bigtable. Te magazyny są obecne na wszystkich poziomach.
Inną interesującą kwestią jest to, że przez pewien czas Bigtable stał się popularny i wszechobecny w Google, a każde zespoły miały swoje własne przechowalnie. Dlatego podczas jednego z piątkowych spotkań Larry Page zadał pytanie: „Dlaczego mamy więcej niż jednego Bigtable? Dlaczego nie wystarczy tylko jeden?” Teoretycznie jedno przechowalnia powinno wystarczyć dla wszystkich potrzeb przechowywania Google. Oczywiście, nigdy nie przeszli na tylko jedną z praktycznych powodów rozwoju (na przykład skutki potencjalnych awarii), ale teoria była interesująca. Jedno przechowalnia dla całego wszechświata (przy okazji, ktoś wie, co zrobił Amazon ze swoim Sable?)
Tak czy inaczej, oto moja historia.
W tym czasie pracowałem w Google trochę ponad dwa lata, i pewnego dnia otrzymałem e-mail od zespołu inżynieryjnego Bigtable o mniej więcej takiej treści:
Drogi Steve,
Witaj od zespołu Bigtable. Chcemy Cię poinformować, że w centrum danych [nazwa centrum danych] używasz bardzo, bardzo starego pliku binarnego Bigtable. Ta wersja nie jest już wspierana, a my chcemy Ci pomóc w przejściu na najnowszą wersję.
Proszę daj znać, czy możesz zaplanować trochę czasu na wspólne rozwiązanie tego problemu.
Wszystkiego najlepszego,
Zespół Bigtable
W Google dostajesz wiele emaili, więc przy pierwszym spojrzeniu przeczytałem to mniej więcej tak:
Drogi odbiorco,
Witaj od jakiegoś zespołu. Chcemy Cię poinformować, że bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, i bla-bla-bla natychmiast.
Proszę daj nam znać, czy możesz zaplanować część swojego cennego czasu na bla-bla-bla.
Wszystkiego najlepszego,
Jakiś zespół
Prawie usunąłem to od razu, ale na granicy świadomości poczułem dokuczliwe, pulsujące uczucie, że to nie do końca wygląda jak formalny e-mail, chociaż oczywiście, że pomylono adresata, ponieważ nie korzystałem z Bigtable.
Ale to było dziwne.
Resztę dnia na przemian myślałem o pracy i o tym, jaki rodzaj mięsa rekina spróbować w mikro-kuchni, z których przynajmniej trzy były wystarczająco blisko, aby osiągnąć je rzucając biszkotem, ale myśl o e-mailu nie opuszczała mnie z narastającym uczuciem lekkiego niepokoju.
Oni wyraźnie wymienili moje imię. I list został wysłany na mój adres e-mail, a nie na czyjś inny, i to nie jest cc: ani bcc:. Ton jest bardzo osobisty i wyraźny. Może to jakiś błąd?
W końcu ciekawość wzięła górę i poszedłem zobaczyć konsolę Borg w centrum danych, o którym wspomnieli.
I oczywiście miałem w zarządzeniu magazyn BigTable. Co? Spojrzałem na jego zawartość i - dajcie spokój! Był to magazyn z inkubatora Codelab, w którym spędziłem pierwszy tydzień pracy w Google w czerwcu 2005 roku. Codelab zmuszał cię do uruchomienia Bigtable, abyś wprowadził tam pewne wartości, a ja najwyraźniej nie zamknąłem magazynu po tym. Wciąż działał, mimo że minęły ponad dwa lata.
W tej historii jest kilka istotnych aspektów. Po pierwsze, działanie Bigtable było tak nieistotne w skali Google, że dopiero po dwóch latach ktoś zauważył niepotrzebny magazyn, i to tylko dlatego, że wersja binarna była przestarzała. Dla porównania, kiedyś rozważałem możliwość użycia do mojej gry online. W tamtym czasie ta usługa kosztowała około 16 000 dolarów rocznie za pusty Bigtable na GCP. Nie mówię, że cię oszukują, ale moim osobistym zdaniem to dużo pieniędzy za pustą cholerną bazę danych.
Kolejny istotny aspekt polega na tym, że magazyn wciąż działał po dwóch latach. WTF? Centra danych przychodzą i odchodzą; doświadczają przerw, przechodzą zaplanowane konserwacje, cały czas się zmieniają. Sprzęt jest aktualizowany, przełączniki są zmieniane; wszystko jest w ciągłym ulepszaniu. Jak do diabła udało im się utrzymać moją aplikację uruchomioną przez dwa lata mając na uwadze wszystkie te zmiany? Może to nie wyglądać na wielkie osiągnięcie w 2020 roku, ale w latach 2005-2007 było to naprawdę imponujące.
A najbardziej niesamowitym aspektem jest to, że zewnętrzny zespół inżynierski z jakiegoś innego stanu kontaktuje się ze mną, właścicielem jakiegoś maleńkiego, praktycznie pustego egzemplarza Bigtable, który ma zerowy ruch przez ostatnie dwa lata - i oferuje pomoc w jego aktualizacji.
Podziękowałem im, usunąłem magazyn, a życie toczyło się dalej. Ale trzynaście lat później wciąż myślę o tym liście. Bo czasami dostaję podobne listy od Google Cloud. Wyglądają tak:
Drogi użytkowniku Google Cloud,
Przypominamy, że z końcem sierpnia 2020 roku zaprzestajemy wsparcia dla usługi [ważny serwis, który używasz], po czym nie będziesz mógł aktualizować swoich instancji. Zalecamy przejście na najnowszą wersję, która jest w fazie beta, nie ma żadnej dokumentacji, żadnej drogi migracji i która już wcześniej stała się przestarzała przy naszej uprzejmej pomocy.
Stawiamy sobie za cel, 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 nie czytam takich wiadomości, ponieważ tak naprawdę mówią one to:
Drogi odbiorco,
Odpuść sobie. Odpuść sobie, odpuść sobie, odpuść sobie. Porzuć wszystko, co robisz, bo to nie ma znaczenia. To, co jest ważne, to nasz czas. Marnujemy czas i pieniądze, aby utrzymać nasze gówno, i mamy tego dość, więc już nie będziemy tego wspierać. Więc odstaw swoje przeklęte plany i zacznij kopać w naszej gównie dokumentacji, pytając o ochłapy na forach, a swoją drogą, nasze nowe gówno jest całkowicie inne niż stare gówno, bo naprawdę zepsuliśmy ten design, heh, ale to twój problem, a nie nasz.
Nadal staramy się, aby wszystkie twoje rozwinięcia stały się nieużywalne w ciągu roku.
Proszę, idź sobie,
Platforma chmurowa Google
I chodzi o to, że takie wiadomości otrzymuję mniej więcej raz w miesiącu. Dzieje się to tak często i tak regularnie, że nieuchronnie odrzuciły mnie od GCP w oboz przeciwko chmurom. Nie chcę już polegać na ich zamkniętych rozwiązaniach, ponieważ naprawdę jest łatwiej devopsowi utrzymać system z otwartym kodem źródłowym na czystej wirtualce, niż próbować nadążyć za Google i jej polityką zamykania 'przestarzałych' produktów.
Zanim wrócę do Google Cloud, ponieważ ja nawet blisko Nie przestałem ich krytykować, więc przyjrzyjmy się pracy firmy w kilku innych obszarach. Inżynierowie Google są dumni ze swojej dyscypliny w tworzeniu oprogramowania i to właśnie to generuje problemy. Duma to pułapka dla niedoświadczonych, przez którą wielu pracowników Google myśli, że ich decyzje są zawsze słuszne, a poprawność (według jakiejś nieokreślonej definicji) jest ważniejsza niż troska o klientów.
Podam kilka przypadkowych przykładów z innych dużych projektów spoza Google, ale mam nadzieję, że dostrzeżesz ten wzór wszędzie. Ja polega na tym, że: wsparcie dla wstecznej kompatybilności wspiera trwałość i aktualność systemów przez dziesięciolecia.
Wsteczna kompatybilność to cel projektowania wszystkich udanych systemów, które są przeznaczone do otwartego użycia, czyli implementowane z otwartym kodem źródłowym i/lub na otwartych standardach. Czuję, że mówię coś zbyt oczywistego, co może być wręcz niewygodne, ale nie. To kwestia polityczna, dlatego potrzebne są przykłady.
Pierwszy system, który wybiorę, jest najstarszy: GNU Emacs, to swego rodzaju hybryda między Notatnikiem Windows, jądrem systemu operacyjnego a Międzynarodową Stacją Kosmiczną. Trochę trudno to wyjaśnić, ale mówiąc krótko, Emacs to platforma stworzona w 1976 roku (tak, prawie pół wieku temu) do programowania, mająca na celu zwiększenie Twojej produktywności, ale maskująca się jako edytor tekstu.
Korzystam z Emacs każdego dnia. Tak, używam również IntelliJ każdego dnia, sama stała się potężną platformą narzędziową. Ale pisanie rozszerzeń dla IntelliJ to znacznie bardziej ambitne i skomplikowane zadanie niż pisanie rozszerzeń dla Emacs. I co jeszcze ważniejsze, wszystko, co zostało napisane dla Emacs, zachowuje się na zawsze.
Wciąż korzystam z oprogramowania, które napisałem dla Emacs w 1995 roku. I jestem pewien, że ktoś używa modułów napisanych dla Emacs w połowie lat 80-tych, jeśli nie wcześniej. Od czasu do czasu mogą wymagać drobnych korekt, ale to naprawdę rzadko się zdarza. Nie znam nic, co kiedykolwiek napisano dla Emacs (a napisałem dużo), co wymagałoby przebudowy architektury.
W Emacs znajduje się funkcja o nazwie make-obsolete dla przestarzałych bytów. Terminologia Emacs dotycząca fundamentalnych pojęć komputerowych (np. czym jest „okno”) często różni się od branżowych konwencji, ponieważ Emacs wprowadził je bardzo dawno temu. To typowe niebezpieczeństwo dla tych, którzy wyprzedzili swoją epokę: wszystkie twoje terminy są niepoprawne. Ale w Emacs rzeczywiście istnieje koncepcja przestarzałości, która w ich żargonie nosi nazwę przestarzałość.
Ale w świecie Emacs wydaje się, że obowiązuje inne robocze definicja. Inna podstawowa filozofia, jeśli chcesz.
W świecie Emacs (i w wielu innych dziedzinach, które omówimy poniżej) status przestarzałych API w większości oznacza: „Naprawdę nie powinieneś korzystać z tego podejścia, ponieważ chociaż działa, ma różne wady, które wyliczymy tutaj. Ale w końcu to twój wybór”.
W świecie Google status przestarzałego produktu oznacza: „Nie dotrzymujemy swoich zobowiązań wobec ciebie”. I rzeczywiście tak jest. Oto co to zasadniczo oznacza. Oznacza to, że zmuszą cię do regularnego wykonywania pewnej pracy, być może dużej pracy, w ramach kary za to, że uwierzyłeś w ich : mamy najlepsze oprogramowanie. Najszybsze! Robisz wszystko zgodnie z instrukcjami, uruchamiasz swoją aplikację lub usługę, a potem — bum, po roku lub dwóch przestaje działać.
To jak sprzedaż używanego samochodu, który na pewno zepsuje się po 1500 km.
To dwa zupełnie różne filozoficzne definicje „przestarzałości”. Definicja Googla pachnie . Nie wierzę, że to w rzeczywistości zaplanowana przestarzałość w tym samym sensie, co u Apple. Ale Google zdecydowanie ma zamiar zepsuć twoje programy w okrężny sposób. Wiem to, ponieważ przez ponad 12 lat pracowałem tam jako programista. Mają niejasne wewnętrzne wytyczne, w jakim stopniu należy zachować zgodność wsteczną, ale ostatecznie zależy to od każdego zespołu lub usługi. Nie ma żadnych wytycznych na poziomie korporacyjnym lub inżynieryjnym, a najbardziej odważna rekomendacja w kwestii cyklu przestarzałości to „spróbuj dać klientom 6–12 miesięcy na aktualizację, zanim zepsujesz im cały system”.
Problem jest znacznie poważniejszy, niż myślą, i utrzyma się przez wiele lat, ponieważ troska o klientów nie jest częścią ich DNA. Więcej o tym poniżej.
Na ten moment zamierzam postawić odważną tezę, że Emacs odnosi sukces w dużej mierze właśnie dlatego, głównie że tak poważnie podchodzą do kompatybilności wstecznej. Właściwie, to jest teza naszego artykułu. Udane, długo żyjące systemy open-source zawdzięczają swój sukces mikrospołecznościom, które przez dziesięciolecia żyją wokół rozszerzeń/wtyczek.To właśnie jest ekosystem. Już myślałem o samej istocie platform i o tym, jak bardzo są one ważne, i o tym, że Google przez całą swoją historię korporacyjną nigdy nie rozumiało, co potrzeba, aby stworzyć udaną otwartą platformę, z wyjątkiem Androida czy Chrome'a.
Właściwie, powinienem krótko wspomnieć o Androidzie, ponieważ zapewne pomyślałeś o nim.
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, tej firmie pozwolono działać w dużej mierze autonomicznie i faktycznie pozostała w znacznym stopniu nietknięta przez te lata. Android to dobrze znany stos techniczny i równie dobrze znana zorganizowana chaotyczność. Jak powiedział jeden z pracowników Google, „nie można po prostu wejść do Androida”.
W jednym z wcześniejszych artykułów już zastanawiałem się, jak złe były niektóre z wczesnych decyzji projektowych Androida. Rany, kiedy pisałem ten artykuł, zajmowali się wdrażaniem czegoś, co nazywano „aplikacjami natychmiastowymi”, które teraz (niespodzianka!) , i współczuję, jeśli byłeś na tyle głupi, by posłuchać Google i przenieść swoją treść do tych aplikacji natychmiastowych.
Ale jest tu różnica, zasadnicza różnica, polegająca na tym, że ludzie z Androida naprawdę rozumieją, jak ważne są platformy, starają się ze wszystkich sił utrzymać działanie starych aplikacji Android. W rzeczywistości ich wysiłki w zachowaniu zgodności wstecznej są tak ekstremalne, że nawet ja, podczas swojego krótkiego pobytu w zespole Android kilka lat temu, odkryłem, że próbuję ich przekonać do rezygnacji z wsparcia dla niektórych z najstarszych urządzeń i API (miałem rację, jak w wielu innych sprawach z przeszłości i teraźniejszości. Przepraszam, ludzie z Androida! Teraz, gdy byłem w Indonezji, rozumiem, dlaczego są nam potrzebni).
Ludzie z Androida utrzymują zgodność wsteczna do niemal niewyobrażalnych ekstremów, co prowadzi do ogromnej liczby przestarzałych długów technicznych w ich systemach i łańcuchach narzędzi. O Boże, widzielibyście niektóre szalone rzeczy, które muszą robić w swoim systemie budowania, i to wszystko w imię zgodności.
Za to przyznaję Androidowi wymarzoną nagrodę „Nie jesteś Googlem”. Oni naprawdę nie chcą stać się Googlem, który nie potrafi tworzyć trwałych platform, a Android wie, jak to robić. wie, dlatego Google zachowuje się bardzo mądrze w jednym aspekcie: pozwala ludziom w Androidzie robić wszystko po swojemu.
Jednak natychmiastowe aplikacje dla Androida były dość głupim pomysłem. I wiecie dlaczego? Ponieważ wymagały przepisania i zaprojektowania na nowo swojej aplikacji! Jakby ludzie po prostu wzięli i przepisali dwa miliony aplikacji. Przypuszczam, że natychmiastowe aplikacje były pomysłem jakiegoś googlera.
Ale jest tu różnica. Zgodność wsteczna wiąże się z dużymi kosztami. Android sam ponosi ciężar tych kosztów, podczas gdy Google wymaga, aby ten ciężar nosili będziecie, płatny klient.
Można zobaczyć zaangażowanie Androida w zgodność wsteczną w jego interfejsach API. Kiedy masz cztery lub pięć różnych podsystemów do wykonywania dosłownie tego samego, to pewny znak, że w podstawie leży zaangażowanie w zgodność wsteczną. Co w świecie platform jest synonimem zaangażowania w swoich klientów i rynek.
Głównym problemem Google jest ich duma z inżynieryjnej higieny. Nie lubią, gdy istnieje wiele różnych sposobów na wykonanie tej samej czynności, a stare, mniej pożądane metody współistnieją z nowymi, bardziej wyszukanymi sposobami. To zwiększa krzywą uczenia się dla nowicjuszy w systemie, zwiększa obciążenie wsparcia dla przestarzałych API, spowalnia tempo wprowadzania nowych funkcji, a największym grzechem jest to, że wygląda to nieestetycznie. Google jest jak Lady Escott z "Alicji w Krainie Czarów" Tima Burtona:
Lady Escott:
— Alicjo, wiesz, czego boję się najbardziej?
— Upadku arystokracji?
— Obawiałam się, że będę miała nieładnych wnuków.
Aby zrozumieć kompromis między pięknym a praktycznym, spojrzymy na trzecią udaną platformę (po Emacs i Androidzie) i zobaczymy, jak działa: sama Java.
W Javie jest mnóstwo przestarzałych API. Przestarzałość jest bardzo popularna wśród programistów Javy, nawet bardziej niż w większości języków programowania. W samej Javie, głównym języku i bibliotekach, regularnie występuje przestarzałość API.
Weźmy tylko jeden z tysiąca przykładów: jest uważane za przestarzałe. To zostało uznane za przestarzałe od momentu wydania Javy 1.2 w grudniu 1998 roku. Minęło 22 lata, odkąd to przestało być aktualne.
Ale mój rzeczywisty kod w produkcji nadal zamyka wątki każdego dnia. Czy to dobrze? Absolutnie! Chociaż, oczywiście, gdybym pisał kod dzisiaj, zrealizowałbym to inaczej. Ale kod mojej gry, która przez ostatnie dwa dekady uszczęśliwiła setki tysięcy ludzi, jest napisany z funkcją zamykania wątków, które wiszą zbyt długo, i nigdy nie musiałem go zmieniać. Znam swój system lepiej niż ktokolwiek inny, mam dosłownie 25-letnie doświadczenie w pracy z nim w produkcji i mogę z pewnością powiedzieć: w moim przypadku zamykanie tych konkretnych wątków jest całkowicie nieszkodliwe. Nie ma sensu tracić czasu i energii na przepisywanie tego kodu, a dzięki Larry'emu Ellisonowi (prawdopodobnie) Oracle nie zmusiło mnie do jego przepisania.
Pewnie Oracle też zna się na platformach. Kto to wie.
Dowody możesz znaleźć we wszystkich kluczowych Java API, które są przesiąknięte falami przestarzałości, podobnie jak linie lodowca w wąwozie. W bibliotece Java Swing można łatwo znaleźć pięć lub sześć różnych menedżerów fokusów klawiatury (KeyboardFocusManager). W rzeczywistości trudno znaleźć Java API, które nie jest przestarzałe. Ale wciąż działają! Myślę, że zespół Java naprawdę usunie API tylko w przypadku, gdy interfejs spowoduje oczywisty problem bezpieczeństwa.
Oto o co chodzi, koledzy: my, programiści, wszyscy jesteśmy bardzo zajęci i w każdej dziedzinie oprogramowania napotykamy konkurencyjne alternatywy. W każdej chwili programiści w języku X rozważają użycie języka Y jako możliwej zamiany. O, nie wierzycie mi? Chcecie wymienić Swifta? Mówią, że wszyscy migrują na Swifta, a nikt się go nie wyrzeka, prawda? Ojej, jak mało wiecie. Firmy rozważają koszty podwójnych zespołów mobilnych (iOS i Android) – i zaczynają rozumieć, że te wieloplatformowe systemy rozwijania z absurdalnymi nazwami, takimi jak Flutter i React Native, naprawdę działają, i dzięki nim mogą zmniejszyć rozmiar swoich zespołów mobilnych o połowę lub wręcz uczynić je dwa razy bardziej produktywnymi. W grze są prawdziwe pieniądze. Tak, są kompromisy, ale z drugiej strony, de-e-e-enie.
Załóżmy hipotetycznie, że Apple głupio wzoruje się na Guido van Rossumie i ogłasza, że Swift 6.0 jest wstecznie niekompatybilny ze Swiftem 5.0, tak jak Python 3 jest niekompatybilny z Pythonem 2.
Pewnie opowiadałem tę historię jakieś dziesięć lat temu, ale piętnaście lat temu jeździłem na obóz O’Reilly’s Foo Camp z Guido, siedziałem w namiocie z Paulem Grahamem i grupą wielkich graczy. Siedzieliśmy w upale i czekaliśmy, aż Larry Page przyleci swoim prywatnym helikopterem, a Guido monotonnie paplał o „Pythonie 3000”, który nazwał tak, ponieważ tyle lat zajmie wszystkim migracja. Cały czas zadawaliśmy mu pytanie, dlaczego łamie zgodność, a on odpowiadał: “Unicode”. A my zadawaliśmy pytanie, jeśli będziemy musieli przepisać swój kod, to jakie inne korzyści zobaczymy? A on odpowiadał “Yoooooooooooooouuuuuuuniiiiiiicoooooooode.”
Jeśli zainstalujesz Google Cloud Platform SDK („gcloud”), otrzymasz następujące powiadomienie:
Drogi odbiorco,
Chcielibyśmy przypomnieć, że wsparcie dla Pythona 2 zostało zakończone, więc idź sobie.
... i tak dalej. Koło życia.
Ale chodzi o to, że każdy programista ma wybór. A jeśli zmusisz ich do ciągłego przepisywania kodu, mogą pomyśleć również o innych opcjach. Nie są twoimi więźniami, jakkolwiek byś tego chciał. Są twoimi gośćmi. Python nadal jest bardzo popularnym językiem programowania, ale, do diabła, Python 3(000) stworzył taki bałagan w swoich społecznościach i użytkownikach, że konsekwencje nie mogą zostać rozwiązane od piętnastu lat.
Ile programów Pythona zostało przepisanych na Go (lub Ruby, lub inną alternatywę) z powodu tej niekompatybilności wstecznej? Ile nowego oprogramowania zostało napisane w czymś innym niż Python, chociaż mogło być napisane w Pythonie, gdyby Guido nie spalił całej wioski? Trudno powiedzieć, ale Python zdecydowanie ucierpiał. To ogromny bałagan i wszyscy są na przegranej pozycji. Więc załóżmy, że Apple bierze przykład z Guido i łamie kompatybilność. Co myślisz, co się stanie potem? 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 przeniosą się na jakiś konkurencyjny język, na przykład Flutter.
Zrób to kilka razy — a stracisz połowę swojej bazy użytkowników. Tak jak w sporcie, w świecie programowania aktualna forma też ma znaczenie
wszystko. . Każdy, kto straci połowę użytkowników w ciągu pięciu lat, będzie uważany za Wielkiego Grubego Przegranego. Musisz być na bieżąco w świecie platform. Ale w tym miejscu rezygnacja ze wsparcia starych wersji w końcu cię pogrąży. Ponieważ za każdym razem, gdy pozbywasz się części programistów, (a) tracisz ich na zawsze, ponieważ są na ciebie złotni za złamanie umowy, i (b) oddajesz ich swoim konkurentom.Ironią losu, ja również pomogłem Google stać się taką primadoną, która ignoruje kompatybilność wsteczną, kiedy stworzyłem Grok, system analizy i zrozumienia kodu źródłowego, który ułatwia automatyzację i wyposażenie w narzędzia na podstawie samego kodu — przypomina IDE, ale tutaj usługa w chmurze przechowuje zmaterializowane widoki wszystkich miliardów linii kodu źródłowego Google w dużym magazynie danych.
W ironii losu, również pomogłem Google stać się taką primadoną, która ignoruje wsteczną kompatybilność, gdy stworzyłem Grok, system analizy i zrozumienia kodu źródłowego, który ułatwia automatyzację i wyposażenie w narzędzia w oparciu o sam kod — przypomina IDE, ale tutaj chmurowa usługa przechowuje zmaterializowane widoki wszystkich miliardów linii kodu źródłowego Google w dużym magazynie danych.
Grok dostarczył Google'owi potężną podstawę do przeprowadzania zautomatyzowanej refaktoryzacji w całej bazie kodu (dosłownie w całym Google). System oblicza nie tylko Twoje zależności w górę (od których jesteś zależny), ale także zależności w dół (które od Ciebie zależą), więc przy zmianie API wiesz, kogo łamiesz! W ten sposób, wprowadzając zmiany, możesz zweryfikować, że każdy konsument Twojego API zaktualizował się do nowej wersji, a w rzeczywistości często za pomocą narzędzia Rosie, które napisali, możesz całkowicie zautomatyzować ten proces.
To pozwala bazie kodu Google wewnętrznie być niemal nadnaturalnie "czystą", ponieważ mają te robotyczne sługi, które wędrują po całym domu i automatycznie sprzątają wszystko, jeśli zmienili nazwę SomeDespicablyLongFunctionName na SomeDespicablyLongMethodName, ponieważ ktoś postanowił, że to brzydki wnuk i należy go uśpić.
I, szczerze mówiąc, to całkiem dobrze działa dla Google... wewnętrznie. Mam na myśli, tak, społeczność Go w Google naprawdę z uśmiechem patrzy na społeczność Java w Google z powodu ich zwyczaju ciągłej refaktoryzacji. Jeśli coś uruchamiasz N razy, to oznacza, że nie tylko zepsułeś to N-1 razy, ale po jakimś czasie staje się całkowicie jasne, że prawdopodobnie zepsułeś to także przy N. próbie. Ale, ogólnie rzecz biorąc, pozostają ponad tym zgiełkiem i utrzymują kod "czystym".
Problemy zaczynają się, gdy próbują narzucić takie nastawienie swoim klientom w chmurze i użytkownikom innych API.
Trochę zapoznałem Cię z Emacsem, Androidem i Javą; przyjrzyjmy się ostatniej udanej długowiecznej platformie: samemu Webowi. Możesz sobie wyobrazić, przez ile iteracji przeszedł HTTP od 1995 roku, kiedy używaliśmy migających tagów i znaczków "W trakcie tworzenia" na stronach internetowych.
Ale to wciąż działa! I te strony wciąż działają! Tak, panowie, przeglądarki są mistrzami świata w zachowywaniu kompatybilności wstecznej. Chrome to kolejny przykład rzadkiej platformy Google, której głowy są przykręcone tak jak należy i, jak już zgadłeś, Chrome działa skutecznie jako odizolowana firma, oddzielona od reszty Google.
Chciałbym również podziękować naszym przyjaciołom wśród twórców systemów operacyjnych: Windows, Linux, NIE APPLE IDŹ APPLE, FreeBSD i tym podobnych, za włożoną pracę w zapewnienie dużej zgodności wstecznej na swoich udanych platformach (Apple dostaje w najlepszym przypadku trójkę z minusem, ponieważ nieustannie psuje wszystko bez żadnego uzasadnionego powodu, ale jakoś społeczność radzi sobie z tym przy każdej wersji, a kontenery z OS X wciąż nie są całkowicie nieaktualne… na razie).
Ale poczekaj, powiesz. Czyż nie porównujemy jabłek do pomarańczy — autonomicznych systemów programowych na jednej maszynie, takich jak Emacs/JDK/Android/Chrome, z systemami wieloserwerowymi i API, jak w usługach chmurowych?
Cóż, pisałem o tym wczoraj na Twitterze, ale w stylu Larry'ego Walla (twórcy języka programowania Perl — przyp. red.) w duchu 'słabość/zasady' poszukałem słowa deprecated na stronach dla programistów Google i Amazon. I choć AWS ma setki razy więcej ofert usług niż GCP, dokumentacja dla programistów Google wspomina o nieaktualności około siedmiu razy częściej.
Jeśli ktoś z Google to czyta, to na pewno jest gotów pokazać wykresy w stylu Donalda Trumpa, że tak naprawdę robią wszystko dobrze i że nie powinienem robić niesprawiedliwych porównań, takich jak 'liczba wzmiankowa słowa deprecated w zależności od liczby usług'.
Jednak po tylu latach Google Cloud nadal pozostaje usługą nr 3 (nadal nie napisałem artykułu o nieudanej próbie bycia nr 2), ale jeśli wierzyć informatorom, istnieją pewne obawy, że mogą wkrótce spaść do nr 4.
Nie mam silnych argumentów, by 'udowodnić' swoją tezę. Wszystko, co mam, to barwne przykłady, które zgromadziłem przez 30 lat pracy jako programista. Wspominałem już o głęboko filozoficznej naturze tego problemu; w pewnym sensie jest on upolityczniony w społecznościach programistów. Niektórzy uważają, że twórcy platform powinni dbać o zgodność, a inni uważają, że to troska użytkowników (samych programistów). Jedno lub drugie. I naprawdę, czy nie jest to polityczne pytanie, kiedy decydujemy, kto powinien ponosić koszty za wspólne problemy?
Więc to polityka. I na pewno będą gniewne odpowiedzi na moje wystąpienie.
Jak użytkownik Jako użytkownik Google Cloud Platform oraz AWS przez dwa lata (pracując w firmie Grab), mogę powiedzieć, że istnieje ogromna różnica między filozofiami Amazon i Google, jeśli chodzi o priorytety. Nie prowadzę aktywnego rozwoju na AWS, więc nie wiem, jak często usuwają stare API. Ale podejrzewam, że dzieje się to znacznie rzadziej niż w Google. I szczerze wierzę, że ten stały źródło sporów i rozczarowań w GCP jest jednym z największych czynników, które powstrzymują rozwój platformy.
Wiem, że nie wskazałem konkretnych przykładów systemów GCP, których wsparcie zostało zakończone. Mogę powiedzieć, że praktycznie wszystko, co używałem, od sieci (od najstarszych po VPC) po magazyny (Cloud SQL v1-v2), Firebase (teraz Firestore z zupełnie innym API), App Engine (nawet nie zaczynajmy), chmurowe punkty końcowe Cloud Endpoint, a do… nie wiem — absolutnie wszystko to zmuszało do przepisania kodu maksymalnie co 2-3 lata, a oni nigdy nie automatyzowali migracji za was, a często . Jakby to było normalne.
I za każdym razem, gdy patrzę na AWS, pytam siebie, dlaczego wciąż siedzę na GCP. Wyraźnie nie potrzebują klientów. Potrzebują kupujących. Rozumiesz różnicę? Pozwól, że wyjaśnię.
Google Cloud ma , na którym ludzie oferują swoje rozwiązania oprogramowania, a żeby uniknąć efektu pustej restauracji, trzeba było go wypełnić pewnymi ofertami, więc podpisali umowę z firmą Bitnami, aby stworzyć mnóstwo rozwiązań, które wdrażają się „jednym kliknięciem”, albo sam muszę napisać „rozwiązania”, bo te niczego nie rozwiązują. Po prostu istnieją jako znaczki, jako marketingowy wypełniacz, a Google nigdy nie dbało o to, czy któreś z tych narzędzi działa naprawdę. Znam menedżerów produktu, którzy byli u władzy, i mogę cię zapewnić, że ci ludzie mają to gdzieś.
Weźmy na przykład rozwiązanie rzekomo „jednym kliknięciem” . Miałem dość sztuczek Google Cloud SQL, więc zacząłem rozważać stworzenie własnego klastra Percona jako alternatywy. I tym razem Google wydawało się, że dobrze zrobiło, chcieli zaoszczędzić mi trochę czasu i wysiłku jednym kliknięciem przycisku!
No dobrze, jedziemy. Przechodzimy pod ten link i klikamy ten przycisk. Wybieramy „Tak”, aby zgodzić się na wszystkie domyślne ustawienia i rozwinąć klaster w swoim projekcie chmurowym Google. Haha, to nie działa. Nic z tego g.... nie działa. Narzędzie nigdy nie było testowane i zaczęło gnić od pierwszej minuty, a nie zdziwiłoby mnie, gdyby więcej niż połowa „rozwiązań” do wdrażania jednym kliknięciem (teraz rozumiemy, dlaczego w cudzysłowach) w ogóle nie działa. To całkowicie beznadziejna otchłań, do której lepiej nie wchodzić.
Ale Google wręcz zachęca cię do ich używania. Chcą, abyś je kupił. Dla nich to transakcja. Nie chcą niczego obsługiwać. To nie jest część DNA Google. Tak, inżynierowie wspierają się nawzajem, co potwierdza moja historia z Bigtable. Ale w produktach i usługach dla zwykłych ludzi byli zawsze bezwzględni w , która nie spełnia progu rentowności, nawet jeśli ma miliony użytkowników.
I to stanowi prawdziwy problem dla GCP, ponieważ to DNA stoi za wszystkimi ofertami chmurowymi. Nie dążą do utrzymania czegokolwiek; wiadomo, że odmawiają hostowania (jako usługa zarządzana) jakiegokolwiek oprogramowania firm trzecich dopóki, dopóki AWS nie zrobi tego samego i nie zbuduje wokół tego udanego biznesu, a kiedy klienci dosłownie nie zażądają tego samego. Jednak trzeba włożyć pewien wysiłek, aby zmusić Google do utrzymywania czegokolwiek.
To brak kultury wsparcia, w połączeniu z zasadą „złam, aby uczynić to piękniejszym”, alienuje od nich programistów.
I to nie jest zbyt dobrze, jeśli chcesz zbudować trwałą platformę.
Google, obudź się, do cholery. Jest rok 2020. Wciąż przegrywasz. Czas dokładnie spojrzeć w lustro i odpowiedzieć, czy naprawdę chcesz pozostawać w biznesie chmurowym.
Jeśli chcesz zostać, to przestań wszystko łamać. Chłopaki, jesteście bogaci. My, programiści — nie. Dlatego gdy chodzi o to, kto poniesie ciężar zgodności, musicie to wziąć na siebie. Nie my.
Bo są jeszcze przynajmniej trzy naprawdę dobre chmury. Przyciągają nas.
A teraz idę dalej naprawiać wszystkie moje zepsute systemy. Ech.
Do następnego razu!
P. S. Aktualizacja po przeczytaniu niektórych dyskusji dotyczących tego artykułu (uwagi są świetne, nawiasem mówiąc). Wsparcie Firebase nie zostało zakończone i nie ma żadnych planów, o których wiem. Niemniej jednak mają nieprzyjemny błąd strumieniowy, który powoduje, że klient Java zatrzymuje się w App Engine. Jeden z ich inżynierów pomógł mi poradzić sobie z tym problemem, gdy pracowałem w Google, ale nigdy na serio nie naprawili tego błędu, więc mam kiepską alternatywę, muszę codziennie ponownie uruchamiać aplikację GAE. I tak już od czterech lat! Teraz mają Firestore. Migracja na to zajmie dużo pracy, ponieważ jest to zupełnie inny system, a błąd Firebase nigdy nie zostanie naprawiony. Co można z tego wywnioskować? Możesz otrzymać pomoc, jeśli pracujesz w firmie. Chyba jestem jedyną osobą, która używa Firebase na GAE, ponieważ zapisuję mniej niż 100 kluczy w aplikacji napisanej w 100%, a przestaje ona działać co kilka dni przez znany błąd. Co tu można powiedzieć, poza tym, że trzeba to robić na własne ryzyko. Przechodzę na Redis.
Zauważyłem również, że niektórzy bardziej doświadczeni użytkownicy AWS mówili, że AWS zazwyczaj nigdy nie przerywa wsparcia dla żadnych usług, a SimpleDB jest doskonałym przykładem. Moje przypuszczenia, że w AWS nie ma takiej przypadłości jak wygaszanie wsparcia, jak w Google, wydają się być uzasadnione.
Dodatkowo zauważyłem, że 20 dni temu zespół Google App Engine zepsuł hosting krytycznej biblioteki Go, zamykając aplikację GAE dla jednego z głównych twórców Go. Naprawdę, to było głupie.
Na koniec słyszałem, że google'owcy już dyskutują o tym problemie i w zasadzie zgadzają się ze mną (kocham was, chłopaki!). Ale wydaje się, że uważają problem za nierozwiązywalny, ponieważ w kulturze Google nigdy nie było odpowiedniej struktury bodźców. Myślę, że warto byłoby znaleźć trochę czasu, aby omówić absolutnie niezwykłe doświadczenie pracy z inżynierami AWS, gdy pracowałem w firmie Grab. Mam nadzieję, że w przyszłości!
Tak, w 2005 roku rzeczywiście mieli różne rodzaje mięsa rekina na gigantycznym szwedzkim stole w budynku 43, a najbardziej podobało mi się mięso rekinów młotów. Jednak do 2006 roku Larry i Sergey pozbyli się wszystkich niezdrowych przekąsek. Tak więc podczas historii z Bigtable w 2007 roku nie było już żadnych rekinów i oszukałem was podstępnie.
Gdy patrzyłem na chmurową Bigtable cztery lata temu (plus-minus), cena była dokładnie taka. Wydaje się, że teraz trochę spadła, ale to wciąż strasznie dużo za pustą przestrzeń danych, szczególnie biorąc pod uwagę, że moja pierwsza historia pokazuje, jak nieistotna jest pusta duża tabela w ich skali.
Przepraszam, że obraziłem społeczność Apple i że nic dobrego nie powiedziałem o Microsoftcie itd. Macie rację, bardzo doceniam wszystkie dyskusje, które ta artykuł wywołał! Ale czasami trzeba trochę wzburzyć wodę, aby rozpocząć dyskusję, prawda?
Dziękuję za przeczytanie.
Aktualizacja 2, 19.08.2020. Stripe !
Aktualizacja 3, 31.08.2020. Skontaktował się ze mną inżynier Google w Cloud Marketplace, który okazał się moim starym przyjacielem. Chciał dowiedzieć się, dlaczego C2D nie działa, i w końcu odkryliśmy, że przyczyną jest to, że stworzyłem swoją sieć kilka lat temu, a C2D nie działa w przestarzałych sieciach z powodu brakującego parametru podsieci w ich szablonach. Myślę, że potencjalni użytkownicy GCP powinni upewnić się, że mają wystarczająco znajomych inżynierów w Google...
Źródło: habr.com
