Dwa lata temu pisałem o mikroserwisach:

Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem  ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst  (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien być nadrzędny) wobec zakresu projektu, ten drugi jest ustalany, drugi wynika z systemu pojęciowego (bałwan z okazji zimy będzie trwalszym pojęciem w projekcie niż bałwan z okazji członków doraźnego spotkania zespołu). (Źródło: Granice kontekstu i mikroserwisy)

Mikroserwisy to bardzo wygodna architektura. Wymaga całkowitej rezygnacji z jednego, relacyjnego systemu danych dla dużej aplikacji, dzięki czemu możliwe jest niezależne, iteracyjno-przyrostowe (zwinne) implementowanie kolejnych usług.?(Woodie, 2018)? ?(Arsov, 2017)? Powyższy artykuł zawiera kilka przykładów (polecam lekturę całości), które pokazują przyczyny problemów z tradycyjnymi “całościowo” zintegrowanymi systemami (np. ERP).

Ogólna idea to budowanie aplikacji tak, by każdy przypadek użycia stanowił praktycznie odrębny mały komponent. W efekcie mamy dużą swobodę zarządzania kolejnością ich implementacji a lokalne modyfikacje nie przenoszą się na resztę systemu. Ewentualne współdzielone komponenty to wyłącznie elementy logiki biznesowej, co nie ogranicza zbyt mocno kolejności implementowanych i wdrażanych usług aplikacyjnych. 

Architektura ta jest znana od lat, dość precyzyjnie opisał ją Fowler w 2014 roku (Microservices). 

Czym są mikrousługi? Zwrot w kierunku oprogramowania opartego o mikrousługi i kontenery to cicha rewolucja, która w ostatnich miesiącach dokonuje się na globalnym rynku IT. Mikrousługi stanowią alternatywę dla monolitycznego stylu tworzenia oprogramowania. Tworząc aplikacje z wykorzystaniem architektury mikrousług i kontenerów, programiści mogą odpowiednio dobrać jej poszczególne elementy, nie zajmując się całością aplikacji, co ma miejsce w przypadku podejścia monolitycznego. Tym samym cykl produkcyjny ulega skróceniu, a związane z nim koszty obniżeniu nawet o 60 proc. Zwiększa się także elastyczność oraz szybkość wprowadzania innowacji? ? tłumaczy Rafał Głąb, Business Technology Unit Director, odpowiedzialny za rozwój Onwelo Microservices Lab, największego w Polsce centrum kompetencyjnego dotyczącego mikrousług. (Źródło: Słyszałeś o mikrousługach? Twoje ulubione aplikacje działają w oparciu o nie! – ERP-view.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Aplikacje budowane w oparciu o tradycyjny monolityczny relacyjny model danych wymagają zaprojektowania całościowego modelu danych co jest dużym wyzwaniem, obecnie graniczącym z cudem (niedawno o tym pisałem w Biznesowy model danych – nie chcemy).

Prawdopodobieństwo zmian pierwotnych (z dnia rozpoczęcia projektu) wymagań na “całość systemu”, dla projektów trwających ponad rok, obecnie graniczy z pewnością, dlatego po prostu nie sensu tego robić.

Projekt może być realizowany przyrostowo tylko pod warunkiem, że pozwala na to architektura całego systemu, ta więc nie może mieć monolitycznej podstawy jaką jest jeden relacyjny model danych. Implementacja (proces) bazująca na mikroserwisach wygląda tak:

Takie podejście pozwala tworzyć szybciej przy minimalnym ryzyku pojawienia się potrzeby re-faktoringu całości a także czyni aplikację łatwą do tworzenia w zespole i późniejszej rozbudowy ?(Gage, 2018)?. Rosnąca popularność tej architektury, tylnymi drzwiami powoli ruguje z rynku monolity ERP, które (niektóre) podlegają re-faktoringowi (ich producenci  nie chwalą sie tym bo to powolny i bardzo kosztowny proces). Te systemy, które nadal są oparte na fundamencie jednej bazy danych  z integracją bazująca na współdzieleniu danych,  powoli przegrywają kosztami. Mit “monolitycznego zintegrowanego” systemu powoli przestaje działać na rynku… powoli… bo nadal jest żywy w ofertach.?(D., 2019)?

W nieco innej formie, ale bardzo zbliżonej mówimy też o mikro aplikacjach (microapp). Pojęcie mikroserwisów zostało nieco zawłaszczone przez dostawców technologii (VMWare, dokery, itp.), pojęciem bliższym opisanej wyżej architektury jest pojęcie mikroaplikacji. W tym kontekście spotykane jest także pojęcie “modularyzacja”. Więcej o tym innym razem …