~ # whoami

Ja nazywam się Wojtek Gawroński. Jestem programistą z ponad 6 letnim doświadczeniem. Informatyką pasjonuję się już ponad 10 lat. Zajmuję się tworzeniem i projektowaniem aplikacji webowych, przez ostatnie 2 lata również projektowaniem i tworzeniem systemów rozproszonych.
W śląskiej społeczności jestem znany jako jeden ze współorganizatorów NodeSchool Silesia i aktywny członek różnej maści spotkań.
Mała prośba: jeśli macie jakieś pytania, nie czekajcie do końca prezentacji, dajcie mi znak - chętnie odpowiem w trakcie.
Tematyką prezentacji zainteresowałem się ponad 2 lata temu. Przy pracy z dużym systemem rozproszonym poszukując lepszego rozwiązania od technologii, która została tam zastosowana, natrafiłem właśnie na Erlanga.
Ktoś kto przeczytał abstrakt na stronie konferencji może pomyśleć, że będę Wam tu "gadał" o jakiejś archaicznej i egzotycznej technologii, która nie ma zastosowania, z którą nikt się nie spotkał.
Chciałbym rozwiać te wątpliwości i mówię: "Sprawdzam!".

Ankieta

Erlang?

Agenda

Korzenie

Platforma

Ekosystem

Korzenie

Powód, Historia, Zastosowanie

Powód

Ponad 30 lat temu wewnątrz firmy Ericsson została założona specjalna komórka badawcza nazwana Computer Science Laboratory.
Ericsson już wtedy intensywnie korzystał z języka C, eksperymentował z C++, posiadał własny język wysokiego poziomu - Plex. Koszty utrzymania oraz niezawodność poszczególnych produktów pozostawiała wiele do życzenia. Ericsson poza tym, że sprzedaje urządzenia, utrzymywał je i niektóre w dalszym ciągu utrzymuje przez wiele wiele lat.
Celem nowo utworzonej komórki było przeanalizowanie istniejących na rynku rozwiązań i jeśli okażą się niewystarczające zaprojektowanie nowego języka programowania, który umożliwi efektywniejszą (w sensie zasobów - czasu, ludzi, pieniędzy) budowę oraz utrzymanie obecnych produktów oraz wprowadzenie nowych na rynek - taniej.
Widać wyraźnie, że język i platforma powstały wskutek wyraźnego bodźca biznesowego. Brak dobrych alternatyw pociągnął za sobą inwestycje w postaci czasu i pieniędzy przeznaczonych na przygotowanie nowego rozwiązania.

Historia

Pierwsze sukcesy, które pozwoliły na dalsze finansowanie projektu pojawiły się bardzo szybko, bo już w 1988 - prototyp nowego produktu zbudowany w oparciu o Erlanga został stworzony w krótszym czasie i miał mniej błędów w początkowym okresie testów niż odpowiednik stworzony z użyciem C/C++.
Jednym z największych sukcesów Ericssona, było stworzenie i sprzedaż rozwiązań opartych o switch AXD 301. Paradoksalnie to on i jedna kłopotliwa decyzja otworzyła drogę platformy do Open Source. To co miało kluczowy wpływ na decyzję z 1998 roku to kłótnie i napięcia związanych z nową taktyką firmy, która paradoksalnie odsuwała się od Erlanga, kosztem języka C++. Otwierając go, firma chciała się pozbyć problemu.
Nowa polityka firmy nie odniosła oczekiwanych rezultatów, wybór okazał się błędny więc Ericsson ostatecznie nie odsunął się od rozwijania platformy. Z drugiej strony społeczność Open Source intensywnie zaadoptowała nowe narzędzie.
Zaowocowało to pojawieniem się wielu nowych narzędzi, które są wam dobrze znane. Do teraz ekosystem i cała platforma rozwijają się dość harmonijnie i przede wszystkim stabilnie.
W ostatnich latach można dostrzec zwiększone zainteresowanie Erlangiem za sprawą udanych wdrożeń w takich firmach jak Facebook, Klarna czy Heroku. Szczególnie do ludzi biznesu przemówiła transakcja zakupu WhatsApp za 19 miliardów dolarów właśnie przez Facebooka.
My jako "inżynierowie" wiemy, że największą wartością tej transakcji były tak naprawdę dane użytkowników. Niemniej, sukces WhatsApp nie byłby możliwy, gdyby nie wykorzystana technologia.
Spójrzmy zatem na największy sukces związany z Erlangiem.

Historia

Sukces - 1998

AXD 301

Niezawodność: 99.9999999%

Rozmiar: ~2M LOC

Czas pracy bez przerwy: 21 lat

AXD 301 to switch telekomunikacyjny, oferujący dużą przepustowość 160 Gb/s (jak na tamte czasy).
Zwróćcie uwagę na niezawodność - na tym poziomie oznacza ona przestój rzędu 32 ms w ciągu roku, który jest spowodowany błędem.
Na cały system składa się 2 milionów linii kodu - to nie tylko kod w Erlangu, ale także C. Większość (ok. 65-70%) to jednak kod napisany w Erlangu. Szacuje się, że to był na tamte czasy największy system informatyczny napisany w oparciu o język funkcyjny.
Cały system działał 21 lat bez przestoju. To oczywiście nie oznacza, że każdy komponent działał bez przerwy tyle lat, mowa tutaj o kontekście całego systemu. Ale nawet w takim kontekście to bardzo imponująca wartość.

Zastosowanie

Analogia

Zastosowanie

Kto?

Zastosowanie

Obszary

Obserwując poprzedni slajd można zauważyć kilka powtarzających się obszarów.
Najważniejsze z nich to: Telekomunikacja (T-Mobile, Ericsson, Motorola), Chmura (Amazon, Heroku, CloudBees), Serwery gier (DemonWare, Riot Games, Wooga) czy Wiadomości - Mobilne i Social Media (Facebook, WhatsApp, Yahoo!).
Kategorie wyspecjalizowane takie jak Internet Rzeczy, Sieci oraz Bazy Danych czy mają również swoich ważnych ale mniej znanych przedstawicieli.
Widać wyraźnie, że wszystkie dziedziny wymagają niezawodności, zajmują się wymianą dużej ilości komunikatów, są z natury rozproszone.
Ta technologia sprawdzi się również w tzw. soft real-time systems. Jest idealnie przystosowany do pracy z danymi binarnymi (wszelkiego rodzaju implementacje protokołów sieciowych).
Erlang nie sprawdzi się w miejscach, gdzie potrzeba mocy CPU i najwydajniejszej implementacji związanej z konkretną architekturą procesora. Nie sprawdzi się również w aplikacjach, które są typowo CRUDowe lub operują na dużych ilościach danych tekstowych.

Platforma

Budowa, Koncepcje, Mechanika

Budowa

The systems we were building are world wide distributed systems.
Where’s the shared memory when you’ve got one node in London and another in Paris and another in Stockholm.
There is no shared memory!

Joe Armstrong

Budowa

Problemy i Wymagania

Koncepcje

Rdzeń

W związku z problemami, które napotkali twórcy Erlanga, wykrystalizowały się 3 fundamentalne koncepcje jeśli chodzi o budowę platformy.
Musimy radzić sobie w geograficznie rozproszonym systemie oraz z redundancją maszyn - w celu zapewnienia niezawodności. Jedna maszyna nie spełnia żadnych kryteriów niezawodności.
Lekkie procesy zapewniają nam obsługę wielu współbieżnych żądań, które mają miejsce w Naszym systemie. Dzięki ich lekkości możemy obsłużyć więcej żądań na dostępnym sprzęcie, a dzięki ich optymalizacji wykorzystać efektywniej dostępne zasoby sprzętowe.
Co nam po dużej ilości lekkich procesów, jeśli błąd w jednym z nich wyłożyłby całą maszynę wirtualną. Izolacja jest kluczowa w systemach, które muszą spełniać wysokie standardy niezawodności. Bez niej awaria jednego z procesów, oznaczałaby katastrofę dla wszystkich.
Odnosząc te koncepcje do systemu telekomunikacyjnego widzimy analogię: mamy dużą liczbę równolegle prowadzonych i rozproszonych geograficznie połączeń telefonicznych, a awaria jednego połączenia nie wpływa na żadne inne trwające połączenie.

Koncepcje

Let it crash

Dzięki izolacji, która jest zagwarantowana na poziomie koncepcyjnym, otrzymujemy jedną z kluczowych rzeczy, która odróżnia omawianą technologię od innych. "Let it crash", choć brzmi to przekornie, jest mechanizmem który pomaga nam radzić sobie z błędami.
Wiele badań przeprowadzonych zarówno na sprzęcie jak i oprogramowaniu potwierdza tezę, że większość z błędów operacyjnych (czyli nie spowodowanych przez błędy programisty) jest przejściowa. Przykładem takiego błędu może być brak pamięci lub niedostępna baza danych.
Oznacza to, że pewne kategorie błędów będą występować zawsze, niezależnie od ilości czasu i energii skupionych na przeciwdziałaniu im. Co więcej, zdecydowana większość kodu w obecnych systemach skupia się właśnie na obsłudze błędów, i co gorsza stworzona jest w tzw. defensywnym stylu. Oznacza to, że staramy się wykryć wszystkie możliwe błędne sytuacje przed, co koniec końców zaciemnia oryginalną intencję autora kodu i powoduje inne błędy.
Byłoby idealnie, ddyby odwrócić sytuację i skupić się na takim projekcie systemu, który byłby nie tylko odporny na błędy, ale byłby także na tyle elastyczny, że potrafiłby "automatycznie" reagować na błędne sytuacje np. dzięki zrestartowaniu błędnego procesu, potrafił odtworzyć ostatni dobry stan.
Moglibyśmy się skupić na małym wycinku funkcjonalności, tzw. rdzeniu systemu, w który włożymy maksymalny wysiłek jeśli chodzi o bezawaryjność i implementację. Reszta systemu, mogłaby być zbudowana (przy wsparciu systemu i języka) na kształt hierarchii, która potrafi radzić sobie z błędami lub eskaluje problem wyżej.
Zanim opowiemy sobie jak takie cegiełki wyglądają w praktyce chciałbym przejść do innego kluczowego elementu związanego z mechaniką.

Mechanika

BEAM

czyli maszyna wirtualna Erlanga

Wizualizacja procesów na maszynie wirtualnej Erlanga

Temat maszyny wirtualnej omijaliśmy skutecznie do tej pory, jednak nie da się nie wspomnieć o niej w kontekście "jak systemy napisane w Erlangu funkcjonują".
Przy tym slajdzie chciałbym sprostować tytuł prezentacji - ekosystem Erlanga to tak naprawdę środowisko skupione wokół maszyny wirtualnej Erlang, zwanej również BEAM, od imienia autora aktualnej implementacji.
Siłą maszyny są bardzo lekkie procesy, których nie należy mylić z procesami systemu operacyjnego, czy nawet z wątkami. Dla porównania możemy przyjąć, że proces w Erlangu jest 1000 krotnie lżejszy od standardowego wątku (alokacja wątku pochłania 1 MB, alokacja nowego procesu 1000 słów pamięci).
Mimo, że samych procesów nie możemy porównywać do procesów dostępnych na poziomie systemu operacyjnego, to maszyna wirtualna zbudowana jest tak jak jądro nowoczesnego systemu operacyjnego. Izolujemy od siebie procesy, umożliwiamy śledzenie i obserwację tego jak system działa, udostępniamy stabilny fundament. To ułatwia wiele rzeczy - np. propagację i obsługę błędów, odśmiecanie pamięci czy lokalne optymalizacje.

Mechanika

Functional Programming

Kolejnym ważnym elementem całej układanki jest zestaw cech języka programowania. Erlang jest jednym z funkcyjnych języków programowania i naturalnie czerpie z tego dziedzictwa.
Najważniejszym elementem spośród wymienionych na slajdzie jest zupełnie innemu podejściu do zarządzania stanem wewnątrz aplikacji, który opiera się na braku mutowalności. Dzięki temu możemy pewne elementy aplikacji traktować jak przezroczyste skrzynki, w których dokładnie widać co się dzieje - wnioskowanie na temat zachowania systemu jest znacznie prostsze.
Na pierwszy rzut oka może to wyglądać jak ograniczenie, natomiast przy pracy z wysoce współbieżnymi systemami warto mieć jak najwięcej takich ograniczeń, którzy są naszymi "sprzymierzeńcami".

Ekosystem

Społeczność, Wybór, Cegiełki

