Micro services

I denne artikel vil jeg undersøge følgende omkring Microservices:

• Sammenlign Monolit og Distribuerede systemer
• Vis system diagrammer over monolitiske og simple distribuerede systemer
• Hvad er årsagen til at distribuerede systemer har udviklet sig til microservice arkitekturer?
• Hvordan kan en microservice arkitektur ud?

Monolitiske og distribuerede systemer

Før jeg vil gå i dybden med Microservices vil jeg først ridse op hvad monolitiske og distribuerede systemer er. Dette vil give en bedre forståelse for hvorfor Microservices er så populære. Den primære forskel mellem monolitiske systemer og distribuerede systemer er deres anatomi. En Monolit er ligesom en krop med et hoved som er databasen, der opbevarer alt hvad der skal huskes. Et distribueret system består af flere dele som medfører fordele og ulemper.

Monolitisk system

En monolit kan være god at bruge i et team som har brug for at levere en prototype hurtigst muligt. Som vist på billedet nedenfor kan en monolit være komplet og bestå af alle ønskede funktioner, men stadig være kompakt og simpel.

Fordele

• De er ofte nemmere at udvikle og implementere, da alle komponenter er samlet i en applikation og samtidigt er applikationen lille.
• Det kan give momentum ved at levere en prototype hurtigt.
• Det kan være nemmere at fejlsøge og debugge når det er samlet i en applikation.
• Monolitisk applikation vil oftest være hurtigere, da man ikke er begrænset af netværkshastighed.
• Deployment kan være nemmere fordi der kun er en applikation som skal i udgives.

Ulemper

• Kan give udfordringer i produktion, fordi at bare en fejl et sted i systemet kan crashe hele systemet.
• Det kan være sværere at skalerer, fordi hele applikationen skaleres som en enhed.
• Efterhånden som applikationen vokser kan den blive sværere at vedligeholde, fordi alle ændringer små som store kan påvirke hele systemet.
• Som applikationen vokser, kan udviklingshastigheden falde da det bliver sværerer for teams at arbejde parallelt uden at forstyrre hinanden.

Distribueret system

Et distribueret system består af flere selvstændige komponenter, som arbejder sammen for at levere en samlet pakke. Komponenterne kan køre på forskellige maskiner og kommunikerer typisk via netværk.

Fordele

• Hver komponent kan skaleres, hvilket gør det nemmere at håndtere belastning og forbedre ydeevnen.
• Udviklingere kan arbejde på forskellige komponenter på samme tid uden at forstyrre hinanden.
• Fejl i en komponent påvirker ikke nødvendigvis hele systemet, hvilket derfor øger systemets stabilitet.
• Mulighed for at bruge forskellige teknologier til forskellige komponenter, alt efter hvad der passer bedst til den specifikke funktion.
• Det er nemmere at vedligeholde og opdatere systemet, da ændringer i en komponent ikke nødvendigvis påvirker de andre komponenter.

Ulemper

• Øget behov for kommunikation og dataudveksling som gør udviklingen langsommere.
• Det kan være sværere at administrere et distribueret system sammenlignet med en monolitisk applikation.
• Systemets ydeevne kan påvirkes af netværkshastighed og stabilitet.
• Håndteringen af data og transaktioner på tværs af komponenter kan være indviklet.
• Deploymentprocessen kan være mere kompleks, da hver komponent skal implementeres og konfigureres rigtigt ift. hinanden.

Microservices

Microservices fungerer lidt ligesom legeklodser, hvor hver service fungerer som en separat klods, der kan udvikles og vedligeholdes enkelstående. Dette designmønster gør det muligt for teams at arbejde på forskellige tjenester uden at påvirke hinanden hvilket øger fleksibiliteten og effektiviteten.

Skalerbarhed er endnu fordel ved microservices. Hver service kan skaleres uafhængigt af hinanden, hvilket gør det muligt at håndtere belastning og forbedre ydeevnen uden at påvirke hele systemet. Dette er bl.a. nyttigt i komplekse systemer, hvor forskellige dele af applikationen kan have brug for forskellige belastning.

En anden vigtig egenskab ved microservices er deres løse kobling. Tjenesterne designes til at være uafhængige af hinanden, hvilket betyder at ændringer i en service ikke altid kræver ændringer i andre tjenester. Dette gør det nemmere at implementere og vedligeholde systemet henover tid.

Microservices er ikke afhængige af en specifik teknologi. Hver service kan udvikles med forskellige teknologier og programmeringssprog, alt efter hvad der passer bedst til den specifikke funktion. Dette giver udviklerne mulighed til at vælge de bedste værktøjer til de forskellige opgaven. Det er også en fordel for personalegrupper som kun kan bestemte sprog.

Tolerance overfor fejl er en anden egenskab ved microservices. Fejl i en service påvirker ikke nødvendigvis hele systemet, hvilket øger systemets stabilitet. Dette gør det nemmere at isolere og rette fejl uden at forstyrre resten af applikationen. Når microservices kommunikere over netværk istedet for internt på en maskine, kan dette også introducere mange flere fejl. Så det er en overvejelse man skal gøre sig for at få succes med microservices.

Udfordringer ved microservices

Selvom microservices tilbyder en del fordele, er der også udfordringer med denne arkitektur. Kommunikation og dataudveksling mellem tjenester kan være kompleks og kræve grundig planlægning og implementering. Distribueret systemstyring kan være sværere at administrere sammenlignet med en monolitisk applikation. Håndtering af data og transaktioner på tværs af tjenester kan også være svære og kræve avancerede teknikker og værktøjer.

Microservices er en populær tilgang til at bygge skalerbare og fleksible applikationer, især i store og komplekse systemer. Ved at forstå både fordelene og udfordringerne ved microservices kan udviklere træffe bedre beslutninger om, hvordan de bedst kan implementere arkitekturen i deres projekter.

Nedenfor er et eksempel på arkitekturen bag en microservice applikation.

Refleksion

Efter at have dykket ned i Microservice, vil jeg vurdere at jeg fremadrettet vil starte de fleste software projekter med en monolitisk struktur. Det vil jeg gøre for at kunne levere en prototype hurtigere til kunden i stedet for at introducere en del unødvendige kompleksiteter som vil følge med at starte en distribueret struktur fra starten.

Hvis projektet forventes enorm trafik fra første deployment, ville jeg overveje at starte med en microservice arkitektur for at vise kunden at systemet er stabilt fra starten. Det vil dog altid være en vurdering fra projekt til projekt, men min umiddelbare tanke er at starte med en monolitisk arkitektur.

Kilder:

https://microservices.io/patterns/microservices.html (opens in a new tab)

https://martinfowler.com/microservices/ (opens in a new tab)

https://learn.microsoft.com/en-us/azure/architecture/microservices/ (opens in a new tab)

Microservices Architectures fra Tryhackme (opens in a new tab)