Mikrotjänster är den arkitekturnyhet som fått störst genomslag bland utvecklare under senare år och det är inte konstigt. Mikrotjänster, att dela in applikationer i flera mindre autonoma delar som kommunicerar med varandra, passar bra ihop med de flesta andra utvecklartrender. Containerteknik är ett exempel, kontinuerliga leveranser ett annat.

Men som alltid med silverkulor så börjar invändningarna att poppa upp i takt med användningen. Nyligen lade Red Hats John Frizelle ut texten om ämnet i ett föredrag på Red Hat Summit, vilket beskrivs i ett blogginlägg. Frizelle är chefsarkitekt för mobila lösningar på Red Hat.

Han räknar upp hela åtta utmaningar med mikrotjänster:

1. Beroenden lurar under ytan

Det är lätt hänt att beroenden mellan mikrotjänster smyger sig in i koden till dem. Det innebär att en ändring av en mikrotjänst kan medför att flera andra måste byggas om, med allt vad det medför av tidsåtgång och andra bekymmer.

Dessutom är det en utmaning att hålla reda på vilka versioner av olika mikrotjänster som ska ingå i en större release.

Läs också: Nu vill Docker modernisera företagens gamla applikationer – med konsulthjälp

2. Tester kräver koll på läget

Enhetstester blir enkla med mikrotjänster, men integrationstester kan bli krångliga, eftersom man måste lista ut vilka mikrotjänster som hänger ihop. För helhetstester som inbegriper flera mikrotjänster måste man hålla reda på vilka versioner av de olika mikrotjänsterna som ska testas.

3. Versionselände i flera nivåer

Att hålla reda på versioner för mikrotjänster har redan nämnts som en utmaning flera gånger. Och det blir ännu värre. Förutom att det krävs versionshantering för varje enskild mikrotjänst så måste man även hantera versioner för samlingar av mikrotjänster som hänger ihop.

Versionsmatrisen blir lätt väldigt komplex. Och när du lyckas få ordning på den kommer nästa utmaning: Hur garanterar du bakåtkompatibilitet? Å ena sidan, om man behåller den gamla koden och lägger till nya funktioner så blir koden rörig. Å andra sidan, om man släpper förändringarna separat så måsta man hålla reda på olika versioner av ännu flera enheter.

4. Automatisering är ett krav

För att lyckas med att driftsätta mikrotjänster blir man tvungen att automatisera hela processen. Det blir för komplext annars. Och det krävs förstås kunskap, tid och pengar för att få ihop en sådan lösning.

5. Måste styra upp loggar

Det krävs centraliserad loggning för att jobba med mikrotjänster, för att kunna hålla koll på vad som händer under driften av dem. Det blir totalt oöverskådligt att hålla reda på separata loggar för tiotals, hundratals eller ännu flera mikrotjänster.

Man behöver tänka ut ett smart system för identifiering av kommunikationen mellan mikrotjänsterna, kallas ibland global request tracing, för att kunna se vad som händer.

6. Övervakning är a och o

Man bör bara använda mikrotjänster om man har centraliserad övervakning av dem, i form av någon slags kontrollpanel (dashboard). På något sätt måste man sammanställa data om mikrotjänsterna, liksom man måste hålla reda på flödet mellan dem (se föregående punkt). Dessutom måste prestanda mätas, eftersom en långsam mikrotjänst kan sänka prestanda för en hel applikation.

Läs också: 3 steg till att bli ett algoritm-drivet företag

7. Avlusning kräver isolering

Det är väldigt viktig att identifiera var problem har uppstått i en arkitektur som inbegriper flera mikrotjänster. Det är i princip omöjligt att veta utan bra övervakning av mikrotjänster. Eftersom det inte fungerar med fjärravlusning av flera mikrotjänster måste man veta i vilken det finns ett fel och man måste ha koll på de olika versionerna av mikrotjänsterna.

8. Kommunikation av den högre skolan

Det behövs någon slags katalog över mikrotjänster (en sådan kallas ofta service discovery registry). Det är ingen bra idé att hårdkoda adresser till mikrotjänster. Det gäller att hålla reda på hur mikrotjänster ska kommunicera med varandra, till exempel vad gäller vilka versioner av dem som bör anropas.

Dessutom gäller det att ha koll på nätverksprestanda och hur man ska hantera avbrott i kommunikationen. Ett tips är att se till att misslyckanden sker snabbt, då går det snabbare att komma upp på banan igen.