Dwa lata temu pisa­łem o mikroserwisach:

Obecnie mamy już dość dobrze wypra­co­wa­ne wzor­ce pro­jek­to­we ale nadal jest pro­blem ze zro­zu­mie­niem ?kie­dy i jak?. Ładnie to opi­sał swe­go cza­su E.Evans przy oka­zji wzor­ca DDD, Tu poprze­sta­nę jedy­nie na poję­ciu boun­ded con­text czy­li ?gra­ni­ca kon­tek­stu?. Granica ta ma podwój­ne zna­cze­nie: kon­tekst nada­je (zmie­nia) zna­cze­nia w mode­lu poję­cio­wym (bał­wan w kon­tek­ście zimy to co inne­go niż bał­wan w kon­tek­ście człon­ków zespo­łu pro­jek­to­we­go) oraz kon­tekst (bar­dzo czę­sto) wyzna­cza zakres pro­jek­tu (inne aspek­ty wzor­ca DDD tu pomi­nę). Pierwsza uwa­ga: kon­tekst dzie­dzi­no­wy (poję­cio­wy) jest waż­niej­szy (powi­nien być nad­rzęd­ny) wobec zakre­su pro­jek­tu, ten dru­gi jest usta­la­ny, dru­gi wyni­ka z sys­te­mu poję­cio­we­go (bał­wan z oka­zji zimy będzie trwal­szym poję­ciem w pro­jek­cie niż bał­wan z oka­zji człon­ków doraź­ne­go spo­tka­nia zespo­łu). (Źródło: Granice kon­tek­stu i mikro­ser­wi­sy)

Mikroserwisy to bar­dzo wygod­na archi­tek­tu­ra. Wymaga cał­ko­wi­tej rezy­gna­cji z jed­ne­go, rela­cyj­ne­go sys­te­mu danych dla dużej apli­ka­cji, dzię­ki cze­mu moż­li­we jest nie­za­leż­ne, ite­ra­cyj­no-przy­ro­sto­we (zwin­ne) imple­men­to­wa­nie kolej­nych usług.?(Woodie, 2018)? ?(Arsov, 2017)? Powyższy arty­kuł zawie­ra kil­ka przy­kła­dów (pole­cam lek­tu­rę cało­ści), któ­re poka­zu­ją przy­czy­ny pro­ble­mów z tra­dy­cyj­ny­mi ​„cało­ścio­wo” zin­te­gro­wa­ny­mi sys­te­ma­mi (np. ERP).

Ogólna idea to budo­wa­nie apli­ka­cji tak, by każ­dy przy­pa­dek uży­cia sta­no­wił prak­tycz­nie odręb­ny mały kom­po­nent. W efek­cie mamy dużą swo­bo­dę zarzą­dza­nia kolej­no­ścią ich imple­men­ta­cji a lokal­ne mody­fi­ka­cje nie prze­no­szą się na resz­tę sys­te­mu. Ewentualne współ­dzie­lo­ne kom­po­nen­ty to wyłącz­nie ele­men­ty logi­ki biz­ne­so­wej, co nie ogra­ni­cza zbyt moc­no kolej­no­ści imple­men­to­wa­nych i wdra­ża­nych usług aplikacyjnych. 

Architektura ta jest zna­na od lat, dość pre­cy­zyj­nie opi­sał ją Fowler w 2014 roku (Microservices). 

