Mikrousługi to model tworzenia aplikacji, który coraz bardziej wypiera tradycyjną architekturę monolityczną. Zapewnia systemom większą elastyczność i ułatwia ich skalowanie. Pozwala również zmniejszyć koszty developmentu. Na czym polegają oba podejścia, jakie są ich zalety i wady oraz jak uwolnić się od uciążliwości związanych z architekturą monolityczną?

Wyobraź sobie dwa zamki z klocków Lego. W jednym klocki sklejone są super glue, w drugim – nie. A teraz pytanie za sto punktów: który zamek łatwiej będzie przebudować? Nie jest to pewnie najbłyskotliwsza ani najtrafniejsza analogia, ale w zgrubnym zarysie oddaje kluczowe różnice między architekturą monolityczną a architekturą mikroserwisów. Mówiąc bez metafor: oprogramowanie projektowane zgodnie z tą pierwszą jest trudniejsze do modyfikowania i skalowania niż software tworzony w schemacie mikroserwisów.

Mikroserwisy kontra monolity

Architektura monolityczna to model tradycyjny. Polega na umieszczeniu wszystkich funkcji oprogramowania w jednej bazie kodu i wdrażaniu ich jako pojedynczego pliku. System monolityczny obsługiwany jest więc przez jedną aplikację, która stanowi efekt żmudnej pracy wielu współpracujących ze sobą developerów.

W ten sposób tworzono oprogramowanie przez wiele lat – i nadal się je tak tworzy. Aplikacje monolityczne są szeroko rozpowszechnione zarówno jako systemy legacy (zastane) – czyli wdrożenia już istniejące, stworzone według klasycznego standardu – jak i nowe projekty, budowane od podstaw.

Jednak od pewnego czasu na popularności zyskuje inne podejście: mikrousługi, zwane również mikroserwisami. Ma ono liczne przewagi nad modelem monolitycznym, choć uznawane jest za bardziej złożone i trudniejsze do wdrożenia, przynajmniej na początkowym etapie developmentu. W zaawansowanej fazie rozwoju aplikacji wydaje się jednak nieuchronne – zarówno ze względu na stabilność systemu, jak i koszty jego utrzymania i skalowania.

Nieelastyczne i nieprzewidywalne. Wady aplikacji monolitycznych

Powodów, by zastąpić aplikację monolityczną mikrousługami, jest sporo. Kluczową kwestią jest elastyczność tego drugiego rozwiązania i „sztywność” tego pierwszego. Mankamenty monolityczności mogą dać o sobie znać na rozmaite sposoby. Główne obciążenia związane z tą architekturą są następujące:

• elementy składowe aplikacji są ze sobą ściśle powiązane, więc drobne zmiany mogą wywierać wpływ na całość kodu,
• w efekcie pojedyncze błędy mogą zakłócić działanie całego systemu,
• a wprowadzenie nawet nieznacznych modyfikacji wymusza ponowne wdrożenie całej aplikacji,
• duża aplikacja monolityczna jest trudna do zrozumienia i „ogarnięcia”, co spowalnia wprowadzanie zmian i zwiększa ryzyko pomyłek,
• skutki zmian są często trudne do przewidzenia, co rodzi konieczność prowadzenia dłuższych i dokładniejszych testów,
• aplikacje monolityczne są trudniejsze do skalowania, szczególnie w sytuacji, gdy ich poszczególne moduły mają sprzeczne wymagania dotyczące zasobów,
• nie ma możliwości skalowania poszczególnych komponentów – konieczne jest skalowanie całej aplikacji,
• złożoność aplikacji monolitycznej sprawia, że zarządzanie systemem w miarę wzrostu bazy kodu jest coraz trudniejsze,
• z tego samego powodu do pracy nad monolitem trudniej jest wdrożyć nowych programistów – co jest szczególnie problematyczne w świetle faktu, że developerzy chętnie zmieniają firmy i projekty.

Skalowalność i łatwość modyfikacji. Jak działają mikrousługi i jakie problemy rozwiązują?

To oczywiście tylko uogólnione zestawienie problemów, jakie mogą generować aplikacje monolityczne. Mankamenty tej architektury mogą się „skonkretyzować” na niezliczoną ilość sposobów. Tymczasem mikrousługi są wolne od większości słabości charakterystycznych dla monolitów ze względu na zupełnie odmienny schemat działania.

Model mikrousługowy polega na rozbiciu poszczególnych funkcji aplikacji na mniejsze, powiązane ze sobą komponenty. W praktyce każda mikrousługa stanowi odrębną aplikację opartą na logice biznesowej odseparowanej od zewnętrznych zależności. Zastosowanie mikroserwisów pozwala na rozbicie nawet bardzo dużego systemu na mniejsze, autonomiczne części.

W efekcie skalowanie i modyfikowanie aplikacji staje się znacznie prostsze, ponieważ nie trzeba przerabiać jej od podstaw – wystarczy rozwijać lub przekształcać poszczególne jej składowe. W tej sytuacji odpada problem rozgryzania skomplikowanej całości i wdrażania nowych developerów do pracy nad systemem. Wystarczy określić zakres działania, np. dodanie lub modyfikację konkretnej funkcji, i przystąpić do kodowania – bez obaw, że w trakcie pracy, wskutek przypadkowego błędu, „posypie się” cały system.

Mikrousługi stanowią odpowiedź na szereg wyzwań, z którymi nie radzą sobie aplikacje monolityczne. Ułatwiają rozwijanie złożonych systemów i wdrażanie nowych funkcji, skracają czas pracy, a więc i koszt zatrudnienia developerów. Zmniejszają również prawdopodobieństwo wystąpienia i przeoczenia błędów, które nieuchronnie pojawiają się podczas programowania. Łatwiej jest kodować i testować poszczególne, niezależne od siebie moduły niż „prześwietlać” złożony, monolityczny system po update'cie.

Architektura monolityczna dobra na start? Przejście do mikrousług jest nieuchronnne

Nie znaczy to, że monolity skazane są na śmietnik historii i należy unikać ich jak koronawirusa. Istnieje kilka argumentów przemawiających za korzystaniem z tego typu aplikacji – w określonych okolicznościach. To przede wszystkim rozwiązanie dobre na start. Jest łatwiejsze do zastosowania niż mikroserwisy na etapie tworzenia aplikacji, ponieważ wdrażane jest jako jeden plik, bez podziału na moduły.

Z tego samego powodu niewielkich rozmiarów aplikacja monolityczna może być również bardziej wydajna niż system stworzony na bazie mikroserwisów. Jest również łatwiejsza do wprowadzenia na rynek niższym kosztem i w krótszym czasie. Jednak w miarę rozwoju systemu jego monolityczność staje się obciążeniem, a architektura mikrousługowa – rozwiązaniem coraz bardziej pożądanym.

Na szczęście w takiej sytuacji nie trzeba tworzyć systemu od podstaw. Wiele firm stosuje podejście hybrydowe, łącząc oba modele: architektura monolityczna ma zastosowanie tam, gdzie jest to niezbędne, a przynajmniej nieuciążliwe, zaś mikrousługi wdrażane są z myślą o skalowaniu systemu i tworzeniu nowych funkcji. Oczywiście tego typu „innowacje” powinny być poprzedzone skrupulatną analizą potrzeb i możliwości. Nie chodzi o to, by wdrażać mikroserwisy na wszelki wypadek lub na fali mody, ale w konkretnym, uzasadnionym celu.

Jak rozbić aplikację monolityczną na mikrousługi?

Alternatywą dla modelu hybrydowego jest rozbicie aplikacji monolitycznej na mikroserwisy. Choć brzmi to jak ryzykowne przedsięwzięcie, w istocie jednak chodzi o proces relatywnie łatwy do wdrożenia dzięki zastosowaniu odpowiednich narzędzi. Jednym z dostępnych rozwiązań jest usługa Amazon Elastic Container Service (Amazon ECS).

Pozwala ona na uruchomienie aplikacji monolitycznej w trybie mikroserwisów po jej uprzedniej konteneryzacji za pomocą platformy Docker – oprogramowania do tworzenia, wdrażania i uruchamiania aplikacji rozproszonych. Dzięki zastosowaniu Dockera aplikacja wraz z jej zależnościami zostaje umieszczona w wirtualnym „pojemniku” (kontenerze), który można uruchomić na niemal dowolnym serwerze z systemem Linux lub w usługach takich, jak ECS.

Konteneryzacja aplikacji monolitycznej pozwala na wyodrębnienie z monolitu poszczególnych usług i swobodne nimi zarządzanie – wraz ze wszelkimi zaletami tego podejścia, takimi jak:

• izolacja ryzyka,
• zwiększenie bezpieczeństwa,
• zapewnienie możliwości niezależnego skalowania poszczególnych usług czy
• przyspieszenie tempa rozwoju aplikacji.

Amazon ECS to rozwiązanie, które pozwala na uwolnienie się od obciążeń systemów legacy bez konieczności przebudowywania ich od podstaw. Jeśli szukasz firmy, która pomoże ci uporać się ze słabościami aplikacji monolitycznych i wykorzystać potencjał, jaki zapewnia architektura mikrousług, skontaktuj się z nami!

Zapewniamy specjalistyczne wsparcie przy migracji do chmury Napisz do nas