Grace Hopper – wykład dla NSA (część 1)
Amerykańska National Security Agency (NSA) udostępniła wykład kontradmirał (Rear Admiral) Grace Hopper z 1982 roku. Jego tytuł to „Future Possibilities: Data, Hardware, Software, and People”.
Przyszłość widziana oczami Hopper w 1982 roku jest teraz. Mamy 2024 rok, a problemy inżynierii software’u i hardware’u pozostały niezmienne.
Pozwoliłam sobie przytoczyć cytaty z wykładu Hopper, dodając do nich swój komentarz. Zainteresowanych odsyłam do obu części nagrania, bo to po prostu wybitny content. Hopper przedstawia skomplikowane problemy w obrazowy i gawędziarki sposób, zrozumiały nawet dla osób nietechnicznych. Link do wykładu poniżej, część druga w feedzie na YouTube:
Wartość informacji
Nobody is looking at the value of information or comparative value of different pieces of information, and we ve got to look at it because it is cutting up our online systems
W dobie big data, AI, IoT to zdanie wybrzmiewa w mojej głowie bardzo głośno. Jasne, mamy w opór danych. Potrafimy je szybko przetwarzać, transportować i udostępniać gdziekolwiek chcemy, co w latach 80. nie było możliwe. Ale problem się nie zmienił, bo często nie wiemy, jakie informacje są dla nas istotne. Zbieramy więc dużo śmieci. W dodatku – kosztownych śmieci, bo przecież operacje i przechowywanie danych nie są darmowe, choć dostawcy chmurowi próbują nam to wmówić – przynajmniej do momentu wydania wszystkich darmowych kredytów na ich usługi. Koniec końców, zawsze mamy trade off między ilością dostępnej informacji a szybkością pozyskania tej, która nas naprawdę interesuje. Koszt pamięci jest związany z szybkością dostępu do danych zgromadzonych w danym rodzaju pamięci – im szybsza pamięć, tym jest droższa. Coś za coś.
Obecnie zwraca się także uwagę na ekologiczny aspekt pracy z danymi, który za czasów Hopper nie brany pod uwagę. Chmurowi hiperskalerzy obiecują progresywne zmniejszanie generowanego przez nich śladu węglowego, a Google wręcz dąży do tego, aby stać się „net-zero emissions across all of our operations and value chain by 2030″. Zobaczymy. W kontekście wartości informacji warto jednak zastanowić się, czy musimy mieć absolutnie wszystkie dane, które zbieramy.
Umysłowe koleiny
I think the saddest praise I ever hear in a computer installation is that horrible one „but we ve always done it that way.” That’s a forbidden phrase in my office.
„Bo przecież tak się to u nas robi”. Jest to gotowy przepis nie tylko na dług technologiczny, ale i mentalny zastój całego zespołu. Bo zespoły tworzą ludzie, right? I tutaj, moim zdaniem, mamy bezpośrednie przełożenie jakości: jacy ludzie, taka technologia. W organizacjach potrzebni są ludzie, którzy potrafią spojrzeć z dystansu na zastałe warunki i zakwestionować ich sens albo zaproponować ich ulepszenie.
Capt. Grace Hopper on Future Possibilities: Data, Hardware, Software, and People (Part Two, 1982)
Skalowanie horyzontalne
Now, back in the early days of this country, when they moved heavy objects around, they didn’t have any Caterpillar tractors, they didn’t have any big cranes. They used oxen. And when they got a great big log on the ground, and one ox couldn’t budge the darn thing, they did not try to grow a bigger ox. They used two oxen. And I think they’re trying to tell us something. When we need greater computer power, the answer is not get a bigger computer – it’s get another computer. Which, of course, is what common sense would have told us to begin with. Incidentally, common sense is a legitimate scientific technique.
Ten gigantyczny wół z analogii Hopper pasie się niemal w każdej serwerowni. Przykład pierwszy, który mi przychodzi to klasyczny SQL server. Łatwo go skalować wertykalnie przez dodawanie zasobów, ale przy dużych bazach danych staje się to bardzo kosztowne, a samo utrzymywanie bazy i zarządzanie nią – trudne. W idealnej sytuacji warto byłoby pomyśleć zawczasu i stworzyć taką strukturę bazy albo wybrać taki jej typ, który skalowanie horyzontalne ma wpisane w swoją architekturę. Idea Kubernetesa opiera się przecież na tego typu skalowaniu.
Analogia wołowa, o ile bardzo wymowna, nie jest jednak odpowiedzią na wszystkie problemy IT. Wielu z nich nie da się rozwiązać przez zrównoleglanie operacji. Zauważony przez Hopper problem znalazł jednak swoje rozwinięcie w układach wieloprocesorowych i wielordzeniowych oraz architekturze chmury. Proponowane przez nią podejście stało się standardem w branży, chociaż wiele aplikacji, np. gier, nie potrafi tego dobrodziejstwa optymalnie (albo w ogóle) wykorzystać.
Mikroserwisy
It means you write the system in independent modules. Modules have one entrance point and one exit point. And no module ever accesses the interior of any other module. Never touches it. And the way you exchange data between the modules is through a series of interfaces. This module put something down, another module picks it up.
Hopper pół wieku temu proponowała decoupling (obecnie kojarzony głównie z mikroserwisami) jako podejście do architektury systemów komputerowych. To było 50 lat przed tym, kiedy te terminy stały się modnymi buzzwordami! Mówimy o czasach, kiedy REST API, SOAP czy gRPC nie istniały. W roku wykładu protokoły stosu TCP/IP dopiero stawały się standardem ARAPENT-u, a protokół HTTP miał powstać dopiero za dekadę.
Przypuszczam, że wielu z nas była jeśli nie autorem, to świadkiem sytuacji, w której mała zmiana w tworzonym lub utrzymywanym przez nas systemie powodowała kaskadę błędów prowadzącą do utraty stabilności całej aplikacji czy integracji. Ja byłam i pewnie dlatego wypowiedź Hopper wciąż głośno rezonuje w mojej głowie. A jeśli nie byliście to polecam poczytać o architekturze Gwiazdy Śmierci.
Dług technologiczny
That was a case where most people totally failed to look at the cost of not doing something.
Znów wracamy do tematu zaniechania i technologicznej abnegacji, które w zespołach developerskich rozkwitają w dług technologiczny liczony w stertach przepalonych bez sensu pieniędzy.
Hopper już na emeryturze wraz ze swoim zespołem opracowała oprogramowanie do walidacji COBOL-a. Ten język miał wówczas wiele dialektów, pisanych pod poszczególne potrzeby użytkowników komputerów. Dodajmy, komputerów, które nie dość, że były wielkie, to były w dodatku kosmicznie drogie i stać na nie było jedynie instytucje rządowe, wojsko i największe przedsiębiorstwa. Efektem prac zespołu Hopper było stworzenie kompilatora COBOL-a, dzięki któremu kod napisany w tym języku można było uruchamiać na każdej maszynie. Kompilator COBOL-a stał się istotną częścią programu standaryzacji tego języka i rozpowszechnienia go, nie wspominając o milionach dolarów oszczędności dla budżetu państwa. Tyle właśnie – Hopper wylicza to w wykładzie, ale można na ten temat informacje znaleźć na przykład tutaj – kosztowało utrzymywanie niekompatybilnych ze sobą dialektów Cobola w instytucjach państwowych. Analogia tej historii do czasów współczesnych jest dla mnie oczywista. Mamy skomplikowany stack, bo byliśmy (i nadal jesteśmy) agile, więc piszemy w czym popadnie i na czym popadnie (zazwyczaj na kolanie), byleby szybko, byle ASAP, a po nas choćby fakap.
Zaniechania te, często wliczane w TCO całego zespołu, platformy czy usługi, giną gdzieś w tabelkach dla biznesu i upper managementu. W jego przedstawiciele po prostu nie wiedzą, że tej daniny można by uniknąć, gdyby rozsądni Tech Leaderzy mieli odpowiednią wizję, czas i zasoby, aby z wyprzedzeniem zmitygować konsekwencje długu technologicznego zanim objawią się w pełnej krasie. Ach, można pomarzyć.
Tym mało optymistycznym akcentem chciałabym zakończyć pierwszą część wpisu o wykładzie Hopper.
Część druga