Społeczność

Wybór

Bardzo często argumentem przeciwko Erlangowi, jest odwołanie do jego niszowości (trudno o programistów) i nietypowej składni wzorowanej na Prologu (panuje pogląd, że z tego powodu programiści nie lubią tej platformy).
Składnia tak naprawdę nigdy nie powinna być problemem, ale dzięki ostatnim zmianom i ten argument stracił na wadze, dlatego że pojawiły się dojrzałe i alternatywne rozwiązania.
Oprócz Erlanga mamy do dyspozycji również LFE (Lisp Flavoured Erlang) oraz Elixir, o składni zaczerpniętej z języka Ruby. Oba rozwiązania wykorzystywane są produkcyjnie, i korzystają w pełni z dobrodziejstw maszyny wirtualnej.
Przy tej okazji chciałbym wspomnieć, że problemy składniowe nigdy nie powinny być przeszkodą w doborze narzędzia. Czym innym jest biznesowy problem dot. braku wykwalifikowanej kadry a czym innym subiektywne odczucie na temat przecinków i średników.

Cegiełki

OTP

Ważnym elementem jest OTP czyli Open Telecom Platform, to biblioteka (ale nie standardowa) zbierająca wspólne wzorce i implementację generycznych elementów.
Obecna nazwa jest odrobinę myląca, zważywszy na to, że nie dotyczy tylko systemów telekomunikacyjnych a raczej systemów, które mają podobną charakterystykę jak omawiane systemy.
Na framework składają się generyczne komponenty, ale także mechanizm obsługi wersji aplikacji, elementy zapewniające przeładowywanie kodu na żywo, mechanizmy wspierające procesy utrzymaniowe (śledzenie i obserwacja działającego systemu).
Nacisk ukierunkowany na procesy utrzymaniowe spowodowany jest wagą, jaką Ericsson przykładał do tego elementu od początku dla tworzonych systemów. Badania mówią, że 60% czasu jeśli chodzi o cykl życia oprogramowania to okres utrzymaniowy. Twórcy OTP postawili sobie za cel, ułatwienie procesu utrzymania i dostarczenie efektywnych narzędzi właśnie dla tej fazy.
Powinniśmy tworzyć oprogramowanie od początku mając w głowie utrzymanie i procedury utrzymaniowe, ew. optymalizacja powinna dotyczyć elementów pod spodem np. maszyny wirtualnej. Jeśli ktoś kojarzy cytat Donalda Knutha, że "przedwczesna optymalizacja to przyczyna wszelkiego zła" - to jest dokładnie ten kontekst w którym padło to stwierdzenie.

Cegiełki

Zachowania (Behaviours)

Struktura bibliotek dostępnych w Erlangu

Inżynierowie odpowiedzialni za rozwój OTP, zaobserwowali i wyodrębnili zestaw wzorców. Udostępnili je w postaci generycznych zachowań (ang. behaviors). Części wspólne są zamknięte w bibliotece, implementację szczegółów dostarczamy z zewnątrz.
Mamy do dyspozycji generyczne implementacje serwera z wywołaniami asynchronicznymi i synchronicznymi, mechanizm obsługi zdarzeń, generyczną maszynę stanów, nadzorców oraz wiele, wiele innych implementacji.
Jeśli w naszej aplikacji pojawią się wzorce, charakterystyczne dla naszej domeny - nic nie stoi na przeszkodzie aby wykorzystać taki mechanizm do przygotowania własnego zestawu zachowań.

Cegiełki

Elementy Systemu

Wewnętrzna struktura aplikacji Erlangowej

Wizualizacja wewnętrznych elementów systemu Erlangowego

Korzystając z biblioteki oraz przygotowanych cegiełek, możemy śmiało budować stabilne i dostępne systemy, które są odporne na błędy.
Na system w Erlangu składają się aplikacje (odpowiednikiem będą komponenty). Zamiast tworzyć monolity, tworzymy rozproszone systemy - złożone z wielu aplikacji. Wdrożenie każdej aplikacji odbywa się za pomocą wydań (releases), mechanizmu dostarczonego przez OTP.
Ostatnio popularnym trendem są mikro-serwisy, których idea jest łudząco podobna do tego jak konstruuje się systemy w Erlangu. Można pokusić się o stwierdzenie, że to pojęcie zostało odkryte 30 lat temu i nie jest to nic nowego.
Jeśli spojrzymy głębiej, na to jak zbudowana jest aplikacja, to mamy do czynienia z hierarchiczną strukturą w której każdy element to proces. Jedne procesy nadzorują inne, korzeń jest nadzorowany przez mechanizmy wbudowane w maszynę wirtualną i aplikację.
O tej hierarchii wspominałem wcześniej, dzięki niej możemy konstruować systemy, które w razie wystąpienia błędu obsługują go na poziomie zarządcy i restartują podległe mu procesy, przywracając ich stan do ostatniego, dobrego momentu. Jeśli liczba błędów lub typ błędów przekracza możliwości nadzorcy, problem może zostać wyeskalowany wyżej, aż do korzenia i w końcu do maszyny wirtualnej, która wykona odpowiednią procedurę, dbając przy tym o podległe zasoby.

Podsumowanie

30 lat doświadczeń i dziedzictwa
Solidna i sprawdzona maszyna wirtualna
Dobre dopasowanie do różnych przypadków
Unikalne mechanizmy obsługi błędów
Zupełnie inne podejście do współbieżności

Chciałbym, żebyście zapamiętali tę technologię i zarazili się nią, tak jak ja ponad 2 lata temu.
Należy pamiętać, że narzędzia mogą tylko ułatwić rozwiązywanie trudnych problemów, ale nie wyeliminują ich całkowicie. Narzędzi można użyć źle i w złym kontekście.
Myślę jednak, że dobre i solidne rozwiązania warto naśladować, niemałym zaniedbaniem z naszej strony byłoby nie sprawdzić i jeśli to możliwe, skorzystać z olbrzymiego doświadczenia i dziedzictwa.
Mimo relatywnej niszowości technologii od której wszystko się zaczęło, znajduje ona zastosowanie w bardzo dużej liczbie innych przypadków.
Unikalne mechanizmy wbudowane w platformę służące do obsługi trudnych problemów są znaczącą przewagą nad innymi środowiskami.
Dodatkowo ekosystem skupia dużo ludzi, którzy inne trudne problemy rozwiązują właśnie z użyciem tych narzędzi.
To wszystko czyni tę technologię, bardzo atrakcyjną dla pewnej klasy problemów - i jeśli chodzi o wyłącznie merytoryczny wybór, jest ona praktycznie najlepsza.
Bardzo często przegrywa ona z inną, gorzej przystosowaną ale "wystarczająco dobrą" technologią. Głównie przez znajomość i czynniki inne niż czysto merytoryczne np. koszty znalezienia i wyszkolenia programistów lub popularność.
Jako środowisko, społeczność IT możemy to zmienić, budując systemy w oparciu o solidne rozwiązania. Wydaje mi się, że warto poświęcić własny czas, aby bliżej poznać bardzo dobry fundament dla Naszych przyszłych rozwiązań, który co najważniejsze, jest od blisko 30 lat przystosowany do dzisiejszej otaczającej nas rzeczywistości.
Dziękuję za uwagę!

Ekosystem Erlanga

Ankieta

Erlang?

Agenda

Korzenie

Platforma

Ekosystem

Korzenie

Powód, Historia, Zastosowanie

Powód

Historia

Historia

Sukces - 1998

AXD 301

Niezawodność: 99.9999999%

Rozmiar: ~2M LOC

Czas pracy bez przerwy: 21 lat

Zastosowanie

Analogia

Zastosowanie

Kto?

Zastosowanie

Obszary

Agenda

Korzenie

Platforma

Ekosystem

Platforma

Budowa, Koncepcje, Mechanika

Budowa

Budowa

Problemy i Wymagania

Koncepcje

Rdzeń

Koncepcje

Let it crash

Mechanika

BEAM

czyli maszyna wirtualna Erlanga

Mechanika

Functional Programming

Agenda

Korzenie

Platforma

Ekosystem

Ekosystem

Społeczność, Wybór, Cegiełki

Społeczność

Wybór

Cegiełki

OTP

Cegiełki

Zachowania (Behaviours)

Cegiełki

Elementy Systemu

Podsumowanie

Pytania?

Dziękuję!

Materiały:

Fonty:

Obrazy: