Dawid Wieczorek | Rozwój oprogramowania | 10.11.2021
Mikroserwisy są odpowiedzią na problemy związane z tworzeniem i utrzymaniem monolitycznych systemów. W czasie, gdy aplikacje muszą być stale rozwijane, a jednocześnie dostępne dla użytkowników, mikrousługi stają się state-of-the-art w rozwoju oprogramowania. W jakich projektach się sprawdzą, a w których rozsądniej jest pozostać przy konstrukcji monolitu?
Idź do:
Pojęcie architektury mikroserwisowej pojawiło się po raz pierwszy na scenie IT w okolicach roku 2013. Od tego czasu jej popularność wydaje się poruszać tylko w jednym kierunku – w górę! Potwierdzenie takiej hipotezy możemy znaleźć na przykład w raporcie „Microservices adoption” przygotowanym przez firmę O’Reilly w roku 2020, z którego wynika, że 77% firm, w których pracują respondenci, stosują taką architekturę. Jednocześnie aż 92% pytanych określiło zastosowanie mikroserwisów jako sukces z perspektywy oczekiwanych zysków, które przynosi takie podejście.
W innej ankiecie przeprowadzonej przez IBM Market Development & Insights o opinię zapytanych zostało ponad 1200 osób z branży IT, w tym dyrektorzy techniczni, menedżerowie i programiści pracujący w firmach, które stosują lub planują zastosować architekturę mikroserwisową.
Wyniki są jednoznaczne:
Chociaż jest to oczywiście bardzo wątpliwa miara, z własnej perspektywy programisty – sądząc po opisach projektów w ofertach pracy – mógłbym stwierdzić, że praktycznie większość projektów jest aktualnie tworzona w architekturze mikroserwisowej. Pomimo że na takie opisy musimy spojrzeć z przymrużeniem oka, widać, że mikroserwisy szybko stają się standardem w świecie IT.
Jednym z największych wyzwań architektury mikroserwisowej jest silna zależność od infrastruktury (serwerowej, sieciowej itp.), a co za tym idzie – zwiększona potrzeba inwestycji w jej tworzenie. Jeszcze kilka lat temu było to jednak dużo większym wyzwaniem niż dzisiaj. W odpowiedzi na potrzeby nowego modelu powstał szeroki wachlarz narzędzi, które usprawniają pracę w rozproszonym środowisku.
Inną istotną zmianą, która pojawia się wraz z rozwojem mikroserwisów, jest obecność sieci jako niestabilnego elementu, którego nie da się uniknąć. Każdy programista musi w końcu poradzić sobie z problemami sieciowymi, zarówno jeśli chodzi o transport, jak i o znacznie bardziej złożone narzędzia wymagane do debugowania.
Wspomniane wyżej narzędzia wspierające pracę i debugowanie aplikacji kontenerowej również przeżyły rozkwit i dzisiaj możemy wspierać się narzędziami do monitorowania, logowania i tracingu. Rozwiązania takie jak Prometheus, ELK czy AWS CloudWatch pozwalają sprostać wyzwaniom utrzymywania lub debugowania aplikacji w rozproszonym środowisku.
Powstanie i ostateczny sukces mikroserwisów nie wziął się oczywiście z niczego. Jest to raczej odpowiedź na trudności związane z klasycznym podejściem, które w wielu przypadkach przeważają nad plusami podejścia monolitycznego.
Z perspektywy biznesowej możemy wymienić wiele wad, które mogą wpłynąć na doświadczenia użytkowników i tym samym – na ostateczny sukces aplikacji:
Patrząc z perspektywy developera pracującego nad monolitem, możemy dodatkowo wymienić jeszcze kilka wad:
Przejdźmy teraz do możliwości i udogodnień dostępnych przy wykorzystaniu mikroserwisów.
Z zastosowaniem mikroserwisów łączy się też kilka pozytywów dla pracujących z nimi developerów:
Większość korzyści płynących z zastosowania architektury rozproszonej jest efektem stworzenia prawidłowego podziału odpowiedzialności poszczególnych usług i wyznaczenia sposobu komunikacji między nimi. Celem jest stworzenie silnej spójności serwisów i jednocześnie luźnego powiązania pomiędzy nimi. Innymi słowy, rzeczy, które zwykle wymagają wspólnej zmiany, powinny należeć do jednego serwisu. Bez odpowiedniego podziału zamiast korzyści, jak niezależna implementacja czy skalowalność usług, możemy skończyć z niewydajnym lub trudnym w utrzymaniu projektem. W praktyce jest to oczywiście trudniejsze do zrealizowania niż w teorii – wstępne założenia lub późniejsze wymagania ulegają zmianie. Z tego powodu możliwość łatwego wprowadzania zmian jest kolejnym krytycznym aspektem podczas projektowania każdej aplikacji.
Podejście Domain-driven design (DDD) jest kluczowym narzędziem podczas projektowania architektury mikroserwisowej, tak przy rozbijaniu aplikacji monolitycznej, jak i tworzeniu aplikacji od zera.
DDD zapoczątkowane w książce Erica Evansa to zestaw zasad i wzorców, których celem jest wsparcie tworzenia aplikacji rozproszonych w oparciu o model domeny biznesowej będącej tematem tworzonego oprogramowania. Zespół programistów wraz z ekspertami domeny biznesowej tworzą model biznesowy w wypracowanym wspólnym języku, tzw. ubiquitous language. Następnie stworzony model jest tłumaczony na poszczególne usługi, ustalane są protokoły komunikacji między nimi oraz tworzone są zespoły odpowiedzialne za poszczególne serwisy. W całym procesie pomocny może być dodatkowo event storming. Wzorce DDD mają na celu ułatwienie zrozumienia domeny i zależności w niej zachodzących. Od tego już niedaleko do wyznaczenia granic w domenie, a tym samym wypracowania podziału na usługi zmapowane na domenę biznesową.
W istniejącej od wielu lat platformie e-commerce pojawiło się nowe wymaganie biznesowe, polegające na masowym tworzeniu nowych ofert na bazie plików. Narzędzie miało być głównie stosowane przez sprzedawców oferujących szeroki asortyment, którzy w ten sposób mogliby usprawnić i zautomatyzować interakcję z platformą w kwestii tworzenia i edycji swoich ofert.
Wspomniana platforma, chociaż została stworzona jako monolit, od dawna jest już rozbita i rozwijana w architekturze mikroserwisowej. Zadanie zlecone jednemu z zespołów JCommerce polegało więc na stworzeniu nowej mikrousługi (ostatecznie powstało ich kilka) odpowiedzialnej za realizację tej funkcjonalności. Prace nad rozwiązaniem postępowały bez ingerencji w resztę usług aplikacji, której rozwój mógł postępować niezależnie. Jedynym punktem styku z resztą platformy stała się inna mikrousługa, a szczegóły komunikacji i implementacji zostały ustalone pomiędzy zespołami odpowiedzialnymi za obie usługi. Również decyzje o wyborze technologii (jak baza danych czy nawet język programowania) pozostawały w dużej mierze w gestii zespołu. Po wdrożeniu na produkcję zespół JCommerce jest w stanie dynamicznie skalować ilość instancji usługi adekwatnie do liczby zapytań od użytkowników.
Taka autonomia jest kluczowa przy rozwoju aplikacji, nad którą kolektywnie pracują nawet setki zespołów. Trudno sobie wręcz wyobrazić skuteczne wdrożenie takiej funkcjonalności, gdyby cala platforma była nadal monolitem.
Odpowiedź na to pytanie musi być niestety wymijająca – to zależy. Decydując się na dany model, akceptujemy kompromis, czyli przyjmujemy go razem z jego mocnymi i słabymi stronami.
Jeżeli rozważamy rozbicie istniejącej aplikacji monolitycznej, decyzja jest może prostsza, zmotywowana wszystkimi bolączkami, które nastręcza monolit. W tym przypadku jednym ze sprawdzonych podejść jest odcinanie mniejszych serwisów z głównego bloku, aż w końcu nowe funkcjonalności będą mogły być tworzone w całkowitej izolacji, a mniejszy centralny monolit będzie stopniowo wygaszany.
Jeżeli jednak rozpoczynamy tworzenie aplikacji od zera, jednym z kluczowych względów, na którym możemy oprzeć decyzję, jest rozmiar docelowej aplikacji. W przypadku tworzenia MVP aplikacji, najważniejsza jest szybkość dostarczenia funkcjonalności kosztem innych priorytetów. Zgodnie z zasadą YAGNI (You Ain’t Gonna Need It) nie ma sensu inwestować w zastosowanie zbyt wyszukanych narzędzi, jeśli nie mamy pewności, że aplikacja będzie się cieszyć odpowiednim poziomem zainteresowania.
Taka sytuacja przemawia więc za zastosowaniem monolitu, który dopiero w dalszej fazie zostanie podzielony – ciekawym rozwiązaniem może być zastosowanie architektury tzw. modularnego monolitu, w której funkcjonalności rozbite są na poszczególne moduły tworzone w ramach jednej aplikacji.
Jeśli jednak wiemy, że rozmiary docelowej aplikacji uzasadniają wstępną inwestycję, wtedy architektura mikroserwisowa jest jak najbardziej rozsądnym wyborem.
Idź do:
Dodaj komentarz: