Jag var på plats på Øredev 2013 när Fred George höll sin nästan legendariska dragning Implementing Micro Service Architecture. Jag hade inte hört begreppet förut men skulle snart höra det överallt. Det tog inte långt tid för mikrotjänster att bli IT-världens nya silver bullet.

Vad innebär då mikrotjänster?

I korthet innebär det att man styckar upp ett systems logiska delar i tjänster som tillhandahåller sin funktionalitet genom ett API. Varje tjänst utvecklas, versioneras, lanseras och underhålls som separata applikationer.

Vad är då fördelarna med att skära elefanten i mindre bitar? Det är givetvis flera men några är att

  • En buggfix till produktkatalogen betyder inte att du måste lansera all kod på nytt. Du behöver bara uppdatera produktkatalogens kod.
  • Varje enskild tjänst kommer vara mindre komplex än vad den stora monoliten kommer vara.
  • Att göra varje del i monoliten till en tjänst, tvingar din kod till bättre design och tydligare gränssnitt.

Kort sagt, programmerare älskar det här, men det innebär också en hel del utmaningar.

  • Stark koppling mellan tjänsterna kan innebära att du ändå måste uppdatera samtliga tjänster varje gång du gör en ändring.
  • Det finns en frestelse att dela kod mellan tjänsterna, eller att dela definitioner som ”vad är en order”. Det är en farlig fälla att gå i.
  • Tjänster som anropar andra tjänster blir snabbt en pyramid av tillgänglighetsproblem, där en tjänst kan sänka hela systemet.

Vad kan man göra för att bli redo?

Man måste inse att allt jobb man idag gör för sin monolit måste gå att kvantifiera och automatisera för att man skall kunna hantera 20 – 50 – 100 mikrotjänster. Att sätta upp en ny miljö eller göra en ny deploy måste reduceras till ett par knapptryckningar. Detta går och göra tack vare ett antal tekniska landvinningar det senaste årtiondet

  • DevOps. Se till så att du minimerar avståndet mellan utveckling och produktion, så att kod ”flödar” ut i produktion och användningen återkopplar tillbaka med instrumentation. (Continuous Integration, Continuous Deployment, Provisioning, Monitoring)
  • Testdriven utveckling hjälper till att kvalitetssäkra kod som inte har tid att sitta fast i UAT (user acceptance test) i 3 månader.
  • Dokumentation. Det duger inte att lansera 100 mikrotjänster utan att förklara hur de är tänkt att hänga ihop. Varje tjänst måste tydligt beskriva sitt syfte och sitt gränssnitt, och du måste ha koll på vilka tjänster som används.
  • Versionering. Du måste bli expert på att versionera tjänster, men också att ha koll på bakåtkompabilitet. Skall du lansera en ny tjänst för att du bryter kompabiliteten? hur länge skall du då supportera den gamla tjänsten?
  • Protokoll. Du kommer snabbt upptäcka att komplexiteten flyttar från de enskilda tjänsterna till kommunikationen och kompositionen av tjänster. Det kommer krävas urtydliga sätt att kommunicera med tjänster, men också för tjänster att kommunicera med varandra.

Det bästa tips jag har till dig som funderar på att ge dig i kast med mikrotjänster är att göra det med ett lagom mått av planering. Det går inte att skapa en massa tjänster och tro att de skall självorganisera sig. Då slutar det med att du sitter där med en ny slags monolit vars kodkomponenter kommunicerar över HTTP.