I en serie intervjuer får vi träffa några av Citerus utvecklare ute på uppdrag. Här träffar vi Tobias Modig som är på väg att kasta ut ett Cobol-baserat system till fördel för en modernare microservice-arkitektur. Läs om hans iakttagelser kring detta och vad han har att säga om aktivitetsbaserade kontor!
Hej Tobias! Berätta kort om ditt uppdrag.
Jag sitter som utvecklare i SIMS-teamet på en svensk bank.
Det skulle därmed vara lätt att tro att vi i teamet springer runt med små, gröna diamanter ovanför huvudet och låter någon annan kontrollera vad vi ska göra men i själva verket är det precis tvärt om. “IMS” i “SIMS” står nämligen för “Impossible Mission Solvers”. Jag är alltså en utvecklarvariant av Ethan Hunt som med kreativa lösningar löser riktigt kniviga problem.
Just nu håller vi på med det som nästan varenda bank i Europa har misslyckats med, nämligen att kasta ut den gamla Cobol-baserade systemfloran och ersätta den med en modern och lättföränderlig microservice-arkitektur.
Wow, du måste berätta: Hur lägger ni upp strategin?
För att citera en gammal slalomlegend, “De e bar å åk”. Det kanske låter lite som en klyscha men vi bryter ny mark och springer på okända överraskningar nästan varje dag. Därför har vi svårt att hålla oss till en förutbestämd strategi utan vi lär oss hela tiden nya saker, anpassar oss kontinuerligt och vågar ifrågasätta ingrodda gamla sanningar.
Som med alla initiativ av det här slaget så är den kanske största utmaningen tidshorisonten på systemskiftet, det handlar om år innan de gamla systemen kan stängas ned helt. Något vi brottas med är därför hur vi ska kunna leverera värde nu, att försöka hitta de delar som faktiskt kan börja användas redan idag. Exempel på detta är att vi nu sitter och bygger en lösning som hämtar historik både från det nya och de gamla systemen. På så vis kan man successivt slussa över trafiken till det nya systemet utan att slutanvändarna märker något.
Det nya ni bygger, alltså micoservice-arkitekturen, vilka fördelar ser ni där? Och vilka har utmaningarna varit?
Mikrotjänster har, precis som alla arkitekturval, sina fördelar och sina nackdelar. Om vi börjar med det positiva så har vi absolut blivit snabbare och mer lättrörliga. För några år sedan ägnade sig banken till exempel åt stora bigbang-releaser som skedde kvartalsvis. Numera släpper vi kod till produktion på daglig basis. Detta kan till stor del kan tillskrivas mikrotjänsterna i kombination med att det gjorts ett jättejobb rent infrastrukturmässigt.
Om vi istället tittar på de utmaningar vi fortfarande kämpar med så är det ofta så att när en organisation går över till mikrotjänster så går det väldigt bra i början. Så också för oss, vi skapade vår första, andra och tredje mikrotjänst och allt var guld och gröna skogar. Det gick fort att bygga, det var lätt att deploya och det var dessutom väldigt roligt. I takt med att tjänsterna sedan blev allt fler så ökade också komplexiteten. Efterhand är det lätt att hamna i en känsla av att vi bygger en distribuerad monolit. Ett system som brutits ned till många små delar men där varje del fortfarande har alltför många beroenden. Dessutom med ett extra lager av komplexitet jämfört med tidigare, nämligen nätverkskommunikationen. Därför laborerar vi till exempel med att gå från traditionell synkron kommunikation via REST till mer asynkrona lösningar som meddelandeköer.
En annan problematik som vi börjar märka av är frågan hur vi ska administrera den växande skaran med tjänster inom organisationen. Vilka team ansvarar för vilka tjänster? Hur vet man vilka tjänster som redan utvecklats? Hur identifierar man tjänster som inte används längre? Hur ser man till att tjänsterna förvaltas aktivt och uppgraderas kontinuerligt även om det inte utvecklas ny funktionalitet i tjänsten? Det här är frågor som vi brottas med men som vi inte riktigt vet hur vi ska hantera långsiktigt.
Felsökning, loggning och monitorering är ett tredje område som blir mer komplext med en mikrotjänstarkitektur. I den gamla monoliten var det exempelvis väldigt lätt att veta var man skulle börja leta om något inte fungerade som önskat. Nu krävs det en mer genomtänkt strategi för till exempel loggning och monitorering och där har vi inte riktigt kommit i mål ännu.
Vilka har varit dina största lärdomar i det här projekt?
Släng det aktivitetsbaserade kontoret i papperskorgen! När vi började med detta projekt satt utvecklingsteamen, den externa leverantören, projektledning och kravhantering utspridda. Samtidigt hade vi bekymmer med tillit, det var gott om missförstånd, produktiviteten var låg och det var allmän irritation gentemot “de andra”. Efter några retron togs beslutet att alla borde sitta tillsammans. Flyttkarusellen gick och resultatet var häpnadsväckande. Plötsligt började alla jobba tillsammans och dra åt samma håll. Produktiviteten sköt i höjden, humöret steg och det blev kul att gå till jobbet.
Fantastisk roligt att höra! Tack Tobias!
Vill du jobba med Tobias? Kolla gärna här!
