Det går inte att lyckas med mikrotjänster utan rätt organisation

Mikrotjänster, eller microservices, är en utvecklingsteknik inom mjukvara som påminner om föregångaren serviceorienterad arkitektur (SOA), men mikrotjänster är uppdelade i ännu mindre delar. En applikation struktureras i olika löst kopplade tjänster, små moduler med enkla kommunikationsgränssnitt.

När produkter och system växer kan även team göra det. När systemen blir distribuerande och tillgängliga för en större publik börjar andra faktorer inom arkitekturen ta större plats. Vissa delar av ett system kan belastas mer än andra. Vissa funktioner används mer frekvent och vissa delar av ett system utvecklas snabbare än andra. Sådana system ställer hårdare krav på flexibilitet, prestanda och tillgänglighet. Dessutom kräver sådana system en helt annan organisation och hantering av källkoden och releasecyklar.

Det är då mikrotjänster kan komma till sin fördel. Fördelen med att dela upp en applikation i olika mindre tjänster gör applikationen lättare att förstå, utveckla, testa och den blir mer motståndskraftig för rekonstruktion av arkitekturen.

Det skapar även fördelar kring parallell utveckling genom små autonoma team. Dessa team kan utveckla, distribuera och skala sina respektive tjänster oberoende av varandra. Det möjliggör också att arkitekturen för en individuell tjänst inte måste följa något gemensamt arkitekturmönster utan kan byggas utifrån den arkitektur som kraven ställer på just den tjänsten.

Mikrotjänstbaserade arkitekturer ger även stora fördelar kring kontinuerlig leverans och distribution. Det är därför devops, kontinuerliga leveranser, agilitet, kontinuerliga releaser är vanliga värdeord vid mikrotjänstarkitekturer.

Mikrotjänster är inte bara små separationer av kod utan ställer även krav på hur vi arbetar i vår organisation. Det är oftast här företag kan göra fel. Om organisationen inte delas upp efter samma separationskrav kan det leda till långsammare leveranser, där team blir beroende av varandra istället för tvärt om. Då har man istället skapat en mikrotjänstmonolit, det vill säga tjänster som pratar med varandra och där flera tjänster delar på samma databas och är hårt beroende av varandra. Just detta är monolitens problem och det problem som mikrotjänstarkitekturen är till för att lösa. Vad som sker här är att man istället går från något dåligt till något ännu värre.

Conways lag säger att systemdesignen oundvikligen speglar strukturen i organisationen som skapar den. När det gäller mikrotjänster rekommenderas det att man skapar mikrotjänster som speglar den egna organisationsstrukturen, men ännu hellre bygger en organisationsstruktur efter hur man vill dela upp sina tjänster. Om du till exempel vill ha en ordermikrotjänst så bör du ha en ordergrupp.

Här är en checklista för mikrotjänster. Du vet att du gör fel om du svarar nej på någon av följande frågor:

1. Dina mikrotjänster har sina egna komponenter, sin egna arkitektur och datakälla?
2. Team kan jobba isolerat utan att vara beroende av varandra för en release och under utvecklingen?
3. En enskild tjänst klarar av att skalas upp utan att skapa en större kedjereaktion där flera andra tjänster måste skalas upp tillsammans?
4. När undantag måste göras där vissa tjänster måste prata med varandra, så finns det bra stöd för resiliens. Det vill säga, om en tjänst inte svarar skyddar tjänsten från ytterligare påföljdsfel som kan skada andra tjänster?
5. Enskilda tjänster går att testa genom regression, integration och systemtester då de inte påverkar varandra?
6. En tjänst kan sättas i produktion med ny version av enskilt team utan att tvinga med flera andra?
7. Tjänsterna är indelade i egna domän/affärs-moduler exempel som Order, Artiklar, Varukorg?
8. Varje team kan ha sin egna agila utvecklingsmetod och leveranstakt?
9. Varje tjänst har en tydlig monitorering stöd för att ge stöd för snabb MTTR (Mean time to recover)?

Läs också: 
Är containers nästa säkerhetshål för applikationer?
Förändringskraften förvandlar it-avdelningen till en tryckkokare