Mikrousługi - styl architektoniczny, który z różnych względów zyskiwał w ostatnich latach - a może nadal zyskuje - na popularności. Jedną z obietnic tego stylu była możliwość zapanowania nad złożonością systemów poprzez dzielenie ich na luźno powiązane ze sobą usługi.

Tymczasem, w Internecie pojawiały się, przy różnych okazjach, ilustracje przedstawiające diagramy zależności pomiędzy usługami wytwarzanymi w systemach, często przez znane i duże organizacje.

Netflix

Amazon

Jeśli porównać to z często przytaczaną w literaturze ilustracja zależności pomiędzy klasami w przypadku antywzorca “Wielkiej Kuli Błota”, widać znaczące podobieństwa.

Jaki z tego może płynąć dla nas wniosek? Ano taki, że jeśli mamy do czynienia ze złożoną dziedziną, to system, który tę logikę modeluje (lub tworzy - mamy XXI w.) również będzie złożony. Ta nie zniknie jeśli zmienimy medium komunikacji np. wewnątrzprocesowe wywołania metod zamienimy na zdalne wywołania punktów końcowych REST API.

Rozważając mikrousługi jako styl architektoniczny dla opracowywanego systemu należy - oprócz licznych zalet przytaczanych szeroko w literaturze - brać pod uwagę liczne wady tego rozwiązania np.:

• Przeniesienie komunikacji z wnętrza procesu na infrastrukturę sieciową (implikacje wydajnościowe, koszt infrastruktury),

• Utraty potężnych sprzymierzeńców w zapewnianiu jakości architektury w postaci narzędzi do statycznej i dynamicznej analizy kodu źródłowego (pojawiają się zastępniki w świecie mikrousług, jednak użycie ich - 2 rzędy wielkości trudniejsze niż uruchomienie przystawki w środowisku IDE),

• W kontekście wdrożenia w chmurze w modelu PaaS - nieprzewidywalność kosztową oraz stromą, liniową zależność pomiędzy złożonością architektury, a kosztem utrzymania infrastruktury.

W kontekście tego ostatniego punktu zaszła tutaj, przeoczona chyba przez szeroko rozumianą “branżę IT”, zmiana:

Wdrażając rozwiązania w Chmurze Obliczeniowej, zwłaszcza w modelu PaaS, płacimy (jak chętnie powtarzają nam to dostawcy) “tylko za to co używamy”. Zapominamy tylko, że dochodzi nam kolejny wymiar owego “używania”. Płacimy bowiem za każdą powołaną do życia mikrousługę, co przy ich liczbie idącej w dziesiątki lub setki oraz wymaganiom redundancji może iść już w grube dziesiątki lub setki tysięcy złotych miesięcznie.

Zależność taka w zasadzie nie zachodzi w przypadku korzystania z chmury w modelu IaaS oraz stylach architektonicznych z mniejszą ilością kwantów architektury np. Monolit, monolit rozproszony / modułowy, SOA itp.

Wszystko to - w mojej ocenie - wskazuje na to, że do tego stylu architektonicznego należy podchodzić z dużą ostrożnością i że nie jest to w żadnym wypadku domyślne podejście, w którym powinniśmy projektować nowe rozwiązania. Do takiego podejścia przekonują nas liczni publicyści technologiczni, często powiązani z dostawcami Chmury Obliczeniowej.