{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikroservisi: \u0161to su, za\u0161to su potrebni i kada ih treba implementirati","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u017delio sam pisati \u010dlanak o mikroservisnoj arhitekturi ve\u0107 dugo vremena, no uvijek su me sprje\u010davala dva razloga \u2014 \u0161to sam vi\u0161e istra\u017eivao temu, to mi se vi\u0161e \u010dinilo da je ono \u0161to znam o\u010dito, a ono \u0161to ne znam jo\u0161 uvijek treba prou\u010diti. S druge strane, smatram da ve\u0107 postoje teme o kojima se mo\u017ee razgovarati s \u0161irom publikom. Tako da su alternativna mi\u0161ljenja dobrodo\u0161la.
\n<\/a><\/noindex><\/p>\n

Conwayov zakon i povezanost izme\u0111u poslovanja, organizacije i informati\u010dkog sustava<\/h2>\n

\nJo\u0161 jednom \u0107u si dopustiti da citiram:<\/p>\n

\u201eSvaka organizacija koja dizajnira neki sustav (u \u0161irokom smislu) dobit \u0107e dizajn \u010dija struktura opona\u0161a strukturu timova unutar te organizacije\u201c
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Po mom mi\u0161ljenju, ovaj zakon vi\u0161e se odnosi na svrhu organizacije poslovanja, nego izravno na informati\u010dki sustav. Objasnit \u0107u na primjeru. Recimo, imamo dovoljno stabilnu poslovnu priliku s \u017eivotnim ciklusom takve du\u017eine da ima smisla organizirati poduze\u0107e (to nije tipfeler, jako mi se svi\u0111a taj izraz koji sam posudio). Naravno, da \u0107e sustav koji podr\u017eava ovo poslovanje biti organizacijski i procesno uskla\u0111en s tim poslovanjem.<\/p>\n

Poslovno orijentiranost informati\u010dkih sustava<\/h2>\n

\n\"Mikroservisi:
\n
\nObjasnit \u0107u na primjeru. Recimo da imamo poslovnu priliku za organizaciju prodaje pizza. U verziji V1 (nazovimo je doinformacijskom) poduze\u0107e je predstavljala pizzerija, blagajna, usluga dostave. Ova verzija bila je dugovje\u010dna u uvjetima niskih promjena u okolini. Zatim je do\u0161la verzija 2 \u2014 naprednija koja koristi informati\u010dki sustav kao osnovu za poslovanje s monolitnom arhitekturom. I tu, po mom mi\u0161ljenju, nastaje grozno nepo\u0161tovanje prema monolitima \u2014 navodno monolitna arhitektura ne odgovara domeni poslovnog modela<\/b>. Da jest to tako, sustav ne bi mogao funkcionirati uop\u0107e - \u0161to 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\u0107 stvoren i pu\u0161ten u rad. Posve je zanimljivo da bez obzira na arhitektonski pristup, i uslu\u017ena arhitektura verzije 3 i mikroslu\u017ebena arhitektura verzije N, \u0107e raditi jednako dobro. Gdje je trik?<\/p>\n

Sve te\u010de, sve se mijenja ili su mikroslu\u017ebe sredstvo za borbu protiv slo\u017eenosti?<\/h2>\n

\n Prije nego \u0161to nastavimo, razmotrimo neka zabluda o mikroslu\u017ebenoj arhitekturi.<\/p>\n

Pristalice kori\u0161tenja mikroslu\u017ebenog pristupa \u010desto isti\u010du da razbijanje monolita na mikroslu\u017ebe pojednostavljuje pristup razvoju smanjenjem koda pojedinih usluga. Po mom mi\u0161ljenju, ova tvrdnja je potpuni besmisao. Ozbiljno, o\u010digledna interakcija unutar monolita i homogeni kod izgleda te\u0161ka? Da je to uistinu tako, svi bi projekti inicijalno bili izra\u0111eni kao mikroslu\u017ebe, dok praksa pokazuje da je migracija iz monolita u mikroslu\u017ebe mnogo \u010de\u0161\u0107a. Slo\u017eenost ne nestaje, ona jednostavno prelazi iz pojedinih modula u su\u010delja (bila to, podatkovne sabirnice, RPC, API i drugi protokoli) i orkestracijske sustave. I to je - slo\u017eeno! <\/p>\n

Prednost kori\u0161tenja heterogenog stoga tako\u0111er je upitna. Ne\u0107u se raspravljati da je to mogu\u0107e, ali u stvarnosti se rijetko susre\u0107e (Usput, to bi trebalo biti - ali vi\u0161e kao posljedica nego prednost).<\/p>\n

\u017divotni ciklus proizvoda i \u017eivotni ciklus usluge<\/h2>\n

\nPogledajte jo\u0161 jednom na dijagram iznad. Nije slu\u010dajno da sam ozna\u010dio smanjeni \u017eivotni ciklus pojedine verzije poslovanja - u modernim uvjetima, upravo ubrzanje prijelaza poslovanja izme\u0111u verzija odre\u0111uje njegov uspjeh. Uspje\u0161nost proizvoda odre\u0111uje brzina provjere poslovnih hipoteza u njemu<\/b>. I ovdje mislim da se skriva klju\u010dna prednost mikroslu\u017ebene arhitekture. No krenimo redom. <\/p>\n

Prelazimo na sljede\u0107i korak u evoluciji informacijskih sustava \u2014 na servisno orijentiranu arhitekturu SOA. Dakle, u nekom trenutku smo izdvojili u na\u0161em proizvodu dugoro\u010dne servise<\/b> \u2014 dugoro\u010dne u smislu da prilikom prelaska izme\u0111u verzija proizvoda postoji \u0161ansa da \u0107e \u017eivotni ciklus servisa biti du\u017ei od \u017eivotnog ciklusa odre\u0111ene verzije proizvoda. Logi\u010dno bi bilo ne mijenjati ih uop\u0107e \u2014 nama va\u017ena je upravo brzina prelaska na sljede\u0107u verziju<\/b>. No, na\u017ealost, prisiljeni smo neprestano unositi promjene u servise \u2014 i tu nam sve odgovara, i DevOps prakse, i kontejnerizacija, i sve drugo \u0161to nam padne na pamet. No, to su jo\u0161 uvijek ne mikroservisi! <\/p>\n

Mikroservisi kao sredstvo borbe sa slo\u017eeno\u0161\u0107u\u2026 upravljanja konfiguracijom<\/h2>\n

\n I ovdje kona\u010dno mo\u017eemo pre\u0107i na odre\u0111uju\u0107u ulogu mikroservisa \u2014 to je pristup koji pojednostavljuje upravljanje konfiguracijom proizvoda. Detaljnije re\u010deno, funkcija svakog mikroservisa opisuje upravo poslovnu funkciju unutar proizvoda prema domennoj modelu \u2014 a to su ve\u0107 stvari koje ne \u017eive u kratkoro\u010dnim verzijama, ve\u0107 u dugoro\u010dnim poslovnim mogu\u0107nostima. A prelazak na sljede\u0107u verziju proizvoda doga\u0111a se doslovno neprimjetno \u2014 mijenjate\/dodajete jedan mikroservis, a mo\u017eda i samo shemu njihove interakcije i iznenada se nalazite ve\u0107 u budu\u0107nosti, ostavljaju\u0107i iza sebe pla\u010dljive konkurente koji i dalje ska\u010dem izme\u0111u verzija svojih monolita. Sada zamislite da imate dovoljno veliki broj mikroservisa s unaprijed definiranim su\u010deljima i poslovnim mogu\u0107nostima. I dolazite i gradite strukturu va\u0161eg proizvoda od gotovih mikroservisa \u2014 jednostavno nacrtaju\u0107i dijagram, na primjer. \u010cestitam \u2014 sada imate platformu \u2014 i sada mo\u017eete stvoriti svoj biznis. Snove, snove. <\/p>\n

Zaklju\u010dci<\/h2>\n

<\/p>\n