Moderne softwareudvikling med Cloud, Microservices, Kubernetes og Domain-Driven Design

Fra Monolit til Microservices

I DFDS har de over de seneste år været i gang med en omfattende modernisering og transformation til cloud-baserede systemer. Det har man gjort for at gøre virksomhedens IT mere smidig og omstillingsparat i forhold til markedet og på tværs af alle forretningsområder. Jens’ arbejde har været at nedbryde DFDS’ kritiske forretningssystemer til mindre applikationer samt at bidrage til implementeringen af en topmoderne microservice baseret arkitektur:

”Man kan sige, det var en tobenet rejse. Jeg blev hevet ind til at hjælpe DFDS i gang med Cloud adoption, men også for at nedbryde monolitterne, altså den gamle arkitektur, men det har ligeledes været en rejse med et skift over til et microservice baseret IT-landskab. Førhen lavede man typisk nogle store applikationer - senere kendt som monolitter - hvor man fik puttet al mulig funktionalitet i og med tiden blev de tungere og tungere at danse med. Nu er der kommet en microservices-bølge, hvor man prøver at bryde det hele op i nogle mindre klumper, der stadig kan snakke sammen, men de er afgrænsede. Det gør, at man kan fokusere lidt mere isoleret.”

Takket være en stor del af dette arbejde har udviklingsafdelingerne (og mange forretningsenheder) i DFDS opnået mere frihed og fleksibilitet i processen. Hvert område kan nu udvikles i takt med, at der opstår nye behov:

”Hvis vi nu f.eks. skal udvikle en ny funktionalitet, så kan vi gøre det isoleret i en separat microservice. Vi har selv autonomi til at bestemme hvilke teknologier den skal baseres på alt efter hvad der er behov for. Man kan selv vælge en passende database eller om der skal inkluderes andet “Off The Shelf” software til at løfte opgaven. Et team kan selv stykke det sammen via en moderne cloud provider.”

Den store udfasning af monolitterne til fordel for en moderne løsning med microservices har åbnet op for nye muligheder. Det har givet en helt anden fleksibilitet til de respektive forretningsenheder rundt om i DFDS.

Moderne udviklere bør mestre begrænsningens kunst

Når man står overfor en transformation i denne størrelsesorden, kan det hurtigt virke overvældende. Der ikke noget at sige til, at de vanlige, velafprøvede og sikre valg kan være at foretrække. For med nutidens mange muligheder kan selv de mest erfarne IT-folk blive helt rundt på gulvet:

”Det er her, hvor panikken oftest står malet i ansigtet på folk. Selv for garvede IT-konsulenter kan moderne clouds virke enormt uoverskuelige med nærmest uanede mængder af services. Man når aldrig til det punkt, hvor man kan sige at man er ekspert i AWS eller Azure. Det hele går nemlig så vanvittig stærkt.”

Tager man cloud-brillerne på, bliver der alene fra de tre store (Amazon, Microsoft og Google) frigivet over 500 nye services hvert år - fra hver af dem - men det er der følge Jens ingen som har behov for:

”Der er noget smukt i at kunne begrænse sig. Man fremtidssikrer ikke noget ved at bruge alle de nyeste features. Kunsten er at vide, hvornår man skal bruge noget fremfor noget andet - og i særdeleshed hvornår man IKKE skal bruge noget.”

Selvom tingene går stærkt indenfor softwareudvikling med nye metoder og løsninger næsten hver eneste dag, så er der ikke tale om en ny problemstilling. Det går blot endnu hurtigere end tidligere. At forstå helheden, bevare overblikket og træffe en informeret og kalkuleret beslutning er derfor nøglen til det bedste resultat.

Kubernetes var et boost for DFDS i deres cloudrejse over til AWS

Tilbage i 2017 var der i DFDS blevet taget en beslutning om at skifte fra Microsoft Azure til AWS. Ideen skulle derfor også sælges internt, og der var brug for noget intelligent (men samtidig nemt), som kunne få udviklerne med på vognen og overbevise dem om, at cloud ikke bare var nymoderne besvær. Her var Kubernetes en øjenåbner og en god løsning.

Kubernetes var nemlig i samme periode den helt store hype, og til sidst var Jens selv blevet så inspireret af al hypen, at han en novemberaften i 2017 selv sad og legede med det derhjemme. For måske kunne lige præcis dette stykke software være svaret på, hvordan man i DFDS kunne få udviklerne med på vognen og lave en blidere overgang til at lave cloud-baserede microservices:

”Jeg var helt nyforelsket. Det havde potentialet til at blive en PaaS-løsning hos DFDS, og det ville fjerne en masse bøvl som udviklerne ikke skulle sidde og bekymre sig om. Det kan virke utroligt skræmmende hvis man går fra at have en hel driftsafdeling, der drifter tingene on-premis, til selv at skulle drifte sin egne løsninger på en public cloud.”

Kubernetes gjorde det nemmere at komme i cloud

For udviklere, der ikke har nogen erfaring med cloudteknologier, kan det virke meget uoverskueligt at skulle i gang med. Men det smukke ved valget af Kubernetes og hele ideen bag var ifølge Jens, at man stadigvæk udelukkende skulle forholde sig til at bygge sin forretningsapplikation, og derudover kun lære relativt få ting for at kunne komme i cloud med den. Og det var akkurat det, der var behov for ude i DFDS:

”Ved at begrænse de nye ting til noget, der lignede det gamle, skulle man ikke forholde sig de lavpraktiske cloud-detajler som virtuelle maskiner, netværk, disk osv. Man skulle i princippet gøre, som man plejer. Det gjorde det nemmere at fortælle og få folk med på vognen.”

I dag er Kubernetes gået hen og blevet ’default runtime platform’ for udviklingsteams i DFDS. Implementeringen af Kubernetes er blevet så stor en succeshistorie, at det har betydet, at DFDS nu prioriterer at have et særskilt team, hvis job det er at vedligeholde selve Kubernetes-platformen og bygge services ovenpå. Adspurgt om det også gør én stolt at kunne være med til at påvirke udviklingsprocesserne i en så stor virksomhed som DFDS, svarer Jens:

”Det er da meget cool! Det er overhovedet ikke noget, jeg kan tage æren for alene, for det har bestemt ikke været nogen solorejse. Der ligger virkelig meget hårdt arbejde i udrulningen af Kubernetes, og der er mange skarpe hjørner i Kubernetes, men det har været fedt at være med hele vejen!”

Og nu er tilgangen til Kubernetes ligeledes også vendt helt på hovedet:

”Tingene har ændret sig, og det er blevet lidt af en principsag – nu skal man virkelig have en god grund til IKKE at putte sine services på Kubernetes!”

Event-drevet Microservicearkitektur

Men arkitekturen i DFDS har også stået på dagsordenen hos Jens. Efter indførelsen af Kubernetes gik Jens i gang med at slå på tromme for sin anden store passion; event-drevet arkitektur:

”Med event-drevet arkitektur kan man bygge reaktive systemer. Det passer godt ind i en stor virksomhed som DFDS, der har mange forretningsområder. Ofte er de produkter som DFDS har, egentlig fordelt over mange forretningsenheder, der er stykket sammen til en forretningsproces, som så ender med et salg til kunden.”

Fordelen ved denne form for programmering er, som Jens fortæller, at man som moderne virksomhed kan skabe processer, der gør, at man kan omstille sig til nye behov. Med en arkitektur, hvor komponenter kan reagere på hinanden, er der et godt udgangspunkt for at lave automatiserede processer:

”Det gør det nemt at bygge videre på. Man kan løbende tilføje nye komponenter der lytter med på strømmen af events og derefter reagerer på dem. Det er dejligt afkoblet og helt klart vejen frem.”

I en moderne verden, hvor virksomheder skal være omstillingsparate, så er det en klar fordel, hvis man har bygget event-drevet og reaktive systemer. Det reaktive kan gå hen og blive proaktivt. Den klassiske adoption af Microservices var karakteriseret ved at være mere baseret på synkron API baseret kommunikation, som indebærer at services udstiller et API som andre kan kalde:

”En service kalder først én service, så kalder den en anden, så kalder den måske en tredje osv. Sådan lyder en klassisk adoption af Microservices. I kontrast til det, så fungerer det event-drevet og reaktive asynkront. Der rapporterer servicen om at der er sket en ændring via en event bliver rejst, og så kan det være der er nogle andre services, som lytter og reagere på det. Det gør at de forskellige services er mere fleksible og utrolig løst koblet til hinanden.”

Domain-Driven Design er aktuelt igen

Populariteten af event-drevet microservice arkitektur har givet fornyet liv til en filosofi og tilgang til softwaredesign ved navn Domain-Driven Design (DDD), som blev introduceret i 2003:

”Da Domain-driven design kom frem i 2003 fik det en relativt beskeden popularitet. Da vi så fik hele bølgen af Microservices, så kom folk pludselig i tanke om DDD igen og populariteten eksploderede. De to ting passer nemlig sindssygt godt sammen. Eftersom DDD giver en overordnet retning for, hvordan man kan lave Microservices - hvordan man deler monolitter op. Jeg plejer at sige til de forskellige teams, prøv nu at se om I kan få noget inspiration til at løse en udfordring fra DDD. Det giver nogle enormt gode retningslinier for, hvordan man laver distribuerede systemer, og hvordan man laver softwaredesign i det hele taget.”

Jens forklarer, at DDD især er et godt fit med en stor virksomhed som f.eks. DFDS. Modsat tidligere, hvor alt skulle passe ind i en forståelse og i en enkelt model, så er tilgangen i DDD, at man anerkender, at der er forskelligheder i en virksomhed og at der nok er en årsag til de forskelligheder - og i tilfældet af at de bringer nytte så er der store fordele i at understøtte forskellighederne, frem for at ensrette:

”Ideen med DDD er bl.a. at man understøtter de forskelligheder der i forretningen og at man implementerer de samme forskelligheder helt nede i koden. Det er vigtigt at man adopterer samme sprogbrug og terminologi i koden, som den man finder i forretningen. En virksomhed som DFDS opererer indenfor flere forretningsområder og spænder derved flere domæner, så som logistik- og passagerdomænet. Udgangspunktet er, at man understøtter de forskelligheder og nuancer der er. Det er her, man kan koble en retning på og lade domænet være driver for designet.”

Adspurgt om denne tilgang til softwaredesign har været en succes, så er der ifølge Jens lidt vej endnu. Han oplever nemlig ofte, at der er en tendens blandt udviklere til at komme for hurtigt i gang med løsningen, før man har sat sig ind i det problem, der skal løses. Der bliver hurtigt tænkt meget i teknik og i valg af teknologi:

”Forståelsen af forretningen er altid det vigtigste. Når vi udviklere får krav fra forretningen, er der en tendens til straks at begynde at tænke i kode og databasetabeller, der i princippet er ligegyldige. Det kan jo være vi ender med at vælge en helt anden database, hvor man gør det helt anderledes – og så er vi ligevidt.”

At forretningen kommer før teknikken er en grundlæggende præmis uanset om man taler Cloud, Kubernetes, Microservices eller Domain-Driven Design. Og selvom moderne softwareløsninger er fantastisk smarte og bringer et væld af muligheder med sig, er der i højere grad end tidligere, et øget behov for en metode og retning, der kan styre nutidens distribuerede systemer:

”Det er helt klart den rigtige vej, synes jeg. For det handler nemlig ikke kun om at nedbryde monolitter til atomer - der skal et softwaredesign nedover.”