Kas geriau: mikroservisai ar monolitai?

Nė vieno universalaus „geriausio“ sprendimo nėra. Pasirinkimas tarp mikroservisų ir monolitų priklauso nuo projekto konkrečių poreikių, jo masto, komandos ir verslo tikslų.

Monolitas

• Privalumai:
  • Paprasčiau pradžioje kurti.
  • Paprasčiau testuoti ir klaidas taisyti.
  • Mažesnės išlaidos infrastruktūrai ir komunikacijai.
  • Lengviau organizuoti transakcijas.
• Trūkumai:
  • Sudėtingiau mastelį didinti atskiriems komponentams.
  • Pakeitimai viename modulyje gali paveikti kitus.
  • Sudėtingiau naudoti skirtingas technologijas skirtingose programėlės dalyse.
  • „Big ball of mud“ augant.

Mikroservisai

• Privalumai:
  • Lengviau mastelį didinti atskiriems servisams.
  • Leidžia naudoti skirtingas technologijas skirtingiems servisams.
  • Palengvina nepriklausomą diegimą.
  • Didina atsparumą gedimams (vieno serviso gedimas nebūtinai paveiks kitus).
  • Skatina agile vystymąsi didelėse komandose.
• Trūkumai:
  • Sudėtingiau kurti ir valdyti.
  • Didesnės infrastruktūros išlaidos (tinklas, API Gateway, Service Discovery).
  • Sudėtingiau testuoti ir taisyti klaidas paskirstytame sistemoje.
  • Problemos su paskirstytomis transakcijomis sprendimas.
  • Reikalauja aukštos kvalifikacijos komandos.

Kada naudoti:

• Monolitas: Startuoliai, mažos projektai, kai rinkos išėjimo greitis yra kritiškas, komandos su ribota patirtimi mikroservisų srityje.
• Mikroservisai: Didelės, sudėtingos programėlės, kurioms reikalingas mastelis, patyrusių komandų, dirbančių paskirstytose sistemose, kai reikia naudoti skirtingas technologijas.

Dažnai pradeda nuo monolito ir augant jį skaidina į mikroservisus („Strangler Fig“ strategija).

# Monolito diegimo pavyzdys
docker build -t my-monolith .
docker run -p 8080:80 my-monolith

# Dviejų mikroservisų diegimo pavyzdys
docker build -t user-service ./user-service
docker build -t product-service ./product-service
docker run -d -p 8081:80 user-service
docker run -d -p 8082:80 product-service

Lyginamoji lentelė:

Savybė	Monolitas	Mikroservisai
Pradinis vystymas	Paprastesnis	Sudėtingesnis
Mastelis	Sudėtingas	Lengvesnis (pagal paslaugas)
Pakeitimai	Aukštas rizikos lygis visam sistemai	Žemas rizikos lygis (paslaugos ribose)
Technologijos	Dažniausiai viena	Galima naudoti skirtingas technologijas
Diegimas	Vienas visuma	Nepriklausomas pagal paslaugas
Atsparumas	Žemas (viena klaidos vieta)	Aukštas (klaida vienoje paslaugoje nėra kritinė)
Infrastruktūra	Paprastesnė	Sudėtingesnė (reikalingi papildomi komponentai)
Komandos	Tinka mažoms komandoms	Tinka didelėms (nepriklausomos komandos)

Pasirinkimas turi būti sąmoningas ir pagrįstas projekto reikalavimų analize. Taip pat galimi hibridiniai požiūriai.