Kas ir labāk: mikroservisi vai monolīti?

Nav universāla "labākā" risinājuma. Izvēle starp mikroservisiem un monolītiem ir atkarīga no konkrētajām projekta vajadzībām, tā mēroga, komandas un biznesa mērķiem.

Monolīts

• Priekšrocības:
  • Vienkāršāka izstrāde sākotnēji.
  • Vienkāršāka testēšana un atkļūdošana.
  • Mazāk papildu izmaksu infrastruktūrai un komunikācijai.
  • Vieglāk organizēt transakcijas.
• Trūkumi:
  • Grūti mērogot atsevišķas sastāvdaļas.
  • Izmaiņas vienā modulī var ietekmēt citas.
  • Grūti izmantot dažādas tehnoloģijas dažādām lietojumprogrammas daļām.
  • "Big ball of mud" pie izaugsmes.

Mikroservisi

• Priekšrocības:
  • Vieglāk mērogot atsevišķus pakalpojumus.
  • Atļauj izmantot dažādas tehnoloģijas dažādiem pakalpojumiem.
  • Atvieglo neatkarīgu pakalpojumu izvietošanu.
  • Palielina izturību pret kļūdām (viena pakalpojuma kļūme ne vienmēr ietekmē citus).
  • Veicina agilās izstrādes pieejas lielās komandās.
• Trūkumi:
  • Sarežģītāka izstrāde un pārvaldība.
  • Augstākas papildu infrastruktūras izmaksas (tīkls, API Gateway, Service Discovery).
  • Sarežģītāka testēšana un atkļūdošana izplatītā sistēmā.
  • Risinājumi izplatītu transakciju problēmām.
  • Prasa augstu komandas kvalifikāciju.

Kad ko izmantot:

• Monolīts: Startapi, nelieli projekti, kad ir kritiska laika tirgū izejai, komandām ar ierobežotu mikroservisu pieredzi.
• Mikroservisi: Lieli, sarežģīti lietojumprogrammas, kas prasa mērogošanu, komandām ar pieredzi ar izplatītām sistēmām, kad nepieciešams izmantot dažādas tehnoloģijas.

Bieži sāk ar monolītu un ar izaugsmi to sadala mikroservisos ("Strangler Fig" stratēģija).

# Monolīta izvietošanas piemērs
docker build -t my-monolith .
docker run -p 8080:80 my-monolith

# Divu mikroservisu izvietošanas piemērs
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

Salīdzināšanas tabula:

Raksturlielums	Monolīts	Mikroservisi
Sākotnējā izstrāde	Vienkāršāka	Sarežģītāka
Mērogošana	Grūti	Vieglāk (pa pakalpojumiem)
Izmaiņas	Augsts ietekmes risks uz visu	Zems risks (robežās ar pakalpojumu)
Tehnoloģijas	Parasti viena	Iespējamas dažādas tehnoloģijas
Ieviešana	Vienots veselums	Neatkarīgs pa pakalpojumiem
Noturība	Zema (viena kļūdas punkta)	Augsta (viena pakalpojuma kļūme nav kritiska)
Infrastruktūra	Vienkāršāka	Sarežģītāka (papildu komponentes nepieciešamas)
Komandas	Labāk nelielām	Labāk lielām (neatkarīgas komandas)

Izvēle jābalsta uz apzinātu analīzi par projekta prasībām. Hibrīdmetodes ir arī iespējamas.