Hvad er microservices

Microservices er et af de hotteste buzzwords indenfor softwarearkitektur lige nu – det er en tilgang til softwareudvikling, der kommer som en direkte videreudvikling af serviceorienteret softwarearkitektur og til dels også agil-/scrum-baseret projektledelse.

Microservices er en god måde at opbygge software på, hvis du er interesseret i:

• • At sætte forretningens behov i centrum
  • At reducere time-to-market for nye features med continuous delivery
  • At kunne vælge det bedste værktøj til hver enkelt opgave
  • Fleksibel software, som kan videreudvikles i årevis

• Uendelig skalering
• Bedre kommunikation mellem forskellige systemer
• Forenkling af forretningsprocesser
• At kunne genbruge services og fokusere på udvikling af kritiske, nye elementer

Vandfaldsmodellen

I mange gik monolitten og vandfaldsmodellen hånd i hånd og udvikling foregik i (ofte lange) fastlåste faser med en større implementering i enden. For at have historikken på plads, kommer her en kort gennemgang af den tilgang til udvikling – hvis du har helt styr på den, så kan du springe de to næste afsnit over og gå direkte til ”Alternativet: microservices”.

Vandfaldsmodellen går i korte træk på at bygge komplette systemer i en samlet proces. Du kan sammenligne det med at bygge et hus, hvor du går gennem faserne specifikation, design, implementering, test, integration og vedligeholdelse. Når vandfaldet så er færdigt, er tanken, at du står med et færdigt hus, der lever op til alle de opsatte krav.

Det giver et meget langt feedback loop (hvis der overhovedet er et feedback loop) og dermed en risiko for at udvikle i en forkert retning og bruge mange resurser på det. Har du for eksempel taget et forkert valg i designprocessen eller overset noget i kravspecifikationen, så kan der gå måneder før det bliver rettet. Typisk går vandfaldsmodellen hånd i hånd med mindre frekvente deployments (eller endda Big Bang), hvilket også betyder at du kommer til at have mange timers arbejde (design, kode og så videre) til at ligge “dødt” i et testmiljø.

Hvad er en monolit?

Monolitten er betegnelsen for en samlet, selvunderstøttet softwarearkitektur. En applikation, der rummer alle delene af din software i en udelelig komponent.

I takt med at computere og internet er blevet hurtigere og software har fået en større betydning i mange virksomheder, er begrænsningerne ved monolitten blevet tydelige: arkitekturen kommer til kort for softwareløsninger, der skal dække flere forretningsområder, eller i applikationer, der bruger flere forskellige teknologier. Det er, lidt forenklet, en softwarearkitektur, der hører en tid med mindre applikationer til.

Alternativet: microservices.

Kort fortalt er microservices en måde at opbygge en softwareapplikation på, hvor udgangspunktet er at se på den som en samling af mindre tjenester, der alle kører deres egne processer og kommunikerer via simple mekanismer – oftest et API. Hvor du kan se en monolit som en samlet struktur, er microservices mere som LEGO-klodser. Det kan eksempelvis være en loginklods, en playliste-anbefalingsklods eller en betalingsklods.

Det giver fleksibilitet i udviklingen, fordi kommunikationen tjenesterne imellem er skarpt defineret via deres API. Derfor kan du bruge den rigtige teknologi til den enkelte tjeneste i stedet for at bruge den teknologi, som tjener hele systemet bedst. Med microservices får du frihed til at vælge .NET baserede programmeringssprog, Python, eller Java eller noget tredje. Baseret på, hvilken teknologi der er bedst til den enkelte tjeneste. Du har også  frihed til at vælge den bedste cloud platform, den bedste database, den bedste webserver etc.

Fordi den enkelte microservice er lille, og har en meget klart defineret grænseflade, kan microservicen opdateres uafhængigt af resten af systemet. Dermed kan hele systemet løbende tilføjes nye features eller fejlrettelser. I modsætning til monolitten, hvor nye features leveres ved en opdatering af hele systemet, med hvad dertil hører af procedurer og nedetid, kan microservices levere nye features til slutbrugerne hver uge, hver dag eller hver time.

Hvordan defineres en microservice?

En microservice er en softwarekomponent, der kan udskiftes og opgraderes uafhængigt. Der er ikke nogen hård definition på størrelsen, så det er op til arkitekten at sikre at de enkelte moduler er tilpas små og uafhængige til, at de kan opgraderes og deployes hurtigt.

En microservicearkitektur har et minimum af central styring og kan bruge forskellige teknologier til at opbevare data – mere om det i næste afsnit.

For at opsummere, så er en microservice kendetegnet ved:

• Et velafgrænset modul i en applikation eller et system
• Uafhængigt opgraderbar og udskiftelig
• Ikke bundet til specifik teknologi
• Begrænset i omfang – dækker en specifik, afgrænset funktion
• Tilgængelige kontaktflader

Og så er der skalerbarheden, der ofte følger med – de enkelte moduler i applikationen er uafhængigt skalerbare, fordi de ikke behøver at bruge samme tekniske setup.

”Microservices is a label, not the description”. Citat: Martin Fowler i denne artikel.

Microservices og cloud – det perfekte par

Du kan godt køre en microservicebaseret applikation on premise, men i langt de fleste tilfælde ligger den serviceopdelte arkitektur i skyen. Det gør den især fordi cloud infrastruktur støtter op om en af microservicearkitekturens styrker – den uafhængige og dynamiske skalerbarhed.

Hvor en monolit skaleres ved at køre hele systemet på kraftigere servere, kan du med microservices nøjes med at skalere de specifikke moduler, du har behov for. Det giver dig et mere fleksibelt og et billigere setup.

Hvor monolitten er en stor supertanker, kan du se microservices-applikationen som en flåde af samarbejdende speedbåde, der hver især kan sejle hurtigere eller langsommere end resten af flåden. Synergien mellem de dynamiske cloud-muligheder og den opdelte softwarearkitektur i microservices giver en manøvredygtighed som aldrig før.

Microservices er en meget velegnet tilgang, hvis du har en lokal monolit, du gerne vil have i en cloud tjeneste: du bryder gradvist monolitten ned i microservices, og flytter dem løbende til en cloudplatform.

Microservices og DevOps – den korteste vej

Her er endnu et eksempel på to principper, der passer enormt godt sammen. DevOps indebærer kontinuerlig overvågning, test og deployment af softwaren. Microservices er modulære i deres natur, fordi de er designet til at udføre en afgrænset funktion.

Modulære software passer godt ind i DevOps-strukturen, fordi du, med gode servicekontrakter og kontrolmekanismer kan bygge, opgradere, teste, deploye og overvåge en specifik microservice. Uden at sende en tsunami af bugs gennem resten af din applikation.

Nogen ville mene at DevOps kræver en serviceopdelt softwarearkitektur, men det behøver ikke være helt så firkantet. Det er dog indiskutabelt at de to principper spiller meget godt sammen.

I fællesskab giver de dig mulighed for at bygge og opgradere software hurtigt, nemt og med lav risiko. Kombinerer du det med effektive arbejdsprocesser, får du den korteste vej fra forretningsudvikling til softwareudvikling.

Decentraliseret styring og datahåndtering

Hvor en monolitisk applikation bygges med en central database, ligger databaserne i en microservices-arkitektur decentralt sammen med de enkelte services. De enkelte moduler kan enten dele en database eller have deres egen. Det kan være forskellige instanser af den samme databaseteknologi, men det kan også være bygget på forskellige teknologier – såkaldt ”polyglot persistence”.

Polyglot persistence kan bruges i en monolitisk arkitektur, men forekommer oftest med microservices fordi den softwarearkitektur støtter op om individuelle teknologivalg for de enkelte moduler.

