Dlaczego Erlang i BEAM to idealna platforma dla systemów ERP i CRM

System ERP pada w środku dnia. 200 osób nie może wystawić faktury, magazyn stoi, a prezes dzwoni co 5 minut. Znasz ten scenariusz? Większość systemów ERP i CRM jest zbudowana na technologiach, które nigdy nie były projektowane z myślą o niezawodności. Erlang i platforma BEAM - były.

Czym jest BEAM?

BEAM (Bogdan/Björn's Erlang Abstract Machine) to maszyna wirtualna stworzona przez Ericsson w latach 80. do obsługi central telefonicznych. Wymagania były proste: system musi działać bez przerwy, obsługiwać miliony równoczesnych połączeń i pozwalać na aktualizację kodu bez restartu.

Centrale telefoniczne Ericsson osiągały dostępność na poziomie 99.9999999% - to 31 milisekund przestoju rocznie. Ta sama platforma stoi dziś za WhatsApp (2 miliardy użytkowników, 50 inżynierów), Discord, RabbitMQ i wieloma systemami finansowymi.

Model aktorów - każdy proces to osobny świat

W tradycyjnych systemach ERP (Java, .NET, PHP) wszystkie operacje dzielą pamięć i zasoby. Jeden błąd w module magazynowym może zawalić cały system - łącznie z fakturowaniem, CRM-em i raportami.

BEAM działa inaczej. Każda operacja to osobny, izolowany proces (aktor). Procesy BEAM:

• Nie dzielą pamięci - każdy ma własny heap, własny garbage collector
• Komunikują się przez wiadomości - asynchronicznie, bez blokowania się nawzajem
• Są ekstremalnie lekkie - jeden serwer BEAM może obsłużyć miliony procesów jednocześnie. Nie tysiące, nie setki tysięcy - miliony
• Działają równolegle - BEAM automatycznie rozkłada procesy na wszystkie rdzenie CPU

Co to oznacza dla ERP? Wyobraź sobie, że każda faktura, każde zamówienie, każdy kontakt w CRM to osobny proces. Użytkownik A generuje raport roczny, który zjada CPU? Użytkownik B nawet tego nie zauważy - jego proces wystawiania faktury działa na osobnym rdzeniu, z osobną pamięcią.

Supervisor trees - architektura nadzoru

Procesy w BEAM są organizowane w drzewa nadzorców (supervisor trees). Supervisor to proces, którego jedynym zadaniem jest pilnowanie procesów podrzędnych. Jeśli proces-dziecko padnie, supervisor wie co zrobić:

• Zrestartować proces - najczęstszy scenariusz
• Zrestartować grupę procesów - gdy są ze sobą powiązane
• Eskalować problem wyżej - gdy restart nie pomaga

To jak struktura zarządzania w firmie. Kierownik magazynu nie dzwoni do prezesa, gdy ktoś upuści paczkę - rozwiązuje problem na swoim poziomie. Prezes dowiaduje się tylko wtedy, gdy pali się cały magazyn.

"Let it crash" - filozofia, która zmienia wszystko

W większości języków programowania uczymy się pisać defensywny kod: sprawdzaj każdy warunek, obsługuj każdy wyjątek, nigdy nie pozwól programowi się wysypać. Rezultat? Tysiące linii kodu obsługi błędów, które same w sobie zawierają błędy.

Erlang podchodzi do tego odwrotnie: pozwól procesowi się wysypać. Brzmi szaleńczo? W kontekście BEAM to genialne:

1. Proces napotyka nieoczekiwany stan - pada
2. Supervisor wykrywa to natychmiast - w mikrosekundach
3. Nowy, czysty proces startuje na jego miejsce - z czystym stanem
4. Reszta systemu nawet nie zauważyła, że coś się stało

Dlaczego to jest lepsze niż tradycyjna obsługa błędów? Bo czysty restart eliminuje problem "zepsutego stanu". W typowym systemie ERP połowa błędów to nie błędy logiki - to sytuacje, w których dane w pamięci znalazły się w stanie, którego nikt nie przewidział. Restart procesu to jak "wyłącz i włącz ponownie" - ale tylko dla jednej operacji, nie dla całego systemu.

Praktyczny przykład w ERP

Moduł fakturowania przetwarza 500 faktur. Faktura #347 ma uszkodzone dane kontrahenta. W tradycyjnym systemie:

• Optymistyczny scenariusz: wyjątek jest złapany, faktura #347 jest pominięta, reszta się przetwarza
• Pesymistyczny scenariusz: nieobsłużony wyjątek, cały batch pada, 499 poprawnych faktur nie zostaje przetworzonych
• Realistyczny scenariusz: wyjątek jest częściowo obsłużony, system jest w nieokreślonym stanie, następne 153 faktury mają błędne kwoty VAT

W BEAM:

• Każda faktura to osobny proces
• Proces faktury #347 pada
• Supervisor restartuje go i loguje błąd
• Pozostałe 499 procesów nawet nie wie, że coś się stało
• Administrator dostaje powiadomienie o fakturze #347

Elixir - nowoczesna twarz Erlanga

Erlang ma ponad 35 lat i jest genialny w tym, co robi. Ale jego składnia, wywodząca się z Prologa, potrafi odstraszyć. Dlatego w 2012 roku José Valim stworzył Elixir - nowoczesny język, który działa na tej samej platformie BEAM.

Elixir to nie "wrapper na Erlanga". To pełnoprawny język z własną składnią (inspirowaną Ruby), systemem makr, narzędziami (Mix, Hex) i ogromnym ekosystemem. Ale pod spodem działa ten sam BEAM, te same procesy, ten sam model aktorów, ta sama niezawodność.

Phoenix LiveView - interfejs bez JavaScriptu

Phoenix LiveView to framework, który zmienia zasady gry w budowie interfejsów webowych. Zamiast budować osobny frontend w React/Vue/Angular i komunikować się z backendem przez API, LiveView renderuje interfejs po stronie serwera i synchronizuje zmiany z przeglądarką przez WebSocket.

Co to daje w kontekście ERP/CRM:

• Real-time z automatu - gdy użytkownik A zmieni status zamówienia, użytkownik B widzi zmianę natychmiast. Bez pollingu, bez dodatkowego kodu
• Mniej kodu, mniej błędów - jeden język (Elixir), jeden codebase, jedna logika walidacji. Nie ma rozbieżności między frontendem a backendem
• Natywne formularze - LiveView ma wbudowaną obsługę formularzy z walidacją w czasie rzeczywistym. Użytkownik widzi błędy zanim kliknie "Zapisz"
• Brak problemów z synchronizacją stanu - stan żyje na serwerze, nie ma "stale data" w przeglądarce

Dashboard ERP z dziesiątkami tabel, filtrów i wykresów aktualizujących się w czasie rzeczywistym? W LiveView to naturalny sposób pracy, nie heroiczny wyczyn inżynierski.

Oban - kolejki zadań na sterydach

Każdy system ERP potrzebuje przetwarzania w tle: generowanie raportów PDF, wysyłka e-maili, synchronizacja z magazynem, import danych z CSV. W większości stacków technologicznych wymaga to osobnego systemu kolejek (Redis + Sidekiq, RabbitMQ, Celery).

Oban rozwiązuje to inaczej - używa PostgreSQL jako backend kolejki. Brzmi prosto, ale konsekwencje są ogromne:

• Jedna baza danych - nie potrzebujesz Redis ani innego systemu. Mniej infrastruktury = mniej punktów awarii
• Transakcyjność - zadanie w kolejce jest w tej samej transakcji co operacja biznesowa. Zapisujesz fakturę i dodajesz zadanie wysyłki e-maila atomowo - albo oba się udają, albo żadne
• Niezawodność - jeśli serwer padnie, zadania nie giną. Są w PostgreSQL, czekają na przetworzenie po restarcie
• Harmonogramy - cron-like scheduling wbudowany. Raport dzienny o 6:00, synchronizacja magazynu co 15 minut - bez zewnętrznych narzędzi
• Monitoring - Oban Web daje pełny wgląd w kolejki, błędy, czasy przetwarzania

ElectricSQL - synchronizacja danych nowej generacji

ElectricSQL to stosunkowo nowa technologia, która rozwiązuje problem, z którym zmaga się każdy system ERP: praca offline i synchronizacja danych między klientami.

Handlowiec jest u klienta, wpisuje zamówienie w CRM na tablecie. Nie ma zasięgu. W tradycyjnym systemie - pech, trzeba czekać. Z ElectricSQL:

• Local-first - dane są zapisywane lokalnie, aplikacja działa pełną prędkością bez internetu
• Automatyczna synchronizacja - gdy pojawia się połączenie, zmiany są synchronizowane z serwerem i innymi klientami
• Rozwiązywanie konfliktów - ElectricSQL wie, jak połączyć zmiany wprowadzone offline przez różnych użytkowników
• PostgreSQL jako źródło prawdy - cała synchronizacja jest zbudowana na replikacji logicznej PostgreSQL. Nie ma dodatkowej bazy, nie ma osobnego systemu

W połączeniu z Phoenix LiveView daje to architekturę, w której ERP działa płynnie zarówno online, jak i offline - i automatycznie się synchronizuje, gdy połączenie wróci.

Dlaczego nie wszyscy tak budują ERP?

Dobre pytanie. Kilka powodów:

• Przyzwyczajenie - większość firm IT zna Javę, .NET lub PHP. BEAM to inna planeta
• Ekosystem - Elixir ma mniej gotowych bibliotek niż Java. Ale te, które ma, są przemyślane i dobrze utrzymane
• Rekrutacja - programistów Elixir jest mniej. Ale ci, którzy są, zwykle rozumieją współbieżność i niezawodność na głębszym poziomie
• "Nikt nie został zwolniony za wybór Javy" - bezpieczny wybór to nie zawsze najlepszy wybór

Systemy ERP i CRM to infrastruktura krytyczna dla firmy. Zasługują na platformę, która była projektowana z myślą o niezawodności od pierwszego dnia - nie taką, do której niezawodność jest doklejana frameworkami i workaroundami.

Podsumowanie

Budujesz system ERP lub CRM i chcesz, żeby działał bez niespodzianek? Porozmawiajmy - pokażemy, jak BEAM może zmienić zasady gry w Twoim projekcie.