Hvad er microservices?

  • #knowhow
Nr. 23 22.04.2021

Microservices er en af mulighederne for den arkitektoniske opbygning af et system. I korte træk handler det om at få fordelt ansvaret ud i mindre bidder.

Monolitisk arkitektur

Monolitisk arkitektur er en software arkitektur, som i sagens kerne er meget simpel: et website der håndterer data i en database. Det er den mest simple tilgang til en arkitektonisk opstilling.

Behandling af eksempelvis produkter, brugere og statistikberegninger er noget som websitet står for - derfor giver det mening, at websitet også skal stå for de bagvedliggende databehandler og -udtræk. Ved at vælge denne arkitektur opnås der mindre udvikling, og der er, helt naturligt, et mindre lag af områder hvor fejl kan opstå.

Begrænset integration

Den simple arkitektur kommer dog med en pris. Faktisk løber man ind i problemer allerede ved integrationen til andre systemer. Det kunne eksempelvis være en webshop, som har sine produkter i en Product Information Manager (PIM) eller en informationsside om medarbejdere, hvor al data allerede er tilgængeligt i et intranet.

I begge tilfælde kan der være tale om enorme mængder af data, som man ikke ønsker at opstille igen. Desuden er det ikke sikkert man kan stole på de andre systemer. Alle systemer kan opleve fejl og hvis et af de to systemer er nede betyder det, at man har et website uden indhold. Endvidere kan en udskiftning eller videreudvikling af de andre systemer betyde massere af udviklingsarbejde på websitet - netop fordi den valgte arkitektur betyder, at al funktionalitet er placeret ét sted.

Begrænset skalering

Integrationer bliver altså hurtigt et problem, men det samme gør muligheden for skalering. Når alt er samlet ét sted går der ikke lang tid før det bliver for meget arbejde - både for en udvikler men også for systemet selv. Man kan sammenligne det med et rum i et hus. Det er ét rum og det sætter rammerne for det område det er designet til - man kan godt tilføje elementer til rummet og derved udvide dets formål, men kun til en vis grænse. Alle husets rum kan ikke være på ét og samme sted, selvom man vælter et par vægge. Man har behov for at dele rummene op. Der er brug for en distribuering - sagt på en anden måde; der er behov for at uddelligere ansvar. 

Monolitisk arkitektur er en simpel arkitektur, hvor websitet henter data direkte i databasen.

Distribueret monolitisk arkitektur

Den simple tilgang til en løsning af problemet ved den monolitiske arkitektur er med en distribueret monolitisk arkitektur. Ved denne opstilling er det stadig websitet der står for langt den største del af ansvaret, men der er ved denne arkitektur opnået hjælp til noget af datahåndteringen. 

Helt konkret opstilles der nu små separate applikationer, der sørger for at hente data ud af eksterne systemer og ligge det ned i websitets lokale database. Dermed er ansvaret opdelt, så man kan tilpasse koden i den applikation hvorved noget evt. fejler.

Dette er en rigtig god arkitektur, og det er ligeledes et valg der bliver taget på en del projekter. Vores bedste eksempel er udbudshuset.dk. Det er en løsning, som består af mere end 10 separate applikationer, som alle har hver deres speciale og ansvar. Årsagen til arkitekturvalget her, er at alle applikationerne anvender samme datalag. Det er altså én applikation, som styrer kommunikationen for alle de andre applikationer. Helt præcist betyder det, at sådan et system har et stort behov for sikkerhed og ved at samle det hele ét sted kan adgangen til dets data styres meget enklere.

Læs vores case om Udbudshuset

Hvis vi tager fat i eksemplet fra før omkring et rum i et hus vil den distribuerede monolitiske arkitektur svare til, at man godt må gøre brug af andre rum og værelser - men huset har den størrelse det nu engang har. Helt præcist betyder det at man på et tidspunkt vil komme til kort for man kan ikke skalere yderligere. Eksemplet her er simplificeret, men pointen er valid; valget på denne arkitektur kan altså ende med at blive på bekostning af, hvad man havde af fremtidige ønsker for sit projekt. 

Distribueret monolitisk

Distribuerede microservices

