To jest 186. odcinek podcastu Porozmawiajmy o IT, w którym to ja sam opowiadam o niezawodności języków programowania na bazie Erlang i Elixir. Przypominam, że w poprzednim odcinku rozmawiałem o frameworku Qt. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/186. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

Zastanawiasz się nad zmianą pracy, ale gdy przeglądasz oferty na popularnych stronach, to nie jesteś przekonany, czy młody, dynamiczny zespół oraz owocowe środy są dla Ciebie? Na szczęście jest solid.jobs – portal z ofertami pracy dla ludzi, którzy chcą wiedzieć, ile będą zarabiać, z jakimi technologiami i nad jakimi projektami będą pracować. Solidne oferty pracy znajdziesz na solid.jobs. 

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, dzieląc się tym odcinkiem w swoich kręgach lub feedbackiem na jego temat ze mną, pomagasz w realizacji tej misji. A teraz życzę Ci już miłego słuchania!

 

Odpalamy!

 

Cześć!

Dzisiejszy odcinek jest nieco inny, ponieważ jest odcinkiem solowym. Tak naprawdę nie mogę sobie przypomnieć w tym momencie, kiedy ostatni raz realizowałem właśnie taki odcinek, w którym nie ma gościa, nie ma wywiadu, a ja sam wypowiadam się na jakiś temat. 

Musiało to być chyba dosyć dawno temu, więc tym bardziej z pewnym entuzjazmem i powiewem świeżości podchodzę do nagrywania tego odcinka. Jestem bardzo ciekawy, czy tego typu treści solowe, gdzie nie ma żadnego rozmówcy, z którym wymieniam poglądy, to jest coś, czego chciałbyś słuchać więcej. Daj mi koniecznie znać, ponieważ to mi też pozwoli planować w przyszłości odcinki – za co Ci oczywiście bardzo dziękuję.

W dzisiejszym odcinku poruszę temat, który jest mi dosyć bliski zawodowo. Będę mówił o językach, z którymi działam od kilku ostatnich lat i które są dla mnie też pewnym powiewem świeżości, bo wcześniejszy okres zawodowy poświęciłem głównie językowi Ruby, frameworkowi Ruby on Rails – to było grubo ponad 10 lat moich doświadczeń zawodowych. W momencie, kiedy przeszedłem na Elixir, kiedy znalazłem ten język, później dowiedziałem się, że on pracuje tak naprawdę na maszynie wirtualnej Erlanga, to można powiedzieć, że doświadczyłem czegoś zupełnie nowego; doświadczyłem zupełnie innego paradygmatu, ponieważ Elixir jest językiem funkcyjnym i to też była dla mnie swego rodzaju świeżość, nowe podejście do rozwiązywania problemów.

Dzisiaj będę się skupiał głównie na niezawodności języków programowani, posiłkując się przykładami z Erlanga i Elixira, natomiast jeśli jesteś zainteresowany tym, żeby usłyszeć więcej o samym języku Elixir, to odsyłam Cię do odcinka 134., który jest poświęcony w całości temu językowi.

Na początku każdego odcinka pytam mojego gościa o to, czy słucha podcastów i proszę, żeby polecił jakieś audycje, o których warto tutaj wspomnieć. Nie muszę pewnie Ci mówić, że ja podcastów słucham na potęgę, jestem wręcz od nich uzależniony, ale też, żeby tradycji stało się zadość, to chciałbym dzisiaj polecić dwa podcasty, na które trafiłem nie tak dawno temu, ale które myślę, że są wartościowe.

Pierwszym podcastem jest podcast Gosi Fraser TECHSPRESSO.CAFE. To podcast technologiczny, ale skupiający się głównie na bezpieczeństwie informacji, na cyber security.

Może niekoniecznie od takiego bardzo technicznego podejścia, czyli narzędzi, sposobów zapewnienia bezpieczeństwa aplikacji, ale o bezpieczeństwie informacji jako takim oraz tym, jak rządy i wielkie korporacje do tego podchodzą. Myślę, że często otwiera oczy ta perspektywa Gosi, zdecydowanie warto tego podcastu posłuchać, bo wszyscy obecnie żyjemy w takim środowisku i takim społeczeństwie informacyjnym, gdzie musimy aktywnie o to bezpieczeństwo informacji z naszego kręgu zabiegać.

 

A drugi podcast, o którym chciałem powiedzieć, jest zupełnie odmienny, dla fanów fantasy, może dla fanów Sapkowskiego. To będzie naprawdę gratka, ponieważ tym podcastem jest podcast Michała Kuźniara Słowiańskie demony. To są takie raczej krótsze podcasty, które opisują wybrane, najczęściej spotykane w naszym kręgu Europy Środkowej demony pojawiające się w spuściźnie słowiańskiej. Całkiem ciekawy, dobrze opowiedziany podcast, więc zapraszam.

 

A teraz przejdźmy do przedstawienia niezawodności języków projektowania, posiłkując się przykładami z Erlanga i z Elixira. 

 

Myślę, że nieraz masz okazję zobaczyć gdzieś w internecie tryb maintenance, kiedy aplikacje, serwer muszą być na pewien czas wyłączone, aby określone prace związane z deploymentem, releasem nowej wersji aplikacji albo podniesieniem jakiś komponentów całego systemy mogły się odbyć. Korzystając z jakiegokolwiek tak naprawdę systemu bankowości elektroniczne,j pewnie co jakiś czas masz z tym do czynienia. Tak to już się w tym świecie technologicznym aplikacji webowych dzieje, że ten tryb jest co jakiś czas potrzebny.

 

Tymczasem gdy spojrzymy na nieco inną, ale bardzo pokrewną dziedzinę, jaką jest telekomunikacja, to tam czegoś takiego praktycznie nie ma. Nowoczesne rozwiązania telekomunikacyjne są oparte, można powiedzieć, na komputerach, maszynach, serwerach, centralkach telefonicznych, które de facto można by porównać do serwerów z rozwiązań webowych, a mogę się prawie że założyć, że nigdy nie miałeś okazji usłyszeć, rozmawiając przez tradycyjny telefon ze swoją babcią, że niestety, musimy za chwilę włączyć tryb maintenance i rozłączyć połączenie, ponieważ na najbliższej centralce będzie wgrywane nowe oprogramowanie. Raczej się to nie zdarza. I warto się zastanowić, dlaczego tak się dzieje

 

Nowoczesne rozwiązania telekomunikacyjne są oparte, można powiedzieć, na komputerach, maszynach, serwerach, centralkach telefonicznych, które de facto można by porównać do serwerów z rozwiązań webowych, a mogę się prawie że założyć, że nigdy nie miałeś okazji usłyszeć, rozmawiając przez tradycyjny telefon ze swoją babcią, że niestety, musimy za chwilę włączyć tryb maintenance i rozłączyć połączenie, ponieważ na najbliższej centralce będzie wgrywane nowe oprogramowanie. Raczej się to nie zdarza.

 

Jednym z powodów tak dużej niezawodności rozwiązań w systemie telekomunikacyjnym jest użyty język programowania i cała maszyna wirtualna, na której ten język działa. I tym językiem jest Erlang działający na maszynie Erlanga, nazywanej Beam.

 

Oczywiście sam język nie jest gwarantem tego, że aplikacja działająca z jego wykorzystaniem będzie niezawodna, bo byłaby to zbyt daleko idąca teoria. Śmiem twierdzić, że wykorzystując nawet najlepszy, najdoskonalszy język programowania, jesteśmy w stanie napisać coś fatalnego. Natomiast oczywiście, posiadając odpowiednie narzędzia, jesteśmy w stanie zbudować coś niezawodnego, coś bardzo dobrego, działającego optymalnie.

 

Takim narzędziem jest moim zdaniem Erlang. Powstał on w laboratoriach firmy Ericsson – tej znanej skandynawskiej firmie zajmującej się telekomunikacją. W latach 80. zaczęła ona eksperymentować z istniejącymi językami programowania, żeby wykorzystać je do programowania nowoczesnego sprzętu telekomunikacyjnego, który miał obsługiwać mocno narastający i wzmagający się ruch telekomunikacyjny jak na ten czas. 

 

Próbowano różnych języków, ale żaden do końca nie pasował do tej domeny, dlatego podjęto decyzję, że firma stworzy swój własny język do tego przeznaczony. Została powołana pewna grupa, która w ramach firmy Ericsson i pod wodzą Joe Armstronga zaczęła tworzyć ten język, wzorując się na ówcześnie istniejących rozwiązaniach, np. na Prologu, Lispie itp., wręcz pierwszy kompilator języka Erlang został napisany z wykorzystaniem Prologa.

 

Po kilku latach powstał język, który został przyjęty dość entuzjastycznie przez środowisko, przez partnerów firmy Ericsson i zaczęto coraz intensywniej pracować nad rozwojem tego języka. Firma inwestowała oczywiście w ten język, traktowała go jako swój produkt. Na ten czas oprogramowania open source de facto nie istniały albo były czymś rzadkim, więc język Erlang jako produkt rozwijał się tylko i wyłącznie w ramach firmy Ericsson.

 

Istotny tu jest też rok 1996, kiedy powstało OTP, czyli Open Telecom Platform, która jest biblioteką dającą mnóstwo narzędzi, wbudowaną już w Erlanga. I tutaj jesteśmy w stanie wykorzystać wiele narzędzi, których używamy w codziennym programowaniu, nie musimy tego tworzyć na co dzień. To nie jest biblioteka standardowa w takim rozumieniu, ale jest zestawem wielu przydatnych narzędzi.

 

I tak to się stało, że firma Ericsson postanowiła po kilku latach jednak wycofać się z udostępniania tego języka dla swoich partnerów. Przeszła w zupełnie zamknięty wariant, co oczywiście spotkało się z protestem Joe Armstronga i grupy inżynierów tworzących język Erlang. Ta grupa opuściła firma, protestując w ten sposób. Ericsson bardzo szybko się zreflektował, że to był zły ruch i przywrócił wariant open source’owy języka Erlang.

 

Joe Armstrong z grupą inżynierów po kilku latach wrócili do firmy, język jest cały czas rozwijany, istnieje całkiem sporo konferencji międzynarodowych, więc jest to aktywne community, które nadal rozwija język.

 

Największym użytkownikiem języka Erlang na ten moment jest oczywiście firma Ericsson wykorzystująca go do zastosowań telekomunikacyjnych, ale wykorzystują go również takie znane firmy jak Facebook, T-mobile czy Goldman Sachs.

 

Specyfika języka Erlang została dobrana do domeny telekomunikacyjnej, czyli do wielu połączeń, które muszą się odbywać równocześnie, konkurencyjnie, na tej samej maszynie i musimy też mieć możliwość aktualizacji oprogramowania na tej maszynie bez bezpośredniego fizycznego dostępu. Często te centralki telekomunikacyjne są umiejscowione w ten sposób, że raczej fizyczny dostęp jest utrudniony.

 

Specyfika języka Erlang została dobrana do domeny telekomunikacyjnej, czyli do wielu połączeń, które muszą się odbywać równocześnie, konkurencyjnie, na tej samej maszynie i musimy też mieć możliwość aktualizacji oprogramowania na tej maszynie bez bezpośredniego fizycznego dostępu.

 

Oczywiście te równolegle trwające połączenia nie mogą na siebie wpływać, powiedziałbym wręcz, że jeśli coś złego się wydarzy, nastąpi jakiś błąd z jednym połączeniem, to nie może to powodować, że wszystkie inne, równolegle obsługiwane połączenia również zakończą się niepowodzeniem. Takie są, dosyć ostre wymagania co do tej domeny telekomunikacyjnej, na której język Erlang działał.

 

Żeby podać kilka przykładów na to, jak duża jest niezawodność tego języka, to firma Ericsson chwali się takim switchem, który jest rozwiązaniem telekomunikacyjnym, można powiedzieć, że przypomina duży serwer, switch AXD301, który to po 20 latach użytkowania (jest to urządzenie, które cały czas jest produkcyjnie wykorzystywane i cały czas działa) odznacza się bardzo wysoką i rzadko spotykaną niezawodnością. Jak dużą niezawodnością, to pozwolę sobie odpowiedzieć na końcu tego odcinka, więc pozostań ze mną, by dowiedzieć się, o jakiej niezawodności urządzeń telekomunikacyjnych działających na Erlangu możemy mówić.

 

Innym ciekawym przykładem jest WhatsApp, który zasłynął nie tylko z tego, że gdy w 2014 roku był sprzedawany do Facebooka za 19 mld dolarów, to w tym momencie sprzedaży na platformie było 900 mln użytkowników i tylko 50 inżynierów do obsługi i rozwoju całej aplikacji, a core WhatsAppa jest napisany właśnie w Erlangu.

 

To pokazuje, jak relatywnie nieduże zasoby ludzkie są potrzebne, żeby utrzymywać tak wielki system konkurencyjnie obsługujący tak wiele połączeń. 

 