At decentralisere styringen med data påvirker den måde, du kan opdatere de enkelte moduler på. Historisk set har opdateringer krævet skarpt fokus på at alle dele af monolitten fortsat kan kommunikere med hinanden – med microservice-arkitekturen skal API’er holdes konstante, men udover det påvirker opdateringer af de enkelte moduler ikke resten af applikationen.

Risikostyring

Kontinuerlig deployment og konstant feedback giver sikkerhed for stabilitet af den samlede applikation og prioritering af udviklingstid. Hvis du konstant deployer små opdateringer, er det nemmere at se, hvis noget giver problemer. Det er nemmere at gå tilbage til en tidligere version uden at flere måneders arbejde går tabt.

Men der er flere fordele i forhold til risikostyring. Klart definerede services med definerede API’er er ikke integrerede i samlede system, som en monolitisk applikation. Det betyder, at risikoen for at hele applikationen bliver ustabil mindskes drastisk. Typisk vil problemer, der opstår i en afgrænset service også have afgrænsede implikationer i produktionsmiljøet.

En afledt fordel ved at bruge services modulært er, at de skal kunne håndtere at andre tjenester ikke svarer. Her bevæger vi os ind på en af de ting, der gør, at du skal holde tungen lige i munden, når du bygger microservices.

Forbered hver enkelte service på det værste

Det er vigtigt, at sikre at alle komponenter kan håndtere, hvis andre komponenter ikke svarer. Helst på en måde, så brugeren så vidt muligt ikke opdager noget. Det betyder at udviklerteams der arbejder med microservices konstant skal tænke over, hvordan eventuelle fejl skal håndteres. Nogle teams arbejder endda med automatiske og planlagte kaostilstande i produktionsmiljøet, for at sikre, at monitoreringstjenester fanger alle problemer.

Alle services altid kan fejle, derfor er det vigtigt at opdage fejlene hurtigt og reagere på dem. Sofistikerede monitoreringssystemer, der kigger på både strukturelle- og forretningsmetrikker er derfor en helt essentiel del af en microservicebaseret softwarearkitektur.

Små, løbende justeringer

En af grundene til at microservices er blevet så populære er, at arkitekturen ligger i direkte forlængelse af agil softwareudvikling ved at understøtte korte feedbackloops. Du kan konstant forbedre, justere og fejlrette i enkelte elementer i din applikation.

Med korte feedback loops bliver din udvikling meget mere manøvredygtig – det svarer til at tage mange korte skridt i stedet for få lange skridt – bortset fra, at agil udvikling ikke er langsommere end klassisk vandfaldsudvikling.

Agil udvikling er inspireret af LEAN-princippet fra Toyotafabrikkerne. Helt grundlæggende er tanken, at jo mindre arbejde du har i gang, desto mindre må du smide væk, hvis du skal skifte retning. Det understøttes typisk af sprints der, i Scrum-baseret udvikling, maksimalt varer en måned. Det står i skarp kontrast til vandfaldsmodellen, der ofte løber over både 3, 6 og 12 måneder. Med continuous integration/delivery er det ikke utænkeligt at deploye ny kode til produktion 5-10 gange om dagen. Det giver dig en ekstrem manøvredygtighed i forretningen.

Det betyder primært to ting:

• At du meget hurtigere kan rette op på fejl og komme tilbage på sporet
• At det er markant hurtigere at skifte retning, hvis forretningens behov ændrer sig (og det gør de!)

Det er to temaer, der gennemsyrer hele microservices-tilgangen – bevægelighed og fokus på forretningens behov. To helt essentielle faktorer i det nuværende og fremtidige digitale landskab.

Hvor stor er en microservice?

Der findes ikke en størrelse, men der er en guideline: den skal kunne skiftes ud og opgraderes uafhængigt. Det betyder også, at hvis du tit opgraderer de samme to services samtidig, skal du overveje at slå dem sammen.

Det er ikke et mål i sig selv at bryde applikationen op. Målet er at bruge den softwarearkitektur, der bedst kan støtte op om forretningen.

