Želio sam pisati članak o mikroservisnoj arhitekturi već dugo vremena, no uvijek su me sprječavala dva razloga — što sam više istraživao temu, to mi se više činilo da je ono što znam očito, a ono što ne znam još uvijek treba proučiti. S druge strane, smatram da već postoje teme o kojima se može razgovarati s širom publikom. Tako da su alternativna mišljenja dobrodošla.
Conwayov zakon i povezanost između poslovanja, organizacije i informatičkog sustava
Još jednom ću si dopustiti da citiram:
„Svaka organizacija koja dizajnira neki sustav (u širokom smislu) dobit će dizajn čija struktura oponaša strukturu timova unutar te organizacije“
— Melvyn Conway, 1967
Po mom mišljenju, ovaj zakon više se odnosi na svrhu organizacije poslovanja, nego izravno na informatički sustav. Objasnit ću na primjeru. Recimo, imamo dovoljno stabilnu poslovnu priliku s životnim ciklusom takve dužine da ima smisla organizirati poduzeće (to nije tipfeler, jako mi se sviđa taj izraz koji sam posudio). Naravno, da će sustav koji podržava ovo poslovanje biti organizacijski i procesno usklađen s tim poslovanjem.
Poslovno orijentiranost informatičkih sustava
Objasnit ću na primjeru. Recimo da imamo poslovnu priliku za organizaciju prodaje pizza. U verziji V1 (nazovimo je doinformacijskom) poduzeće je predstavljala pizzerija, blagajna, usluga dostave. Ova verzija bila je dugovječna u uvjetima niskih promjena u okolini. Zatim je došla verzija 2 — naprednija koja koristi informatički sustav kao osnovu za poslovanje s monolitnom arhitekturom. I tu, po mom mišljenju, nastaje grozno nepoštovanje prema monolitima — navodno monolitna arhitektura ne odgovara domeni poslovnog modela. Da jest to tako, sustav ne bi mogao funkcionirati uopće - što bi bilo u suprotnosti s Conwayevim zakonom i zdravim razumom. Ne, monolitna arhitektura potpuno odgovara poslovnom modelu u ovoj fazi razvoja poslovanja - ovdje mislim na fazu kada je sustav već stvoren i pušten u rad. Posve je zanimljivo da bez obzira na arhitektonski pristup, i uslužna arhitektura verzije 3 i mikroslužbena arhitektura verzije N, će raditi jednako dobro. Gdje je trik?
Sve teče, sve se mijenja ili su mikroslužbe sredstvo za borbu protiv složenosti?
Prije nego što nastavimo, razmotrimo neka zabluda o mikroslužbenoj arhitekturi.
Pristalice korištenja mikroslužbenog pristupa često ističu da razbijanje monolita na mikroslužbe pojednostavljuje pristup razvoju smanjenjem koda pojedinih usluga. Po mom mišljenju, ova tvrdnja je potpuni besmisao. Ozbiljno, očigledna interakcija unutar monolita i homogeni kod izgleda teška? Da je to uistinu tako, svi bi projekti inicijalno bili izrađeni kao mikroslužbe, dok praksa pokazuje da je migracija iz monolita u mikroslužbe mnogo češća. Složenost ne nestaje, ona jednostavno prelazi iz pojedinih modula u sučelja (bila to, podatkovne sabirnice, RPC, API i drugi protokoli) i orkestracijske sustave. I to je - složeno!
Prednost korištenja heterogenog stoga također je upitna. Neću se raspravljati da je to moguće, ali u stvarnosti se rijetko susreće (Usput, to bi trebalo biti - ali više kao posljedica nego prednost).
Životni ciklus proizvoda i životni ciklus usluge
Pogledajte još jednom na dijagram iznad. Nije slučajno da sam označio smanjeni životni ciklus pojedine verzije poslovanja - u modernim uvjetima, upravo ubrzanje prijelaza poslovanja između verzija određuje njegov uspjeh. Uspješnost proizvoda određuje brzina provjere poslovnih hipoteza u njemu. I ovdje mislim da se skriva ključna prednost mikroslužbene arhitekture. No krenimo redom.
Prelazimo na sljedeći korak u evoluciji informacijskih sustava — na servisno orijentiranu arhitekturu SOA. Dakle, u nekom trenutku smo izdvojili u našem proizvodu dugoročne servise — dugoročne u smislu da prilikom prelaska između verzija proizvoda postoji šansa da će životni ciklus servisa biti duži od životnog ciklusa određene verzije proizvoda. Logično bi bilo ne mijenjati ih uopće — nama važna je upravo brzina prelaska na sljedeću verziju. No, nažalost, prisiljeni smo neprestano unositi promjene u servise — i tu nam sve odgovara, i DevOps prakse, i kontejnerizacija, i sve drugo što nam padne na pamet. No, to su još uvijek ne mikroservisi!
Mikroservisi kao sredstvo borbe sa složenošću… upravljanja konfiguracijom
I ovdje konačno možemo preći na određujuću ulogu mikroservisa — to je pristup koji pojednostavljuje upravljanje konfiguracijom proizvoda. Detaljnije rečeno, funkcija svakog mikroservisa opisuje upravo poslovnu funkciju unutar proizvoda prema domennoj modelu — a to su već stvari koje ne žive u kratkoročnim verzijama, već u dugoročnim poslovnim mogućnostima. A prelazak na sljedeću verziju proizvoda događa se doslovno neprimjetno — mijenjate/dodajete jedan mikroservis, a možda i samo shemu njihove interakcije i iznenada se nalazite već u budućnosti, ostavljajući iza sebe plačljive konkurente koji i dalje skačem između verzija svojih monolita. Sada zamislite da imate dovoljno veliki broj mikroservisa s unaprijed definiranim sučeljima i poslovnim mogućnostima. I dolazite i gradite strukturu vašeg proizvoda od gotovih mikroservisa — jednostavno nacrtajući dijagram, na primjer. Čestitam — sada imate platformu — i sada možete stvoriti svoj biznis. Snove, snove.
Zaključci
- Arhitektura sustava trebala bi biti određena životnim ciklusom komponenti koje je čine. Ako komponenta živi unutar verzije proizvoda — nema smisla povećavati složenost sustava primjenom mikroservisnog pristupa.
- Mikroservisna arhitektura trebala bi se temeljiti na domennoj modelu — iz razloga što su poslovne mogućnosti najdugovječnije područje
- Prakse isporuke (DevOps prakse) i orkestracije imaju izuzetno važnu ulogu za mikroservisnu arhitekturu — zbog toga što povećanje brzine promjena komponenti postavlja veće zahtjeve za brzinom i kvalitetom isporuke.
Izvor: habr.com
