Dags att bryta med monoliten!

Ett återkommande kundcase och ett inte helt ovanligt uppdrag idag är ju att en kund har ett gammalt system som drar alldeles för mycket kostnader för att det ska vara försvarbart att ha det kvar. Det följer egentligen ett ganska återkommande mönster hos många av våra kunder. Ett nytt fräscht system lanseras, må det vara egenproducerat eller en färdig produkt, det underhålls och vidareutvecklas under flera år. Ny funktionalitet läggs till och tas bort, utvecklare kommer och går, liksom administratörer, redaktörer osv. På bara 4-5 år kan det ha hänt en hel del på både teknik- och personalsidan som gör att det börjar göra ont. 

Dags att bryta med monoliten!

1920 1280 C.A.G

Någonstans i tidsaxeln börjar det bli jobbigt att leva med det som en gång var top notch. Den tid man lägger ner på att hantera underhåll och vidareutveckling börjar bli svår att motivera. Kanske får man inte fram den funktionalitet verksamheten behöver snabbt nog. Kanske kan det vara utmanande att få in nya medarbetare eller konsulter som kan, eller vill, jobba med systemet. Systemet börjar helt enkelt nå slutet på sin livscykel. Ett sånt uppdrag brukar bli en rolig utmaning för oss utvecklare.

 

Varför det gör ont att hantera en monolit

I en så kallad monolit hänger all kod eller funktionalitet tight ihop och har sin livscykel i en och samma applikationsserver och jvm (för oss javautvecklare). Visserligen kan den sammantagna funktionaliteten vara utspridd på olika applikationer och visst finns det ofta massa kod med bra kvalitet men ofta finns där en central, rejält tilltagen, applikation där de flesta kodrader återfinns. Och det är oftast här man känner att det gör ont, är svårast att förändra eller lägga till det man behöver för att driva sin affär framåt.

 

När man sätter sig in i en monolitisk kodmassa och börjar skapa sig en förståelse kan man ofta ana den genomtänkta kompassriktning man följde i början. Nu har den  ersatts av nya idéer, kodmönster och speciallösningar, kanske en och annan fulfix. Ibland vet man helt enkelt inte om koden används längre. Långa kommentarer i koden om vad som implementerats, och varför, brukar vara tydliga varningstecken på att kodbasen börjar degenerera. Till slut kanske man är orolig för att ändra koden för att man inte vet var förändringen slår.

 

Kodningen i sig är oftast inga större problem vid förändringar, även om dessa kan bestå av en del letande och funderingar kring vilka klasser man ska förändra och att det verkligen inte påverkar något man förbisett. Kodändringarna ska sedan passera befintliga enhetstester och komponenttester, integrationstester och regressionstester…för det finns väl regressionstester som fångar upp i fall att jag tänkt galet? Och hur regressionstestar man egentligen att allt fortfarande funkar till 100%….? I bland finns automatiserade regressionstester, ibland sker testningen manuellt. Min erfarenhet säger att det gör man inte så lätt. För vem kan säga att nu funkar allt i en monolit som innehåller så mycket funktionalitet att det kanske inte finns en enda person på företaget som kan hela produkten/appen? Den samlade kunskapen kan vara, och är ofta, utspridd på ett flertal olika personer i organisationen.

 

Har man otur kan man hamna i ett läge där releaser upplevs som ett orosmoment både för verksamheten och för de personer som ska släppa releasen. Man vill ju gärna se många händer i luften när man frågar vem som släpper ut den nya releasen eftersom en release ska vara något kul att genomföra. Det är ju det vi jobbar för…att skapa ny funktionalitet och möjligheter för de som använder systemet.

 

Hur det dagliga arbetet påverkas av den nya arkitekturen

Att istället låta systemet baseras på ett flertal olika tjänster som kommunicerar med varandra kan skapa fördelar i alla led. Som utvecklare är det enkelt att direkt känna av fördelarna med mikrotjänster. Modern teknik som valts efter behov, smidiga att jobba med och enkelt att förändra och releasa. I jämförelse med den round trip det innebär att förändra koden i monoliten är det ju som att vända på en 5-öring (för er som kommer ihåg dessa).

 

Hur liten en mikrotjänst ska vara finns det många intressanta diskussioner om, men troligtvis är den i alla fall den så pass liten att förståelsen ökar och att man känner sig trygg i de förändringar man gör i koden. Sammantaget blir det inte bara enklare att få kontroll över tjänsten i den mening att man lättare hittar fram till det man vill förändra, även testningen av tjänster bli enklare. En annan fördel är att man enklare kan jobba parallellt med andra team utan att trampa varandra på tårna med trista mergar som resultat.

 

Hur vi successivt bryter ned monoliten

En bra strategi för att bryta upp en monolit i mindre tjänster är att identifiera och isolera funktionalitet som kan lyftas ut och läggas i egna tjänster. Den nya tjänsten bygger man efter den arkitektur och teknik som passar. I monoliten finns nu ett hål där all kod som nu finns i mikrotjänsten en gång var. Där jackar man helt enkelt in den nya tjänsten. På så sätt jobbar man sig igenom monoliten och minskar på så sätt successivt antal kodrader i den samtidigt som antalet mikrotjänster ökar. Monoliten kan leva parallellt i takt med att de nya tjänsterna skapas och till slut når man fram till en arkitektur helt baserad på mikrotjänster.

 

Vid pennan/Stefan Nildén, fullstackutvecklare C.A.G Contactor

Kontaktperson

Annika Rogneby

+46 70 687 33 08

annika.rogneby@cag.se

X
X