Alm. Brand har banket deploytid ned: »Tidligere var det helt forfærdeligt«

Ny kode skulle tidligere igennem et køsystem, hvilket kunne tage meget lang tid pga. begrænsninger i applikationsserver-softwaren.

En deploytid, der er sænket fra 20 minutter til knap et minut. Det er blandt de mest markante effekter af et nyt teknologisk set-up og nye værktøjer, der er indført i operations- og udviklingsafdelingen i Alm. Brand.

De nye it-værktøjer har sat fart på indrulningen af nye eller opdaterede applikationer i koncernen, der omfatter både forsikring, pension og bank i et on-premises it-miljø.

»Vores gamle system var blevet forældet – det var helt forfærdeligt, hvad angår deployment af nye applikationer,« fortæller Loke Johannessen, der er systemspecialist i den finansielle koncern.

Problemet med det tidligere tekniske system-setup var, at applikationsserverne kørte med 50-70 applikationer som kørte sammen i flere store applikations-JVM'er (Java Virtual Machine).

Det betød, at skulle udviklerne eller driften f.eks. have en fejlrettelse eller noget ny kode igennem, så skulle det igennem et køsystem pga. begrænsninger i applikationsserver-softwaren, Oracle WebLogic, hvilket kunne tage meget lang tid.

»Desuden kunne en fejl – f.eks. en kodefejl - ødelægge det for de efterfølgende deploys, fordi vores applikationsservere kørte som store monolitiske maskiner,« siger han.

16 parallelle miljøer

For forretningen betød det, at det var svært at leve op til et mål om 'time to market', når der var flere end få apps, som skulle deployes samtidig. Koncernen kører omkring 16 parallelle miljøer.

»Desuden havde vi brug for at isolere vores apps, så fejl eller mangler i den ene ikke kunne påvirke de andre.«

Løsningen blev en omfattende renovering af systemerne bag drift og udvikling og en ibrugtagning af en række nye produkter, som sikrede, at applikationer blev isoleret i containere på serverne.

»Også det at finde en bestemt loglinje på en kørende app voldte førhen store problemer,« fortæller Sune Keller, der er it-arkitekt hos Alm. Brand.

»Vi ville gerne, at det var simplere for udviklerne at gå ind i loggen for en kørende applikation, uden at de skulle læse mellem loglinjerne fra en række andre irrelevante applikationer, der tilfældigvis kørte på samme server,« tilføjer Sune Keller.

De produkter, Alm. Brand har indført, er ifølge Sune Keller og Loke Johannessen:

Docker
Docker er kernen i vores nye setup. Det er ikke en ny ide med containere (se her for en fin infografik) men den muliggør isolering og standardisering af software ved at simplificere byg, deploy og drift.

Elastic
Selskabet bruger samtlige produkter fra Elastic til at: opsamle, processere og vise logs fra selskabets nye services og fra dets legacy apps.

  • Elasticsearch er en fuldtekst søgbar datastore.
  • Logstash processerer logs sendt fra Docker Containere i JSON-format.
  • Kibana giver indblik og er en simplere måde at søge i logs, som ligger i Elasticsearch.

Puppet
Et automationssystem til at styre infrastruktur og maskiner efter prædefinerede roller eller profiler. Kan overvåge og sikre, at en maskine eller komponent ikke begynder at afvige fra de gældende konfigurationer

Springboot
Er et Java framework til at simplificere udvikling og læner sig meget op ad micro-service-tankegangen læs mere her

Consul
Et servicekatalog og key/value store, som er en af de vigtigste komponenter i koncernens nye setup. Den indeholder konfigurationsværdier som infrastrukturkomponenter, og nye services henter ved runtime, hvilket betyder, at kodebasen er ens hele vejen fra udvikling til produktion.

GitLab
Er Alm. Brands nye kodeversioneringsværktøj, som giver lidt samme muligheder som GitHub, bare on-premise og med mulighed for at udnytte en indbygget CI-løsning (Continuous Integration).

Jenkins
Et af de mest kendte og brugte CI-systemer, der findes. I Alm. Brands nye setup bruges den kun til at vise deployment pipelines, da byg og test af kode nu foregår i GitLab.

I dag er Loke Johannessen og Sune Keller, som begge arbejder på tværs af hhv. udviklings- og driftsafdelingerne, noget mere tilfredse med, hvordan de kan deploye applikationer i deres it-miljø:

Der er ingen køer, da hvert deploy starter i en container, uafhængige af hinanden og andre.

Det skyldes, at Alm. Brand nu har en komplet isolering mellem de forskellige services. Hvis behovet for at udvide eller flytte services ud i skyen kommer, så giver Puppet os muligheden for lynhurtigt (3-3,5 minut) at opsætte og indmelde en ny server ind i farmen.

»Det skal ses i lyset af, at det snildt kunne tage en arbejdsdag selv og opsætte den - med stavefejl og fejlkonfigurationer til følge,« lyder det fra Loke Johannessen og Sune Keller.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (0)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere