Mikroservisna arhitektura smanjuje rizik kada odvaja dio poslovanja koji ima jasnog vlasnika, drukčiji ritam promjene ili zaseban pritisak skaliranja. Povećava složenost kada samo razbije jednu aplikaciju na mrežne dijelove koji i dalje moraju mijenjati podatke, puštati verzije i rješavati incidente zajedno. Tada mikroservisi ne uklanjaju ovisnosti - samo ih premještaju na mrežu, gdje ih je skuplje razumjeti i održavati.
Mikroservis nije cilj sam po sebi. To je operativna odluka koja uvodi nove ugovore, načine kvara i odgovornosti. Dobar modularni monolit često je zreliji izbor od prerane distribucije.
Granica servisa treba slijediti koherentan dio poslovnog ponašanja i podataka. Nazivi poput kupac, narudžba ili obračun nisu sami po sebi dovoljan razlog za izdvajanje. Potrebno je utvrditi koje se poslovne odluke mijenjaju zajedno, tko ih razvija, tko odgovara za podatke i koliko čvrstu konzistenciju proces zahtijeva.
Primjerice, odobravanje narudžbe i rezervacija zalihe mogu biti usko povezani ako poslovni proces ne smije potvrditi narudžbu bez raspoložive robe. Ako se oba dijela gotovo uvijek mijenjaju u istom poslu i zahtijevaju zajedničku transakciju, njihovo rano razdvajanje uvodi koordinaciju bez jasne koristi.
Nasuprot tome, dio sustava koji obrađuje veliki broj specifičnih zahtjeva, ima zaseban tim ili mora slijediti poseban sigurnosni režim može biti dobar kandidat za izdvajanje. Pitanje nije može li se komponenta tehnički odvojiti. Pitanje je hoće li odvajanje poboljšati donošenje promjena i ograničiti posljedice kvara.
Prije promjene arhitekture korisno je nacrtati pet granica:
Ako te granice nisu jasne unutar jedne aplikacije, mreža ih neće učiniti jasnijima.
U monolitu je poziv druge funkcije uglavnom lokalna operacija. U distribuiranim sustavima isti poziv postaje mrežni zahtjev koji može kasniti, ne stići do odredišta ili se zbog ponovnog pokušaja izvršiti dvaput. Poslovna posljedica nije apstraktna: sustav mora znati što učiniti kada je plaćanje zaprimljeno, ali potvrda narudžbe nije dovršena, ili kada drugi servis ne odgovori na vrijeme.
Jedna lokalna transakcija tada često postaje slijed događaja i kompenzacijskih radnji. Umjesto oslanjanja na jedan zajednički zapis promjene, tim mora definirati prihvatljivo privremeno neslaganje podataka, način naknadnog usklađivanja i ponašanje korisničkog procesa dok se usklađivanje ne dovrši.
Mikroservisi zato traže disciplinu u nekoliko područja:
Bez tih sposobnosti mikroservisna arhitektura može usporiti isporuku. Tim najprije rješava infrastrukturu, ugovore i dijagnostiku, a tek zatim poslovnu promjenu.
Odluka nije ideološka. Usporedite konkretne signale.
Mali tim i zajednički release. Ako isti tim mijenja većinu funkcionalnosti, a promjene se prirodno puštaju zajedno, monolit ili modularni monolit obično stvaraju manje troška koordinacije. Više deployabilnih jedinica ne daje autonomiju ako se i dalje moraju izdavati u paketu.
Jasna domena i neovisan tim. Kada jedan tim može razumjeti poslovnu domenu, promijeniti njezin ugovor, pustiti verziju i pratiti ponašanje u produkciji, zaseban servis može dati stvarnu autonomiju. Ako za svaku izmjenu treba sastanak više timova, tehnička granica vjerojatno samo povećava broj handoffa.
Izrazito različito opterećenje. Ako jedan dio sustava ima bitno drukčije opterećenje od ostatka, ciljano skaliranje može opravdati odvajanje. Ako opterećenje nije stvaran problem, skaliranje šire cjeline može biti jednostavnije od održavanja nove distribuirane komponente.
Stroga zajednička transakcija. Kada poslovni proces zahtijeva zajednički uspjeh ili neuspjeh više promjena, modularni monolit omogućuje jednostavniji model konzistencije. Mikroservisi mogu riješiti proces kroz događaje i kompenzacije, ali model pogreške postaje složeniji i mora biti vidljiv poslovnim pravilima.
Različiti sigurnosni ili regulatorni zahtjevi. Različiti zahtjevi mogu opravdati snažniju operativnu granicu. Ipak, izdvajanje servisa samo po sebi ne rješava upravljanje pristupom, podacima ni operativnim postupcima. Treba jasno definirati što se odvaja, tko upravlja pristupom i kako se granica provjerava u radu.
Najsigurniji put nije započeti s podjelom cijelog sustava. Potražite dio koji se mijenja, skalira ili pada drukčije od ostatka. To je kandidat za izdvajanje.
Prvo unutar monolita definirajte modul, njegov ugovor i vlasništvo nad podacima. Smanjite izravne ovisnosti drugih modula o njegovim internim strukturama. Tek kada granica funkcionira u istom procesu, razmotrite premještanje izvršavanja preko mreže.
Takav slijed omogućuje provjeru koristi prije pune distribucije. Nakon izdvajanja promatrajte praktična pitanja:
Broj servisa nije metrika napretka. Korist se vidi tek ako se promjene lakše isporučuju, kvarovi bolje izoliraju, a odgovornost postane jasnija.
Servis s vlastitim repozitorijem nije autonoman ako za svaku promjenu treba odobrenje ili intervencija više timova. Prije izdvajanja provjerite može li jedan tim voditi cijeli životni ciklus: razumjeti domenu, mijenjati ugovor, puštati novu verziju, reagirati na incident i odlučivati o podacima koje servis posjeduje.
Posebno dogovorite tko dežura kada servis padne i tko smije promijeniti njegove podatke. Autonomija bez produkcijske odgovornosti brzo postaje tuđi problem. Zdrav servis ne mora biti potpuno izoliran niti nikada ne komunicirati s drugima. Zdrav znak je kontrolirana evolucija ugovora i kvar koji ostaje dovoljno ograničen da ostatak poslovanja zna kako postupiti.
ORKA arhitekturni pregled povezuje granice domene, timova, podataka, opterećenja i operativne sposobnosti. Za organizacije koje razmatraju promjenu ERP-a, integracija ili povezanih poslovnih modula, koristan prvi korak može biti ERP i procesni screening .
Ishod ne mora biti mikroservisna arhitektura. Ako pregled pokaže da su ovisnosti još čvrste, modularni monolit može biti razuman sljedeći korak. Mikroservis ima smisla kada rješava poznat pritisak, uz tim i operativni model koji mogu nositi njegovu cijenu.