Mikrousługa ang. Microservices

Mikrousługi posiadają trzy najbardziej istotne cechy odróżniające je od innych usług. Według O’Reilly mikrousługi są:

• niewielkie, dzięki czemu wprowadzanie zmian jest łatwe i obarczone małym ryzykiem. Jon Eaves z firmy RealEstate.com.au z Australii uważa, że kod mikrousługi można przepisać w dwa tygodnie, co odpowiada czasowi trwania przeciętnego sprintu, podczas którego Zespół powinien dostarczyć działający fragment kodu.
• autonomiczne, co oznacza, że każda jest odrębnym podmiotem, czyli może być wdrożona jako odizolowana usługa w ramach infrastruktury PaaS (ang. Platform as a Service) lub może być procesem systemu operacyjnego. Mikrousługi muszą pozwalać na wprowadzanie zmian niezależnie od innych usług oraz pozwalać na odrębne wdrażanie — bez konieczności zmiany konsumentów.
• zdecentralizowane, czyli nie ma scentralizowanego zarządzania mikrousługami, co powoduje, że każda z nich może być przygotowana w innym języku programowania oraz może używać innej technologii przechowywania danych.

Praktyka budowania systemów w oparciu o mikrousługi opiera się na wcześniejszym wykorzystaniu takich technik jak (źródło: O’Reilly "Budowanie mikrousług", Wyd. Helion, 2015 r.):

• projektowanie tematyczne (ang. domain-driven design — DDD) modelowanie oparte na reprezentowaniu w kodzie rzeczywistego świata;
• ciągłe dostarczanie (ang. continuous delivery) czyli skuteczne i wydajne wdrażanie tworzonego oprogramowania;
• struktury sieciowe – komunikowanie się maszyn oparte na koncepcji WWW;
• architektura sześciokątna – jako alternatywa architektury warstwowej, pozwalającej ukryć logikę biznesową;
• wirtualizacja na żądanie – platformy pozwalające na konfigurowanie i i zmianę rozmiarów maszyn;
• automatyzacja infrastruktury;
• małe, autonomiczne zespoły odpowiedzialne za pełny cykl życia swoich produktów;
• elastyczne systemy (ang. antifragile), które można obecnie budować w dużej skali.

Wykorzystanie rozwiązań opartych o mikrousługi wiąże się z konkretnymi korzyściami dla firmy, która takie rozwiązanie stosuje: (źródło: Onwelo Microservices Lab)

• obniżenie kosztów nawet o 60%;
• zwiększenie tempa pracy nad wprowadzaniem nowych rozwiązań (produktów i usług);
• nawet 10-krotnie bardziej efektywne wykorzystanie infrastruktury IT;
• redukcja czasu potrzebnego na wprowadzenie rozwiązania na rynek (Time to Market)
• sprawne dopasowanie się do zmian i potrzeb rynku.

Podejście do budowy aplikacji bazujące na mikrousługach można uznać za styl architektoniczny alternatywny względem monolitycznego, co trafnie zauważył Martin Fowler (źródło: Andrzej Sobczak: Mikrousługi (Microservices) – faktyczna nowość, czy kolejny buzzword? ArchitekturaKorporacyjna.pl). Architektura oparta o mikrousługi pozwala na uniknięcie takich wad systemów monolitycznych jak:

• złożony kod, w którym wprowadzanie zmian jest trudne i wiąże się z dużym ryzykiem,
• konieczność tworzenia rozległej dokumentacji pozwalającej na utrzymanie przez duże zespoły,
• narastający w miarę rozwoju systemu brak spójności kodu,
• konieczność rygorystycznego przestrzegania standardów (rygorów) ustalonych na początku,
• współzależność, czasami niezamierzona, fragmentów kodu odpowiedzialnych za różne funkcjonalności, która musi być uwzględniana przy rozwoju systemu.

Natomiast każda mikrousługa wspiera jedną, określoną funkcjonalność biznesową i będąc niezależna od innych mikrousług może być samodzielnie deploymentowana. Każda mikrousługa działa w ramach własnego procesu i komunikuje się z innymi mikrousługami za pomocą lekkich protokołów komunikacyjnych – takich jak np. HTTP.

Podstawowymi korzyściami stylu opartego o mikrousługi są:

• skalowalność,
• autonaprawa,
• wykrywanie usług,
• pełna automatyzacja,
• niewymagające utrzymanie, a nawet brak konieczności utrzymania (NoOps/ZeroOps).

(źródło: Onwelo Microservices Lab)

Architektura monolityczna

• Miesiące spędzone przez programistów na nauce kodu
• Ryzyko znacznej przebudowy aplikacji podczas wprowadzania zmian do kodu
• Ograniczenia w wykorzystaniu różnych języków programowania
• Długi proces budowy aplikacji
• Długi okres testowania
• Złożona struktura zespołu pracującego nad aplikacją, brak jasnej odpowiedzialności
• Wydajność serwerów wykorzystywana jedynie w kilku procentach • Szybkie przyswojenie kodu dzięki podziałowi na mniejsze elementy

Architektura oparta o mikrousługi

• Sprawne identyfikowanie i rozwiązywanie problemów bez konieczności przebudowy aplikacji
• Możliwość wykorzystania różnych technologii
• Skrócony do minimum cykl produkcyjny
• Automatyczne testowanie, poprawa wydajności i jakości
• Praca w mniejszych bardziej produktywnych zespołach deweloperskich
• Zoptymalizowanie wykorzystania serwerów

(źródło: O’Reilly: "Budowanie mikrousług", Wyd. Helion, 2015 r.)

Cała komunikacja pomiędzy mikrousługami odbywa się za pośrednictwem wywołań sieci. To pozwala wymusić podział między mikrousługami i unikać niebezpieczeństw związanych ze zbyt ścisłymi sprzężeniami.

Mikrousługa udostępnia interfejs programowania aplikacji (API), przez który komunikują się z nią usługi współpracujące. Aby dobrze rozdzielić interfejsy API, należy właściwie zamodelować usługi oraz odpowiednio zaprojektować interfejsy API.

Filozofia mikrousług jest zbieżna z modelem, który Gartner określił mianem Gospodarka API (ang. API Economy).

Mikrousługi ze swej natury nadają się do wytwarzania przez zespoły Agile, jeszcze lepiej wpasowują się w koncepcję DevOps – zespół, który je wytworzył odpowiada za ich utrzymanie.

Wykorzystanie mikrousług wymaga podejścia continuous delivery czyli kompletnej automatyzacji i optymalizacji procesów dostarczania, które odbywa się ustawicznie, a nie w rocznych, półrocznych czy w najlepszym przypadku kwartalnych cyklach. Programista zasila repozytoria, narzędzia same kojarzą właściwe wersje kodów i środowisk, przeprowadzają różnego rodzaju testy w tym wydajnościowe i regresyjne. Następnie następuje integracja kodów, która również jest procesem ciągłym, to znaczy w dużym uproszczeniu, znika część ograniczeń związanych z oczekiwaniem propagowanej wersji kodu na właściwe środowisko integracyjne a tym samym skraca się czas do przejścia na produkcje. Ten ostatni etap również może nastąpić automatycznie – choć jak pokazują doświadczenia – zwykle zachowujemy dozę zdrowego rozsądku i ostatecznie czekamy na decyzję ludzką. (źródło: Krzysztof Waszkiewicz: "Mikrousługi, jako podstawa aplikacji trzeciej generacji", ITwiz.pl, 14 grudnia 2015 r.)

Mikrousługi i SOA to podobne, ale jednak dwie różne rzeczy. Na ogólnym poziomie obie koncepcje wzięły się z frustracji budowania monolitycznych aplikacji. Zamiast tego proponują budowanie aplikacji jako zestawu usług, a nie jednego, monolitycznego kodu. Takie podejście ułatwia modyfikowanie aplikacji i ich utrzymanie. Zakłada się, że wystarczy refaktoryzacja i ponowne wdrożenie kilku usług zamiast ponownej inżynierii i wypuszczania nowej wersji monolitu. Rzeczywiste korzyści stają się lepiej widoczne, jeśli rozważymy całe portfolio aplikacji. Kiedy usługi są współdzielone, można wyeliminować powtarzające się prace. Zamiast zbioru monolitycznych aplikacji zarządzanych przez różne zespoły, z których każdy duplikuje wysiłki pozostałych, można skomponować swoje aplikacje z już istniejących usług, wdrożonych przez innych. Zauważmy, że nie chodzi o ponowne wykorzystanie kodu, ale o używanie istniejących, działających usług jako części własnych aplikacji i zapewnianie komunikacji między nimi za pomocą API. Jeśli taka usługa jest udoskonalana, każda korzystająca z niej aplikacja korzysta na tym. Wdrożenia SOA były z reguły inicjowane odgórnie przez menedżerów sfrustrowanych współpracą z wieloma samodzielnymi zespołami deweloperskimi opracowującymi wielokrotnie te same funkcje. Natomiast architektura mikrousług jest raczej inicjowana przez deweloperów. Ta grupa pracowników również nie lubi powtarzania tych samych prac, szczególnie jeśli trzeba pracować pod stale rosnącą presją, aby tworzyć coraz więcej coraz lepszych aplikacji. Często są to aplikacje mobilne i webowe, z różnymi warstwami prezentacji, ale podobnymi usługami działającymi w tle. źródło: (Tomasz Kowalczyk: "Architektura mikrousług", Computerworld.pl, 28.01.2015)