Natomiast Erlang ma pewną dość istotną wadę, kiedy się na niego spojrzy, to nie da się ukryć, że wzorował się na językach powstałych w latach 70. ubiegłego wieku i ta składani dosyć daleko ma do czytelności – to jest jeden z głównych zarzutów.

 

I tutaj na scenie pojawia się nasz bohater José Valim, Brazylijczyk, który mieszka w Krakowie, tutaj założył rodzinę i który działał w core teamie frameworka Ruby on Rails. Tam zajmował się w pewnym momencie takim problemem, trade safety , czyli trybu działania frameworka na serwerze, kiedy wiele wątków wykonujących ten sam kod jest w stanie bezpiecznie i konkurencyjnie ten kod wykonywać.

 

I José sprawdzał, jak podobny problem jest rozwiązywany w innych językach, i tak m.in. trafił na Erlanga. Natomiast też uderzyło go to, że czytelność Erlanga nie była na najwyższym poziomie, powiedział nawet, że zakochał się we wszystkim tym, co znalazł w Erlangu, ale znienawidził to, czego tam nie znalazł. 

 

Chodziło mu o to, że zakochał się w całym ekosystemie, w całym bogactwie różnych rozwiązań, które już są w Erlangu, i tej zapewnionej niezawodności, ale brakowało mu właśnie community, nowoczesnych narzędzi, czytelności języka.

 

Postanowił więc to zmienić i w roku 2012 stworzył język programowania Elixir, który działa na maszynie wirtualnej Erlanga, kompiluje się do tego samego byte codu, jednak składniowo jest bardzo podobny do Ruby’ego, czyli do języka, który był bliski autorowi, ale charakteryzuje się dużo lepszą czytelnością i wygląda jak nowoczesny język programowania.

 

Oprócz wysokiej niezawodności w Erlangu istotne jest to, że wykorzystuje on cały potencjał maszyny. Do pewnego momentu rozwój hardware’u polegał po prostu na miniaturyzacji, na podkręcaniu częstotliwości taktowania procesorem. Natomiast w pewnym momencie pojawiła się ta bariera fizyczna i zaczęto dokładać kolejne core’y do tego samego procesora.

 

W roku 2007 w Erlangu pojawiła się obsługa symetrycznej wieloprocesorowości, czyli sama maszyna wirtualna jest w stanie wykorzystać wszystkie core’y. I z punktu widzenia programisty nie trzeba nic więcej, żeby daną funkcję uruchamiać np. na innym corze, tutaj maszyna wirtualna zajmuje się tym, żeby zutylizować maksymalnie całą dostępną moc obliczeniową.

 

Kiedy zapyta się przeciętnego programistę o to, co sprawia mu największy ból w programowaniu, to bardzo często usłyszy się właśnie, że programowanie współbieżne jest tego typu problemem. Wszelkiego typu mutexy, semafory i innego typu podejścia do problemu, w jaki sposób zapewnić, żeby program wykonywany w sposób współbieżny był bezpieczny, sprawiają, że nie tylko pisanie, ale też debugowanie kodu jest problematyczne.

 

Jeśli chodzi o Erlanga czy Elixira, to wykonywanie współbieżne kodu, czyli można powiedzieć, obsługiwanie przez jeden wątek pojedynczej rozmowy telefonicznej, jeśli by to sprowadzić do źródeł, leży w założeniach, u podstaw stworzenia samego języka i ekosystemu, więc naturalnie tam nie mamy tego typu problemu.

 

Zatem jakie elementy wpływają na niezawodność Elixira i Erlanga? Jest kilka takich elementów. Jest to programowanie funkcyjne, zbiór lekkich procesów maszyny wirtualnej, wielowątkowość oparta na modelu aktorów, supervision tree, Hot Code Swap. 

 

Zatem jakie elementy wpływają na niezawodność Elixira i Erlanga? Jest kilka takich elementów. Jest to programowanie funkcyjne, zbiór lekkich procesów maszyny wirtualnej, wielowątkowość oparta na modelu aktorów, supervision tree, Hot Code Swap.

 

To są te elementy, które bardzo często wykorzystujemy, tworząc oprogramowanie w Elixirze czy w Erlangu, które później składają się na to, że ten tworzony przez nas program jest niezawodny. 

 

Zacznijmy od samego języka programowania, który jest oparty na paradygmacie funkcyjnym. Paradygmat funkcyjny można by przyrównać do metafory linii produkcyjnej w fabryce, gdzie jeden robot wykonuje pewną pracę, algorytm, który jest w niego zaszyty, na materiale, który uzyskał. Po wykonaniu tej pracy przekazuje materiał dalej, gdzie następny robot wykonuje charakterystyczną dla siebie pracę. 

 

I tak samo w oprogramowaniu bazującym na paradygmacie funkcyjnym tym materiałem są dane, które są podawane do funkcji, która realizuje sobie właściwy algorytm, modyfikuje, przetwarza te dane i podaje je później dalej, do następnego robota.

 

Dążymy do tego, żeby te funkcje były jak najbardziej czyste. Mówimy o czymś takim, jak pure functions. Czysta funkcja polega na tym, że operuje tylko na tej paczce danych, która pojawiła się na wejściu, i przekazuje na wyjście zmodyfikowaną paczkę danych. Czyli w żaden sposób nie wpływa ona na środowisko zewnętrzne. Nie zapisuje gdzieś do bazy, nie odpytuje jakiegoś API, nie modyfikuje jakiegoś pliku. 

 

Oczywiście nie jest możliwe, żeby stworzyć nowoczesny program tylko i wyłącznie na podstawie pure functions, natomiast im więcej ich mamy, tym łatwiej jest testować oprogramowanie, łatwiej jest wydzielać pewne funkcje i łatwiej też jest ten kod zrozumieć. Ale kiedy jesteśmy w stanie pisać kod, który jest lepiej zrozumiały, lepiej odseparowany, to oczywiście wynikowa niezawodność ma szansę być sporo wyższa.

 

W programowaniu funkcyjnym w językach Elixir i Erlang mówimy też o niemutowalności danych. Polega to na tym, że raz zaalokowana przestrzeń w pamięci, którą nazywamy, dajmy na to, A, na zawsze już tam zostaje. Jeśli tę zmienną A będziemy chcieli w jakiś sposób zmienić, dajmy na to, jest to jakaś tablica danych, chcemy dopisać kolejny element, to tak naprawdę wynikowa tablica będąca efektem dodania tego jednego elementu będzie zapisana już pod nowym adresem. Czyli nie modyfikujemy tej pierwotnie zalokowanej przestrzeni, tylko alokujemy nową przestrzeń.

 

To też ma wpływ na wysoką niezawodność, ponieważ zmniejszamy tutaj ten problem, który pojawia się często w programowaniu obiektowym, gdzie wiele różnych metod próbujących zmodyfikować tę samą przestrzeń niestety bardzo często prowadzi do problemów z działaniem aplikacji.

 

Kolejny taki element, który wpływa na niezawodność oprogramowania pisanego w Elixirze i Erlangu to są lekkie procesy maszyny wirtualnej. Działa to w ten sposób, że maszyna wirtualna jest, powiedzmy, takim jednym procesem systemu operacyjnego. W ramach tego procesu, w którym działa maszyna wirtualna, tworzymy pewne aplikacje, które składają się z kolei z lekkich procesów maszyny wirtualnej.

 

Te procesy są bardzo małe. Ich powołanie praktycznie nic nas nie kosztuje, a przynajmniej bardzo mało. I gdybyśmy spojrzeli na to z lotu ptaka, taki program, który działa w pewnym punkcie czasu, to jest zbiór wielu różnych lekkich procesów maszyny wirtualnej, które w jakiś sposób mogą ze sobą rozmawiać.

 

Maszyna wirtualna została zoptymalizowana do efektywnego przełączania kontekstu i z racji na to, że te lekkie procesy maszyny wirtualnej faktycznie są lekkie, powoływane do życia, tylko żeby zrealizować pewne zadanie i później są likwidowane, to bardzo często okazuje się, że nawet nie ma potrzeby włączania garbage collectora, ponieważ proces powstaje, alokuje jakąś pamięć, wykonuje pracę, jest usunięty i nawet ten garbage collector nie zdąży się załączyć.

 

Żeby podać, w jaki sposób zmierzyć, jak mały jest ten proces maszyny wirtualnej, to warto powiedzieć, że w przypadku Erlanga jest to zazwyczaj 2 –2,5 kB, gdzie w przypadku Javy taki wątek to przeważnie 1024 kB, o ile nie jeszcze więcej, więc widać, jakie tu są różnice i jak relatywnie mało pamięci kosztuje nas powołanie lekkiego wątku maszyny wirtualnej.

 

Te lekkie procesy maszyny wirtualnej rozmawiają ze sobą na podstawie modelu współbieżności, który nazywany jest modelem aktorów. Pojedyncza funkcja, która gdzieś tam działa w maszynie wirtualnej, jest tym aktorem. Aktor ma skrzynkę mailową (mail box), do której to mogą wysyłać „listy”, czyli różnego typu wiadomości, właśnie inne wątki.

 

Wątek ten wykonuje to w sposób asynchroniczny, czyli jeden wątek wysyła wiadomość do skrzynki odbiorczej drugiego wątku i ten wątek, który jest adresatem tej wiadomości, oczywiście nie wykonuje tego synchronicznie i nie odpowiada od razu, tak jak zwykliśmy to robić chociażby w przypadku metod, obiektów w programowaniu obiektowym, tylko raczej sobie w pętli procesuje po kolei te wiadomości, które wpadły, i co najwyżej w sposób asynchroniczny może odpowiedzieć do tego wątku, który tę wiadomość wysłał.

 

Tu się właśnie pojawiają te dwa istotne koncepty. Pierwszy, że nie możemy liczyć na synchroniczność. Możemy oczywiście poczekać, aż dostaniemy tę wiadomość z wykonywaniem kolejnego kroku, ale musimy być świadomi, że to się dzieje asynchronicznie. Oraz drugi koncept: pamięć alokowana w ramach tego aktora, czy tego takiego lekkiego wątku, jest tylko dla niego przeznaczona. Żaden inny wątek nie może się do tej pamięci odwołać, co oczywiście wpływa na ogólną podniesioną niezawodność, ponieważ mamy tutaj taką wyraźną izolację dostępu do pamięci.

 

Urządzenia telekomunikacyjne muszą charakteryzować się wysoką niezawodnością przez długi czas, po to, żeby nie trzeba było tam jeździć, serwisować ich czy w jakikolwiek sposób zdalnie dokonywać napraw. Byłoby to bardzo trudne do osiągnięcia, gdyby nie kolejny mechanizm, który jest wbudowany w Elixira i Erlanga i który wpływa właśnie na taką niezawodność w czasie. Tym mechanizmem jest supervision tree, czyli drzewo nadzorcze.

 

Polega to na tym, że powołujemy pewne specjalne wątki, nazywane supervisorami czy też nadzorcami, które kontrolują, co się dzieje z procesami wykonującymi pracę, pracownikami, workerami. I w momencie, kiedy ten proces zarządzający, ten supervisor zauważy, że coś dzieje się niewłaściwego z podległymi mu pracownikami, może w jakiś sposób na to zareagować.

 

Może np. powołać nową instancję takiej funkcji, może usunąć wszystkich pracowników czy też procesy, wątki, którymi zarządza i powołać ich nową instancję – ma kilka różnych możliwości zareagowania. Wszystko to w efekcie daje nam tzw. samo leczącą się strukturę. 

 

Oczywiście tylko te najważniejsze wątki, które są kluczowe dla działania aplikacji, dajemy pod taką strukturę zarządzania, jakieś dostępy do bazy danych, systemy, które są krytyczne. Wówczas nadzorujemy, czy taki wątek nadal działa, i jeśli coś się z nim dzieje, możemy go zrestartować, co w efekcie działa na samo leczącą się strukturę. Jeśli coś się dzieje nie tak, to często w dużym stopniu dzięki zastosowaniu supervision tree taki program jest w stanie sam siebie uleczyć czy przywołać do takiego stanu, w którym może kontynuować swoje działania.

 

Na początku mówiłem o tym, że w tej domenie webowej często musimy wprowadzić maintenance mode, musimy odciąć użytkowników po to, żeby wykonać pewne prace. Oczywiście nikt tego nie lubi, ani użytkownicy, ani administratorzy, ani programiści, którzy muszą takich prac dokonać.

 

W Erlangu istnieje tzw. mechanizm Hot Code Swap, czyli takiej gorącej podmiany kodu. Jesteśmy w stanie zainstalować czy też zdeployować nową wersję jakiegoś modułu, odpowiednio go tagując, że to jest kolejna wersja, mówiąc, w jaki sposób ma dokonać maszyna wirtualna migracji z poprzedniego stanu tego modułu na nowy stan. I maszyna wirtualna, widząc, że pojawił się nowy kod z nową wersją, jest w stanie automatycznie nie tylko to zauważyć, ale również przeprowadzić migrację i zacząć działać z nowym kodem. Więc nie musimy tutaj niczego zatrzymywać, żadnych serwerów, maszyny wirtualnej. Może się to dziać w sposób automatyczny.

 

