Aleksandar Roksandić
Autor:
Aleksandar Roksandić

.Net guru

Microservices Architecture

Posljednjih nekoliko godina Microservices postaje sve popularniji termin u krugovima softverske arhitekture, pogotovo u posljednje vrijeme kad je eksplodirala količina članaka i konferencijskih prezentacija na tu temu, zbog čega nije loše vidjeti što to najnovija iteracija jedne stare ideje donosi.

Ugrubo, Microservices predstavlja arhitekturni koncept koji nema egzaktnu definiciju koja ga opisuje, već se u osnovi radi o dekompoziciji funkcionalnosti u diskretne servise. Pod tim, servisi predstavljaju skup manjih i neovisnih, ali kohezivnih i inteligentnih servisa s jasnim razgraničenjem odgovornosti, koji zajedno grade neki kompleksniji sustav. Osim što ovakav pristup krasi naglasak na modularnost, skalabilnost i dostupnost, može se i pohvaliti kao arhitektura koja continuous deployment čini mogućim.

 

Arhitektura

Svi smo naviknuti na to kako funkcionira stvarni svijet oko nas i volimo da su nam stvari Plug-and-Play, te mi iole ozbiljniji developeri težimo sličnom principu; da imamo univerzalno plugabilne komponente, gotovo neovisne jedna o drugoj, dok s druge strane kompatibilne i interoperabilne u izgradnji većeg i kompleksnijeg rješenja… no u tim težnjama treba ostati realan, jer niti je svaki problem čavao, niti je svaka arhitektura čekić.

Koncepti koji grade i definiraju Microservices ne predstavljaju potpuno novu stvar, nego se radi o evoluciji postojećih arhitektura i ideja. Na primjer, svijet Unixa je građen na konceptima definiranja i izgradnje malenih i dobro definiranih alata s jasnim ulazima i izlazima, koji su omogućavali izvođenje kompleksnijih operacija ulančavanjem osnovnih 'servisa' komunicirajući pomoću named pipes, npr. cat file | sed | tail. Drugim riječima, okosnica arhitekture je na odvajanju/dekompoziciji odgovornosti i funkcionalnosti u zasebne servise, pa kad bi htjeli malo karikirati, Microservices bi mogli nazvati Single Responsibility Principle na servisnim steroidima.

No Microservices ne obuhvaća samo funkcionalnu dekompoziciju. Moguća je i horizontalna dekompozicija, koja pretpostavlja skaliranje aplikacije na način da se izvode potpuno identične kopije servisa na više servera; idealno za poboljšanje dostupnosti i kapaciteta.  Dodatno, aplikacija se može podatkovno segmentirati, gdje se dekompozicija odnosi na segmente podataka s kojima aplikacija radi, dok su kod i baza isti. Ovakva metodologija skaliranja aplikacija dobro je opisana Scale Cube modelom.

Lijepo kako zvuči, Microservices ipak ne predstavlja besplatan ručak. Sa segmentacijom aplikacije treba biti oprezan, jer iako Micro u imenu može navoditi developera u smjeru definiranja veličine i količine servisa, primarni cilj nije stvoriti šumu od 30 ili 100 malih servisa, jer tada upravljanje servisima na nivou gdje se orkestrira logika sustava postaje izrazito kompleksna, a dodatno se proširuju i zahtjevi na testiranje, jer osim cjeline potrebno je testirati i svaki od servisa zasebno. Kako kompleksnost sustava raste, javlja se potreba za kvalitetnijim nadzornim mehanizmima koji će radit monitoring svih tih servisa; jesu li procesi živi, jesu li ostali bez diskovnog prostora, da li se dogodio negdje deadlock

Ako imate nekoliko vrlo malih servisa i par većih kraj njih, i to je sasvim OK, dokle god se držimo principa; veličina ni(je) važna koliko je važno kako se servisi koriste, jer na taj način ujedno utječete i na dizajn komunikacije između servisa koja bi po prirodi arhitekture idealno bila asinkrona. Cilj je jasno adresirati probleme i zahtjeve koji se postavljaju, te na temelju toga pokušati odrediti kakva dekompozicija osigurava željenu skalabilnost i fleksibilnost u okvirima planirane funkcionalnosti i u konačnici, realne poslovne vrijednosti.

