Scenka, którą zna prawie każdy
Masz duży system ERP albo CRM. Działa od lat, wszyscy go znają, firma na nim stoi.
Handlowcy proszą o drobiazg: niech w oknie klienta będzie widać numer promocji, z której klient korzysta. Księgowość prosi o drugi: niech system przed przelewem sam sprawdzi, czy rachunek kontrahenta jest na białej liście podatników VAT. Ministerstwo udostępnia do tego darmowe API, więc to wygląda na prostą integrację.
Dwie małe rzeczy. Kilka dni pracy, prawda?
A potem zaczyna się znany scenariusz:
- zmiana trafia do kolejki i czeka na najbliższy release,
- po kilku tygodniach wychodzi nowa wersja całego systemu,
- cała firma testuje wszystko, bo „zmiana mogła dotknąć wszystkiego”,
- wdrożenie idzie w weekend, z dyżurem i nerwami.
W poniedziałek rano okno reklamacji, które działało od lat i którego nikt nie ruszał, wita użytkowników komunikatem:
Object reference not set to an instance of an object.
Nikt nie wie, co to znaczy. Wszyscy wiedzą, że reklamacje stoją.
Takie objawy zwykle znaczą, że części systemu są ze sobą zbyt mocno powiązane. A najczęściej spotyka się to w dużych monolitach.
Co to jest monolit
Monolit to aplikacja, którą wdrażasz jako jedną całość. Zamówienia, reklamacje, faktury i raporty to jeden program i zwykle jedna wspólna baza. Zmieniasz jedno, wdrażasz wszystko.
Sam w sobie to jeszcze nie problem. Monolit może mieć porządnie oddzielone moduły i żyć latami bez kłopotów. Schody zaczynają się, kiedy moduły zrastają się ze sobą tak, że nawet drobna zmiana w jednym miejscu odbija się w kilku innych.
Najprościej porównać to do nowoczesnego samochodu, w którym jeden komputer pokładowy steruje wszystkim naraz: radiem, szybami, światłami i silnikiem. Chcesz wymienić radio na nowsze. Kiedyś wyjmowało się je z kieszeni i wkładało nowe. Tu serwis musi wgrać nowe oprogramowanie do głównego komputera, bo radio jest jego częścią. Odbierasz auto po dwóch dniach, radio gra, ale nie otwiera się szyba po stronie pasażera.
I nie odbierzesz z serwisu samego radia. Samochód wyjeżdża z warsztatu w całości albo wcale.
Z monolitem jest tak samo. To jeden program, budowany w jedną paczkę i uruchamiany jako całość, a jego części korzystają z tego samego kodu i tej samej bazy. Podmiana jednej części w biegu oznaczałaby, że reszta nagle rozmawia z kimś, kogo nie zna. Dlatego wydaje się nową wersję całości, w której wszystko do siebie pasuje.
Skąd błąd w reklamacjach po dodaniu numeru promocji? Mogło to wyglądać tak. Dane klienta są w systemie wspólnym obiektem, z którego korzysta kilkadziesiąt ekranów. Nowa wersja dokłada do klienta obiekt z danymi promocji i pokazuje numer wszędzie, gdzie pojawia się klient. Tyle że dla starych klientów, przeniesionych kiedyś do archiwum, system tego obiektu w ogóle nie tworzy. Okno reklamacji chce odczytać z niego numer, a obiektu nie ma. Program tego nie sprawdza i się wywraca.
Ten angielski komunikat mówi właśnie to: „próbuję coś zrobić z obiektem, którego nie ma”.
Nie chodzi o szukanie winnego. Nieobsłużony brak danych to zwykły błąd, a takie zdarzają się wszędzie. W monolicie trudniej tylko przewidzieć, w którym miejscu się odezwie.
Monolit to nie grzech
Powiedzmy sobie wprost: na początku życia systemu monolit to często najlepszy wybór. Łatwiej go zbudować i uruchomić, łatwiej znaleźć w nim błąd, wystarcza prostsza infrastruktura i jeden zespół. Wiele firm działa na monolicie latami i nic złego się nie dzieje.
Schody zaczynają się, kiedy system rośnie, zmian przybywa, a modułów coraz trudniej dotknąć osobno. Wtedy nawet drobna prośba potrafi uruchomić całą machinę testów i wdrożenia. I firma zaczyna z drobnych próśb rezygnować, bo „i tak się nie opłaca”.
Po czym poznać, że monolit Ci ciąży
Poza scenką z początku jest kilka sygnałów, które łatwo przeoczyć:
- nikt nie odważy się usunąć starej funkcji, bo nie wiadomo, co od niej zależy,
- po zmianie w module A psuje się moduł B, który z A „nie miał nic wspólnego”,
- integracje z zewnętrznymi serwisami (rejestry, usługi publiczne, kurierzy) są wszyte w środek aplikacji, więc każda zmiana po ich stronie oznacza nową wersję całego systemu,
- nowa osoba w zespole IT potrzebuje miesięcy, zanim odważy się coś zmienić,
- w zespole jest jedna osoba, która wie, gdzie co jest w kodzie, i bez niej żadne wdrożenie nie ruszy.
Co robić i jak z tym żyć
1. Nie przepisuj wszystkiego od zera
To pierwsza myśl i zwykle najgorsza. „Napiszmy to od nowa, porządnie” brzmi świetnie na prezentacji. W praktyce oznacza lata utrzymywania dwóch systemów naraz: starego, bo firma musi działać, i nowego, który ciągle goni starego, bo w międzyczasie biznes dalej czegoś potrzebuje. Takie projekty często przekraczają budżet, a czasem kończą się powrotem do starego systemu.
Lepiej zmieniać system stopniowo, kawałek po kawałku, tak żeby firma przez cały czas działała.
2. Sprawdź, gdzie naprawdę boli
Weź zgłoszenia zmian z ostatniego roku i zobacz, czy skupiają się w kilku obszarach: cennikach i promocjach, integracjach, raportach, komunikacji z klientem. Często tak właśnie wychodzi.
Takie obszary to pierwsi kandydaci do wyjęcia z monolitu. Nie dlatego, że są najważniejsze, tylko dlatego, że zmieniają się najczęściej, a każda ich zmiana oznacza dziś release całego systemu.
Zanim zaczniesz, sprawdź jedną rzecz: czy Twój system w ogóle pozwala podłączyć coś z zewnątrz. Jeśli masz dostęp do kodu, sprawa jest prostsza. Jeśli korzystasz z zamkniętego systemu, zostaje Ci to, co udostępnia jego API.
3. Nowe rzeczy buduj obok, nie w środku
Nowe funkcje, które mają wyraźną granicę i często się zmieniają, warto budować obok systemu, jako mały moduł połączony z nim przez API. Nie każdą funkcję, tylko te, przy których to się opłaca.
Trochę jak z domem. Jeśli potrzebujesz warsztatu, najprościej postawić obok wolnostojący garaż i poprowadzić do niego jeden kabel z prądem. Nie ruszasz konstrukcji domu i nie przebijasz ściany nośnej. Kabel to umówione przyłącze, a w świecie systemów nazywa się to właśnie API.
Weźmy sprawdzanie rachunku na białej liście. Zamiast dopisywać je do kodu ERP, można zrobić mały moduł, który dostaje NIP, numer rachunku i datę, odpytuje wykaz i odsyła wynik. Do tego zapisuje potwierdzenie sprawdzenia, które wykaz zwraca przy każdym zapytaniu. A jeśli API akurat nie odpowiada, mówi wprost „nie udało się sprawdzić”, zamiast udawać, że rachunku nie ma na liście.
Akurat ta integracja to dobry poligon, bo rozwiązuje realny problem. Jeśli wartość transakcji z inną firmą przekracza 15 000 zł brutto, liczy się cała kwota, nawet jeśli płacisz ją w ratach. Gdy zapłacisz za fakturę od czynnego podatnika VAT na rachunek spoza wykazu, możesz stracić prawo do ujęcia tej płatności w kosztach i odpowiadać za zaległy VAT kontrahenta z tej transakcji. Skutków da się uniknąć, na przykład zgłaszając taki przelew do urzędu skarbowego (zawiadomienie ZAW-NR) w ciągu 7 dni od jego zlecenia. Ręczne sprawdzanie każdego przelewu to jednak dokładnie ta praca, którą warto oddać maszynie.
Taki moduł wdrażasz i testujesz osobno, bez stawiania na nogi całej firmy. A jeśli wykaz zmieni sposób odpowiadania, poprawiasz tylko moduł, a nie ERP.
To samo dotyczy wszystkich integracji z zewnętrznym światem: rejestrów, kurierów, bramek płatności. Zmieniają się niezależnie od Ciebie, więc warto, żeby system rozmawiał z nimi przez takiego pośrednika (w żargonie: adapter), a nie bezpośrednio.
4. Wymieniaj stary system kawałek po kawałku
To podejście ma swoją nazwę: strangler fig. Nazwa pochodzi od figowca dusiciela, drzewa, które wyrasta obok starego, owija się wokół niego i powoli przejmuje jego miejsce.
W systemach wygląda to tak: wybierasz jeden obszar (na przykład promocje), budujesz go od nowa jako osobny moduł, przełączasz na niego ruch, a stary kod w monolicie wyłączasz. Potem kolejny obszar. Po roku czy dwóch monolit jest mniejszy, a to, w czym biznes grzebie najczęściej, żyje już osobno.
Jedno ostrzeżenie: zanim przełączysz dany obszar, przygotuj sposób powrotu. Jeśli nowy moduł zdążył już zapisać dane, stary system musi umieć je przeczytać. Wycofanie ruchu jest proste tylko do momentu, w którym nie wyłączysz starego kodu.
5. Zabezpiecz to, co zostaje w starym systemie
Monolit nie zniknie w jeden dzień, więc trzeba go zabezpieczyć:
- Testy automatyczne najważniejszych ścieżek. Nie od razu wszystkiego. Kilkanaście scenariuszy, które firma wykonuje codziennie: złożenie zamówienia, wystawienie faktury, otwarcie reklamacji, także dla klienta z archiwum. Odpala je automat przed każdym wdrożeniem i po paru minutach wiesz, czy podstawy działają.
- Feature flagi. Nową funkcję wdrażasz wyłączoną i włączasz jednym ustawieniem. Jeśli coś pójdzie źle, wyłączasz ją w minutę, zamiast czekać tydzień na poprawkę.
- Monitoring błędów. System sam powinien zgłosić, że w oknie reklamacji coś się wywraca, zanim zadzwoni pierwszy klient.
- Mniejsze i częstsze release'y. Im więcej zmian zbierzesz do jednego wdrożenia, tym trudniej znaleźć tę, która coś popsuła.
6. Nie wpadnij w drugą skrajność
Odpowiedzią na monolit nie jest pocięcie wszystkiego na kilkadziesiąt mikroserwisów. Jeśli usługi trzeba wdrażać razem, a awaria jednej zatrzymuje pozostałe, dostajesz rozproszony monolit (distributed monolith). Ma wszystkie wady monolitu, a do tego jest rozrzucony po wielu serwerach i trudniej go naprawić. Wspólna baza dla wszystkich usług tylko dokłada takich zależności.
Wyjmuj tylko to, co naprawdę zmienia się niezależnie i ma jasną granicę: wchodzi NIP, wychodzi odpowiedź.
Na koniec
Monolit to nie wyrok. To system, który wyrósł z czasów, gdy firma potrzebowała mniej zmian. Nie trzeba go burzyć. Zacznij od wydzielenia tych obszarów, których zmiany najbardziej blokują firmę.
Celem jest krótsza droga od zgłoszenia do działającej zmiany i mniej nerwów przy każdym wdrożeniu. A kolejny release przestaje być wydarzeniem, przed którym wszyscy wstrzymują oddech.
Jeśli chcesz sprawdzić, od czego zacząć u siebie, porozmawiajmy. Pierwsza rozmowa nic nie kosztuje. Przyjrzymy się temu, co najbardziej blokuje zmiany w Twoim systemie, i ustalimy pierwszy krok.