Det er altså grundet de belyste problemstillinger med de andre arkitekturformer, der gør at microservices kan være det rette valg. Ved denne arkitektur beholdes de forskellige applikationer til integrationer - det er i stedet for databasehåndteringen der kigges på. Når alt data skal hives af websitet ét sted fra, vil der helt naturligt opstå en flaskehals på et tidspunkt. Løsningen er at give hver applikation sin egen database - som endda kan være af den type, som indholdet bedst arbejder i. Det betyder, at webshoppens produkter vil passe godt til Algolia, mens medarbejderne fra intranettet kan være i en RavenDB, hvilket vil resultere i et website, der arbejder hurtigere. 

Distribuerede microservices skaber mulighed for at skalere, erstatte, modificere og optimere uden det påvirker andet, end ligepræcis dét som der arbejdes med. På dansk betyder det, at man erstatter den store maskine som kan alt, med mange små der til sammen kan det samme. 

Ulempen ved arkitekturen er kravet om flere databaser og servere, da der kræves separate systemer. Dette giver dog i sig selv også en fordel, da mindre kan gå galt ved separeret hardware. Desuden er det ikke nær det omfang af det tilfælde, hvor man er startet med en anden arkitektur og nu har behov for at mimere microservices. Det er altså vigtigt at overveje nøje hvilken type arkitektur, der vil passe til ens ambitioner for projektet.

Det rette værktøj til opgaven

Det blev tidligere fremhævet, at microservices tillader databasen at være præcis det format der fungerer bedst. Præcis det er fordelen med microservices, da man netop kan vælge det bedste værktøj til opgaven. Blandt udviklere er dette kendt som "best-of-breed". Valgfriheden er dog ikke begrænset til databasen. Fra applikation til applikation er det muligt at lave en individuel vurdering af hvilket værktøj og dertilhørende funktionaliteter, der passer bedst til den problemstilling, som skal løftes.

Case

Det er årsagen til at A-Hjort blev udviklet med microservices tilgangen. Der er her tale om en løsning med over 15 separate applikationer med hver deres ansvarsområde. Der er selve frontend applikationen, som er bygget i TypeScript med Vue og Nuxt, API’et der håndterer indkøbskurvene ligger på en Azure App Service, og de applikationer der håndterer integrationerne til de mere end 10 eksterne systemer er specialiserede Azure Functions.

Alle applikationerne er bundet sammen med Azure Storage Queues og Service Bus. Ved at have de mange små applikationer i stedet for en stor, resulterer i at frontenden er lynhurtig og ved spidsbelastninger kan frontend og api’er skaleres uafhængigt af de andre services. I den daglige drift giver det fordelen af, at alle ordrer bliver behandlet i samme hastighed - uanset om der er 100 brugere eller 10.000 brugere online på samme tid.

Læs vores case om A-Hjort

Distribuerede microservices

Hvilken arkitektur skal man vælge?

Modsat dets navns, så er microservices mega fedt. Vi sætter især stor pris på de adskilte applikationer, som giver mulighed for det bedste værktøj til opgaven. Der er også en enorm fordel i muligheden for skalering samt udskiftning og generel vedligeholdelse på et specifikt plan.

Som digitalt bureau sætter vi stor pris på et godt projekt med en solid kodebase - men hver ting til sin ‘tid’. Der er slet ingen grund til at være bange for den simple monolitiske tilgang. Den - og sammen med den distribuerede monolitiske arkitektur - har bestemt også sin ret. Det kommer helt an på projektet og de dertilhørende ambitioner for fremtiden. Ethvert projekt der kan bære blot en snert af en microservices arkitektur vil altid få anbefalingen herfra. Så sætter man på forhånd bundniveauet højt og det bliver lettere at vedligeholde projektet senere. 

Hvad så nu?

Vi vil altid rådgive om valget på den ene eller anden tilgang - men det kan være til stor gavn at have dannet sig nogle tanker på forhånd om, hvor man egentlig gerne vil have websitet skal hen. Hvilke integrationer og funktionaliteter ser man realistiske i fremtiden? Er det et websted, som typisk håndterer mange brugere på samme tid? Det kan vise sig, at være den helt rette økonomiske tilgang, at skabe sig nogle tanker om fremtiden, og det system man skal skabe.