Czym są mikro­usłu­gi? Zwrot w kie­run­ku opro­gra­mo­wa­nia opar­te­go o mikro­usłu­gi i kon­te­ne­ry to cicha rewo­lu­cja, któ­ra w ostat­nich mie­sią­cach doko­nu­je się na glo­bal­nym ryn­ku IT. Mikrousługi sta­no­wią alter­na­ty­wę dla mono­li­tycz­ne­go sty­lu two­rze­nia opro­gra­mo­wa­nia. Tworząc apli­ka­cje z wyko­rzy­sta­niem archi­tek­tu­ry mikro­usług i kon­te­ne­rów, pro­gra­mi­ści mogą odpo­wied­nio dobrać jej poszcze­gól­ne ele­men­ty, nie zaj­mu­jąc się cało­ścią apli­ka­cji, co ma miej­sce w przy­pad­ku podej­ścia mono­li­tycz­ne­go. Tym samym cykl pro­duk­cyj­ny ule­ga skró­ce­niu, a zwią­za­ne z nim kosz­ty obni­że­niu nawet o 60 proc. Zwiększa się tak­że ela­stycz­ność oraz szyb­kość wpro­wa­dza­nia inno­wa­cji? ? tłu­ma­czy Rafał Głąb, Business Technology Unit Director, odpo­wie­dzial­ny za roz­wój Onwelo Microservices Lab, naj­więk­sze­go w Polsce cen­trum kom­pe­ten­cyj­ne­go doty­czą­ce­go mikro­usług. (Źródło: Słyszałeś o mikro­usłu­gach? Twoje ulu­bio­ne apli­ka­cje dzia­ła­ją w opar­ciu o nie! – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Aplikacje budo­wa­ne w opar­ciu o tra­dy­cyj­ny mono­li­tycz­ny rela­cyj­ny model danych wyma­ga­ją zapro­jek­to­wa­nia cało­ścio­we­go mode­lu danych co jest dużym wyzwa­niem, obec­nie gra­ni­czą­cym z cudem (nie­daw­no o tym pisa­łem w Biznesowy model danych – nie chce­my).

Prawdopodobieństwo zmian pier­wot­nych (z dnia roz­po­czę­cia pro­jek­tu) wyma­gań na ​„całość sys­te­mu”, dla pro­jek­tów trwa­ją­cych ponad rok, obec­nie gra­ni­czy z pew­no­ścią, dla­te­go po pro­stu nie sen­su tego robić.

Projekt może być reali­zo­wa­ny przy­ro­sto­wo tyl­ko pod warun­kiem, że pozwa­la na to archi­tek­tu­ra całe­go sys­te­mu, ta więc nie może mieć mono­li­tycz­nej pod­sta­wy jaką jest jeden rela­cyj­ny model danych. Implementacja (pro­ces) bazu­ją­ca na mikro­ser­wi­sach wyglą­da tak:

Takie podej­ście pozwa­la two­rzyć szyb­ciej przy mini­mal­nym ryzy­ku poja­wie­nia się potrze­by re-fak­to­rin­gu cało­ści a tak­że czy­ni apli­ka­cję łatwą do two­rze­nia w zespo­le i póź­niej­szej roz­bu­do­wy ?(Gage, 2018)?. Rosnąca popu­lar­ność tej archi­tek­tu­ry, tyl­ny­mi drzwia­mi powo­li rugu­je z ryn­ku mono­li­ty ERP, któ­re (nie­któ­re) pod­le­ga­ją re-fak­to­rin­go­wi (ich pro­du­cen­ci nie chwa­lą sie tym bo to powol­ny i bar­dzo kosz­tow­ny pro­ces). Te sys­te­my, któ­re nadal są opar­te na fun­da­men­cie jed­nej bazy danych z inte­gra­cją bazu­ją­ca na współ­dzie­le­niu danych, powo­li prze­gry­wa­ją kosz­ta­mi. Mit ​„mono­li­tycz­ne­go zin­te­gro­wa­ne­go” sys­te­mu powo­li prze­sta­je dzia­łać na ryn­ku… powo­li… bo nadal jest żywy w ofer­tach.?(D., 2019)?

W nie­co innej for­mie, ale bar­dzo zbli­żo­nej mówi­my też o mikro apli­ka­cjach (micro­app). Pojęcie mikro­ser­wi­sów zosta­ło nie­co zawłasz­czo­ne przez dostaw­ców tech­no­lo­gii (VMWare, doke­ry, itp.), poję­ciem bliż­szym opi­sa­nej wyżej archi­tek­tu­ry jest poję­cie mikro­apli­ka­cji. W tym kon­tek­ście spo­ty­ka­ne jest tak­że poję­cie ​„modu­la­ry­za­cja”. Więcej o tym innym razem …