Mikroserwisy czy jeden panel. Hurtownia ma zamówienie, magazyn ma inną liczbę
Autor:
Paweł Matusiak
·
Handlowiec obiecuje towar, magazyn widzi inną liczbę, faktura czeka na komunikat z osobnej usługi. Mikroserwisy pomagają, gdy osobne zespoły naprawdę mają osobne tempo. Przy jednym obiegu zamówienia i dwóch osobach od IT taniej utrzymać jeden panel z modułami niż cztery dzienniki, w których ginie stan.
Handlowiec w hurtowni obiecuje instalatorowi towar na jutro. Magazyn na hali widzi inną liczbę. Faktura stoi, bo osobna usługa jeszcze nie dostała komunikatu. Właściciel słyszy, że tak ma wyglądać nowoczesny program.
Mikroserwisy dzielą aplikację na osobne usługi, które wdraża się i skaluje osobno. Taki podział pomaga, gdy naprawdę osobne zespoły odpowiadają za osobne kawałki produktu i gdy te kawałki zmieniają się w innym rytmie. W firmie z jednym obiegiem zamówienia i dwiema osobami od IT zwykle nic nie przyspiesza. Ten sam dzień — telefon, kompletacja, dokument — rozpada się na kilka wdrożeń i kilka dzienników. Zanim w organizacji widać twarde szwy, taniej utrzymać jeden panel z wyraźnymi modułami niż sieć usług, w której gubi się stan magazynowy. Palety na hali ten podział sam z siebie nie zbierze.
Zamówienie, stan i faktura mieszczą się w jednym dniu
W hurtowni nikt nie planuje dnia według usług. Planuje go według telefonu od instalatora, kompletacji na hali i faktury, która ma wyjść, zanim klient wyjedzie na budowę.
Rano handlowiec bierze zamówienie. Cena rzadko pochodzi z ogólnodostępnego cennika. Jest wyjątkiem z umowy, z rabatu kwartalnego, z kompletu, którego katalog nie trzyma jako jednej pozycji. W południe magazynier robi kompletację. Wieczorem biuro wystawia dokument, czasem z zaliczką, czasem z pozycją dopisaną po drugim telefonie.
Gdy te trzy rzeczy żyją w trzech programach, prawda o zamówieniu składa się z arkusza, z ekranu magazynu i z wątku w poczcie. Ktoś z zewnątrz proponuje wtedy podział: osobny katalog, osobne zamówienia, osobne stany, osobne faktury. Na slajdzie wygląda to jak porządek. W kalendarzu pracy zostaje ten sam bałagan, tylko ze szyną pośrodku.
Zanim powstanie sieć usług, potrzebna jest karta zamówienia, na której widać klienta, cenę, rezerwację i status dokumentu. Panel B2B dla hurtowni opisuje ten obieg od cennika do stanu. Osobne API ma uzasadnienie, gdy ta karta już istnieje i któryś jej fragment regularnie dusi resztę. Nie wtedy, gdy karty jeszcze nie ma.
Handlowiec i tak zadzwoni, gdy klient w południe zmieni komplet. Karta nie zastępuje rozmowy. Zastępuje zgadywanie, która liczba na stanie jest aktualna i który dokument już poszedł do księgowości.
Przykład: hurtownia elektryczna i cztery usługi zamiast panelu
Wyobraźmy sobie hurtownię materiałów elektrycznych. Kilkanaście osób w biurze, magazyn przy hali, handlowcy jeżdżą do instalatorów. Panel ogarnia klientów, indywidualne ceny, zamówienia i faktury. Stany ktoś dopisuje pod koniec dnia. Przy programie siedzą dwie osoby, czasem dochodzi zewnętrzny programista.
Typowa sytuacja wygląda tak. Po szkoleniu o architekturze zapada decyzja: katalog, zamówienia, stany i faktury jako osobne usługi. Między nimi szyna zdarzeń. Zamówienie emituje komunikat, stan ma się zaktualizować, faktura ma się wystawić.
Przez kilka spokojnych tygodni działa. Potem instalator w piątek po południu zamawia zestaw, którego na półce jest mało. Usługa zamówień przyjmuje dokument. Usługa stanów dostaje komunikat z opóźnieniem albo wcale, bo kolejka stanęła. Magazyn kompletuje z tego, co widać na regale. Drugi handlowiec w tym samym czasie obiecuje ten sam towar innemu klientowi, bo jego ekran jeszcze pokazuje starą liczbę. Handlowiec w terenie otwiera panel na telefonie i składa obietnicę z tego, co widzi. Jeżeli ten ekran czyta stan z opóźnieniem, obietnica jest zła, zanim wróci do biura.
Skutek jest zwyczajny i drogi. Jedna pozycja wychodzi dwa razy albo nie wychodzi wcale. Klient dostaje część zestawu. Biuro wystawia notę. Dwie osoby od IT szukają, w którym dzienniku zginął komunikat. Magazynier mówi, że skanował do „swojego” programu. Biuro mówi, że zamówienie w panelu było inne.
W tej historii nie pomaga piąta usługa. Pomaga rezerwacja stanu na tej samej karcie, na której powstaje zamówienie, i kolejka tylko dla ciężkich rzeczy: raport sezonowy, masowa zmiana cennika, wysyłka paczki faktur. Magazynier odhacza kompletację przy tej karcie, nie w osobnym programie, który dogoni resztę kiedyś.
Dwie osoby nie utrzymają czterech wdrożeń
Ten koszt zwykle nie trafia na slajd o skalowaniu.
Każda usługa to osobny obraz, osobne sekrety, osobny dziennik, osobny test, czy w ogóle żyje. Gdy zamówienie wisi, ktoś musi wiedzieć, czy padł katalog, kolejka, stan, czy sieć między nimi. W jednym panelu ten trop jest w jednym miejscu. W czterech usługach składa się go z obserwowalności: śladu żądania, korelacji, limitu czasu, ponowienia, martwego komunikatu, który utknął po restarcie.
Wdrożenie czterech usług to cztery szanse na wersję, która nie pasuje do sąsiada. Katalog zmienił pole. Zamówienia jeszcze czytają stare. Stan czeka na inny identyfikator towaru. Faktury milczą, bo zdarzenie zmieniło nazwę. W sezonie budowlanym takie rozjechanie wychodzi w piątek po południu, gdy hali nie zamknie się na „okienko serwisowe”.
Dwie osoby utrzymają to przez miesiąc, gdy nic się nie psuje. Nie mogą pełnić dyżuru przy czterech programach, gdy zamówienia wchodzą wieczorem, a magazyn pracuje w sobotę. Dyżur jest kosztem ludzi, nie kosztem instancji w chmurze. Podział na usługi przesuwa ten koszt z serwera na sen i na poniedziałkowe odtwarzanie, który komunikat nie doszedł.
Do tego dochodzi infrastruktura, której ruch hurtowni nie usprawiedliwia. Osobne bazy, osobne kolejki, osobne środowiska testowe. Każda zmiana ceny albo kompletu wymaga uzgodnienia kontraktu między usługami. Czas, który miał iść w kartę zamówienia, idzie w rury między programami.
Klient widzi stan, którego nie ma na regale
Spór o diagram milknie, gdy obietnica z panelu nie zgadza się z regałem. Zaczyna się ubytek marży.
Instalator zamawia, bo w panelu B2B widzi towar. Jeżeli ten panel czyta stan z opóźnionej usługi, obietnica jest fałszywa. Magazyn kompletuje coś innego albo nic. Handlowiec traci twarz. Biuro traci przedpołudnie na telefon i na notę korygującą. W hurtowni elektrycznej z przykładu ten sam bęben kabla potrafi być obiecany dwóm budowom, bo żaden ekran nie zdążył odjąć sztuki w momencie przyjęcia dokumentu.
Indywidualny cennik jeszcze to pogarsza. Cena klienta nie jest polem w katalogu. Jest wyjątkiem, terminem, czasem powiązaniem z konkretną inwestycją. Gdy katalog jest osobną usługą, a zamówienie drugą, wyjątek gubi się w drodze albo zostaje w starej wersji. Klient dostaje inną kwotę niż na ofercie. Księgowość dostaje dokument, którego handlowiec nie poznaje.
W jednym panelu rezerwacja i cena siedzą przy zamówieniu. Magazyn widzi, że sztuka jest już obiecana. Handlowiec widzi, że nie wolno sprzedać jej drugi raz. Ośmiu serwisów do tego nie potrzeba. Potrzebna jest jedna prawda o stanie w chwili, gdy dokument powstaje, a nie pół godziny później, gdy kolejka wreszcie dojdzie.
Użytkownik końcowy nie ocenia architektury. Ocenia, czy panel skłamał. Instalator, który raz dostał obietnicę bez towaru, wraca na telefon albo do innej hurtowni. Koszt tej straty nie pojawia się na fakturze za chmurę. Pojawia się w utraconym zamówieniu i w czasie, który biuro spędza na prostowaniu winy.
Granica, której w firmie jeszcze nie ma
Cięcie na usługi ma sens, gdy widać granicę domeny. Zamówienie kończy się w jednym miejscu, kompletacja zaczyna w drugim, a te dwa światy mają innych ludzi, inne tempo i inną odpowiedzialność. W banku albo w platformie z wieloma produktami takie szwy bywają oczywiste. W hurtowni z kilkunastoma osobami w biurze często nie.
W małej hurtowni ta sama osoba rano bierze telefon, w południe zagląda na magazyn, wieczorem pyta o fakturę. Jeżeli teraz pociąć system według slajdu — katalog, koszyk, płatność, magazyn — tnie się warstwy techniczne, nie firmę. Taki podział trudno odwrócić. Każda zmiana ceny, kompletu albo rezerwacji pod budowę idzie przez kilka umów między usługami. Poprawka, która w jednym module trwa dzień, w czterech usługach trwa tydzień uzgodnień.
Bezpieczniejszy ruch to modułowy monolit: jeden program, jedno wdrożenie, wewnątrz wyraźne moduły z własnymi tabelami i zakazem sięgania na skróty do cudzych danych. Raport, który w sezonie dusi ekran zamówień, schodzi do kolejki zadań. Gdy po dłuższym czasie widać, że fakturowanie naprawdę żyje innym rytmem i ma innego właściciela w firmie, wtedy wolno ten kawałek wyciągnąć. Nie odwrotnie.
Dług technologiczny w panelu rośnie szybciej, gdy zła granica zostaje zalana kolejnymi zdarzeniami. Zespół nie spłaca wtedy długu. Buduje mosty nad podziałem, którego firma nie potrzebowała. Sezon budowlany to widać wprost: ciężkie zestawienie sprzedaży powinno zejść z drogi handlowcowi, a nie pociągnąć za sobą rozbiórki cennika, koszyka i magazynu.
Monolit puchnie i jeden błąd kładzie wszystko
Kontrargument jest poważny. Zbywanie go frazą o „dostatecznie dobrym” programie nic nie daje.
W splątanym kodzie raport księgowy i przyjęcie zamówienia siedzą w tym samym procesie. Ciężkie zestawienie na koniec miesiąca spowalnia ekran handlowca. Błąd w imporcie cennika potrafi złożyć całą stronę. Kilka osób zmienia ten sam plik i nadpisuje sobie pracę. Pojedynczy punkt awarii jest wtedy realny: pada wszystko, bo wszystko jest jednym procesem.
Niezależne wdrożenie wygląda w takiej chwili jak obietnica spokoju. Zepsujesz faktury, zamówienia dalej chodzą. Skalowanie też bywa prawdziwym powodem. Raporty zjadają bazę, a przyjęcie zamówienia musi zostać szybkie. Da się wtedy wyciągnąć raport albo czytać go z kopii. Nie trzeba przy tej okazji rozbić cennika, koszyka i magazynu.
Ten opis dotyczy złego monolitu, nie każdego programu w jednym procesie. Moduły, osobna kolejka dla raportu, limit dla ciężkich ekranów i jedna ścieżka wdrożenia, która umie wrócić do poprzedniej wersji, załatwiają większość tego bólu bez sieci usług. Gdy te same dwie osoby wdrażają cztery serwisy, niezależność jest pozorna. Wersje rozjeżdżają się w czterech miejscach, a winy szuka się w czterech dziennikach.
Ograniczenie jest uczciwe. Gdy firma ma kilka produktów, kilka zespołów i różne wymagania dostępności — panel klienta, ciężka analityka, osobna wymiana z kontrahentem — podział na usługi może być uzasadniony. Warunek jest organizacyjny, nie estetyczny: granica już istnieje w ludziach i w kalendarzu, nie tylko na diagramie. Jeśli jeden zespół ma dyżurować przy wszystkim, rozproszony program zostaje rozproszonym monolitem. Awaria nadal kładzie dzień pracy, tylko trop jest dłuższy.
Co wolno wyciągnąć wcześniej
Są wyjątki, które nie wymagają czekania na drugi zespół. Ciężki eksport, masowa przecena, podgląd stanów tylko do odczytu, wysyłka dokumentów w tle. To zadania w tle, nie osobne produkty. Kolejka w tym samym programie zwykle wystarcza. Osobna usługa pojawia się, gdy to zadanie ma własny rytm, własną umowę z otoczeniem i kogoś, kto je utrzyma, gdy reszta panelu stoi.
Arkusz, gotowy program, integracja albo własny panel
Nie każda hurtownia potrzebuje własnego kodu, a tym bardziej własnej siatki usług.
Kilkanaście zamówień dziennie, jeden magazyn i cennik w arkuszu — Excel wystarczy, o ile nikt nie prowadzi drugiej listy w telefonie i o ile stany nie obiecuje się klientowi z pamięci. Gotowy program magazynowo-sprzedażowy bywa tańszy niż własny panel, gdy obieg jest podręcznikowy: dokument, wydanie, faktura, stan. Nie pali się działającego programu magazynowego po to, żeby mieć „nowoczesną architekturę”.
Problem zaczyna się przy indywidualnych cenach, kompletach dla instalatora, rezerwacji pod budowę i przy tym, że księgowość siedzi w innym programie. Wtedy najpierw integracja: panel mówi do programu magazynowego i do księgowości, zamiast udawać, że zastąpi oba. Gotowy program przestaje się spinać, gdy wyjątków jest więcej niż standardu i gdy trzy programy kłamią sobie nawzajem o tej samej sztuce towaru.
Kolejność, która zwykle mniej boli:
- Jedna karta zamówienia: klient, cena, rezerwacja stanu, status dokumentu.
- Integracja z programem, który już liczy magazyn albo księgowość, zamiast drugiego ręcznego przepisywania.
- Moduły w jednym panelu i kolejka dla raportu, który w sezonie dusi resztę.
- Osobna usługa dopiero wtedy, gdy kawałek ma stałą granicę, inny rytm i kogoś, kto go utrzyma.
Dedykowany panel ma uzasadnienie, gdy ten wyjątek jest codziennością i gdy jedna karta oszczędza ludziom składanie prawdy z trzech miejsc. Mikroserwisy nie są kolejnym etapem tego panelu. Są decyzją o organizacji pracy IT. GESOFT w takich zleceniach najpierw rozpisuje obieg: kto obiecuje towar, kto rezerwuje stan, kto kompletuje, kto wystawia dokument. Z tego widać, czy wystarczy spiąć istniejące programy, czy potrzebny jest jeden panel z modułami, a dopiero później — czy któryś moduł zasługuje na osobną usługę.
Czasem wynik jest skromny: karta, rezerwacja, most do księgowości. Czasem raport sezonowy musi zejść z drogi zamówieniom. Rzadziej, przy kilku zespołach i kilku produktach, pojawia się rzeczywisty podział. Ta rozmowa jest tańsza niż zamówienie „architektury mikroserwisowej”, zanim ktoś spisze, co się dzieje między telefonem handlowca a skanerem na hali.
Wniosek z kosztu ludzi, nie z diagramu
Mikroserwisy nie są błędem. Błędem jest stosować je jako domyślny kształt panelu dla firmy, która ma jeden zespół i jeden dzień pracy od telefonu do faktury.
Z argumentów wynika kolejność. Najpierw jedna karta i jedna prawda o stanie, bo bez tego klient dostaje obietnicę bez towaru. Potem moduły i kolejka tam, gdzie ciężar dusi resztę, bo to leczy splątany monolit bez czterech dyżurów. Potem, gdy granica i ludzie są na to gotowi, wyodrębnienie usługi. Odwrócenie tej kolejności daje hurtowni z przykładu cztery dzienniki i instalatora, któremu panel pokazał bęben, którego na regale już nie było.
Kontrargument o awarii i o skalowaniu zostaje w mocy tam, gdzie program naprawdę jest kłębkiem, a raport zjada zamówienia. Odpowiedzią jest wtedy modularność i tło dla ciężkich zadań, nie natychmiastowa siatka usług. Ograniczenie też zostaje: kilka produktów, kilka zespołów, różna dostępność — podział może być uzasadniony. W pozostałych firmach ewolucja architektury jest tańsza niż rewolucja na konferencyjnym rysunku. Dwie osoby od IT utrzymają jeden program z wyraźnymi szwami. Czterech usług z szyną zdarzeń nie utrzymają, gdy w piątek po południu zniknie komunikat.
Najczęściej zadawane pytania
- Czy mała hurtownia powinna zaczynać od mikroserwisów?
- Zwykle nie. Jeden zespół i jeden obieg od zamówienia do faktury lepiej znosi jeden panel z modułami. Osobne usługi mają uzasadnienie, gdy kawałek produktu ma inny rytm, inną dostępność i ludzi, którzy go utrzymają. Sam slajd o skalowaniu tego nie zastąpi.
- Czym różni się modułowy monolit od „jednego wielkiego programu”?
- W module widać, kto odpowiada za cennik, za rezerwację i za dokument, a dane sąsiadów nie są czytane na skróty. W splątanym programie raport, zamówienie i import cennika siedzą w jednym ciągu i kładą się nawzajem. Podział na moduły nie wymaga osobnych wdrożeń. Wymaga szwów w kodzie i w odpowiedzialności.
- Kiedy wyciągnąć z panelu osobną usługę?
- Gdy granica jest stabilna od dłuższego czasu, gdy ten kawałek dusi resztę albo ma inną umowę z otoczeniem, i gdy ktoś w firmie weźmie za niego dyżur. Ciężki raport albo wysyłka dokumentów często wystarcza jako zadanie w kolejce, bez osobnego programu.
Powiązana usługa:
Platformy B2B i CRM na zamówienie
Opisz projekt