Že dolgo sem želel napisati članek na temo arhitekture mikrostoritev, a sta me ovirali dve stvari – bolj ko sem se poglabljal v temo, bolj se mi je zdelo, da je tisto, kar vem, očitno, in tisto, kar ne t know je treba študirati in študirati. Po drugi strani pa mislim, da je že o čem razpravljati med širšim občinstvom. Zato so alternativna mnenja dobrodošla.
Conwayev zakon in odnos med poslom, organizacijo in informacijskim sistemom
Še enkrat si dovolim citirati:
"Vsaka organizacija, ki oblikuje sistem (v širšem smislu), bo prejela načrt, katerega struktura posnema strukturo ekip v tej organizaciji."
- Melvyn Conway, 1967
Po mojem mnenju se ta zakon bolj verjetno nanaša na smotrnost organizacije podjetja, kot neposredno na informacijski sistem. Naj pojasnim s primerom. Recimo, da imamo dokaj stabilno poslovno priložnost s tako dolgim življenjskim ciklom, da je smiselno organizirati podjetje (to ni tipkarska napaka, ampak mi je zelo všeč ta izraz, ki sem ga ukradel). Seveda je podporni sistem tega posla bo organizacijsko in procesno ustrezal temu poslu.
Poslovna naravnanost informacijskih sistemov
Naj pojasnim s primerom. Recimo, da obstaja poslovna priložnost za organizacijo podjetja za prodajo pice. V različici V1 (recimo ji predinformacija) je bila družba picerija, blagajna in dostavna služba. Ta različica je bila dolgo življenjska v razmerah majhne spremenljivosti okolja. Nato ga je nadomestila različica 2 - naprednejša in sposobna uporabljati informacijski sistem v svojem jedru za poslovanje z monolitno arhitekturo. In tukaj je po mojem mnenju preprosto strašna krivica v zvezi z monoliti - domnevno monolitna arhitektura ne ustreza domenskemu poslovnemu modelu. Da, če bi bilo tako, sistem sploh ne bi mogel delovati - v nasprotju z istim Conwayevim zakonom in zdravo pametjo. Ne, monolitna arhitektura je popolnoma skladna s poslovnim modelom na tej stopnji razvoja poslovanja - mislim seveda na fazo, ko je sistem že izdelan in zagnan. Povsem čudovito dejstvo je, da bosta ne glede na arhitekturni pristop tako storitveno usmerjena arhitektura različice 3 kot mikrostoritvena arhitektura različice N delovali enako dobro. V čem je fora?
Vse teče, vse se spreminja ali so mikrostoritve sredstvo za boj proti kompleksnosti?
Preden nadaljujemo, si poglejmo nekaj napačnih predstav o arhitekturi mikrostoritev.
Zagovorniki uporabe mikrostoritvenega pristopa pogosto trdijo, da razbijanje monolita na mikrostoritve poenostavi razvojni pristop z zmanjšanjem kodne baze posameznih storitev. Po mojem mnenju je ta izjava popolna neumnost. Resno, očitna interakcija znotraj monolitne in homogene kode se zdi zapletena? Če bi bilo res tako, bi bili vsi projekti na začetku zgrajeni kot mikrostoritve, praksa pa kaže, da je prehod iz monolita na mikrostoritve veliko pogostejši. Kompleksnost ne izgine; preprosto se premakne s posameznih modulov na vmesnike (pa naj gre za podatkovna vodila, RPC, API-je in druge protokole) in sisteme za orkestracijo. In to je težko!
Vprašljiva je tudi prednost uporabe heterogenega sklada. Ne bom trdil, da je tudi to možno, vendar se v resnici redko zgodi (če pogledam naprej - to bi se moralo zgoditi - vendar bolj kot posledica kot prednost).
Življenjski cikel izdelka in življenjski cikel storitve
Še enkrat si oglejte zgornji diagram. Ni naključje, da sem opazil krajšanje življenjskega cikla ločene različice posla – v sodobnih razmerah je za uspeh odločilno pospeševanje prehoda poslovanja med različicami. Uspešnost izdelka je odvisna od hitrosti preverjanja poslovnih hipotez v njem. In tu se po mojem mnenju skriva ključna prednost mikrostoritvene arhitekture. A pojdimo po vrsti.
Preidimo na naslednjo stopnjo v razvoju informacijskih sistemov - na storitveno usmerjeno arhitekturo SOA. Torej, na določeni točki smo poudarili v našem izdelku storitve z dolgo življenjsko dobo - dolgoživa v smislu, da pri prehodu med različicami izdelka obstaja možnost, da bo življenjski cikel storitve daljši od življenjskega cikla naslednje različice izdelka. Logično bi bilo, da jih sploh ne bi spreminjali – mi Pomembna je hitrost prehoda na naslednjo različico. Ampak žal, prisiljeni smo nenehno spreminjati storitve - in tukaj vse deluje za nas, prakse DevOps, kontejnerizacija in tako naprej - vse, kar nam pride na misel. Ampak to še vedno niso mikrostoritve!
Mikrostoritve kot sredstvo za boj proti kompleksnosti ... upravljanje konfiguracije
In tu lahko končno preidemo na odločilno vlogo mikrostoritev – to je pristop, ki poenostavlja upravljanje konfiguracije izdelka. Podrobneje funkcija vsake mikrostoritve natančno opisuje poslovno funkcijo znotraj produkta po modelu domene – in to so stvari, ki ne živijo v kratkotrajni različici, ampak v dolgoživi poslovni priložnosti. In prehod na naslednjo različico izdelka se zgodi dobesedno neopazno - spremenite/dodate eno mikrostoritev in morda samo shemo njihove interakcije, in nenadoma se znajdete v prihodnosti in za seboj pustite jokajoče konkurente, ki še naprej skačejo med različicami njihovi monoliti. Zdaj pa si predstavljajte, da obstaja dokaj velik obseg mikrostoritev z vnaprej določenimi vmesniki in poslovnimi zmogljivostmi. In pridete in zgradite strukturo svojega izdelka iz že pripravljenih mikrostoritev – preprosto z risanjem diagrama, na primer. Čestitamo – imate platformo – in zdaj lahko pritegnete posle zase. Sanje Sanje.
Ugotovitve
- Arhitektura sistema mora biti določena z življenjskim ciklom njegovih komponent. Če komponenta živi v različici izdelka, nima smisla povečevati kompleksnosti sistema z uporabo mikrostoritvenega pristopa.
- Mikrostoritvena arhitektura bi morala temeljiti na domenskem modelu – saj je poslovna priložnost domena z najdaljšo življenjsko dobo
- Prakse dostave (prakse DevOps) in orkestracija so ene najpomembnejših za arhitekturo mikrostoritev – iz razloga, ker povečanje stopnje spreminjanja komponent postavlja večje zahteve glede hitrosti in kakovosti dostave.
Vir: www.habr.com