I den offentlige sektor i Norge er man i gang med et større paradigmeskift fra systemer baseret på monolitiske siloer til microservice arkitektur kørende på private cloud med IaaS, PaaS, Open Source, DevOps, m.m. Den digitale transformation er i høj grad drevet af krav fra regeringen om digitalisering, effektivisering, forbedret service for borgere og virksomheder, forbedret miljø, m.m. Her gives et indblik i den type transformation, og hvad det indebærer.
Baggrund
Hos en norsk offentlig instans var der en erkendelse af, at man ikke kunne opnå de ønskede mål med den eksisterende monolitiske systemarkitektur, som satte begrænsninger på både hastighed og omfang af leveringen af nye features.
Man havde behov for en systemarkitektur, som understøtter hyppige releases, mindre behov for koordinering mellem forskellige afdelinger, og at hvert udviklingshold havde adgang til den nødvendige infrastruktur uden at skulle vente på, at IT-afdelingen stiller det til rådighed.
Efter en længerevarende analysefase og nogle pilotprojekter, valgte man at indføre en kombineret IaaS/PaaS platform med brug af værktøjer som VMware, Puppet, OpenShift, Kubernetes m.m.
Sopra Steria i Norge og Danmark har bistået med både rådgivning og implementering til opsætning af en ny IT-platform samt hjælp til de forretningsenheder, der skulle gøre brug af den, for to store offentlige instanser i Norge.
De følgende afsnit opsummerer nogle af de beslutninger, der er taget, samt de erfaringer der er gjort undervejs.
Platform og arkitektur
Micro-services
En metode til at opnå en mere agil leveringscyklus er at bruge en microservice arkitektur. I et af projekterne skiftede man integrationsplatformen fra en centraliseret monolitisk løsning (enterprise servicebus med klassisk SOA arkitektur) til over 100 enkeltstående services – alle med egen kodebase. Alle services blev grupperet og fordelt til den relevante forretningsenhed.
De umiddelbare fordele er bedre skalerbarhed (da man kan skalere de services, der har behovet) samt eliminering af afhængigheder mellem de enkelte services. Det sidste medfører, at de enkelte services kan opdateres uafhængigt af øvrige komponenter.
Den decentraliserede organisation og distribuerede system-arkitektur giver dog nogle nye udfordringer, man er nødt til at være opmærksom på:
API-management
Med flere hundrede (hvis ikke tusinde) af services kan man hurtigt miste overblikket. En API-management løsning er essentiel for at holde styr på livscyklus og versionering for et API.
Redundans og genbrug
Med selvstændige services sker det hurtigt, at samme basiskode eksisterer i flere forskellige kodebaser. Man kan lave fælleskomponenter, men det er ofte ikke ønskeligt pga. de bindinger, der dermed introduceres. Man må her afveje fordele/ulemper ved at lave en fælleskomponent (for at spare tid på den lange bane) fremfor at have redundant kode (for at mindske afhængigheden).
Ressourceforbrug
En vigtig forudsætning for at bruge Openshift/Kubernetes er, at de enkelte services kan startes/stoppes på kort tid. Dette er f.eks. vigtigt, når der skal skaleres (op/ned) eller man vil udrulle nye versioner. Med daglige udrulninger bliver opstartstid for de enkelte services en kritisk faktor.
Populære rammeværk som f.eks. Spring Boot koster i både starttid og memory footprint. Hvis man har 1000 services, der er bygget med Spring Boot, er det noget, der kan mærkes, når alle services skal genstartes pga. en systemopdatering. Man kan her overveje at bruge andre rammeværk/programmeringssprog for de mere kritiske services; f.eks. GraalVM, Go.
Overvågning og opfølgning
Når en forretningsproces spænder over flere services (eventuelt på tværs af forretningsenheder), skal man forholde sig til, hvordan man overvåger og følger op på de enkelte forretningsprocesser af hensyn til audit eller fejlfinding. Her vil det være en god ide, at man bruger en fælles model for, hvordan dette skal ske, og finder et værktøj der understøtter distribueret tracing; f.eks. Jaeger eller Splunk.
Fælles domænemodel
Det kan umiddelbart lyde som en god ide at have en fælles domænemodel, da der på tværs af forretningsenheder vil være mange objekter og begreber, som er de samme. Erfaringsmæssigt viser det sig dog at være for tungt at vedligeholde disse i en verden, som hele tiden forandrer sig.
Hver forretningsenhed bruger Domain Driven Design til at definere interne datamodeller, og data udveksles mellem åbne API tjenester – datamodellerne kan således løbende ændres/opdateres, så længe API tjenesterne forbliver bagud-kompatible.
Arkitektens rolle
Selvom hvert team har ansvaret for arkitektur og design af de enkelte services, er der stadig behov for en overordnet arkitekturfunktion til en eller flere af følgende opgaver:
- Som nævnt tidligere, er det en god ide at centralisere beslutningen om, hvordan man håndterer distribueret tracing og overvågning
- Sikkerhed – autentifikation, autorisation, håndtering af udefrakommende angreb, strategi for opdatering af 3-parts værktøjer, osv.
- Vurdering af teknologier og rammeværk – selvom hver forretningsenhed kan bruge de teknologier, der løser opgaven bedst muligt, kan der være nogle firmapolitikker om, hvilke teknologier man vil forpligtige sig til at understøtte fremadrettet. Dette er en afvejning mellem at give frihed til de enkelte forretningsenheder til at løse deres opgave, og undgå at man har et alt for fragmenteret teknologisk landskab, der bliver umuligt at vedligeholde på den lange bane. En mulig middelvej er at arkitekturgruppen definerer en liste af teknologier og rammeværk, der må bruges; det er dog vigtigt, at de enkelte teams har mulighed for at tage nye rammeværk i brug i form af PoC, e.l., og ikke skal vente uger på at få en godkendelse.
- Fremfor at fungere som en komité, der bestemmer og beslutter, hvordan løsninger skal designes, får arkitekten en rolle som rådgiver/sparringspartner for de enkelte forretningsenheder, når nye løsninger skal designes.
Organisation
Organisering af projekter og systemer
Hvert team er selvorganiseret i størst muligt omfang, træffer selv beslutninger om brug af teknologier, design og arkitektur og har det fulde ansvar for hele software livscyklussen: idegenerering, analyse, kravspecifikation, udvikling, test, installation, drift, vedligehold og udfasning.
Der er stadig en fælles IT-afdeling, men den stiller systemressourcer til rådighed for de enkelte teams via IaaS/PaaS.
Hver forretningsenhed har således både ansvar og beslutningsmyndighed til at sørge for at nå deres mål (releases) inden for det budget, der er givet.
Med denne organisationsstruktur fjernes det overhead, der var ved kommunikation og overdragelse af opgaver imellem de forskellige afdelinger.
DevOps
DevOps er et tankesæt inden for agil softwareudvikling, der handler om at forbedre produktivitet og effektivisere udviklings-livscyklussen, gennem forbedret kommunikation, samarbejde og øget automatisering. Mange af tiltagene inden for DevOps er allerede indført med ovenstående tiltag (autonome forretningsenheder med beslutningskompetence til valg af teknologier, selvbetjeningsadgang til infrastruktur, skalerbar infrastruktur, …).
En konkret fordel opnået med DevOps er, at automatiseringen af release-processen har bevirket, at man for installation af nye versioner af applikationer er gået fra fryseperioder og lukkevinder til at kunne installere i dagtimer – uden nedetid!
Kompetencer
En transformation som beskrevet ovenfor kræver selvfølgelig, at organisationen tilegner sig en masse nye kompetencer. Baseret på de erfaringer man har gjort i Norge, er det vigtigt, at centrale ressourcer som projektledelse og arkitektur bemandes internt. Det er en god ide at hente kompetencer udefra, men man skal sørge for, at der på alle projekter er en fornuftig blanding af både interne og eksterne ressourcer (f.eks. 50/50).
Til at optræne egne medarbejdere har sidemandsoplæring vist sig som en effektiv måde at lære medarbejderne at bruge nye værktøjer og metoder. Kurser kan også fungere fint, men det fungerer bedst, hvis de afholdes, når deltagerne har opnået en basal viden om emnet, samt at kurset er tilrettelagt efter de opgaver, deltagerne skal løse.
Konklusion
De nye platforme har været i drift i henholdsvis 1 og 3 år, og der er allerede en del systemer der kører på platformene. Alle nye systemer udvikles mod de nye platforme, og i de kommende år vil der ske en gradvis migrering af eksisterende systemer til de nye platforme.
Fælles for begge de offentlige instanser er, at de har opnået en kraftig reduktion af lead-time for nye features samt en forøgelse af antallet af nye features leveret i produktion – hvilket er en vigtig forudsætning for den planlagte digitalisering.