Det som få vet är att hajpen började som en källarklubb, “Microservice Club”. Där samlades ett gäng utvecklare och arkitekter för att bygga en revolution baserad på små, separata tjänster. Den klubben hade ett antal regler, som tyvärr hittills varit dolda för allmänheten. Vi kan lyckligtvis presentera reglerna här idag, och låta dem ge en mer nyanserad bild av fenomenet.
The first rule of Microservice Club is: You do not need microservices.
Microservices är ett arkitekturmönster för att lösa framför allt tre problem:
- Hur kan jag skala vissa av systemets förmågor oberoende av de andra
- Hur kan jag isolera fel så att en krasch i en del inte sänker hela systemet
- Hur kan jag driftsätta delar av systemet utan att påverka helheten?
Microservices kan också hjälpa till med följande:
- Hur kan självständiga team utveckla delarna i systemet utan att störa de andra teamen?
Microservices är inte ett designmönster för att strukturera din kod. Om du tenderar till att skriva spaghettimonoliter kommer microservicevarianten troligen mest att likna ett kaotiskt barnkalas på en pastarestaurang.
Om det är designen du är ute efter bör du istället titta på domändriven design, DDD, som angriper problemet från affärssidan istället från tekniksidan.
The second rule of Microservice Club is: You do not need microservices!
Du behöver inte microservices förrän du har upptäckt problem med skalbarhet och felisolering.
“Men då är det väl försent?” frågar sig vän av ordning. Inte nödvändigtvis! Om du har designat ditt system i avgränsade komponenter, “bounded context” i DDD-termer, så är kostnaden att bryta ut det till en egen tjänst troligen rätt liten. Använder du dessutom “Strangler Pattern”, det vill säga låter de nya mikrotjänsterna gradvis ersätta existerande funktionalitet, blir övergången vare sig tidskritisk eller resurskrävande.
Microservices är en optimering, och optimeringen medför kostnader, både under utveckling och under drift. Som med alla optimeringar bör man vara försiktig med att göra dem i förtid.
Third rule of Microservice Club: Some service yells stop, goes down, errors out, you recover automatically.
När antalet tjänster — och antalet instanser av varje tjänst — ökar, är det inte längre hållbart med manuell felhantering. Du kan inte ha personal som loggar in på tjänster för att starta om dem när de kraschar. Det går inte att låta tjänster stanna om nätverket får hicka så att databaskopplingen dör.
Det innebär med andra ord att du under utveckling måste tänka på mer än bara affärsrelaterade felfall. Du måste skriva automatiserade tester som simulerar tekniska fel. Du måste våga testa vad som händer när någon tar ner delar av systemet.
Fourth rule: Only asynchronous communication.
Med synkron kommunikation — där du ställer en fråga och väntar på svar — öppnar du upp för felkaskader. Om tjänsten du pratar med har långa svarstider, eller inte svarar alls, kommer även den som anropar dig att uppleva samma sak från dig.
Asynkron kommunikation å andra sidan kräver ett annat tankemönster. Designen brukar bli ett händelsebaserat system, där tjänster reagerar på inkommande data, gör något och publicerar ut det som hänt.
Kopplingen mellan tjänster blir lösare — du behöver inte veta vem som bryr sig om dina händelser, släng ut dem på en gemensam buss och tänk sedan inte mer på det. Det ger också en enklare integrationspunkt mellan team, då det räcker att specificera formatet på händelsemeddelandena.
Naturligtvis måste vi då också börja tänka på vad som händer om ett meddelande går förlorat, eller om det råkar läsas in två gånger…
Fifth rule: One instance at a time, people.
Dina tjänster måste kunna hantera rullande uppdateringar. Du kan inte ta ner alla 200 instanser på en gång, för att sedan rulla upp 200 nya. Åtminstone inte om du vill uppfylla någon slags krav på upptid.
Detta innebär i sin tur att dina tjänster måste vara framåt- och bakåtkompatibla mellan samtliga driftsatta versioner. Du behöver ha ett systematiskt, och automatiskt, sätt att verifiera detta innan du går ut i produktion.
Sixth rule: No coupling, no shared state.
Om du har en hård koppling mellan tjänster kommer det bli svårare, eller rent av omöjligt, att deploya en tjänst i taget. Och kan du inte göra det så kommer du inte kunna uppfylla femte regeln.
Det här innebär att du behöver titta på enkla kommunikationsprotokoll som är bakåtkompatibla. Ett exempel är JSON, som, eftersom det är schemalöst, lätt kan hantera tillägg av fält.
Du får heller inte dela sparad data — och absolut inte databaser — mellan tjänster. Varje tjänst äger ensamt sitt eget data, och det enda som får delas är meddelanden som skickas mellan tjänster.
Seventh rule: Services last as long as they have to.
Var inte rädd för att stänga och slänga tjänster som har spelat ut sin roll. Du har kommit så här långt och har tagit på dig ett antal kostnader för att ta dig hit.
Utnyttja nu det faktum att du har små, väl isolerade, tjänster och fundera på om nya affärsinsikter eller ny funktionalitet innebär att du ska skriva en ny tjänst, istället för att refaktorera den gamla. Fördelarna är framför allt två; dels kan du låta båda tjänsterna leva parallellt tills alla har slutat använda den gamla, och dels slipper du troligtvis en komplicerad migrering av data.
And the eighth and final rule: If this is your first night at Microservice Club, you have to deploy.
Det bästa sättet att verkligen se hur saker fungerar är att prova dem. Se till att snabbt få upp ett fungerande skelett för hela kedjan, från kod till produktion.
Då hittar du snabbt smärtpunkterna och frågetecknen. Du kan se var microservicelösningen skaver för just dig.
För är det någonting som en kväll på Microservice Club kan garantera så är det skavsår och smärtpunkter. Det är bara du själv som kan avgöra om det är värt det.
