Dugo sam želio napisati članak na temu arhitekture mikroservisa, ali dvije stvari su me zaustavljale - što sam dublje ulazio u temu, sve mi se više činilo da je ono što znam očito, a ono što ne znam t know treba proučavati i proučavati. S druge strane, mislim da se već ima o čemu raspravljati među širokom publikom. Dakle, alternativna mišljenja su dobrodošla.
Conwayev zakon i odnos između poslovanja, organizacije i informacijskog sustava
Još jednom ću si dopustiti da citiram:
“Svaka organizacija koja dizajnira sustav (u širem smislu) dobit će dizajn čija struktura replicira strukturu timova u toj organizaciji.”
- Melvyn Conway, 1967
Po mom mišljenju, vjerojatnije je da se ovaj zakon odnosi na izvedivost organiziranja poslovanja, nego izravno na informacijski sustav. Dopustite mi da objasnim na primjeru. Recimo da imamo prilično stabilnu poslovnu priliku sa životnim ciklusom toliko dugo da ima smisla organizirati poduzeće (ovo nije tipfeler, ali jako mi se sviđa ovaj izraz koji sam ukrao). Naravno, sustav podrške ovog poslovanja će organizacijski i procesno odgovarati ovom poslu .
Poslovna orijentacija informacijskih sustava
Dopustite mi da objasnim na primjeru. Recimo da postoji poslovna prilika za organiziranje poslovanja prodaje pizze. U V1 verziji (nazovimo je predinformacija) tvrtka je bila pizzerija, blagajna i dostava. Ova je verzija bila dugovječna u uvjetima niske varijabilnosti okoliša. Zatim ga je zamijenila verzija 2 - naprednija i sposobna koristiti informacijski sustav u svojoj srži za poslovanje s monolitnom arhitekturom. I tu, po mom mišljenju, postoji jednostavno užasna nepravda u odnosu na monolite - navodno monolitna arhitektura ne odgovara poslovnom modelu domene. Da, da je to tako, sustav uopće ne bi mogao funkcionirati - u suprotnosti s istim Conwayevim zakonom i zdravim razumom. Ne, monolitna arhitektura je u potpunosti konzistentna s poslovnim modelom u ovoj fazi razvoja poslovanja - mislim, naravno, na fazu kada je sustav već kreiran i pušten u rad. Apsolutno je divna činjenica da će, bez obzira na arhitektonski pristup, i servisno orijentirana arhitektura verzije 3 i mikroservisne arhitekture verzija N raditi jednako dobro. U čemu je kvaka?
Sve teče, sve se mijenja ili su mikroservisi sredstvo za borbu protiv složenosti?
Prije nego što nastavimo, pogledajmo neke zablude o arhitekturi mikroservisa.
Zagovornici korištenja pristupa mikrousluga često tvrde da razbijanje monolita na mikrousluge pojednostavljuje razvojni pristup smanjenjem baze koda pojedinačnih usluga. Po meni je ova izjava potpuna besmislica. Ozbiljno, očita interakcija unutar monolitnog i homogenog koda čini se kompliciranom? Da je to stvarno tako, svi projekti bi se u početku gradili kao mikroservisi, dok praksa pokazuje da je migracija s monolita na mikroservise puno češća. Složenost ne nestaje; jednostavno se pomiče s pojedinačnih modula na sučelja (bilo da se radi o podatkovnim sabirnicama, RPC-u, API-jima i drugim protokolima) i sustavima za orkestriranje. A ovo je teško!
Prednost korištenja heterogenog steka također je upitna. Neću tvrditi da je i to moguće, ali u stvarnosti se rijetko događa (Gledajući unaprijed - to bi se trebalo dogoditi - ali više kao posljedica nego kao prednost).
Životni ciklus proizvoda i životni ciklus usluge
Još jednom pogledajte gornji dijagram. Nisam slučajno uočio sve manji životni ciklus zasebne verzije poslovanja - u suvremenim uvjetima upravo je ubrzanje tranzicije poslovanja između verzija odlučujuće za njegov uspjeh. Uspjeh proizvoda određen je brzinom testiranja poslovnih hipoteza u njemu. I tu, po mom mišljenju, leži ključna prednost mikroservisne arhitekture. Ali krenimo redom.
Prijeđimo na sljedeću fazu u evoluciji informacijskih sustava – na uslužno orijentiranu arhitekturu SOA-e. Dakle, u nekom određenom trenutku smo istaknuli u našem proizvodu dugovječne usluge - dugotrajan u smislu da pri prelasku s jedne verzije proizvoda na drugu postoji vjerojatnost da će životni ciklus usluge biti duži od životnog ciklusa sljedeće verzije proizvoda. Bilo bi logično da ih uopće ne mijenjamo – mi Bitna je brzina prijelaza na sljedeću verziju. Ali nažalost, prisiljeni smo stalno mijenjati usluge - a ovdje sve radi za nas, DevOps prakse, kontejnerizacija i tako dalje - sve što nam padne na pamet. Ali to još uvijek nisu mikroservisi!
Mikroservisi kao sredstvo za borbu protiv kompleksnosti... upravljanje konfiguracijom
I ovdje konačno možemo prijeći na odlučujuću ulogu mikroservisa - ovo je pristup koji pojednostavljuje upravljanje konfiguracijom proizvoda. Detaljnije, funkcija svakog mikroservisa opisuje upravo poslovnu funkciju unutar proizvoda prema modelu domene – a to su stvari koje žive ne u kratkotrajnoj verziji, već u dugovječnoj poslovnoj prilici. A prijelaz na sljedeću verziju proizvoda događa se doslovno nezapaženo - promijenite/dodate jednu mikroservis, a možda i samo shemu njihove interakcije, i odjednom se nađete u budućnosti, ostavljajući iza sebe uplakane konkurente koji nastavljaju skakati između verzija njihovi monoliti. Sada zamislite da postoji prilično velika količina mikroservisa s unaprijed definiranim sučeljima i poslovnim mogućnostima. A vi dođete i izgradite strukturu svog proizvoda od gotovih mikroservisa – jednostavnim crtanjem dijagrama, na primjer. Čestitamo - imate platformu - i sada možete privući posao za sebe. Snovi Snovi.
Zaključci
- Arhitektura sustava trebala bi biti određena životnim ciklusom njegovih komponenti. Ako komponenta živi unutar verzije proizvoda, nema smisla povećavati složenost sustava korištenjem pristupa mikroservisa.
- Arhitektura mikroservisa trebala bi se temeljiti na domenskom modelu – jer poslovna prilika je najdugovječnija domena
- Prakse isporuke (DevOps prakse) i orkestracija jedne su od najvažnijih za arhitekturu mikroservisa - iz razloga što povećanje stope promjene komponenti postavlja povećane zahtjeve na brzinu i kvalitetu isporuke
Izvor: www.habr.com