Mis on parem: mikroteenused või monoliitrakendused?

Ei ole universaalset "parimat" lahendust. Valiku mikroteenuste ja monoliitide vahel sõltub projekti konkreetsetest vajadustest, selle mahust, meeskonnast ja ärieesmärkidest.

Monoliit

• Eelised:
  • Lihtsam alguses arendamisel.
  • Lihtsam testimisel ja silumiseks.
  • Vähem lisakulusid infrastruktuurile ja kommunikatsioonile.
  • Lihtsam korraldada transaktsioone.
• Miinused:
  • Eraldi komponentide skaleerimine on keeruline.
  • Muudatused ühes moodulis võivad mõjutada teisi.
  • Erinevate tehnoloogiate kasutamine erinevates rakenduse osades on keeruline.
  • "Big ball of mud" kasvades.

Mikroteenused

• Eelised:
  • Lihtsam skaleerida üksikuid teenuseid.
  • Võimaldavad kasutada erinevaid tehnoloogiaid erinevates teenustes.
  • Lihtsustavad teenuste sõltumatut juurutamist.
  • Suurendavad vastupidavust rike (ühe teenuse rike ei pruugi mõjutada teisi).
  • Toetavad agiilset arendust suurtes meeskondades.
• Miinused:
  • Arendus- ja halduskeerulisus.
  • Suurem infrastruktuuri kulu (võrk, API Gateway, Service Discovery).
  • Keerulisem testimine ja silumine hajutatud süsteemis.
  • Probleemide lahendamine hajutatud transaktsioonidega.
  • Vajavad kõrgelt kvalifitseeritud meeskonda.

Millal mida kasutada:

• Monoliit: Start-upid, väikesed projektid, kui turule jõudmise kiirus on kriitiline, meeskonnad piiratud kogemusega mikroteenuste valdkonnas.
• Mikroteenused: Suured, keerulised rakendused, mis nõuavad skaleerimist, meeskonnad kogemustega hajutatud süsteemide valdkonnas, kui on vaja kasutada erinevaid tehnoloogiaid.

Tihti alustatakse monoliidist ja kasvades jagatakse see mikroteenusteks ("Strangler Fig" strateegia).

# Näide monoliidi juurutamisest
docker build -t my-monolith .
docker run -p 8080:80 my-monolith

# Näide kahe mikroteenuse juurutamisest
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

Võrdlustabel:

Omadus	Monoliit	Mikroteenused
Algne arendus	Lihtsam	Keerulisem
Mõõtmete suurendamine	Keeruline	Kergem (teenuste kaupa)
Muutused	Kõrge mõju risk kogu süsteemile	Madal risk (piirides teenust)
Tehnoloogiad	Tavaliselt üks	Võimalik kasutada erinevaid tehnoloogiaid
Juhtimine	Üks tervik	Sõltumatu teenustena
Stabiilsus	Madal (üks rikepunkt)	Kõrge (ühe teenuse rike ei ole kriitiline)
Infrastruktuur	Lihtsam	Keerulisem (vajalikud täiendavad komponendid)
Meeskonnad	Paremini väikestele	Paremini suurtele (sõltumatud meeskonnad)

Valik peaks põhinema teadlikul analüüsil projekti nõuetest. Hübriidlahendused on samuti võimalikud.