Den med Statens Vegvesen

Statens Vegvesen har mye data og sanntidshendelser og er helt avhengig av teknologi til å klare det. Hans Kristian og Audun har med seg Terje Andersen og Petter Breunig for å snakke om applikasjonsplattformen sin Atlas.

Creators and Guests

Host

Audun Fauchald Strand

Prinsipal i NAV

Host

Hans Kristian Flaatten

Platformutvikler i NAV

Producer

Tore Græsdal

Innholdsdesigner - video, animasjon og streaming i NAV

What is Plattformpodden?

En podcast om applikasjonsplattformer og teamene som bygger de. Dette er podcasten for deg som bygger plattformer eller som er interessert i lære med om hvordan noen av Norges største om mest fremoverlente organisasjoner legger til rette for sine utviklere.

Episoden er transkribert av kunstig intelligens, feil forekommer.

Hei, og velkommen til Plattformpodden. En podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg Audun Faukals Strand. Men før vi introduserer dagens gjester, har du et favoritt sci-fi fremkomstmiddel? Jeg tror det må være Melandium Falcon. Jeg er egentlig motstander av sci-fi. Jeg har ikke noe fantasi, så det er vanskelig å forestille meg alt. Men jeg har vokst opp med Star Wars, så da må det være Melandium Falcon. Og fordi sønnen min liker det og Lego-varianten veldig godt. Hva er ditt favorittfremkomstmiddel? Husker du "Back to the future"? Dette hoverboardet. Det har jeg alltid ønsket meg. Jeg tror vi har passert den tiden. Det burde være i nærheten av mulig, det nå. Kan løfte litt svaret på det. Men for det vanlige jobber de ikke med så futteristiske, kanskje ikke så mye svevende kjøretøy.

Men de bygger, drifter og vedlikeholder landets riksveier, og sørger for at reisende kommer seg trygt og effektivt fra AtB. De jobber stadig med mer avansert teknologi, og i 2023 startet de et pilotprosjekt med deteksjon av hendelser inne i tunneler med bruk av kunstig intelligent. Og på Oss i Aberson hadde Vegvesenet en av de kuleste stendene, en modell av en tunnel hvor de detekterte i real time biler som har stoppet opp inne i tunnelen, og dermed avverger uønskede hendelser. I dag er vi så heldige å ha med oss Petter Brauni og Terje Andersen fra applikasjonsplattformen som noen av disse tjenestene kjører på. Nemlig Atlas, velkommen til oss. Peter? Kan ikke du begynne å fortelle litt om hvorfor du begynte i Statens Vegvesen, og hva du jobber med? Ja. Hvorfor jeg begynte i Statens Vegvesen? Jeg har vært i Statens Vegvesen i så mange år at jeg har nesten ikke tenkt på hvorfor. Jeg starta jo som konsulent tilbake i ... Det må ha blitt rundt 2008. Da var min første kunde i Statens Vegvesen.

Og så har jeg jo vært ansatt i en periode. Ble ansatt i 20... I 2015? 2016? Ja. Og det var jo da vi starta med Atlas-plattformen. Og nå er jeg tilbake som konsulent, da. Ja. Det er full sirkel der. Terje, hvorfor begynte du i Statens Vegvesen, og hva er din rolle? Jeg begynte tilbake igjen i 2010. Da var det en omorganisering og en større vekst i IT. Og for min del så var det vel mer hvor jeg var enn før, og hva som var muligheter i Statens Vegvesen den gangen som trakk meg dit. Og så har reisen i Vegvesenet vært veldig lang og veldig positiv deretter. Og i dag skal du snakke om Atlas. Navnet Atlas, hvorfor det? Det er kanskje litt selvsagt, men ...? Det er jo da fra gresk mytologi og titanatlas som da står og bærer jordkloden på sine skuldre. Det er liksom litt symbolsk for den plattformen som alle fagsystemene og publikumsløsningene til Vegvesenet i dag kjører i.

Kan ikke dere begynne med å si hvordan ... Hvorfor begynte dere å lage plattform, og hva er den overordna tekniske arkitekturen? Jeg kan jo begynne med det første. I 2014 ble det pekt på at vi trengte å utforske skyteknologi litt mer. Og det ble beslutta et skyprosjekt, som det egentlig het opprinnelig. Som vi startet med i 2015, hvis jeg husker riktig. Parallelt med det var det også et initiativ rundt det vi kalte for det fjerde miljøet. Altså det å sette fokus på og utvikle behov. Så disse veiene samkjørte i begynnelsen og skulle både realisere behovene til utviklere og også utrede mulighetene for en IAS eller en OG, en PAS, som det var. Og så, fast forward til 2017 ca., tror jeg, så hadde vi utforsket lenge og vel, men vi hadde nok litt for lite fokus. Så da ble det beslutta å fokusere på en PAS, og det var vel egentlig fokusarbeidet derifra og ut som resulterte i Atlas, som så sine første dager i januar 2019. Og litt om den tekniske arkitekturen, kanskje? Litt om den tekniske arkitekturen, ja.

Den er basert på Kubernetes. Det er veldig sentralt. Vi starta jo med OpenShift. Vi begynte jo å se på OpenShift 3.0 allerede. Vi gikk i produksjon med OpenShift 3.1, tror jeg vi fant ut her om dagen. Vi så jo et behov for å orkestrere masse annen infrastruktur rundt det. På den tida var det ikke noen enkel måte å utvide funksjonaliteten i Kubernetes. Så vi har jo laga et API, et Atlas-API, en egen kommandolinjeklient, som egentlig alle utviklingsteam bruker. De bruker ikke API-et direkte, men de bruker den kommandolinjeklienten. Det sikrer jo ... Det gjør jo at ... Altså ... Kunne vi ha bygd i dag, så har vi sannsynligvis ikke valgt den samme løsninga. Da ville vi ha gått mer for custom resources og den midten der. Men det valget vi tok tilbake i 2015, da vi starta på dette, 2016, gjorde jo at f.eks. flyttinga ... Vi har vært innom åpen skift, nå er vi jo på Tansu.

Det å flytte fra open skift til Tansu, når alt lå bak vårt eget API, det ble veldig enkelt. Så det var liksom noen oppsider og noen nedsider med det valget. Vi er absolutt kjent med det å eie abstraksjonen, og hvilke muligheter det gjør, det å kunne bytte det underliggende. Så det er jo kjempegøy å gjøre, at dere har den samme erfaringen. Hvor mange er det som jobber med plattform, og hvor mange applikasjoner eller team er det som bruker denne plattformen i dag? De som jobber med plattformen, det er altfor få. Vi har vel egentlig hatt ... ikke altfor god kapasitet underveis. Og har vel til tider følt at vi har jobbet mot strømmen, men har lykkes på tross av. Hvor mange er det nå? Jeg er litt sånn avtroppende i teamet. Hvor mange er dere nå? Vi er vel sju utviklere. En ren driftsressurs, og en sånn 50-50 utvikler i drift. Så fleste av oss sitter i Drammen, og så er det noen som sitter i Skien.

Og hvor stort miljø server dere? Vi har ca. 400 aktive brukere, altså utviklere som bruker plattformen. Og de er vel rundt regna 75 team, tipper jeg. Så det er ganske bra, vil jeg si. Det er ganske mange som bruker plattformen. Men det må jo nesten være ganske store deler av Vegvesenet, de som jobber med utvikling? Altså bruk av plattformen? Ja, alt som er egetutvikla og relativt nytt, kjører jo på atlas. Det er jo fortsatt litt legenser i systemene som ligger igjen på gammel infrastruktur. Er det også sånne stormaskiner som kjører i en eller annen kjeller, eller er det forbi den? Nei, det er vi ferdig med. Men det tok mange ord å bli kvitt de fra. Vi tar gjerne litt råd på det ennå, vi er ikke ferdig ennå. Det er en helt stor maskin igjen. Det er visst ikke så store de store maskinene. Trenger vi bare en stor nok bil for å flytte det? Hvis veiene holder, da! Men litt mer om plattformen: Hva slags tjenester tilbyr utviklerne deren som en del av plattformen?

Nei, altså ... Vi har jo noe sånn ... Altså, plattformen tilbyr jo ... Altså, de kan jo bygge ... Vi har en del base imager som vi kaller Node, Java mfl. Så man bygger et applikasjonsimage, og så kan man deploye det dit. Det funker jo. Eksponering igjen ... Vegvesenet bruker jo BIGIP. Vegvesenet bruker jo BIGIP og flere ting som ligger der for å hjelpe med eksponeringa. Så alt det der er jo automatisert rundt eksponeringsbiten. Og så har vi en del sånn ... enkelte tjenester for å hjelpe utviklingsteam, altså CED Jenkins til det, og så har vi jo siste året innført Renovate. Ja, fortell litt om Renovate, for det er et ganske kult verktøy. Ja, det er ganske kult. Renovate er et verktøy som skanner gitterrepoene dine, så ser de hvilke avhengigheter du har, og så kommer de med forslag til oppdateringer. Når det kommer en ny versjon av et bibliotek, så får du en puller orchestra. Eller du kan sette opp Renovate, sånn at den gjør automatisk merging og sånne ting, basert på regler som du definerer.

Da ender jeg med å ikke kjøre på github? Vi kjører ikke på github. Ja. Riktig. Og det vil jo være veldig likt som Dependabot for de som hører på. Yes, det stemmer. Ja, og så har vi noe sånn automatisering mot Oracle. Vegvesenet er jo ei Oracle-sjappe, mye Oracle-databaser. Så vi har noe automatisering og oppsett mot det. Så tilbyr vi jo tjenester for Rabbit MQ. Ja, så har vi jo selvfølgelig trikker og overwalking og sånn, som er en del av plattformen. Med trikker på Meteors hjerne, og så at utviklerne kan lage grafana, dashboards? Riktig. Og så har vi jo alarmer. Så gjennom API-et til Atlas kan de sette opp varsel til Slack eller til e-post. Riktig. Men fortell mer om ... Jeg er veldig interessert i å høre. Hva er det utviklerne må lage eller gjøre på sin side

for å deployere en applikasjon gjennom det API-et? Vi kaller det for en deployment-beskrivelse, som er en filstruktur med noen Jason-dokumenter og konfigurasjonsfiler. I den beskriver du eksponeringsadresse, hvor mye ressurser du trenger ... Og så har du noen enkle kommandoer. Du kjører AC-bild for å bygge et image. Og så er deploy for å deploye imaget. En standard arbeidsflyt er jo at man lager en push to get. Det bygges en PR, og så kjøres det tester og alt sånt. Så kan det bygges et image ut fra det, kjøre interaksjonstester hvis man ønsker det. Og det deployes i Atlas som en del av det. Da vi begynte med dette var Kubernetes nesten nyfødt. Det var få som kunne Kubernetes, og det er jo ikke altfor mange som kan det altfor mye enda, selv om mange flere kan det nå. Denne DSL-en som Peter refererer til som deployment-beskrivelsen, noe av hemmeligheten og poenget bak den var jo nettopp det å kunne

abstrahere bort Kubernetes også. Slik at du har et SVV-domene-speciese. Respekt-språk for å beskrive det du trenger. Og så ekspanderes det til Kubernetes-jammel på baksiden. Har utviklerne ellers tilgang til Kubernetes, kan de gå inn og se på de sine? Har full lesetilgang til Kubernetes Appie. På alt bortsett fra Secrets. De kan gå inn og debugge hvis ting går galt. Gjør det mulig å provisjonere Oracle-databaser? Hva sa du? Ikke provisjonere, men lage brannmuråpninger mot Oracle, altså network policy som åpner mot Oracle-miljøet. Vi jobber i disse dager med selvbetjening, så du kan provisjonere Oracle-databaser også gjennom Atlas Appie. Det har jeg kjent med deg. Det er vanskeligere å ha inntrykk av. Vi skal få til den type automatisering mot Oracle enn mot andre ... Vi har jobba med det i fem år. Så det er liksom ... Det er mange humper på veien. Nå er det litt sånn hvordan vi skal håndtere hemmeligheter.

Det meste går jo hvis du har folk som ønsker at det skal gå. Er det sånn det funker, ja? Det er en av fordelene med det mønsteret, med å la én ... Du vet hvilke applikasjoner som kobler sammen, og du kan integrere den prosessen. Når du profesjonerer i passord, kan du også sende det opp i applikasjonen, så du slipper å sende passord på e-post, SMS, Slack-lignende ting. Yes. Det er det målet. Det er dit vi skal. Det er riktig. Men vi har jo også integrert med Fordstruck Access Manager. Vi provosjonerer jo DeConnect-klienter, så alle klienter og hemmelighetene til dem blir provosjonert gjennom Atlas. Vi var inne på det med størrelsen på teamet tidligere, og vi har måttet velge litt underveis hva vi gjør. Vi skulle gjerne ha levert masse tjenester og funksjonalitet, men vi har måttet velge. Noe av det vi har forsøkt å gjøre, er å tilrettelegge for konfigurasjon

mot Oracle-databaser, også med tanke på flere datasentre og redundans. Vi har integrasjon mot Splank, slik at det også kommer automatisk, og mot IDP. Vi har en del sånne integrasjoner for å forenkle bruken av annen infrastruktur. Iallfall for hovedbruksbehovene. Hvordan jobber dere for å avdekke hva som er ...? De største painpointene ute hos teamene? Det er vel et område som IT kunne vært flinkere på å samarbeide rundt. For jeg har hatt rolle som produkteier og teamleder fram til nå nylig, og det har vært en vanskelig prosess å få vite hva behovene er. Peter og jeg har jo sagt at vi har bygd en plattform som vi har lyst til å bruke sjøl. Og det har vært mye av malen til hvordan ting har kommet frem. Og så har vi tidvis hatt litt god dialog med noen team, men generelt så er det for dårlig kommunikasjon mellom Atlas-teamet, som en teknisk enabler, og de som bruker dette. Men så er det jo også selvfølgelig de tilbakemeldingene vi får,

er det ikke alltid at vi klarer å realisere, fordi vi er ikke mange nok. Den tradisjonelle plattformen for det med, er jo liksom å filtrere bort, sånn at du ikke løser alle problemene som brukeren vil ha også. Du må gjøre det som skal være for å dekke mange, på en måte. Ja, vi skal dekke 80-90 %, ikke 100 % av behovene til folk. Det er ikke alle som kan kjøre i Atos-plattformen. Da får de gå den mer tradisjonelle veien. Å bestille servere. Sånn er det i dag, i hvert fall. I prioriteringene som jeg har gjort, så har jeg hatt mantraet "2080". Å prøve å levere 20 % som treffer 80 %, det har vi vært nødt til å gjøre hele veien. Og kanskje en av måtene man avlaster et plattformteam, er å ha noe dokumentasjon, sånn at man ikke blir rennende ned med de samme spørsmålene. Hvordan har dere løst den problematikken der? Vi har en egen dokumentasjonssite som vi ruller ut samtidig med ny funksjonalitet. Der er det aller meste dokumentert.

Og så har vi det vi kaller for et brukerforum på chat. Flere kanaler der hvor det er mulig å stille spørsmål bruker til bruker av plattformen. Men så har vi også en rolle som vi kaller for vaktmester, som har ukentlige ansvar for å prøve å ha et ekstra fokus på å følge opp de kanalene. Så fanger opp mye spørsmål der. Og så er det noen utviklere som er flinkere til å hjelpe andre der enn de fleste. Stor takk til dem. Men det er måten vi forsøker å løse det på. Men dokumentasjonssiten, hvordan har dere satt den opp? Docksiten er skrevet i ASKIDOC. Vi bruker Antora til å generere en site, der de kan finne svar på det aller meste rundt plattformen. Vi har fått veldig mye gode tilbakemeldinger på dokumentasjonen vår, så den tror jeg er veldig bra, faktisk. Det er jo et sånt hallmark, det med hvordan man håndterer dokumentasjon, hvor flink du er til å tenke på det som et produkt, og ikke bare en ting vi bare må gjøre. Det tror jeg er veldig viktig. Det ble nevnt at det gikk fra OpenShift til Tansu.

Kan vi snakke litt om hvordan den migrasjonen der gikk for seg? Var det så lett? Ja, det er sikkert delte meninger om det. For det er klart, teamene måtte gjøre litt selv. Og det var nok litt ulike meninger om hvor krevende det måtte være. Fra mitt perspektiv så tror jeg ikke det var så mye å gjøre for teamene. Det var noen endringer i deployment-beskrivelsen, og så var det å redeploye. Så var det ferdiggjort noen migreringsmekanismer fra plattformen i forkant. Så selve migreringen, når man fikk taket på det ... Etter hvert var det noen team som skjønte at kanskje vi skal sette noen til å gjøre dette på tvers av flere applikasjoner og løsninger. Det var nok en lur strategi for dem, for da gikk det fortere og fortere for hver deploy. Jeg husker ikke hvor lang tid vi brukte totalt fra vi starta. Brorparten var over på en måned, og så var det noen etternølere som måtte følges opp i etterkant. Så selve migreringen gikk smertefritt.

Da kjørte de to i parallell, og så gradvis fikk dere mer og mer i det nye? Ja, og det her skjedde også samtidig som vegvesenet begynte å lukte litt på Public Cloud. Et av målene med Atlas har vært at vi skal være litt agnostisk. Hvor ting kjører igjen, og hvilken Kubernetes som ligger i bunnen. Så i forbindelse med at vi så at den migreringa kom, og at Public Cloud kanskje ble et alternativ, så gjorde vi noen smarte grep som gjorde at vi kunne kjøre med flere klynger i parallell. Det egentlige som var greia for utviklingsteamene, var at de skulle måtte kjøre en kommando med AC. Atlas-klienten, som klona det miljøet de hadde, fra én klynge over til en annen klynge. Og så måtte de deploye tjenestene sine på nytt. For klonen tok bare alt av Egres "network policies" og "The Basis"-oppsettet. Så de ploya dem på nytt, og så var det en bytt i Big IP, som de gjorde sjøl. Kan du ikke også si litt mer om hva han så er, og hvorfor dere bytta?

Ja ... Vi bytta vel ... Vi bytta fordi OpenShift kom i en ny versjon, versjon 4, eller Red Hat kom med det. Og vi hadde egentlig en premiss om at det produktet vi valgte opprinnelig, skulle vi ha en InPlace-oppgradering av hele veien. Og når Red Hat kom med versjon 4, så brøt jo det løftet ved første mulighet. Det var sikkert gode grunner til det, men det gjorde at vi syntes at da må vi orientere oss på nytt igjen. Samtidig så skjedde det også en prisendring fra Red Hat som motiverte litt ekstra. Så det var bakgrunnen for det. Og så er det jo ... Det var jo allerede den gangen mange distribusjoner å velge mellom, men av ulike grunner sendte vi opp med Tansu som en stor VM-virkunde. Det kommer jo en prisendring på Tansu, i og med at VM-vernet er kjøpt opp av Broadcom. Kan vi forvente at det blir en ny migrering? Hva betyr det i åpen skift? Ja, Red Hat vil vel gjerne det. Jeg har hatt som holdning hele tiden,

og egentlig teamet også, at vi gifter oss ikke med noen ting. Og det er en grei utfordring til leverandørene å være klar over også. Vi beviste jo at så abstrahert er vi. Så i det øyeblikket vi av en eller annen grunn ikke er fornøyd, eller av andre årsaker vil ha behov for å velge noe annet, så gjør vi det. Ja, så har jo Vegvesenet starta på den der Public Cloud-racen litt mer for fullt nå, da. Så man er jo i ferd med å inngå en avtale med en leverandør av Public Cloud. Og da vet vi ikke hva som skjer der, hvor mye som skal kjøre der, men det kan jo, altså ... Ja. Altså, det kan jo skje at alt havner der til slutt, det vet vi ikke. Nei, og Atlas er jo klargjort for det, gjennom den abstraksjonen. Det er vel noen, noen mindre tilpasninger som må gjøres eventuelt. Men vi er klare i hovedsak til å også realisere applikasjoner og tjenester i en valgt sky. Men enn så lenge det er når det ikke er på sky, hvordan den infrastrukturen som ellers forvaltes i plattformteamet, det vil jo være primært Hansu ... Har dere direkte tilganger inn i VMW, ved senter, hvor dere kan ...

Administrere det, eller er det gjort på vegne av et annet infrastrukturteam? Vi har tilganger, men det er ikke vi som sitter og gjør det. Det er VMW-gjengen som gjør det. Atlas-teamet hadde ansvaret. Da vi starta, var det vi som laga mye av den automatikken rundt provosjonering av klynga. Så har datasenter tatt over det. Og vi samarbeider fortsatt veldig godt om det. Men ja, per i dag, så er det ikke vi som sitter og ... Hvis vi har behov for en ny klynge, så er det ikke vi som starter den prosessen. Vi gjør en bestilling, sier at vi trenger en ny klynge, og så gjør de noe. Men disse klyngene, er det fysisk separerte sider, eller er det mer logisk, er det miljøer? Hva er klynge i deres definisjon? Ja, altså ... Ja, det er alt det der. I dag er det klyngene vi har strekt over to datasentre. Med den Tansur-versjonen som vi kjører nå.

