Monolity vs. mikroserwisy — zalety i wady [porównanie]
Co wybrać jako architekturę systemu? Monolit czy mikroserwisy? Co lepiej sprawdzi się w naszej firmie? Stawianie na architekturę mikroserwisów, to obecnie jeden z najważniejszych trendów technologicznych, ale i monolity, zwłaszcza te modularne, mają swoje zalety. W dzisiejszym artykule przedstawiamy plusy i minusy każdego z systemów, i wyjaśniamy komu i kiedy lepiej sprawdzi się w biznesie dane rozwiązanie.
Monolit czy mikroserwisy? Ważna decyzja
Mówi się, że architektura systemów kreuje przyszłość danego biznesu i tak jest w istocie. To, czy wewnątrz firmy zdecydujemy się na system monolityczny czy system zbudowany na architekturze mikroserwisów, będzie miało swoje konsekwencje na szereg kolejnych lat — na funkcjonowanie przedsiębiorstwa, na szybkość wprowadzania zmian i integracji, a także na bezpieczeństwo.
Zatem, gdy firma buduje sobie nowy centralny system, w oparciu o który działać będą główne procesy przedsiębiorstwa, po prostu musi swój wybór naprawdę dobrze przemyśleć. Późniejsza zmiana architektury systemu będzie nie tylko niezwykle kosztowna i długa (często mijają całe lata aż da się całkowicie wymienić system), jak i trudna — zmiana procesów i przestawienie się na nowy system, nierzadko kosztuje organizację mnóstwo czasu i wysiłku, a wielu pracownikom adaptacja do zmian przysparza stresu i trudności.
Monolity vs. mikroserwisy — porównanie wad i zalet
Systemy monolityczne
Zacznijmy od systemów monolitycznych, które często kojarzone są — i to niesłusznie — z czymś przestarzałym. Niesłusznie, bo nie każdy monolit jest od razu legacy systemem i jeśli jest dobrze napisany i dostosowany do potrzeb biznesowych przedsiębiorstwa, i co istotne, dba się o niego regularnie, to może efektywnie służyć przez lata.
Wiele odnoszących dziś sukcesy firm, takich jak m.in. Netflix, Spotify, Twitter, Amazon czy Linkedin zaczynały swój biznes właśnie bazując na monolicie. Takie podejście określane jest jako Monolith first. Dopiero później, gdy przedsiębiorstwa te się rozrosły, zaczęły oferować więcej usług i stawiać na szybki rozwój, przerzuciły się na architekturę mikroserwisów, która lepiej spełniała te zadania.
Na początku jednak, z uwagi na łatwość określenia wymagań i stosunkowo niską różnorodność usług, system monolityczny był dla nich lepszym rozwiązaniem. Był wydajny w ramach jednego procesu, a że obejmował dość wąski dziedzinowo obszar, który nie zmieniał się czasem przez całe lata, monolit świetnie się sprawdzał.
To właśnie ta prostota na starcie, wydaje się być największą zaletą monolitów. Nie musimy przy nich zastanawiać się nad podziałem usług i funkcji, jak w przypadku mikroserwisów, gdzie wszystko rozdzielamy na niezależnie działające od siebie małe usługi komunikujące się poprzez sieć API. Czasami, na początkach działalności danej firmy, najzwyczajniej w świecie nie mamy jeszcze czego dzielić — potrzebujemy tylko jednego centralnego systemu, który pozwoli realizować biznesowe cele.
Spójrzmy teraz na najważniejsze zalety i wady architektury monolitycznej:
Systemy monolityczne to najprościej mówiąc, takie systemy, które implementowane są w kontekście jednej aplikacji. Określa się je jako kompleksowe systemy, będące pojedynczymi jednostkami wdrożeniowymi. Posiadają często jedną bazę danych, którą współdzielą wszystkie działy. Ma to taką zaletę, że jeśli chcemy dokonać zmiany we wszystkich usługach, to wystarczy wdrożyć tę zmianę w jednym miejscu, a nie jak w przypadku sieci mikroserwisów, w każdym mikroserwisie. Jest to też jednak wada, bo nie zawsze wszystkie działy potrzebują dokładnie takich samych usług i dostępów.
Minusem jest też to, że taki centralny system, nie pozwala wielu zespołom działać niezależnie od siebie i używa tylko jednej technologii, przez co często integracja z innymi systemami czy API jest utrudniona.
Co więcej, błąd w jakimś miejscu systemu, sprawia, że cały system może paść w jednej chwili. Tak jak trzepot skrzydeł motyla może wywołać burzę piaskową po drugiej stronie półkuli, tak mała awaria monolitu, może go w całości sparaliżować (tzw. Efekt motyla). Jeśli system jest duży, to znalezienie newralgicznego miejsca i przeszukanie setek linijek kodu, zajmuje całe tygodnie czasu, dlatego naprawy monolitów są powolne i kosztowne.
Z uwagi na wspomniany wyżej brak rozdzielenia usług, monolit jest też bardziej podatny na zewnętrzne ataki — wyciek danych sprawi, że od razu haker ma dostęp do całości systemu, a nie tylko do wydzielonej usługi.
To jednak, co najczęściej zarzuca się monolitom, to niska skalowalność i brak elastyczności na zmiany. Dla przykładu, dostosowanie systemu pod nowy format dokumentów księgowych może zająć wiele tygodni, a dodanie jakiejś nowej funkcji, wiele miesięcy. W przypadku architektury mikroserwisów, jest to o wiele łatwiejsze i szybsze — nie jesteśmy “raz na zawsze” skazani na jedną technologię i zamiast “doklejać” nowe funkcje do centralnego systemu (a często te doklejki są, bądźmy szczerzy, słabej jakości), to po prostu zmieniamy tylko jeden mikroserwis albo dodajemy nowy, usuwając inny, już nie spełniający swej funkcji.
Nie bez znaczenia jest również to, że decydując się na system monolityczny niejako skazujemy siebie na jednego dostawcę — mało kto przejmie taki system i zajmie się jego utrzymywaniem czy przebudową. Firmy technologiczne proponują wówczas przejście na nowy system lub ewentualnie refaktoryzację kodu. Dzieje się tak dlatego, że gdy system monolityczny ma “trafić” w nowe ręce, jest już najczęściej legacy systemem [więcej pisaliśmy o tym TUTAJ].
Podsumowując, system monolityczny — o ile oczywiście zamierzamy o niego dbać — może być dobrym rozwiązaniem dla dopiero co startujących firm, które nie mają wielkich potrzeb szybkiego wdrażania zmian i które nie do końca jeszcze wiedzą, czego chcą. Może być też dobrym wyborem, gdy system, którego potrzebujemy, ma być stosunkowo mały i obsługiwać jeden proces.
Ważne!
Warto wówczas wybrać tzw. monolit modularny — młodszego brata typowego systemu monolitycznego — który cechuje to, że można go później stosunkowo łatwo podzielić na mikroserwisy. Stanowi on więc swoisty złoty środek między monolitem a systemem rozproszonym.
Mikroserwisy
Systemy rozproszone to wbrew pozorom wcale nie mikroaplikacje. Nazwa ta nawiązuje nie tyle do wielkości systemu, a pełnionych przez nie funkcji biznesowych, czyli danych usług.
Mikroserwis A odpowiada za taką usługę, mikroserwis B za taką, a mikroserwis C za jeszcze inną. Decydując się na architekturę mikroserwisów, wybieramy zatem budowę wielu systemów, z których każdy jest w pełni autonomiczny, a następnie łączymy je ze sobą za pośrednictwem input i output API, niekoniecznie wiążąc wszystkie ze sobą. Nie jest to wcale wymagane — A może się kontaktować tylko z B, nie musi też z C [TUTAJ pisaliśmy o tym więcej]. Dzięki temu, nie wszystkie działy w firmie muszą mieć takie same dostępy, awaria w jednym miejscu nie powoduje położenia całego systemu, łatwo je integrować z nowymi usługami i rozwijać.
Innymi słowy, największe wady monolitów, to największe zalety systemów opartych o architekturę mikroserwisów.
Jak widać na powyższej grafice, niebagatelną zaletą architektury rozproszonej jest to, że możemy swobodnie wybrać technologię, a wiele zespołów może pracować niezależnie od siebie w różnych miejscach sieci — wymieniać mniejsze części, wprowadzać zmiany, dostosowywać system pod wymagania “tu i teraz”. Ta wysoka skalowalność i elastyczność na zmiany, to korzyści, których nie sposób odmówić temu rozwiązaniu.
Ale i systemy rozproszone mają swoje wady. Zapewnienie wymaganego bezpieczeństwa jest dużo trudniejsze niż w systemie monolitycznym, ponieważ komunikacja tutaj odbywa się po sieci, a nie w pamięci. Wywołania sieciowe mogą zawodzić i trzeba się liczyć z możliwością opóźnienia. Trudniejsze jest w mikroserwisach analizowanie i debugowanie i trudniej w nich zagwarantować transakcyjność w rozumieniu ACID. Ponadto, złożoność infrastruktury pozwalającej na prawidłowe działanie architektury systemów rozproszonych szybko rośnie.
Podobnie więc jak i w przypadku monolitów, mamy coś za coś.
Podsumowując, architektura mikroserwisów, to rozwiązanie dla firm, które potrzebują szybko wdrażać nowe zmiany i skalować swój biznes, i które potrzebują dużego systemu, który można rozłożyć na mniejsze moduły, po to, by autonomicznie je później rozwijać.
Chcesz przebudować swój system IT lub platformę danych?
Specjalizujemy się w tym temacie w Transparent Data. Napisz do nas https://transparentdata.pl/
Mogą zainteresować Cię również:
