Mikrotjänster, microservices, innebär som namnet antyder att applikationer och webbtjänster byggs upp av små delar. Då kanske du tänker att det handlar om miniversioner av tjänster i tjänsteorienterade arkitekturer (soa)? Nej, inte riktigt.

– Det finns flera skillnader mellan soa och mikrotjänster. En är att en mikrotjänst är mindre än en soa-tjänst är och istället för kommunicera med hjälp av scheman och kontrakt så används klasser, då det i praktiken är frågan om rest-lösningar, säger Johan Normén, utvecklare och agil coach på konsultföretaget Softhouse i Göteborg.

Läs också: 6 saker du missförstått om microservices

Mikrotjänster körs var och en under sina egna processer och kommunicerar med lätta mekanismer, oftast via protokollet http med rest, och helst oberoende av varandra. En av ursprungstankarna med soa var tvärtom att paketera ihop dem till större lösningar med hjälp av xml-scheman och kontrakt, oftast till en mer monolitisk komponent. Det här gör att användningen av mikrotjänster blir mer flexibel än byggandet av traditionella soa-lösningar, förutom att mikrotjänster kan bli mindre än delarna i mer traditionella arkitekturer.

– Varje mikrotjänst kan ha en egen unika arkitektur som är lämpad för ändamålet, säger Johan Normén.

Som exempel på det tar han upp ett projekt han är inblandad i för tillfället, i vilken varje mikrotjänst har sin egna arkitektur och sina egna komponenter kopplade till sig. Exempel på områden, eller domäner, som de olika mikrotjänsterna täcker in är hantering av produkter, kvitton, order och autentisering.

Varför denna separering? En anledning är att koden blir enklare, man slipper helt enkelt mycket hantering i koden. På en högre abstraktionsnivå handlar det om att isolera olika domäner i olika mikrotjänster. Det ger flera fördelar, enligt Johan Normén:

  • Eftersom man inte behöver ha samma kodbas för alla olika delar av en applikation blir det lättare att leverera ny funktionalitet snabbt och kontinuerligt.
  • Uppdateringar, till exempel för att rätta fel, blir enklare att hantera, eftersom det är mindre delar av en applikation som behöver uppdateras.
  • Skalbarhet blir enklare att ordna eftersom det går att skala de mikrotjänster som blir belastade, i stället för hela applikationen.
  • Olika mikrotjänster kan vara av olika versioner, de kan alltså utvecklas oberoende av varandra och man slipper i hög grad synka de olika mikrotjänsterna mot varandra.
  • Sist, men inte minst, kan den sammantagna arkitekturen för alla ingående mikrotjänster i en applikation bli mindre komplex än arkitekturen för en applikation i vilken alla delar hänger tätt ihop. Man slipper helt enkelt kod för att samordna funktionalitet i de enskilda mikrotjänsterna.

Alla de här fördelarna bottnar i ett enda antagande: ju mindre komplexitet, desto bättre på alla sätt.

Så till den svåraste frågan av dem alla. Hur omvandlar man en gammal monolit (en stor applikation i vilken alla delar hänger tätt ihop) till flera mikrotjänster?

Läs också: 13 färdigheter som är ett måste för en topputvecklare

– Ett sätt är att behålla monoliten, men lägga till nya funktioner med mikrotjänster. Då är det viktigt att så långt det går undvika kommunikation mellan de nya mikrotjänsterna och monoliten, säger Johan Normén.

Det här innebär kanske en viss redundans för kod och data, alltså att viss funktionalitet och datalagring byggs på nytt i de nya mikrotjänsterna.

– Redundans av data behöver inte vara farlig om den inte behöver uppdateras. Exempel så är det vanligt att koppla samman produkt och kvitto i en databas, medan i en separation mellan kvitto-mikrotjänst och produkt-mikorotjänst har ett kvitto sin kopia av sina produktdata. På å sätt slipper man även hantera versionshantering av produkter i produktdatabasen, med mera.

Finns det inga nackdelar med mikrotjänster?

– Det kan blir dyrt om man har en server för varje mikrotjänst.

En lösning på det problemet är att använda en containerlösning som Docker för att köra flera mikrotjänster på en server.