Vi som jobber i teknologibransjen deltar i en evig runde med buzzwordbingo. Et av buzzwordene som stadig dukker opp er: Mikrotjenester. Men hva er det egentlig? Er det en eliksir som løser alle våre problemer, eller skaper det flere problemer enn det løser?
En mikrotjeneste tilbyr et sett med funksjonalitet innenfor sitt begrensede virksomhetsområde. For å lykkes med mikrotjenester, er man helt avhengig av å ha full oversikt over sitt domene. Dette krever at kunden har stålkontroll på egen forretning og hvilke avhengigheter man må ta hensyn til i en ny løsning. Utfordringen er at krav og avhengigheter ikke nødvendigvis er fastsatte ved prosjektets begynnelse og mest sannsynlig vil endre seg i løpet av prosjektfasen. Dette er helt naturlig. Erfaringsmessig er det også måten vi kommer frem til de beste løsningene på, men det krever fleksibilitet i arkitekturen slik at vi kan tilpasse oss underveis. Derfor mener jeg at man ikke ukritisk skal starte et prosjekt basert på en mikrotjenestearkitektur.
Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. — Martin Fowler
Design monolitten basert på mikrotjenestearkitektur
Så hvordan begynner du egentlig å designe et system etter en mikrotjenestearkitektur, som egentlig ikke baserer seg på en mikrotjenestearkitektur? Kontroversielt nok mener jeg at en monolittisk løsning ikke er en dum ide. Det er mange fordeler med en slik løsning i startfasen av et prosjekt. All kildekode ligger på ett sted fremfor at det er spredd over utallige repositories. Progresjonen i utviklingen er merkbart bedre nettopp på grunn av at man slipper å forholde seg til mange ulike løsninger. Samspillet og avhengighetene mellom dem, samt at refaktorering av kode er mye lettere. Men det gjelder å designe og kode med varsomhet. Vårt ultimate mål er, gitt at man ser behovet, å bryte opp monolitten vår i en mikrotjenestearkitektur.
“En god mikrotjenestearkitektur er Single Responsibility Principle i praksis.”
Noen enkle tips
- Moduliser løsningen din. Modulene skal reflektere kundens forretningsområder.
- Betrakt hver modul i løsningen din som en potensiell mikrotjenestekandidat.
- Ikke ha kryssreferanser mellom disse modulene, da blir det fort vanskelig å bryte modulene ut fra monolitten.
- La kommunikasjonen mellom modulene skje via en meldingsbuss eller andre protokoller.
Suksess i praksis
I mitt nåværende prosjekt hvor jeg sitter som tech lead, har vi fulgt de ovennevnte prinsippene med stor suksess. I starten av prosjektet hadde vi et klart og definert målbilde av hvor vi skulle. Teknologien, rammeverkene, miljø og ulike programmeringsspråk ble definert av utviklingsteamet i samarbeid med kunden.
Det vi ikke hadde var et totalbilde av de ulike forretningsområdene og avhengighetene mellom dem. Derfor utviklet vi en modulær monolitt og strukturerte kildekoden gjennom å lage flere rammeverksprosjekter.
Disse dekker ikke funksjonelle krav, men støtter oppunder komponenter og moduler som dekker dem. Da vi satte første versjon av løsningen i produksjon, kjørte hele applikasjonen som en modulær monolitt. Hver modul hadde sin egen database å forholde seg til. Den eksponerte sitt eget api hvor modulen var ansvarlig for versjoneringen av api’et, og all intern kommunikasjonen mellom modulene skjedde over en meldingsbuss og andre protokoller.
Fra monolitt til mikrotjenester
Et par måneder senere fant vi det naturlig å skille ut deler av løsningen i mikrotjenester. En av hovedgrunnene til dette, var at ulike tjenester krevde ulik skaleringsstrategi i Azure. Vi hadde flere tjenester hvor lasten var betraktelig høyere enn andre tjenester. Ønsket var også at deler av teamet skulle eie hele vertikalen for en tjeneste. Dette være seg alt fra implementasjon, produksjonssetting og drift.
Ettersom applikasjonen vår ble utviklet som en modulær monolitt, var det svært lett å bryte modulene ut fra monolitten og opprette mikrotjenester. Vi opprettet et nytt prosjekt, flyttet kildekoden over hit og satt opp nye bygg- og releasepipeliner basert på ferdigdefinerte maler.
Raskere og mer effektivt
Jeg har vært med på prosjekter hvor det har tatt månedsvis å omskrive deler av monolitten til mikrotjenester. Men fordi vi denne gangen hadde lagt til rette for dette allerede før vi begynte å utvikle, tok det oss bare en arbeidsdag å gå fra modulær monolitt til mikrotjenester i produksjon.
Ved å følge de ovennevnte prinsippene i ditt neste prosjekt, kan du ha større fokus på å levere funksjonalitet til din kunde fremfor å rette opp i teknisk gjeld ved overgangen til en mikrotjenestearkitektur.