Wyobraźmy sobie, że mamy jeden olbrzymi plastikowy klocek o zwartej strukturze. Obok niego znajduje się klocek o takiej samej wielkości oraz tym samym kształcie, ale będący zlepkiem kilku mniejszych klocków.
W którym z klocków będzie nam łatwiej dokonać zmian? Tak właśnie można zobrazować monolit i mikroserwisy.
Zmiana skali biznesu a mikroserwisy
Mikroserwisy są odpowiedzią m.in. na problem nadążania za wzrostem biznesu, gdzie dotychczasowa architektura IT przestaje już wystarczać. Ale skalowanie takiej architektury nie należy do najprostszych – to skomplikowany proces, w którym zmieniamy ilość danych, liczbę interakcji i funkcjonalności.
Tym bardziej, że dane, które gromadzimy i przetwarzamy, są ogromne, a ich liczba ciągle wzrasta. Od pewnego czasu funkcjonuje nawet – cokolwiek idiotyczne – pojęcie „diety informacyjnej”, odnoszące się do ucieczki od natłoku informacji. Lecz w wypadku prowadzenia przedsiębiorstwa wszystkie dane (informacje) są na wagę złota.
Zobrazujmy to na przykładzie rejestru zamówień sklepu internetowego. Choć po pewnym czasie traci on na aktualności, jego przechowywanie jest ważne z punktu widzenia prowadzenia biznesu: rejestr może okazać się przydatny przy dokonywaniu późniejszych analiz, które usprawnią prowadzenie sprzedaży.
Wydaje się, że najprościej byłoby przenieść nieaktualny zbiór z zamówieniami do innego miejsca. Gdy korzystamy z monolitu, nie jest to jednak proste. Wszystko dlatego, że monolit jest zwartą strukturą, która zawiera więzy integralności. Powodują one, że wprowadzenie modyfikacji jest trudne, podobnie jak testowanie bądź skalowanie odrębnej części aplikacji.
Rozwiązaniem jest podzielenie monolitu na części, czyli stworzenie mikroserwisów, lecz oznacza to zmianę całej architektury – idą za tym oczywiście duże koszty i ryzyko.
Audytujemy. Badamy. Projektujemy.
Mikroserwisy – architektura
Problemy zaczynają się, kiedy firma tworzy nowe produkty czy usługi w obrębie monolitu – albo dodaje nowe funkcje lub modyfikacje do już istniejących usług. Prace z kodem okazują się wówczas czasochłonne.
Dlatego, zamiast tworzenia monolitu, bardziej praktycznym rozwiązaniem wydaje się podzielenie aplikacji na mniejsze elementy.
W tym celu przydzielamy każdemu zespołowi prace nad poszczególną, stosunkowo niewielką częścią aplikacji. To jak tworzenie wielkiej konstrukcji z klocków Lego, w którego trakcie dzieci lub dorośli w niewielkich grupach przygotowują oddzielnie każdy z jej elementów.
Czym są mikroserwisy?
Mikroserwisem nazwiemy małą aplikację, która dobrze wykonuje tylko jedno zadanie. To niewielki komponent, który można łatwo wymienić, niezależnie rozwijać i niezależnie instalować. Mikroserwis to część większego systemu, uruchomionego i działającego razem z innymi mikroserwisami dla osiągnięcia tego, co inaczej byłoby obsługiwane przez jedną dużą, samodzielną aplikację.
Definicja na podstawie książki „Mikrousługi” Susan J. Fowler.
Giganci wolą mikroserwisy
Nic więc dziwnego, że z budowy monolitycznych aplikacji zrezygnowali Amazon, Twitter, Netflix, eBaya i Uber. Wymienione firmy postawiły na architekturę mikroserwisów, bo zauważyły, że mają do ominięcia poważne przeszkody, które w swojej książce wymienia Susan J. Fowler:
- Niewystarczającą efektywność systemów.
- Wolne tempo rozwoju.
- Trudności z przyjęciem nowych technologii.
Susan J. Fowler przestrzega, że problemy pojawiają się, gdy próbujemy wdrożyć złożone systemy oprogramowania w dużej monolitycznej aplikacji. Doradza, by – mimo wspomnianego już ryzyka – w takiej sytuacji przyjąć architekturę mikroserwisów, tym bardziej, że mikroserwisy można wdrożyć w monolicie.
Dziś powszechne jest dzielenie aplikacji na trzy odrębne elementy: fronton (frontend), czyli stronę klienta, zaplecze (backend) oraz bazę danych. Współpracę między każdym z tych elementów Susan J. Fowler opisuje jako architekturę trójwarstwową:
Żądania są kierowane do aplikacji za pośrednictwem strony klienta, kod zaplecza realizuje główną pracę, a potrzebne dane, które muszą być składowane lub udostępniane (bez względu na to, czy tymczasowo w pamięci, czy trwale w bazie danych) są wysyłane lub pozyskiwane z miejsc, w których są przechowywane dane. Nazywamy to architekturą trójwarstwową”.
Susan J. Fowler, „Mikrousługi”
Wyzwania programistyczne a mikroserwisy na przykładzie software house’u
Dla dodatkowego zobrazowania, jak pomocne są mikroserwisy, przytoczmy przykład młodego software house’u, który początkowo zatrudnia niewielu pracowników i tworzy proste aplikacje, a liczba zleceń pokrywa się z zasobami ludzkimi, którymi dysponuje firma.
Ale już po paru latach działalności biznes znacznie się rozrasta i zyskuje coraz więcej klientów. Dlatego pojawiają się nowi pracownicy, zaś aplikacje zyskują dodatkowe funkcjonalności. Wiążą się z tym wszystkim nowe wyzwania.
Susan J. Fowler w pierwszej kolejności wymienia wzrost obciążenia związanego z uruchamianiem i utrzymaniem aplikacji. Idzie za tym zazwyczaj konieczność zatrudnienia np. administratorów systemów, którzy biorą na siebie większość wezwań związanych ze sprzętem i obsługą. Kolejnym, oczywistym już elementem jest to, że wraz z dodawaniem nowych funkcji do aplikacji zwiększa się jej złożoność i liczba wierszy kodu.
Trzeci element odnosi się do wzrostu ruchu, który wymusza zwiększoną skalowalność i wydajność aplikacji – idzie za tym potrzeba użycia większej liczby serwerów, dlatego tak dobrym rozwiązaniem jest chmura, gdzie nasza informacja zostaje podzielona na mniejsze części i każda z nich przechowywana jest na innym serwerze.
Wraz z nowymi funkcjami i pozostałymi zmianami w aplikacji jej kod ogromnie się rozrasta. Susan J. Fowler przestrzega, że oznacza to konieczność napisania setek albo tysięcy testów, których celem byłoby sprawdzenie, czy wprowadzone zmiany nie naruszają integralności istniejących już tysięcy wierszy kodu. I to, nawet jeśli wspomniane zmiany polegają tylko na przekształceniu jednej lub dwóch linijek kodu.
Mikroserwisy a monolit
Tworząc architekturę mikroserwisu, naszym zadaniem jest stworzenie zbioru małych aplikacji, z których każda będzie odpowiedzialna za wykonanie jednej funkcji.
Podstawowa różnica między monolityczną aplikacją a mikroserwisem polega na tym, że monolityczna aplikacja zawiera wszystkie cechy i funkcje w jednej aplikacji i jednej bazie kodu. Co więcej, są one instalowane w tym samym czasie, każdy serwer jest zaś hostem dla kompletnej kopii aplikacji. Z kolei mikroserwis zawiera tylko jedną funkcję lub cechę i funkcjonuje w ekosystemie mikroserwisów wraz z innymi mikroserwisami, z których każda realizuje jedną funkcję lub cechę funkcjonalną.
Mikroserwisy – zalety
Na koniec przyjrzyjmy się pozytywom, które idą za mikroserwisami:
- Zmniejszenie długu technicznego.
- Poprawa wydajności pracy programistów.
- Lepsza wydajność testowania.
- Zwiększona skalowalność i łatwość wdrażania.
- Poradzenie sobie z wyzwaniami skalowalności i problemami organizacyjnymi.
Fot. główna: FonsoSac / Flickr.com
