Parallellisering är en grundpelare i datortekniken. Traditionella datorsystem hanterar multipla applikationer och deras processer på ett operativsystem som schemalägger åtkomsten till gemensamma resurser. Applikationerna måste utvecklas med detta i åtanke. Ett mycket modernare, smartare och mer applikationsekonomiskt sätt att dela upp applikationer, idag mer använda som tjänster på moln, är att dela upp tjänsten i funktionella öar av kod som fokuserar på sin uppgift och kommunicerar med andra öar över väldefinierade protokoll. Ett allt mer populärt sätt att göra detta på är att utveckla tjänsten som en skärgård av mikrotjänster, på engelska microservices.

Förledet mikro implicerar att varje ö är liten, och det bör de vara, men det stämmer inte alltid. Varje ö, som i sig är en liten applikation, ska vara så stor i termer av rader kod att den precis uppfyller sin konceptuella funktion eller löser ett avgränsat konceptuellt problem. Vi betonar alltså konceptuella funktioner framför tekniska dito.

Mikroarkitektur

Det det smarta med denna design ligger i hur mikrotjänsterna utvecklas. Eftersom de kodas som små enskilda applikationer, som fristående funktionella öar, är det mycket enklare att kontinuerligt uppdatera tjänsten som helhet utan glesa stora releaser. Istället utvecklas varje mikrotjänst för sig och kan modulärt uppdateras var för sig i en kontinuerlig tät ström av små uppdateringar av tjänsten som helhet. Mikrotjänsterna kommunicerar med varandra genom stabila api:er och bildar så en helhet som utåtriktad tjänst.

Detta är inte minst ett effektivt ekonomiskt sätt att driva och utveckla moderna molntjänster. Mikrosericises svarar också mot konceptet med CI/CD (continuous integration and continuous delivery) och är nära vän med devops.

I samband med mikrotjänster hör man ofta även termen mikroarkitektur, eller microarchitecture på engelska. I detta begrepp ingår även de nödvändiga komponenterna som hanterar mikrotjänstern och en api-gateway som hanterar mikrotjänsternas kommunikation med tjänstens omvärld. Nackdelen med mikroarkitekturen är att den ofta kräver mer hantering än så kallade monolitiska applikationer, med en stor binärfil. Monolitiska applikationer är å andra sidan svårare att skala upp och att utveckla vidare.

Att varje mikrotjänst ska utföra sin speciella distinkta uppgift är inte alltid realistiskt. När man utvecklar en tjänst byggd på mikrotjänster möts man av en verklighet där mikrotjänsterna inte blir fullt så funktionsmässigt åtskilda eftersom en funktion behöver delas mellan mikrotjänster, funktioner som går in varandra. Domänanalys och domändriven design är nyckeln för att reda ut hur funktionerna ska delas upp mellan mikrotjänsterna. I denna process skapar man en abstrakt modell av tjänsten som helhet och identifierar de olika avgränsade funktioner i tjänsten som i sina avgränsade kontexter, och grupperar dessa i de mikrotjänster som kommunicerar mellan varanda och bildar tjänstens helhet.

Microsoft har skrivit en serie utmärkta bloggposter i ämnet doämananalys för mikrotjänster.

Kommunikation mellan mikrotjänster

Ett uttryck som ofta dyker upp i samband med design av en mikroarkitektur är att den ska följa principen med intelligenta ändpunkter och dumma pipor mellan dem. Siktet ska vara inställt på att skapa mikrotjänster som kommunicerar över enkla och välkända protokoll, istället för tät och komplex integration mellan mikrotjänsterna.

Generellt borde kommunikationen mellan mikrotjänsterna vara asynkron. Det går bra med synkron kommunikationer över till exempel http, men lika vanligt är det med asynkrona protokoll som AMQP (Advanced Message Queuing Protocol). Denna typ av lösa förbindelser gör arkitekturen mer flexibel och hanterar avbrott i enskilda mikrotjänster och andra störningar betydligt bättre än en traditionell monolitisk design.

Den som är familjär med stordatorer inser att detta inte är nytt. Stordatorarkitekturer är byggda enligt principen att applikationer ska byggas av små program som gör en sak, men gör det bra, och bygga kommunikation mellan programmen. Den typ av mikrotjänster vi guidar dig till här är dock av senare datum och drogs igång 2012 inom grupper kring programmeringsspråket Java.

Som ett resultat av detta är det mycket som bygger på java-ramverk när vi skapar mikroarkitekturer. Ett av de mer populära ramverken är Spring Boot som är speciellt framtaget för utveckling av mikrotjänster. Boot låter dig även driftsätta mikrotjänster på en molnarkitektur. Boot utvecklas av Pivotal Software som tagit fram en handledning i hur du kommer igång med utveckling av mikrotjänster. Kom dock ihåg att Spring Boot är bundet till programmeringsspråket Java.

Containrar

Den underliggande teknik som gjort mest för att föra ut mikrotjänster på bred front är så kallade containrar. Dessa fungerar ungefär som virtuella maskiner, men istället för att inkludera ett helt underliggande operativsystem i varje virtuell instans, kör mikrotjänster som isolerade användarrymder, eller sandlådor, som nyttjar det underliggande operativsystemets resurser. Containrar är betydligt mindre, gör mindre resursmässiga avtryck, än äkta virtuella maskiner, och de är enklare att hantera med avseende på driftsättning, lokalt eller i ett moln, och kan enkelt startas och stoppas för att möta efterfrågan eller tillgängliga systemresurser.

Att containrar är gjorda för mikrotjänster är ganska uppenbart, kombinationen är större än de ingående delarna. Varje mikrotjänst exekveras i sin egen isolerade container vilket avsevärt minskar på bördan att hantera tjänsterna. De flesta containersystem kommer med inbyggda verktyg för hantering av mikrotjänster och deras containers och automatiserar hanteringen av utrullning, skalning, nätverk och tillgänglighet till mikrotjänsterna. Det är även denna kombination av mikrotjänster och containrar som gör devops-filosofin möjlig.

Det finns flera implementationer av containrar varav den mest populära är Docker, som oftast paras ihop med hanteringssystemet Kubernetes. Även Redhat, Suse, AWS, Google med flera ligger långt framme inom denna teknik och driver den framåt.

En otroligt bra egenskap hos containrar är att mikrotjänsterna kan byggas i valfritt programmeringsspråk så länge koden kompilerar till det underliggande operativsystemet. Detta ger förstås en stor flexibilitet för utvecklarna, och individuella mikrotjänster kan byggas i helt olika språk, beroende på vilket språk som är bäst lämpat för den individuella funktionen för mikrotjänsten, eller vilka språk de tillgängliga utvecklarna behärskar bäst. En mikrotjänst kan byggas om i ett helt annat språk än det ursprungligen var byggt i utan att det påverkar tjänsten som helhet, så länge som den nya applikationen uppför sig väl över tillgängliga api:er.

Oavsett vilka språk som utvecklarna föredrar kommer de att stöta på utmaningar som andra redan brottats med. Designmönster är formaliserade, abstrakta lösningar på återkommande problem inom datavetenskapen och ett antal av dessa datavetenskapliga problem gäller specifikt system som mikrotjänster. Man kan säga att mikroarkitekturen definitionsmässigt bär på specifika datalogiska frågeställningar som måste mötas i designen av arkitekturen och hur tjänsten byggs upp. Som sagt är dessa problem inte nya – Devopedia har tagit fram en lista på de designmässiga utmaningar man kan ställas för när man skapar sin systemdesign och hur man löser dem.

Mikrotjänster i molnet

Som tidigare nämnts gör containrar det enklare att sjösätta mikrotjänster i molnet. Dessa plattformar ger tillgång till flexibla systemresurser så att tjänsten som helhet kan drivas så effektivt som möjligt. Givetvis erbjuder de flesta stora molnplattformar möjligheter att sjösätta och underhålla mikrotjänster som ett sammanhållet system. Man bör i god tid jämföra de olika möjligheterna, till exempel de plattformar som tillhandahålls av AWS, Microsoft och Google.

Läs också:
8 heta tekniker som stöper om ditt företag de närmaste åren
Det går inte att lyckas med mikrotjänster utan rätt organisation