Kad dosad rečeno sumiramo u par natuknica i usporedimo s klasičnim monolitnim aplikacijama možemo izvući nekoliko prednosti:

  • Servisi su manje cjeline, pa je razvoj na nivou servisa jednostavniji
  • Zbog jednostavnosti servisa, lakše je uvođenje novih developera u tim
  • Unutar projekta moguće je koristiti različite tehnologije
  • Servisi mogu biti distribuirani na njima prikladnom hardware-u (CPU zahtjevni servisi dobe novije servere, a podatkovno orijentirani servisi dobe puno diskova…)
  • Poboljšana izolacija grešaka (bug može ubit jedan servis, ali neće cijelu aplikaciju)

Ali i drugu stranu medalje:

  •  Implementacija use-case-ova koji obuhvaćaju nekoliko servisa zahtjeva dobru koordinaciju timova koji rade na servisima
  • Kompleksnost raste zbog distribuiranog sistema
  • Potrebno uložiti dosta rada na među-servisnoj komunikaciji
  • Kompleksniji deployement; operativno

 

Praksa

Moje iskustvo s ovim konceptom je nešto duže nego što sam to mislio, jer u stvari nisam odmah imao pravo ime za to. U domeni tehničke zaštite kada se radi o kompleksnijem integracijskom rješenju opreme različitih dobavljača s kojima sustav simultano komunicira, gdje postoji veliki broj međusobno nekompatibilnih sustava sa brdo ovakvih ili onakvih third-party biblioteka od kojih su neke nativne, neke ne, neke zahtijevaju visoku propusnost (video analitika), neke ne (mjerni senzori), neke rade odlično, a neke malo manje dobro, Microservices koncept se nameće kao prirodno rješenje, tim više ako u kontekst uključimo stvarne zahtjeve:

  • Sustav mora biti skalabilan/distribuiran: od jednostavnije kontrole pristupa za zgradu do velikih i distribuiranih Building Management Sustava
  • Endpoint servisi i njihova implementacija ovisi o funkcionalnostima koje definiraju partneri, te je za očekivati kontinuirane nadogradnje pojedinih podsustava i uvođenje novih funkcionalnosti
  • Savki podsustav je funkcionalno zaokružen i u pravilu ne ovisi o drugim podsustavima, no domenska logika naslanja se na sumi funkcionalnosti uključenih podsustava
  • Implementacija load-balancing / fail-safe mehanizama

Korištenje ovakve arhitekture definitivno ima dodatni benefit da održava dizajn aplikacije 'čistim', jer dok kod monolitnih aplikacija (kad bi zagustilo) bilo je previše lako zakrpat stvar direktnim pozivima između modula/layer-a koji nisu inicijalno bili tako dizajnirani. Na taj način smo si možda 'spasili dan', ali dizajn trpi i kad tad će nam taj potez doći na naplatu. Microservices ovakva 'triper' rješenja ne dozvoljava.

Za kraj

Možda najzahtjevniji segment kada se koristi ovakva arhitektura je definiranje smjernica kako adekvatno segmentirati aplikaciju i kako definirati jasne service boundaries. Ja sam imao sreću da me veličina i domena projekta uvela u Microservices na mala vrata, jer je intuitivno definirala funkcionalnosti po kojoj se treba skalirati, ali bilo bi lijepo vidjeti kako su ispod haube to napravili Netflix, Amazon ili eBay…

Također, uz Microservices dosta se paralela poteže na nivou: Continuous Deployment = Continuous Delivery -> Business innovation?  No to je ipak posebna tema za sebe.

Usporedbu sa SOA (Services Oriented Arhitecture) sam izbjegavao u ovom kratkom pregledu, jer na netu postoji podosta rasprava oko toga koja je fundamentalna razlika između SOA i Microservices, te iako se nekako iskristalizirao stav da je Microservices fino strukturirani SOA, u finalu ono što je najvažnije je to da ste odabrali adekvatan čekić za vaš čavao. 

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone benchmark BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta