Från Conways law till micro services

Conways law är en gammal devis från 60-talet vars innebörd ungefär kan tolkas som att en it-arkitektur avspeglar utformningen av den organisation som har byggt den.  Är du obekant med fenomenet kan du med fördel följa wikipedialänken ovan för att få veta mer.

Stämmer då detta för oss?  Hur ser vår organisation ut och vad har vi för arkitektur?

Om vi börjar med organisationen har vi de senaste åren haft ett stort fokus på agil utveckling där vi har skapat självständiga tvärfunktionella team med ansvar för specifika produktområden, t.ex. “nyheter” och “barn”. Vi tror på styrkan i dessa autonoma team som själva väljer tekniska lösningar och arbetssätt. Utbyte mellan team sker i virtuella grupperingar uppdelat på intresseområden som t.ex. back-end och front-end. Men dessa grupper fungerar mest som forum där idéer utbytes snarare än som beslutsorgan.

Vad gäller arkitektur är vårt publiceringssystem Escenic centralt. Runt detta har vi en kodbas som har växt i en takt som avspeglar uppskalningen av hela vår verksamhet. Vi har nu en kodbas som är som en klassisk “monolit” – stor och ganska snårig och där delar som egentligen inte hänger ihop på ett naturligt sätt ändå gör det. Självklart har vi tillsammans försökt att “amortera teknisk skuld” men det blir svårt när allting hänger ihop och ingen riktigt vet vilka delar som tillhör vilket område och vad förändringar får för konsekvenser.
Ett annat problem är att hela kolossen måste deployas även när endast en liten del förändras.

Om vi då återgår till “Conways law” kan vi utifrån vår situation konstatera att våra självständiga team behöver en arkitektur som mer avspeglar sättet vi önskar att arbeta på.

Det vi i team vill ha möjlighet till är bl.a. att:

  • Kunna välja tekniska lösningar utifrån den uppgift som ska lösas.

  • Själva bestämma releasetakten.

  • Enkelt förstå de tjänster vi byggt och vara trygga med att de går att förändra utan att känna att det finns stor risk att man förstör för andra eller att “korthuset rasar”.

Finns någon arkitektur som skulle kunna vara svar på vår önskan?

Vi har dragit igång ett arkitekturprojekt där vi tillsammans försöker svara på den frågan. Just nu håller vi på att utforska en trend med stort momentum, nämligen micro services.  Än så länge har vi en begränsad erfarenhet av detta men många av oss tror att det här är rätt väg att gå.

Vad är då egentligen en micro service?

Det är svårt att hitta en entydig och exakt definition men man kan konstatera att det är ett litet program med en tydlig uppgift, t.ex. ett program vars enda syfte är att sortera namn.
Man får en tydlig separation of concerns. En tjänst ska vara liten och en bra riktlinje är att en micro service ska kunna “rymmas i en utvecklares huvud”. Innebörden är att man måste kunna förstå hur den i sin helhet är tänkt att fungera och kunna föra ett resonemang utan att hela tiden behöva plocka fram och studera olika delar separat.

En publik tjänst (t.ex. barnplay) utgörs av flera micro services som kommunicerar med varandra, oftast via http.
För en mer utförlig beskrivning rekommenderas att läsa Martin Fowler som har en utmärkt artikel om micro services.

Stor amfibiebåt och liten cykel

Bild på en amfibiebåt som får representera “monoliten” och en mer snabbrörlig cykel, bra på en uppgift som får representera en micro service…

Vi har alltså en tro på att micro services kan vara ett bra val för att få en arkitektur som fungerar ihop med den organisation med självständiga team vi önskar. Självklart tror vi dock inte på “silver bullet” lösningar och utmaningar finns absolut, t.ex. gällande integrationsfrågan och hur man hanterar tjänster som beror på varandra.

Leder inte micro services till en spretig teknikflora och finns det inte en vinst med att göra vissa saker gemensamt?

Det finns många frågor att ställa och i vårt arkitekturprojekt försöker vi ta reda på svar.
Exempelvis kan det finnas vinster med att team använder gemensamt framtagen infrastruktur för till exempel driftsmiljöer, loggning och övervakning.
Kanske är det dessutom en fördel att ha en begränsad uppsättning teknikval (Spring boot, nodejs, …) av olika slag som man får välja mellan i sina micro services.
Det finns en mängd perspektiv att ta hänsyn till.

Vår ambition är att tillsammans skapa en arkitektur som fungerar för den kultur och de värderingar vi har kring arbetssätt och organisation. Självklart vill vi ha ett samarbete mellan våra team, men i grund och botten vill vi att team kan arbeta med stor frihet och flexibilitet och med de verktyg och lösningar som passar deras domän och aktuella uppgift.

Vi kommer att berätta hur det går i kommande inlägg!