W świecie tworzenia oprogramowania łatwo odnieść wrażenie, że nowoczesna aplikacja powinna składać się z mikroserwisów. Osobna usługa do obsługi użytkowników, osobna do zamówień, kolejna do płatności, następna do powiadomień. Każdy element można rozwijać niezależnie, wdrażać osobno i skalować wtedy, kiedy rzeczywiście tego potrzebuje.
Na diagramie wygląda to doskonale. Poszczególne części systemu mają swoje zadania, zespoły mogą pracować równolegle, a awaria jednej usługi nie powinna zatrzymywać całej aplikacji.
Problem zaczyna się wtedy, gdy diagram trafia do rzeczywistości. Zamiast jednej aplikacji zespół utrzymuje kilkanaście usług, kilka mechanizmów komunikacji, wiele procesów wdrożeniowych, dodatkowe logi, monitoring, uprawnienia i konfiguracje. Prosta operacja biznesowa wymaga komunikacji pomiędzy kilkoma komponentami. Testowanie staje się trudniejsze, a znalezienie przyczyny błędu wymaga prześledzenia całego przepływu przez system.
Czy to oznacza, że mikroserwisy są złym rozwiązaniem? Nie. W odpowiednich warunkach potrafią znacząco poprawić sposób rozwijania dużych produktów. Nie są jednak automatycznym etapem dojrzewania aplikacji ani gwarancją lepszej skalowalności.
Dobra architektura to nie ta, która składa się z największej liczby usług. To ta, która pozwala rozwijać produkt bez niepotrzebnego zwiększania kosztów, ryzyka i złożoności.
Dlatego przed podjęciem decyzji warto zrozumieć, czym różnią się monolit, modularny monolit i mikroserwisy, jakie problemy rozwiązują oraz jakie nowe obowiązki wprowadzają.
Czym właściwie jest monolit?
Monolit to aplikacja, której główne elementy są rozwijane i wdrażane jako jedna jednostka. Może zawierać wiele modułów, obsługiwać różne procesy biznesowe i korzystać z rozbudowanej architektury wewnętrznej. Sam fakt, że system jest monolitem, nie oznacza więc, że cały kod znajduje się w jednym pliku albo że aplikacja jest chaotyczna.
Przykładem może być system obsługujący sprzedaż, klientów, produkty, zamówienia, płatności i raportowanie. Wszystkie te funkcje mogą być częścią jednej aplikacji, która korzysta ze wspólnej bazy danych i jest wdrażana jako jeden produkt.
Taka konstrukcja ma konkretne zalety. W wielu przypadkach łatwiej ją uruchomić, przetestować i wdrożyć. Wywołania pomiędzy modułami mogą odbywać się bezpośrednio w ramach procesu aplikacji, bez konieczności przesyłania żądań przez sieć. Transakcje obejmujące kilka obszarów systemu mogą być prostsze do zrealizowania, jeśli korzystają ze wspólnej bazy danych.
Monolit może też ograniczyć liczbę elementów infrastruktury, którymi trzeba zarządzać. Nie ma konieczności konfigurowania osobnego procesu wdrożenia, monitoringu i komunikacji dla każdej niewielkiej funkcji.
Oczywiście monolit ma również ograniczenia. Jeśli przez lata kolejne funkcje są dodawane bez kontroli nad zależnościami, kod staje się coraz trudniejszy do zrozumienia. Zmiana w jednym miejscu może powodować problemy w innym, a wdrożenie niewielkiej funkcji wymaga przetestowania i opublikowania całej aplikacji.
To jednak nie jest nieunikniona cecha monolitu. Często problemem nie jest sam sposób wdrażania aplikacji, lecz jej wewnętrzna struktura.
Monolit monolitowi nierówny
W dyskusjach o architekturze często wrzuca się do jednego worka wszystkie aplikacje monolityczne. Tymczasem istnieje istotna różnica pomiędzy systemem, którego moduły mają jasno określone granice, a aplikacją, w której każdy element może dowolnie odwoływać się do pozostałych.
W pierwszym przypadku mamy uporządkowaną konstrukcję. W drugim może powstać tak zwany big ball of mud, czyli system o niejasnych granicach, licznych zależnościach i trudnej do odtworzenia logice.
Wyobraźmy sobie aplikację sprzedażową, w której moduły klientów, produktów, zamówień i płatności mają własną odpowiedzialność. Moduł zamówień korzysta z określonego interfejsu modułu klientów, a nie z przypadkowych fragmentów jego wewnętrznej implementacji. Zmiany w jednym obszarze nie powinny wymagać niekontrolowanych modyfikacji w całym systemie.
Jeśli natomiast każdy moduł bezpośrednio modyfikuje dane innych modułów, korzysta z ich wewnętrznych klas i zakłada szczegóły ich działania, aplikacja stopniowo traci strukturę.
To właśnie tutaj pojawia się modularny monolit.
Modularny monolit: kompromis, który warto rozważyć
Modularny monolit pozostaje jedną aplikacją wdrożeniową, ale jego wnętrze jest podzielone na wyraźnie zdefiniowane moduły. Każdy z nich odpowiada za określony obszar biznesowy, posiada jasno określone granice i udostępnia innym częściom systemu kontrolowany sposób współpracy.
W praktyce może to oznaczać moduły odpowiedzialne za klientów, katalog produktów, zamówienia, rozliczenia czy powiadomienia. Każdy z nich ma własną logikę, a dostęp do jego wewnętrznych mechanizmów jest ograniczony.
Najważniejsza różnica polega na tym, że granice logiczne nie muszą oznaczać granic infrastrukturalnych. Moduły mogą być dobrze odseparowane w kodzie, mimo że aplikacja nadal jest uruchamiana i wdrażana jako całość.
Taki model pozwala uporządkować odpowiedzialność, ograniczyć zależności i przygotować system do dalszego rozwoju bez wprowadzania wszystkich kosztów architektury rozproszonej.
Modularny monolit może być szczególnie dobrym rozwiązaniem, gdy:
-
produkt rozwija jeden zespół lub kilka zespołów ściśle ze sobą współpracujących;
-
granice biznesowe systemu dopiero się kształtują;
-
większość funkcji korzysta z tych samych danych i musi zachowywać ich spójność;
-
nie ma potrzeby niezależnego skalowania poszczególnych obszarów;
-
obecny proces wdrażania działa wystarczająco dobrze;
-
firma chce zachować możliwość późniejszego wydzielenia wybranych modułów.
To ostatnie jest szczególnie istotne. Rozpoczęcie od modularnego monolitu nie musi oznaczać zamknięcia drogi do mikroserwisów. Jeżeli granice modułów są dobrze zaprojektowane, a potrzeby biznesowe się zmienią, określony obszar można w przyszłości wydzielić do osobnej usługi.
Nie jest to jednak automatyczna migracja jednym kliknięciem. Trzeba uwzględnić sposób przechowywania danych, zależności, transakcje, komunikację i odpowiedzialność za utrzymanie nowego komponentu. Dobra modularność może jednak znacząco ułatwić ten proces.
Mikroserwisy: co rzeczywiście dają?
Architektura mikroserwisowa dzieli aplikację na mniejsze usługi, które realizują określone funkcje biznesowe i mogą być rozwijane oraz wdrażane niezależnie. Usługi komunikują się ze sobą za pomocą zdefiniowanych interfejsów, często poprzez API, komunikaty lub zdarzenia.
Dzięki temu zespół może zmienić jedną usługę bez konieczności publikowania całej aplikacji. Poszczególne komponenty mogą też wykorzystywać inne technologie lub być skalowane niezależnie, jeżeli ich obciążenie i wymagania rzeczywiście się różnią.
Przykładowo, platforma handlowa może mieć osobną usługę wyszukiwania produktów, której obciążenie rośnie znacznie szybciej niż obciążenie modułu zarządzania kontami użytkowników. W architekturze mikroserwisowej można zwiększyć zasoby usługi wyszukiwania bez konieczności skalowania wszystkich pozostałych elementów systemu.
Podobnie może wyglądać sytuacja, gdy jeden obszar produktu wymaga szczególnie częstych wdrożeń, inny ma odrębne wymagania dostępności, a jeszcze inny jest rozwijany przez niezależny zespół.
Mikroserwisy mogą zatem pomóc w kilku konkretnych obszarach:
Niezależne wdrożenia. Zmiana w jednej usłudze nie musi wymagać wydania wszystkich pozostałych komponentów, o ile ich kontrakty pozostają kompatybilne.
Niezależne skalowanie. Można zwiększać zasoby tylko tych usług, które tego potrzebują, zamiast skalować cały system.
Odrębna odpowiedzialność zespołów. Zespoły mogą samodzielnie rozwijać określone obszary produktu, jeśli granice odpowiedzialności są rzeczywiście dobrze zaprojektowane.
Izolacja części problemów. Odpowiednio zaprojektowana usługa może ograniczyć wpływ niektórych awarii na resztę systemu. Nie dzieje się to jednak automatycznie. Jeśli pozostałe komponenty nie potrafią działać bez niedostępnej usługi, problem nadal może objąć znaczną część aplikacji.
Elastyczność technologiczna. Poszczególne usługi mogą być dopasowane do różnych potrzeb technicznych, choć utrzymywanie wielu technologii również zwiększa koszty.
Warto zauważyć, że żadna z tych korzyści nie wynika wyłącznie z liczby usług. Wymaga odpowiednich granic architektonicznych, automatyzacji, monitoringu, procesu testowania i kompetencji zespołu.
Cena rozdzielenia systemu: co pojawia się poza diagramem?
Największym błędem przy planowaniu mikroserwisów jest porównywanie ich wyłącznie na podstawie struktury kodu. Rozdzielenie aplikacji zmienia bowiem nie tylko sposób jej implementacji, ale również sposób uruchamiania, testowania, wdrażania i diagnozowania problemów.
W monolicie wywołanie jednej funkcji przez drugą może odbywać się w ramach tego samego procesu. W systemie rozproszonym współpraca pomiędzy usługami często oznacza komunikację sieciową, która może się opóźnić, zakończyć błędem albo zostać przerwana w nieoczekiwanym momencie.
Pojawiają się nowe pytania. Co zrobić, gdy usługa A wykonała operację, ale usługa B nie otrzymała odpowiedzi? Czy ponowienie żądania nie spowoduje wykonania tej samej operacji dwa razy? Co się stanie, jeśli część procesu zakończy się powodzeniem, a pozostałe elementy nie zarejestrują zmiany?
To nie są rzadkie, teoretyczne problemy. W systemach obsługujących płatności, zamówienia, rezerwacje czy stany magazynowe mogą prowadzić do rzeczywistych rozbieżności biznesowych.
Do tego dochodzą koszty utrzymania:
-
więcej komponentów do monitorowania;
-
osobne konfiguracje i procesy wdrożeniowe;
-
konieczność śledzenia żądań przechodzących przez wiele usług;
-
dodatkowe mechanizmy komunikacji i obsługi błędów;
-
testy integracyjne i kontraktowe;
-
zarządzanie wersjami API;
-
kontrola dostępu pomiędzy komponentami;
-
większa liczba potencjalnych punktów awarii;
-
potrzeba kompetencji związanych z systemami rozproszonymi.
Nie oznacza to, że mikroserwisy zawsze są droższe w całym cyklu życia. W odpowiednio dużym systemie mogą ograniczyć koszty koordynacji i przyspieszyć rozwój. Jednak początkowy koszt operacyjny jest realny i powinien zostać uwzględniony w decyzji.
Jeżeli firma nie ma automatyzacji wdrożeń, dobrego monitoringu i procedur reagowania na awarie, rozdzielenie aplikacji może zwiększyć złożoność szybciej, niż przyniesie korzyści.
Kiedy mikroserwisy zaczynają mieć sens?
Nie istnieje jedna uniwersalna liczba użytkowników, zapytań czy programistów, po przekroczeniu której należy przejść na mikroserwisy. Decyzja zależy od rodzaju produktu, jego obciążenia, struktury organizacyjnej i rzeczywistych ograniczeń obecnej architektury.
Można jednak wskazać sytuacje, w których rozdzielenie części systemu warto poważnie rozważyć.
1. Poszczególne obszary mają wyraźnie różne profile obciążenia.
Jeżeli jedna funkcja wymaga znacznie większej mocy obliczeniowej niż pozostałe, niezależne skalowanie może przynieść wymierne korzyści. Trzeba jednak potwierdzić, że problemu nie da się rozwiązać prostszymi metodami, np. optymalizacją zapytań, cache, kolejką zadań lub zwiększeniem zasobów całej aplikacji.
2. Zespoły muszą rozwijać różne obszary niezależnie.
W dużej organizacji wspólna baza kodu i jeden proces wydawania mogą utrudniać pracę wielu zespołom. Wydzielenie odpowiedzialności może poprawić autonomię, pod warunkiem że usługi mają stabilne granice i jasno określone kontrakty.
3. Różne funkcje mają odmienne wymagania dostępności.
Niektóre obszary produktu mogą wymagać szczególnej odporności na awarie, podczas gdy inne mogą być chwilowo niedostępne bez zatrzymywania najważniejszych procesów. Niezależne usługi dają możliwość dopasowania strategii skalowania, wdrażania i odzyskiwania do konkretnego obszaru.
4. Jeden moduł wymaga innej technologii lub sposobu przetwarzania.
Czasami określone zadanie ma uzasadnione wymagania, których spełnienie w głównej aplikacji byłoby nieefektywne. Wydzielenie może wtedy ograniczyć wpływ tych wymagań na pozostałą część produktu. Warto jednak pamiętać, że dodatkowy stos technologiczny oznacza również dodatkową odpowiedzialność za utrzymanie.
5. Granice biznesowe są już dobrze rozpoznane.
Jeśli wiadomo, gdzie kończy się odpowiedzialność jednego obszaru, a zaczyna drugiego, łatwiej zaprojektować niezależne usługi. Gdy granice są niejasne i często się zmieniają, ich przedwczesne ustalenie może doprowadzić do kosztownych zależności i ciągłych zmian interfejsów.
Najważniejsza zasada brzmi: wydzielaj usługę dlatego, że rozwiązuje konkretny problem, a nie dlatego, że kolejny element na diagramie wygląda nowocześnie.
Kiedy modularny monolit będzie lepszym wyborem?
Modularny monolit często wygrywa wtedy, gdy firma potrzebuje uporządkować aplikację, ale nie ma jeszcze uzasadnienia dla rozproszenia jej na wiele niezależnych usług.
Może to dotyczyć nowego produktu, którego model biznesowy dopiero się rozwija. Na początku trudno przewidzieć, które funkcje staną się najbardziej obciążone, które będą wymagały niezależnych wdrożeń i gdzie ostatecznie przebiegną granice odpowiedzialności.
Podobnie jest w przypadku średniej wielkości systemu biznesowego, w którym większość operacji dotyczy wspólnych danych. Rozdzielenie logiki na kilka usług może wprowadzić dodatkowe problemy ze spójnością danych i transakcjami, nie dając w zamian wystarczającej niezależności.
Modularny monolit warto rozważyć również wtedy, gdy firma ma ograniczone zasoby operacyjne. Jeden proces wdrożeniowy i prostszy model monitorowania mogą być rozsądniejszym rozwiązaniem niż utrzymywanie kilkunastu usług, z których każda wymaga własnej konfiguracji i procedur.
Nie chodzi przy tym o pozostawienie wszystkiego w jednej aplikacji bez planu na przyszłość. Dobrze zaprojektowany modularny monolit wymaga dyscypliny: wyraźnych granic modułów, kontrolowanego dostępu do danych i ograniczania niepotrzebnych zależności.
Jeśli te zasady zostaną zachowane, firma może korzystać z prostszego modelu wdrażania, jednocześnie przygotowując system na ewentualne wydzielenie wybranych funkcji w przyszłości.
Skalowalność to nie tylko liczba serwerów
Jednym z najczęstszych argumentów za mikroserwisami jest skalowalność. Warto jednak rozdzielić dwa różne zagadnienia: skalowanie techniczne i zdolność organizacji do rozwijania produktu.
Skalowanie techniczne oznacza możliwość obsługi większego obciążenia. W wielu przypadkach aplikację monolityczną można uruchomić na kilku instancjach, wykorzystać równoważenie obciążenia, cache, kolejki zadań i odpowiednio zaprojektowaną bazę danych. Taki system może obsługiwać znaczący ruch bez konieczności dzielenia go na dziesiątki usług.
Oczywiście nie każdy monolit można skalować w dowolny sposób. Problemy mogą wynikać z przechowywania stanu w pamięci procesu, wspólnej bazy danych, kosztownych operacji synchronicznych lub ograniczeń konkretnego komponentu. Najpierw jednak warto ustalić, co faktycznie stanowi wąskie gardło.
Skalowanie organizacyjne to inna kwestia. Jeśli nad produktem pracuje wiele zespołów, które regularnie blokują się wzajemnie podczas zmian i wdrożeń, podział odpowiedzialności może przynieść korzyści nawet wtedy, gdy wydajność systemu jest wystarczająca.
W praktyce decyzję warto więc oprzeć na pomiarach. Czy aplikacja ma problem z wydajnością? Czy wdrożenia trwają zbyt długo? Czy zespoły muszą uzgadniać każdą zmianę? Czy konkretna funkcja potrzebuje innych zasobów? Czy awarie jednego modułu wpływają na pozostałe?
Odpowiedzi pozwalają odróżnić problem architektury od problemu infrastruktury, jakości kodu lub organizacji pracy.
Migracja do mikroserwisów: dlaczego nie warto rozdzielać wszystkiego naraz?
Jeśli obecna aplikacja rzeczywiście zaczyna ograniczać rozwój produktu, migracja do mikroserwisów nie musi oznaczać jednorazowego przepisania całego systemu.
Bezpieczniejszym podejściem bywa stopniowe wydzielanie konkretnych obszarów. Najpierw trzeba ustalić, który moduł ma wystarczająco wyraźną odpowiedzialność, jakie dane obsługuje i w jaki sposób współpracuje z pozostałymi częściami aplikacji.
Następnie można zaprojektować granicę komunikacji, przygotować testy i stopniowo przenosić odpowiedzialność do nowej usługi. Pozwala to sprawdzać założenia na ograniczonym obszarze, zanim firma zdecyduje się na kolejne zmiany.
Przykładowo, system sprzedażowy może początkowo zawierać moduł generowania raportów, który mocno obciąża bazę danych i spowalnia operacje użytkowników. Zamiast rozdzielać cały system, można najpierw przeanalizować, czy raportowanie da się przenieść do osobnego procesu lub usługi, ewentualnie wykorzystując dane przygotowywane asynchronicznie.
Takie wydzielenie ma sens, jeśli rzeczywiście zmniejsza obciążenie głównej aplikacji albo pozwala niezależnie rozwijać i skalować raportowanie. Jeżeli jednak raporty są proste, a ich obciążenie niewielkie, dodatkowa usługa może być niepotrzebna.
Właśnie dlatego migracja powinna zaczynać się od problemu i oczekiwanego rezultatu, a nie od założenia, że wszystkie moduły ostatecznie muszą stać się mikroserwisami.
Warto również pamiętać, że wydzielenie usługi nie kończy się na przeniesieniu kodu. Trzeba rozwiązać kwestię danych, komunikacji, autoryzacji, monitorowania, wdrożeń, testów i odpowiedzialności za awarie. Dopiero wtedy nowy komponent staje się rzeczywiście niezależnym elementem architektury.
Jak podjąć decyzję? Praktyczna lista pytań
Przed wyborem architektury warto odpowiedzieć na kilka pytań. Nie zastąpią one analizy technicznej, ale pomogą uporządkować decyzję.
1. Jaki konkretny problem chcemy rozwiązać? Czy chodzi o wydajność, czas wdrożeń, zależności pomiędzy zespołami, dostępność czy trudność utrzymania kodu? Jeśli nie potrafimy wskazać problemu, trudno ocenić, czy mikroserwisy są właściwym rozwiązaniem.
2. Czy problem rzeczywiście wynika z architektury? Powolna aplikacja może wymagać optymalizacji zapytań, a trudne wdrożenia mogą wynikać z braku testów i automatyzacji. Zmiana architektury nie zastąpi tych działań.
3. Czy granice biznesowe są wystarczająco jasne? Jeśli moduły stale korzystają ze swoich wewnętrznych danych i reguł, wydzielenie ich do niezależnych usług może utrwalić nieprawidłowy podział.
4. Czy potrzebujemy niezależnego skalowania lub wdrażania? Jeśli wszystkie części systemu są zmieniane i obciążane w podobny sposób, korzyść z niezależności może być niewielka.
5. Czy mamy narzędzia i kompetencje do utrzymania systemu rozproszonego? Monitoring, logi, śledzenie żądań, automatyczne wdrożenia i procedury obsługi awarii są ważnymi elementami tej decyzji.
6. Jak będą zarządzane dane i transakcje? Wydzielenie usługi może utrudnić zachowanie atomowości operacji obejmujących kilka obszarów. Trzeba zaplanować, co się stanie, gdy część procesu się powiedzie, a inna nie.
7. Czy korzyści uzasadniają całkowity koszt? Warto uwzględnić nie tylko koszt implementacji, ale również infrastrukturę, monitoring, bezpieczeństwo, testowanie, utrzymanie i rozwój kompetencji.
8. Czy możemy zacząć od mniejszej zmiany? Czasem wystarczy uporządkowanie modułów, wydzielenie procesu asynchronicznego lub poprawa automatyzacji wdrożeń. Najmniejsza zmiana, która skutecznie rozwiązuje problem, bywa najlepszym punktem wyjścia.
Najczęstsze błędy przy wyborze architektury
Pierwszy błąd to utożsamianie nowoczesności z liczbą usług. Mikroserwisy są konkretnym sposobem organizacji systemu, a nie celem samym w sobie.
Drugi to projektowanie architektury na podstawie przewidywań, które nie mają jeszcze potwierdzenia w rzeczywistym działaniu produktu. Warto pozostawić sobie możliwość rozwoju i wydzielać kolejne elementy wtedy, gdy pojawia się uzasadniona potrzeba.
Trzeci to rozbijanie systemu bez ustalenia granic biznesowych. Jeśli usługi są silnie od siebie zależne, powstaje architektura rozproszona, która zachowuje problemy monolitu, ale dodaje koszty komunikacji sieciowej.
Czwarty to pomijanie operacyjnej strony rozwiązania. Każda nowa usługa musi być wdrażana, monitorowana, zabezpieczana i diagnozowana. Bez odpowiednich procesów rosnąca liczba komponentów może obniżyć niezawodność zamiast ją poprawiać.
Piąty to próba rozwiązania problemów organizacyjnych samą technologią. Mikroserwisy mogą wspierać niezależność zespołów, ale nie zastąpią jasnego podziału odpowiedzialności, komunikacji i dobrego zarządzania produktem.
Szósty to traktowanie modularnego monolitu jako rozwiązania tymczasowego, które należy jak najszybciej porzucić. Dobrze zaprojektowana aplikacja monolityczna może pozostać właściwym wyborem przez wiele lat. Nie ma potrzeby komplikować jej architektury bez konkretnej korzyści.
Architektura powinna rozwijać się razem z produktem
Nie ma jednej architektury, która będzie najlepsza dla każdej aplikacji. Mały produkt rozwijany przez kilkuosobowy zespół ma inne potrzeby niż platforma obsługująca wiele niezależnych domen biznesowych i rozwijana przez kilkanaście zespołów.
Monolit może zapewnić prostotę wdrażania i łatwiejsze zarządzanie operacjami. Modularny monolit pozwala uporządkować strukturę aplikacji i zachować tę prostotę. Mikroserwisy mogą natomiast zapewnić niezależność rozwoju, wdrażania i skalowania, jeśli produkt oraz organizacja rzeczywiście potrzebują takiego modelu.
Najważniejsze jest rozpoznanie, z jakim problemem mierzy się firma. Nie warto wprowadzać kilkunastu usług tylko dlatego, że tak wygląda architektura popularnych platform. Nie warto też kurczowo trzymać się monolitu, jeśli jego ograniczenia blokują rozwój produktu i można wskazać konkretne korzyści z wydzielenia części systemu.
Dobra decyzja architektoniczna nie polega na przewidzeniu wszystkich przyszłych potrzeb. Polega na zbudowaniu rozwiązania, które odpowiada na dzisiejsze wymagania, nie zamykając drogi do rozsądnych zmian w przyszłości.
Zanim rozdzielisz aplikację na mikroserwisy, sprawdź, czy naprawdę potrzebujesz niezależnych usług, czy przede wszystkim lepiej uporządkowanego systemu. Ta różnica może zdecydować nie tylko o architekturze, ale również o kosztach i tempie rozwoju produktu.
Źródła i dalsza lektura
-
AWS Well-Architected Framework: Choose how to segment your workload - kompromisy między architekturą monolityczną i mikroserwisową.
-
Microsoft Azure Architecture Center: Microservices architecture - złożoność, komunikacja, testowanie i zarządzanie danymi w systemach rozproszonych.
-
microservices.io: How modular can your monolith go? - organizowanie monolitu wokół domen biznesowych.
Powiązane artykuły Web24
-
Dlaczego nowa funkcja w starej aplikacji kosztuje coraz więcej?
-
Twoja aplikacja działa. Ale czy można ją bezpiecznie wdrożyć 100 razy dziennie?
Powyższe odnośniki prowadzą do artykułów poruszających zagadnienia powiązane z modernizacją, kosztami rozwoju i procesem wdrożeń. Nie są zamiennikiem dla odrębnej analizy wyboru architektury.
Zapraszamy do lektury.