Men så vi har jo flere produksjonsklynger, litt avhengig av type applikasjoner. Ja. Soner, kan det også ... Noen bruker "soner" som et ord. Kan det også være gjeldende her, eller er det mer logiske grupperinger? Nei, det er mer sånn ... Vi har én stor produksjonsklynge. Det er den fleste applikasjonene som kjører, og så har vi en for overvåkningsløsning. Vi må også bygge en ny overvåkningsplattform, Okular, oppi der. Den har egen klynge. Den har egen klynge som den kjører i, og så har vi egen klynge for alt som har med bygging å gjøre. Og så er det de applikasjonene som ikke skalerer veldig godt horisontalt, som trenger litt mer CPU og minne, så de har fått sitt eget område. Siden du nevner dette med soner, domener ... Klyngene våre kjører ... Vi prøver å skape ... Vi prøver å skape multitenent mode, så at de er isolert fra hverandre. Og de tilgangene som man har, de er kun til de i praksis namespacene som de har for applikasjonene sine. Det er ikke pip åpent på tvers.

Hver applikasjon er en sone i seg selv, eller hvert namespace, egentlig. Vi bruker network policy, så kunne vi låst ned alt. At det er ikke noe kommunikasjon ... Veldig lite øst-vest. Du nevnte det var en ny overvåkningsklynge under oppseiling? Er det noe du kan fortelle om ...? Det har jeg innommert, så det kan jeg ikke så mye om. Jeg kan si to ord om det. Vi har hatt tradisjonell overvåkingsløsning, som har vært stor og tung å administrere, og kanskje ikke leverte alt vi ønsket å få ut av den investeringen. Og har valgt å lage en egen overvåkingsløsning. Basert på Kubernetes og bl.a. Grafana som dashbord og grensesnitt inn. Det har vært så langt en bra opplevelse. Og har overtatt all funksjonaliteten vi hadde fra den store kommersielle leverandøren. Så er det et godt utgangspunkt for å bygge videre på det. Men det er ikke Atlas-teamet som har ansvaret for det. Kjører dere cluster i hver klynge? Er det mange clustre her det er snakk om?

Mange Kuberneteske clustre, ja. Jeg tror vi har en fem-seks produksjonscluster. Hvordan løser dere det? Hvordan har dere ett oppsett for alle, og så utrulerer dere endringer på et cluster? Eller dette er kanskje sånn som Tansu fikser det? Tansu fikser det. Vi har ei atlasklynge, det er jo ei Tansu-klynge. Så kjører vi noe Ansebol og noe Helm, som måtte installere det vi må. Som vi trenger av infrastruktur. Og så er det klart, egentlig. Så må vi registrere kognetisklynga i Atlas API, sånn at Atlas vet hvordan den kan prate med klynga. Og hvis de skulle gjøre noen Konfig-endringer, da er det bare Atlas som håndterer hvordan det rulles ut i de forskjellige clusterne? Vi har stort sett ikke hatt så voldsomt behov for Konfig-endringer på klyngene. Alt av oppgraderinger og sånn er jo bare rullerende restart. Veldig enkelt sånn sett. Men Atlas API-er og tilhørende Celi, hva er det skrevet i?

Celi er skrevet i Go. Mesteparten av API-er er skrevet i Go. Vi har litt Java, det skal vi skrive oss bort fra og få alt over på Go. Celi sender et Jason-format til API-er, som snakker videre med de redaktørene? Oversetter det til kubanesiske objekter? Ja, API-er oversetter kubanesiske objekter, riktig. Og andre API-er i Vegvesenet som står foran infrastruktur, som Big RP og Splunk. Men også operatorer, eller bare et API på utsiden? Vi har jo, som jeg sa tidligere her, hvis vi skulle ha bygd Atlas i dag, så har vi sikkert bygd det meste basert på operators. Så vi er jo i en sånn ... Fase der vi nå lager en ny funksjonalitet, så ser vi først om det er mulig å gjøre det som en operator. Vi flytter oss jo i den retningen. Kanskje hvis jeg bare kunne skrudd av Vegvesenet i en halvt års tid? Da måtte vi ha fått litt flere folk, tror jeg. Og denne veien til Sky får du snakka med, du sa Jenkins og Rabbit ...

Skal dere bytte ut de tingene når dere går i Skyhjelp? Hva tenker dere om det? Det tror ikke jeg vi har tenkt så nøye over ennå, egentlig. Men vi har jo sett på alternativene til Jenkins. Det finnes jo mange andre gode alternativer. Vi blir jo litt bundet av at vi ikke tillater at de prater direkte med Kubernete-Sapie, at ting går gjennom Atlas-Apie, så det er vanskelig å ta i bruk verktøy som Argo direkte. Det er grunnen til at vi ser i retning Operators og sånne ting, nå når vi lager nye ting. Så det er det jeg tenker å gå bort fra, at du ikke må gå via Atlas-Apie? Ja, det er kanskje en naturlig vei videre. Det virker som en god måte å åpne for å ta i bruk litt flere univertøy, ikke være låst i alt. Spesielt når du går til en sky hvor det er mer integrert og helhetlig verktøystack, der du kan begynne å bruke litt, og så får du en del gratis. Kubernetes økosystem har jo modnet enormt i spede begynnelser,

og vi har verktøy som f.eks. lag-og-cd, som ikke fantes da man begynte. Du sa litt om det, men da var det litt den interne varianten. Men når en utvikler skal lage en ny app, hvordan går man fram? Hvordan man går fram da? Vi har jo en CMDB-katalog, der må man registrere IT-løsninger. Når det er gjort, så kan man jo starte med å ta i bruk Atlas som plattform. Starter med en bestilling for å få oppretta det første miljøet, og ... Derifra, så i den bestillingen, så er det jo også hvem som skal ha hva slags type roller for IT-løsningen, og da er det egentlig bare å få installert klienten via denne programportalen, og så er man egentlig i gang. Ja. Når man har klienten, da, da er det hvordan ... Hva ... Altså, bruker de det i ... Er det manuelt, eller er det liksom kobla opp mot ...? Nei, altså ... eh ... Det er jo ... Altså, du kan jo bruke klienten manuelt fra PC-en din,

men det er veldig få som gjør det. De største brukerne av AC-klienten manuelt, det er nok vi som sitter i Atlas-teamet, som følger opp andre ting. Men det er jo bygd noen enkle Groovy-skript og Theis Jenkins, som rapper, funksjonalitet i AC-klienten, så de aller fleste utviklingstimene sitter jo og bruker de groovy-skriptene for å bygge image og sånne ting. En vanlig flyt er jo at man laster ... Altså, vi ... Utviklingstimene, når du sitter og utvikler, før du kan begynne å bruke Atlas, må du ha produsert en eller annen artefakt, om det er yarfil eller binær... Linux-fil. Den laster opp til Artifactory, og da kan du bruke byggefunksjonaliteten i Atlas til å pakke den artefakten inn i et image, som da blir pusha til et dokkerepo, og så kan du deploye gjennom Atlas. Er det noe sikkerhetsskanning? Du nevnte Renovate, men det var mer for avhengigheter. Har det noe verktøy eller automatikk spesifikt for sårbarheter?

Nei, ikke per nå, men det er også ting vi kikker på. Holder du oppdatert avhengighetene dine, så er jo du i bedre stand enn hvis du ikke gjør det. Det er noe vi har kikka på en god stund, og så er det bare det å finne litt sånn organisatorisk og sånne ting, hvor skal det ligge hen? Det er ikke lenge siden Nav fikk et applikasjonssikkerhetsteam, hvor den sikkerhetsbiten lå som en del av applikasjonsplattformen, uten at det var et mandat eller noe, fordi resten av organisasjonen ikke var moden nok til å ta det ansvaret. For resten av organisasjonen var ikke modne nok til å ta det ansvaret. Men f.eks. disse kunstig intelligens-demoene som det viser ... Er det ting som kjører i disse Cuban Eighth Clusters, eller er det one-offs andre steder, eller hvordan ...? Ja, både òg. Men jeg tror den demoen som kjørte på Jawasson, det kjører i produksjon på Atlas. De trener ikke modellene på Atlas, men de kjører modellene i Atlas.

Så jeg tror de er trent i Google. Men det gir mening, for det er jo helt andre ressurser som trengs for treningsbiten, potensielt, enn det ... Vi har jo kikka på muligheten for å kjøre klynga der vi har GPU tilgjengelig. Sånn at man også kan gjøre trening. Men Terje har jo gått over i en ny rolle, skal bygge dataplattform. Så det er jo mer der det hører hjemme. Ja, neimen da Terje, da må vi invitere deg tilbake hjem. Å gå med dataplattform, det er noe vi også har dekket på denne podkasten her. Vi er allerede i produksjon med Saga, men vi er i en sped begynnelse. Så vi kommer gjerne tilbake og prater om det. Vi må jo tenke at det er mye interessante data i Vegvesenet. Det er det, og mer blir det. Det er det ikke noen tvil om. Men det er jo en god tone å egentlig begynne å gå inn for parkering av denne episoden. Da har vi et spørsmål til alle gjestene våre.

Om dere kan fortelle en gang ting ikke gikk helt etter planen, og hva dere lærte av det? Den tida kan du ta. Du har ikke gjort noe feil? Egentlig så har vi vært veldig heldige og flinke med "Atlas". Vi har egentlig hatt veldig lite trøbbel. Den har stått seg gjennom tykt og tynt, og mye av det er takket være ... Mye av det er takket være robustheten til Kubernettis, men også måten vi har implementert det på. Vi har flere miljøer før vi kommer til produksjon hvor vi avdekker mye trøbbel. Så det hjelper oss veldig. Men vi opplevde jo ... Peter nevnte jo at vi har strukket klynge mellom flere datasentre, to datasentre, og ... Vi har strukket VM-er-klynge. Kan ikke se for meg hvordan det kan være. Men så var vel vi ... Ikke vi, men de som jobber med lagring, de hadde vel ikke den beste dagen på jobb fordi vi mista lagringen i det ene datasenteret.

Og dette skjedde i overgangen fra Openskift til Tansu, som vi snakket om tidligere. Og vi var ute av Support på Openskift og kjørte fortsatt på 3.11 som versjonen var, lenge. Og da var vi veldig, veldig heldige, fordi vi hadde noen VM-er som hadde fått feilprovisjonert lagring i det andre datasenteret. Og det redda oss egentlig. Så de kunne vi eskalere vertikalt opp og holde unna å trykke på, for vi hadde jo ikke muligheten til å provisjonere noen nye noder med Openskift på det tidspunktet. Så litt flaks i uhellet der, men selve Atlas har egentlig ... Stått trygt og godt hele veien. Ja. Vi har det, faktisk. Det var jo maks uheldige, da. En hardwarefeil på disk som slo til samtidig som det var softwarefeil på lagringa, som gjorde at den lagringsfeilen propagerte på begge sidene. Stemmer. Vi mista masse data. Det var mye armer og bein der. Det var ingen gøyal dog på jobb for en del, ja.

Men av og til er det lov å ha litt flaks òg. Er det ellers noe dere har lyst til å si før vi runder? Vi kan jo begynne med deg, Peter. Nei. Jeg sier gjerne noe. For både til Atlas og Saga som dataplattform så rekrutterer vi. Så er det noen som har lyst til å lage verdifulle plattformer til utviklere og datarelaterte. Så er det bare å ta kontakt. Da sier vi tusen takk til Peter Brauni og Terje Andersen fra Statens Vegvesen for at dere har vært med oss i studio i dag og delt om hvordan dere bygger plattform i Vegvesenet. Audun, da har jeg lyst til å høre hva ditt høydepunkt har vært? Jeg syns det var gøy at et valg som ble tatt ganske tidlig med å lage dette i Utafar, har holdt seg så lenge. Det har holdt seg lenge. Det å bytte ut clusterinfrastruktur underveis, såpass smidig, er jo kjempebra. Likevel, når man ser at ting begynner å bli annerledes, begynner man å vurdere å se at kanskje vi skal gå annen vei.

Det tenker jeg er et tegn på ganske moden kultur, når man ikke gjør det for fort, men også ikke holder igjen altfor lenge. Kudos for det. Det er imponerende å høre om et relativt lite plattformer. Relativt lite plattformteam som server så mange team og applikasjoner. Så utrolig kudos til dere der. Det er veldig gøy å se og høre. Og det sier noe om hvordan denne type plattformer, som er selvbetjener, hvor godt det eskalerer. Og med det runder vi av denne episoden av Plattformpodden med Hans-Christian Flåtten og Audun Faukanstrand. Teknisk produsent er som vanlig Tore Græsdal. Nyeste episode finner du alltid på plattformpodden.no eller i din lokale podkastup. Følg oss gjerne på LinkedIn og tips en kollega om denne episoden. Ha det!