Det betyder ofte, at de enkelte services afgrænses af forretningsmæssig organisation – centreret omkring produkter, tjenester eller særlige opgaver. Derfor undgår du interessekonflikter internt i virksomheden. Det bliver også nemmere at prioritere og scope den enkelte service, når de er uafhængige af resten af applikation.

Et eksempel: du opgraderer den del af din applikation, der sikrer, at lagerstatus og tilgængelighed på hjemmesiden er synkroniseret. Kundeservice er glade for den nye feature – den giver færre utilfredse kunder. Salg derimod, anser det ikke for væsentligt nok til at køre en fuld deployment med den risiko det indebærer. Salg vil gerne have, at hjemmesiden er oppe 100% af tiden.

I det scenarie er microservice-arkitekturen perfekt. Det nye modul påvirker ikke eksisterende funktioner og bør derfor ikke give nogen udfordringer.

I virkeligheden er ”micro-”-delen af microservices vildledende. Det er ikke størrelsen, der er vigtig – det er uafhængigheden, det skarpe fokus og de hårdt definerede grænseflader.

Opsummering: en microservice er stor nok, til at være uafhængig, men lille nok til at kunne opgraderes og justeres ”hurtigt”.

Er microservices fremtidens softwarearkitektur?

Microservices er en relativt ny måde at tænke på. Det er derfor ikke til at sige hvor vi er om 3, 5 eller 10 år. Men – der er dog nogle klare indikationer på, at konceptet kommer til at holde ved. Det er vigtigt at huske at det meste software bliver bygget med en ambition om at levere et godt produkt. Det er lappeløsninger, for hurtige småjusteringer, uigennemtænkte tilføjelser og manglende tid til vedligeholdelse der er problemet. Et problem, der over tid får applikationer til at degradere, ofte i en sådan grad, at applikationen helt må udskiftes.

Selvom microservice-arkitekturen modvirker det problem med skarpt definerede grænseflader, så er det en ny måde at bygge software på. Kigger man på Google Trends er det først i 2015, der for alvor begyndte at ske noget omkring microservices. Det betyder ikke at microservices blev ”opfundet” i 2015, men det siger noget om den samlede interesse omkring arkitekturen.

Med så relativt få år på bagen, kan vi ikke definitivt sige, at softwarearkitekturen vil holde i mange år. Der er dog klare tegn både teknologisk og forretningsmæssigt på, at det er en langtidsholdbar løsning.

De store tech-virksomheder

Mange store softwarebaserede virksomheder med softwarearkitektur baseret på microservices – Netflix, Amazon, Spotify, Facebook, Google er eksempler på giganter, der bruger microservice-orienteret software. For enorme tech-virksomheder giver det rigtig god mening. Det ville være meget besværligt, hvis Facebook skulle opdatere hele deres software, hver gang de ændrede en funktion. Det ville også skabe en situation, hvor forretningens evne til at implementere nye funktioner ville blive afhængig af. Hvilke funktioner, der kunne passes ind i en given update. Det ville betyde en deadline, hvor al kode skulle være klar for at nå den regelmæssige opdatering.

For de store softwarevirksomheder er den uafhængige, agile og forretningsorienterede udvikling et kritisk element. De ville ikke kunne fungere med en monolitisk struktur. Og de har i virkeligheden arbejdet i en microservices-lignende softwarearkitektur, før det kom til at hedde microservices.

Udviklingen mod microservices er en direkte konsekvens af de større muligheder vi har fået af større computerkraft og internethastighed. Vi er derfor ikke længere er tvunget til at bygge software, optimeret mod performance (den har vi typisk rigeligt af). Vi kan begynde at kigge på, hvordan softwaren bliver en naturlig forlængelse af virksomheden. Set i det perspektiv, er det svært at se hvordan den udvikling ikke skulle fortsætte.

Vil du vide mere?

Du er selvfølgelig velkommen til at skrive til os på mail@copenhagensoftware.com – vi kommer for eksempel gerne ud og holder et foredrag om microservices til inspiration.