Mikroserwisy to termin określający architekturę aplikacji i sposób ich pisania. W odróżnieniu od monolitycznych rozwiązań, których zasada działania opiera się na rozmieszczeniu poszczególnych części aplikacji w jej wnętrzu (z wykorzystaniem relacyjnego modelu danych), mikroserwisy dzielą je na mniejsze, niezależne od siebie komponenty.
Mikroserwisy są zatem oddzielnymi częściami tej samej aplikacji – komponentami lub procesami. Umożliwiają programistom pracę nad elementami aplikacji bez ingerencji w jej całą architekturę. Przyspieszają proces tworzenia oprogramowania, czynią aplikację lżejszą. Zapobiegają awarii całego systemu (jeśli pojawi się problem, to tylko w jednym komponencie).
Mikroserwisy są ściśle powiązane z architekturą kontenerową. To właśnie dzięki kontenerom możliwe jest sprawne zarządzanie mikrousługami i w związku z tym stworzenie aplikacji opartej na współpracujących ze sobą serwisach (modułach).
Geneza powstania mikroserwisów
Problemy związane z aplikacjami monolitycznymi zostały zauważone jeszcze na długo przed wdrożeniem mikroserwisów. Pierwszą próbą ich rozwiązania była architektura zorientowana na usługi, czyli SOA (Service Oriented Architecture).
SOA miała takie same założenia jak mikroserwisy. Chodziło o to, aby rozbić rozbudowany system na mniejsze, współpracujące ze sobą usługi. Wdrożenie takiej architektury wymagało jednak wykorzystania szyny integracyjnej, czyli ESB (Enterprise Service Bus). Ta odpowiadała za całą masę procesów m.in.: routing, mapowanie i audytowanie. Niestety, właśnie wielozadaniowość ESB stała się jej największą wadą. Szyny zaczęły się przeradzać w kolejną aplikację monolityczną, przez co architektura SOA przestała się dłużej sprawdzać.
Mikroserwisy są de facto ulepszoną wersją SOA. Dzięki postępom w technologii kontenerowej spełniają założenia architektury zorientowanej na usługi, ale jednocześnie nie implementują problemów wynikających z wykorzystania modelu ESB.
Jakie problemy rozwiązują mikroserwisy?
Mikroserwisy są przede wszystkim sposobem na zwiększenie wydajności. W przypadku aplikacji monolitycznych proces realizacji usług wymaga bowiem uwzględniania mnóstwa zależności. To znacznie wydłuża czas pracy nad aplikacją i ogranicza skalowalność.
Ponadto, zaprojektowanie całego modelu danych jest niemałym wyzwaniem. Aplikacje budowane w ten sposób mogą powstawać tak długo, że w połowie pracy konieczne stanie się wprowadzenie początkowo nieprzewidzianych zmian. W efekcie trzeba powtórzyć prace na całym modelu. Biznesowo jest to nieopłacalne.
Dużą bolączką systemów opartych na relacyjnym modelu danych są też awarie. Ze względu na relacyjność wszystkim elementów wystarczy awaria jednego, aby aplikacja przestała działać. Wykorzystując mikroserwisy, można się natomiast skupić tylko na tym elemencie, który działa wadliwie.
Warto też podkreślić, że każdy mikroserwis, chociaż działa niezależnie, współpracuje z pozostałymi komponentami nawet, gdy wykorzystuje inne języki czy technologie. Jak to się ma do aplikacji monolitycznych? Nad mikroserwisami można pracować w bardzo zróżnicowanym zespole, który wykorzystuje niejedną technologię i język. Taka różnokierunkowość nie jest możliwa w tradycyjnej architekturze.
Korzyści biznesowe z mikroserwisów
- zapewniają większą kontrolę nad długiem technicznym
- zmniejszają ryzyko zatrzymania pracy nad całą aplikacją z powodu awarii jednego elementu
- zwiększają stabilność systemu
- umożliwiają wybór technologii
- przyśpieszają wdrażanie usługi
- zapewniają skalowalność
- obniżają koszty (poprzez skrócenie cyklu produkcyjnego)
Kiedy mikroserwisy się nie sprawdzają?
Mikroserwisy są rozwiązaniem, które ma wiele zalet, ale należy podkreślić, że ich wdrożenie wymaga ogromu pracy. Jest to szczególnie zauważalne w zmianach organizacyjnych, które należy wprowadzić w zespole. Aby mikroserwisy się sprawdziły, trzeba bowiem zmienić nie tylko sposób pracy aplikacji, ale też sposób pracy ludzi. Jednostki biznesowe muszą zacząć autonomiczną realizację projektów i zapomnieć o większości aspektów tradycyjnego modelu pracy. Co więcej, praca w imię zasady “design for failure” jest koniecznością.
Należy też podkreślić, że liczba mikroserwisów, chociaż nie zawsze są to systemy naprawdę mikro, nie powinna być zbyt duża. Aby usługi się ze sobą komunikowały i dobrze działały w rozproszeniu, warto tę sprawę poważnie przemyśleć. Niektórzy wpadają w pułapkę setek mikroserwisów, których sprawna obsługa jest prawie niemożliwa, a poziom SLA pozostawia wiele do życzenia. To droga donikąd.
Kiedy wdrażać mikroserwisy?
Mikroserwisy mają albo wielkich fanów, albo zagorzałych przeciwników. Brak porozumienia między tymi grupami wynika z niejednorodności tego typu architektury. Z jednej strony zapewnia ona wiele korzyści biznesowych, ale może też okazać się wyzwaniem nie do sprostania.
Jak temu zapobiec? Przede wszystkim warto skorzystać z usług wdrożeniowych doświadczonej w tym zakresie firmy. Zespół specjalistów wybierze najlepszą opcję dla Twojego biznesu i możliwe, że nie zawsze będą to mikroserwisy. Można też pomyśleć nad hybrydą, czyli nad zastosowaniem monolitycznej architektury tam, gdzie ma to sens. Tyczy się to np. transakcji biznesowych, które ze względu na swój charakter aktualizują wiele jednostek, a to wymaga spójności programowej. W pozostałych przypadkach można zaś oprzeć pracę na technologii mikroserwisów.
