Overveje fordele og ulemper ved at anvende Microservices kontra en monolitisk arkitektur.

Indsamle viden og vurdere forskelle mellem monolitisk- og microservice-arkitektur for applikationer. Overveje hvilke fordele og ulemper der er ved de to forskellige typer.

Monolitisk arkitektur
En applikation, som er bygget med monolitisk arkitektur, er en enkelt enhed, hvor alle komponenter er samlet ét sted. Det betyder, at interface, forretningslogik og dataadgangslag er udviklet, brugt og vedligeholdt som én samlet applikation. Dette er den traditionelle måde at udvikle software på og har flere fordele:

• Nem at komme i gang med: nye udviklere har kortere on-boarding-tid.
• Sikkerhed: færre access points betyder mindre risiko for angreb.
• Økonomi: ofte billigere og mere overskueligt for mindre virksomheder.
• Ydelse: mindre kommunikation mellem dele af systemet kan give bedre performance.
• Test: da hele koden er samlet ét sted, er det nemmere at teste end-to-end funktionalitet.
• Debugging: med al koden samlet ét sted er det lettere at følge en request igennem systemet.

Der er dog også klare ulemper ved monolitiske applikationer:

• Tæt kobling mellem lag: ændringer ét sted kan påvirke resten af systemet.
• Skalerbarhed: systemet skal skaleres som én enhed, hvilket kan være ineffektivt og ressourcekrævende.
• Downtime: ved deployment skal hele systemet ofte tages offline midlertidigt.
• Fleksibilitet: ændringer kræver typisk opdateringer i flere lag, hvilket øger risikoen for fejl og inkonsistens.

Microservices
Når vi taler om microservices, er det en tilgang hvor en applikation opdeles i en række små, selvstændige services, som kommunikerer over et netværk. Kommunikation kan eksempelvis foregå via Kafka (som jeg tidligere har skrevet om her), REST-API’er eller GraphQL. Hver microservice har sit eget ansvar – fx brugerautentificering, produkthåndtering eller billedanalyse.

Fordelene ved microservices inkluderer:

• Teknologivalg: hver service kan udvikles med den tech stack, der er bedst egnet til opgaven.
• Opdateringer: services kan opdateres uafhængigt af hinanden, hvilket reducerer downtime og øger effektiviteten.
• Skalerbarhed: systemet kan skaleres selektivt ved kun at tilføje ressourcer til de services, der har behov.
• Løs kobling: services er uafhængige af hinanden, hvilket gør systemet nemmere at vedligeholde.

Ulemperne ved microservices kan bl.a. være:

• Latenstid: jo flere services, desto større risiko for forsinkelse i kommunikationen.
• Datakonsistens: det kan være svært at sikre, at data forbliver konsistent på tværs af flere services.
• Kompleksitet: mere komplekst at udvikle, teste og vedligeholde et system med mange små dele og forskellige tech stacks.

Kilde: Atlassian – Microservices vs. Monolith

Det er tydeligt, at forskellene mellem monolitisk arkitektur og microservices er markante. For små projekter eller start-ups kan det give mening at begynde med en monolitisk struktur, da det er billigere, hurtigere at komme i gang med, og nemmere at håndtere. Når applikationen vokser, kan der dog være fordele ved at migrere til microservices, som giver bedre skalerbarhed og mulighed for at håndtere mere trafik og kompleksitet.

En udfordring kan være latenstid, når applikationen er opdelt i mange services. For vores mindre applikation er dette dog ikke kritisk. Derimod er det vigtigt, at vi dokumenterer tydeligt, hvordan vores services kommunikerer, så de kan fungere sammen. Test af funktionalitet end-to-end kan være en udfordring, da vi udvikler i forskelligt tempo, men det er en lærerig proces i sig selv.

I vores konkrete projekt giver microservices mest mening, da vi er et lille team, hvor hver især kan arbejde selvstændigt og integrere vores løsninger. Samtidig giver det fleksibilitet ift. at afprøve forskellige teknologier inden for hvert valgfag. Hvis jeg skulle lave et projekt i en anden kontekst, fx i en mindre virksomhed, ville jeg dog kunne argumentere for at starte med en monolit og først migrere senere. Denne refleksion gør, at jeg nu kan begrunde arkitekturvalg både teknisk og forretningsmæssigt.