Szaleństwo mikroserwisów

Na początku należałoby jednak znaleźć odpowiedź na jeszcze inne pytanie: skąd taka popularność architektury mikroserwisowej? Odpowiedź wydaje się dosyć prosta: programiści zazwyczaj nie przepadają za rozwojem i utrzymaniem dużych, ciężkich projektów, a idea mikroserwisów zakłada rozwój niezależnych, małych projektów, nic więc dziwnego, że dla wielu z nich wydaje się być strzałem w dziesiątkę.

Mikroserwis, czyli czy rozmiar ma znaczenie

Ale co to właściwie znaczy, że pojedynczy mikroserwis jest mały? W Internecie można znaleźć wiele absurdalnych pomysłów na ten temat. Jedni uważają, że mikroserwis powinien mieć nie więcej niż tysiąc linii kodu. Inni, że zespół, który go tworzy, powinien być w stanie go napisać, żywiąc się przy tym jedynie trzema pizzami. Inny pomysł jest taki, że mikroserwis powinien być na tyle mały, żeby można go przepisać w ciągu jednego scrumowego sprintu, czyli około dwóch tygodni. Ja osobiście uważam, że mikroserwis powinien być tak mały, jak to możliwe i tylko tak duży, jak to jest absolutnie niezbędne.

Oczywiście rozmiar to tylko jeden z aspektów, który opisuje mikroserwisy. Mikroserwis poza tym powinien cechować się także pojedynczą odpowiedzialnością, czyli być zbudowany w oparciu o pojedynczą domenę biznesową. Jego implementacja powinna być ukryta, czyli komunikacja pomiędzy mikroseriwsami powinna się odbywać wyłącznie w oparciu o ustalony kontrakt. Kolejne cechy to niezależność wdrażania oraz odporność na awarie. Ta ostatnia cecha oznacza, że awaria jednego mikroserwisu nie powinna wpływać na pozostałe.

Microserwis vs aplikacja monolityczna

Jeśli weźmiemy pod uwagę jedynie powyższe cechy, możemy dojść do pochopnego wniosku, że mikroserwisy w porównaniu do tradycyjnej, monolitycznej architektury, rzeczywiście zawsze wypadają znacznie lepiej. Programiści dostają to, czego chcieli, ale i biznes powinien być usatysfakcjonowany, ponieważ dostaje skalowalną i odporną na awarie aplikację. Niestety jest tak głównie w teorii, ponieważ praktyka przynosi wiele problemów i zagrożeń.

Ograniczenia architektury mikroserwisowej

Największe wyzwanie związane z architekturą mikroserwisową dotyczy spójności danych. W systemach rozproszonych nie jest możliwe jednoczesne osiągnięcie spójności, dostępności i odporności na podział, musimy zawsze dokonać wyboru dwóch z pośród tych trzech cech. Jeżeli założymy, że w aplikacjach rozproszonych zawsze występuje podział sieci i odporność na nią musi być zapewniona, to do wyboru pozostaje spójność lub dostępność. W praktyce najczęściej wybierana jest dostępność kosztem spójności, co oznacza problemy dla biznesu, ponieważ może występować czasowa niespójność danych. Możliwe jest również utrzymanie spójności, ale bez gwarancji, że system będzie zawsze dostępny w 100%.

Przeczytaj także: Wykorzystujesz mikroserwisy? Poznaj Service Mesh i nowe możliwości, jakie daje!

Błędne założenia

Dodatkowo w dobie popularnych i ogólnodostępnych chmur obliczeniowych zbyt wiele osób zapomina o komunikacji sieciowej i problemach, jakie może ona stwarzać. Dwie aplikacje, które się ze sobą komunikują, nie robią tego w sposób magiczny. W tej komunikacji trzeba uwzględnić co najmniej kilka zagrożeń, które niestety zazwyczaj są bagatelizowane. Najczęściej występujące błędne założenia, dotyczące komunikacji między aplikacjami, zostały wskazane przez L. Petera Deutscha:

• Sieć jest niezawodna.
• Opóźnienie wynosi zero.
• Przepustowość jest nieskończona.
• Sieć jest bezpieczna.
• Topologia się nie zmienia.
• Jest jeden administrator.
• Koszt transportu wynosi zero.
• Sieć jest jednorodna.

Jeżeli powyższe błędne założenia o sieci nie zostaną zweryfikowane i aplikacja rozproszona nie zostanie na nie odpowiednio przygotowana, to z dużym prawdopodobieństwem problemy w komunikacji pomiędzy mikroserwisami pojawią się szybciej niż się tego spodziewamy.

Mikroserwisy czy rozproszony monolit?

Jest jeszcze jeden często pojawiający się problem. Jak napisałem na początku tego artykułu, każdy mikroserwis powinien być związany z pojedynczą odpowiedzialnością, czyli być związany ściśle z określoną domeną biznesową. Ale nowo tworzone systemy mają to do siebie, że wymagania względem nich często się zmieniają, co może powodować zamazywanie granicy pomiędzy poszczególnymi mikroserwisami, poprzez migrację wzajemnych odpowiedzialności. Skutek jest taki, że system składa się wprawdzie z wielu mikroserwisów, ale każdy z nich odpowiada za wszystko. Nie ma to oczywiście nic wspólnego z aplikacją mikroserwisową, powstaje natomiast rozproszony monolit.

Od monolitu do mikroserwisów

Celem tego artykułu nie było przekonanie czytelnika do tego, że mikroserwisy są dobre lub złe, ale uświadomienie, jakie problemy mogą powodować. A także tego, że przejście z architektury monolitycznej na mikroserwisową nie rozwiązuje z automatu wszystkich problemów, a jedynie przenosi je w inne miejsce. Z drugiej jednak strony, jeżeli podejdziemy do mikroserwisów w sposób odpowiedzialny i przemyślany, to może się to okazać bardzo dobry wybór. Uważam jednak, że w przypadku nowych projektów warto rozważyć rozpoczęcie od monolitycznej architektury i przejście na mikroserwisową po wstępnej fazie rozwoju aplikacji, kiedy główne wymagania nie będą się już zmieniać tak często, a granica pomiędzy domenami nie będzie przesuwana. Zawsze bowiem łatwiej będzie nam wydzielić domeny i określić granice w monolicie, czyli czymś, co już istnieje, niż dzielić coś, czego jeszcze nawet nie ma.