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 …

Bibliografia

  1. Arsov, K. (2017, March 17). What Are Microservices, Actually? Retrieved from DZone website: https://dzone.com/articles/what-are-microservices-actually
  2. D., A. (2019, April 18). Best Architecture for an MVP: Monolith, SOA, Microservices, or Serverless? Retrieved July 7, 2019, from RubbyGarage website: https://rubygarage.org/blog/monolith-soa-microservices-serverless
  3. Gage, J. (2018, April 23). Introduction to Microservices: What are Microservices? Use Cases and Examples. Retrieved September 5, 2019, from Algorithmia website:
  4. Woodie, A. (2018, November 7). Modernizing IBM i Apps with Microservices. Retrieved from IT Jungle website: https://www.itjungle.com/2018/11/07/modernizing-ibm-i-apps-with-microservices/

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 5 komentarzy

    1. Jaroslaw Zelinski

      Nie mają. SCA to udostępnianie usług SOA, tu mamy aplikacje komponentowe, pomysł z początków lat 90’tych. Mikro-serwisy to architektura nieco inna, bo zakałda całkowita separacje implementacji usług (czego nie zakłada SCA/SOA). Aplikacje SCA/SOA nadal mogą być monolitami takimi jak ERP, które nie raz mają architekturę SOA/SCA ale absolutnie nie są mikroserwisami.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.