W Erlangu istnieje tzw. mechanizm Hot Code Swab, czyli takiej gorącej podmiany kodu. Jesteśmy w stanie zainstalować czy też zdeployować nową wersję jakiegoś modułu, odpowiednio go tagując, że to jest kolejna wersja, mówiąc, w jaki sposób ma dokonać maszyna wirtualna migracji z poprzedniego stanu tego modułu na nowy stan. I maszyna wirtualna, widząc, że pojawił się nowy kod z nową wersją, jest w stanie automatycznie nie tylko to zauważyć, ale również przeprowadzić migrację i zacząć działać z nowym kodem. Więc nie musimy tutaj niczego zatrzymywać, żadnych serwerów, maszyny wirtualnej. Może się to dziać w sposób automatyczny.

 

I takimi projektami, oprócz tej domeny telekomunikacyjnej, które wykorzystują Eliksira, jest Fenix, który jest frameworkiem webowym tego języka, czy też projekt Nerves, który jest z kolei dedykowany do urządzeń typu embeddet, tam taka odchudzona wersja maszyny wirtualnej może być zainstalowana i z powodzeniem działać na tych urządzeniach o ograniczonych zasobach.

 

Kto oprócz Ericssona korzysta z Elixira i Erlanga? Trochę już o tym powiedziałem, ale z takich jeszcze bardziej dobitnych przykładów warto tu powiedzieć, że Spotify, WhatsApp, Pepsi czy Discord chociażby to są firmy, które korzystają z tych rozwiązań. Myślę sobie, że jeśli tego typu duże podmioty zdecydowały się na wykorzystywanie Elixira i Erlanga, to też wpływa na to, że musiały stwierdzić, zbadać, że to są rozwiązania o dużej niezawodności. 

 

Podam jeszcze przykład firmy Rose Point, która zajmuje się tworzeniem rozwiązań hardware’owych, nawigacyjnych na statki. Oczywiście tego typu nawigacja, która gdzieś tam pływa sobie po oceanach miesiącami, musi charakteryzować się niezwykle wysoką niezawodnością, ponieważ bardzo wiele od niej zależy. 

I firma Rose Point podała, że bardzo często obserwuje, że te rozwiązania hardware’owe bazujące na Erlangu charakteryzują się właściwie brakiem błędów od strony maszyny wirtualnej i od strony języka oraz bardzo stabilnym zużyciem zasobów. Gdy patrzy się na wykresy zużycia zasobów, to widać, że jest tam taki pick początkowy, kiedy urządzenie jest bootowane i później, dosłownie przez miesiące wykorzystanie zasobów utrzymuje się na tym samym poziomie.

 

Podsumowując, w dzisiejszym podcaście mówiłem o niezawodności języków programowania na bazie Elixir i Erlang, i powiedziałem, że takie przymioty tych dwóch języków, jak programowanie funkcyjne, lekkie procesy maszyny wirtualnej, wielowątkowość oparta na modelu aktorów, supervision tree czy Hot Code Swap wpływają na to, że rozwiązania budowane na ich podstawie po prostu są niezawodne.

A teraz obiecana odpowiedź na pytanie, o jakiej niezawodności switcha AXD301 możemy mówić. Otóż po 20 latach działania tego typu switcha, który w sposób produkcyjny obsługiwał ruch telekomunikacyjny, działał na milionie linii kodu napisanego w Erlangu, wynosiła dziewięć dziewiątek, czyli 99,9999999%. De facto sprowadza się to do niedziałania tego sprzętu przez 0,6 s przez 20 lat. Myślę, że to dobitnie pokazuje, z jaką niezawodnością mamy tutaj do czynienia. 

Sam osobiście działam z ryzykiem Elixir w domenie webowej od czterech lat. Jestem bardzo zadowolony i faktycznie mam okazję obserwować tę niezawodność na co dzień. Jeśli ktoś z Was zastanawia się nad tym, czy to jest dobry język, żeby budować na nim swoją karierę, to polecam. Zdecydowanie warto.

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, w której słuchasz lub w social mediach. 

Daj mi też znać, czy tego typu odcinki solowe przypadły Ci do gustu.

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o niezawodności języków programowania na bazie Erlang i Elixir. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!