Episoden er transkribert av kunstig intelligens, feil vil forekomme.

00:00 --> 01:03

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 som vanlig Audun Faukal Strand. Og i sesong tre av Plattformpodden dykker vi ned i en helt ny verden av dataplattformer. Men før vi introduserer dagens gjester, Audun, har du en favoritt med trikk? Ja, du, jeg tror min favoritt med trikk er ... Selv om det hovedsakelig er knytta vonde opplevelser til lønn med trikken, er consumer lag på Kafka. Hva er differansen mellom siste produserte melding og siste leste melding? I hvert fall da jeg jobba med det i Finn og her i Nava. Hver gang den økte, så var det et eller annet trøbbel. Det var sjelden det var gode nyheter når consumer lag gikk oppover. Det var ofte gode nyheter når det gikk nedover. Hva med deg, Hans Kristian? Det er et historgram. Sikkert at det har ulike buckets, ulike persentiler

01:03 --> 02:14

hvor du kan få ut hvor lang tid du bruker requesten. Dette får du for alt som går inn i et kubanetisk cruster hvis du har NGX Ingress. Det gir deg hva som er baseline, hva som er 50 %-persentilen, men også hva som er 99 %-persentilen, som vi kanskje er vel så interessert i. Men i dag skal vi snakke om data, i hvert fall. Ikke så mye. I dag er vi så heldige å ha med oss Øyvind Bruer Skarsbø og Jon Kasper Sverige fra SSB. SSB er en organisasjon som går helt tilbake til 1800-tallet, med ansvar for offisiell statistikk i og om Norge, som brukes i alt fra forvaltning, utforming av nye lover, media og privat næringsliv. Øyvind, kan ikke du fortelle litt om hvorfor du begynte i SSB, og hva din bakgrunn er? Det kan jeg gjøre. Min bakgrunn er jo fra forretningsområdet. Forretningsområdet til SSB, som vi kaller det. Altså det å produsere statistikk, som er det veldig mange i SSB jobber med. Jeg er utdanna samfunnsøkonom, så samfunnsviter. Jobba mange år med å produsere statistikk over arbeidsmarkedet, over næringslivet,

02:14 --> 03:38

og skrive artikler og rapporter og den type ting. Så for et par år siden gjorde jeg hoppet over til IT-avdelingen i SSB. Kult. Det er kjekt med litt forskjellig bakgrunn. Det blir gøy å dykke ned i. Men først, Jon Karsper, hva med deg? Hvorfor begynte du i SSB, og hva er din rolle? Ja, jeg starta i SSB for to år siden. Da starta jeg som Java-utvikler og cottlene. Det var litt sånn tilfeldigheter at jeg starta i SSB, egentlig. Jobba i Posten i noen år, og så ble jeg klar for litt nye utfordringer, og så kom covid. Så ville tilfeldigheten at han hadde det til at jeg flytta nordover. Hadde jo SSB litt på radaren allerede, og så kom det plutselig en stillingsutlysning om Bust Remote. Så ja, det så ut som en spennende stilling, så hoppa jeg på den. Når det prosjektet jeg først var på var ferdigstilt, så fikk jeg tilbud om å hoppe på. Så da gjorde jeg det i mai i fjor. Du er altså remote i SSB, Jon Carlsberg? Ja, 100 % fjerna i meg.

03:38 --> 04:48

Hvor er det du befinner deg sånn fysisk? Rent fysisk sitter jeg på Finnsnes i Senja kommune i Troms. Hvor er resten av kollegene dine? Er det i hvert fall de du jobber mest med? Ja, jeg jobber jo en del med Øyvind, som er produkteier, men resten av teamet sitter både i Oslo, Kongsvinger og stort sett på hjemmekontoret i Oslo-området. Det er gøy å se at flere og flere tar i bruk de mulighetene man har med hybrid- og digital arbeidshverdag. Så det er gøy. Men Øyvind, kan ikke du gå litt mer i dybden statistikkproduksjon, data ... Og dataplattform, hva er alt dette? Så det er kanskje greit å prate litt om hva statistikkproduksjon er, da. For det er jo litt som ordet tilsier, da. Det er produksjon. Vi produserer ting på gitte intervaller. Så typisk så henter vi inn masse data fra hele Norge. Både spørreskjemaer mot enkeltpersoner, spørreskjemaer i Altinn mot virksomheter, foretak ... Henter inn fra registre og en god del nye spennende kilder.

04:48 --> 05:53

Og en god del nye spennende kilder også. Og så har vi da hovedsakelig ganske mange samfunnsvitere som tar imot de tallene her. Bearbeider de, altså rydder, vasker de, og så kobler de sammen. Det er det som ofte gir det veldig mye verdi, å koble sammen fra ulike kilder. Og så sesongjusterer de, aggregerer, og så publiseres det ut en statistikkbank på ssb.no. Det er liksom hovedvirket i SSB. Når du sier ... Når du sier bearbeider, hva slags verktøy bruker de? Er det R, eller er det Python, eller er det manuelt, eller? Ja, altså der kommer jo den nye dataplattformen inn. For vi har jo tradisjonelt jobba veldig mye med SAS, og hatt databasesystemer som Oracle, som vi har kjørt i vårt eget datasenter i Kongsvinger. Men Dapla, den nye dataplattformen som jeg og Kasper jobber med å utvikle, den baserer seg på en del ny teknologi, og da jobber det. De som jobber nå på Dapla, jobber med Python, R, Git, Github ... de typer verktøy.

05:53 --> 07:25

Men hva er en dataplattform for dere, hvis du skal elevate pitchen for det? En dataplattform for oss, det er et sted å hente inn data fra eksterne. Har verktøy til å bearbeide, automatisere, lage pipelines for data. Og så skal det flyte ut. Enten som en forskningsrapport, eller som et tall i statistikkbanken vår. Hvordan ser den ut på innsiden? Rent teknisk så kjører vi på Google. Så vi har et kybernetisk cluster som kjører på kybernetisk engine. Og så skal det sies at vi ... ja, det er jo statistikerne som skal produsere statistikken, men vi har jo òg noen IT-team eller ekspertteam som står for mye av innsamlinga av dataa, som produserer applikasjoner. Så da har vi et kybernetisk cluster der de applikasjonene kjører. Og det er òg i det clusteret vi hoster bl.a. Jupiter og de tjenestene som statistikerne, statistikerne bruker på den nye plattformen. For de som ikke er så kjent med dataplattform, Jon Casper, vil du fortelle litt hva Jupiter er? Ja, umulig Eivind er bedre til å svare på det enn meg,

07:25 --> 08:33

som tross alt har støtta og arbeida litt med det, men det er jo en ... arbeidsbok for Python, så du kan skrive Python-kode og eksekvere det interaktivt. Du kan sammenligne det med en idé, men den kjører i browseren. Men så trenger den et sted å kjøre, altså backend-messig? Den eksekverer vel koden på backenden. Så da har vi installert det på en sånn måte at hver bruker, hver statistiker som går inn der, får en egen POD, når de da går inn, on demand. Som de kan kjøre Jupiter notebook, som jeg tror det heter? Ja. Jon Kasper, hva er teknisk? Hvordan er det dataplattformen er satt opp? Ja, så vi kjører jo da Kubernates i Google. Google Cloud Engine. Og på Kubernetes-klusteret så har vi installert Istio, Cert Manager, Flux for githops-operasjoner. Og så har vi litt forskjellige typer brukere.

08:34 --> 10:12

Jeg snakka jo om dette IT-teamet. Det er jo ofte de har IT-kompetanse og vet hva Kybernetes er for noe, mens et statistikktime vet ikke nødvendigvis det. Så vi bruker Kybernetes-clusteret til å tilby tjenester til statistikerne. Blant annet Jupiter Notebooks, som en ... Man kan kalle den en IT-kluster. Man kan kalle det en interaktiv IDE i browseren, der man kan skrive Python-kode og eksekvere den, som de fleste statistikere bruker. Og så på andre sida har vi disse IT-teamene, ekspertteamene, som sitter med CubeCTL og deployer applikasjoner ut til klusteret. Hva slags typer? Dataapplikasjoner som de kjører der? Ja, så de IT-teamene, ekspertteamene, de sitter typisk og utvikler ... Det kan være mange typer forskjellige applikasjoner, men mest vanlig er datainnsamling. Det kan være innsamlinger fra folkeregisteret, visumhetsregisteret, Altinn 3-skjema osv. Så vi har vel rundt ti IT-team. Kontra 150, sånn statistikk-teame, da. Så det sier jo litt om dimensjonen, og hvor behovet òg ligger.

10:12 --> 11:31

Men til disse IT-teamene, hva annet leverer dere til dem? Får de ulike databaser? Får de andre verktøy for å lage sine applikasjoner? Vil du fortelle litt om det? I utgangspunktet er IT-teamet mye mer autonomt. De kan ta i bruk den teknologien de har lyst til, på Google, så lenge de tar ansvaret for det. Men det er klart, som et plattformteam må man tilby noe av verdier. Vi tilbyr et Helmet-chart for deployment av applikasjoner, som abstraherer vekk en god del av kompleksiteten med Kubernetes-manifestene. Og det som er nødvendig for at de skal få lov til å kjøre der. Og så har vi terraform-moduler, hvert team har sine egne IAC-repoer. Der vi bruker Atlantis for å effektuere de terraform-endringene. Atlantis er et sånn Proquest Automation-verktøy. Det gjør jo at man ikke blir så avhengig av ... Man blir ikke så avhengig av en enkelt utvikler som sitter på maskina si

11:31 --> 12:48

og skriver terraform-apply, man får det i litt mer kontrollerte former. Så da har vi noen terraform-moduler som vi tilbyr der. Og utover det er det vel dokumentasjon for IT-teamet. Siden det ikke er så mange, er det litt lettere at de bare spør oss direkte. Men Øyvind, disse statistikkerne og statistikkteamet, hvordan opplever de dataplattform? Er det en endring for dere i deres hverdag, eller er det litt sånn same old, same old? Nei, det må vi kunne si er en kjempestor endring for så å si hele organisasjonen. Så vi har jo vært på den reisa her siden 2016, vel. Og jeg vil si sånn: Nå begynner vi å få litt traction på det, og det har vært en stor endring. Som endring i arbeidsprosesser og hvilke verktøy de bruker. Egentlig også litt krav til dem. Det blir kanskje stilt litt andre typer krav på Dappla enn det har vært gjort tidligere. På hvilken måte da? Blant annet versjonshåndtering av kode. Sånn robusthet i produksjonsløpet, og det at du kan gjenskape resultater.

12:48 --> 14:05

Og vi gjør ganske mange løft også med den plattformen. Sånn som metadatasystemene får en hel ... Vi gjør en god del om på metadatasystemene. Og det blir mye strengere krav knytta til metadata på data. Vi ønsker å kunne bruke mer av dataene til raskere å snu oss og publisere nye ting. Da er man helt avhengig av metadata. Og det kommer som et strengere krav på statistikktimene. Når du sier strengere krav, blir det underbygd av plattformkapabiliteter, eller er det dokumentert? Er det dokumenterte krav, eller hvordan gjør dere det? Vi bygger jo tjenester for å gjøre det så lett som mulig å oppfylle de kravene her. Et viktig prinsipp vi har på plattformen, er at vi ønsker at statistikktimene skal være så autonome som mulig. Som vel er en sånn erkjennelse om at hvis man skal kunne snu seg litt raskt når ting skjer rundt i verden, så må de kunne styre sine egne ting. At ikke de må ha en kundeserviceticket for å gjøre en endring upstream. Det er jo en av de målsettingene vi bygger veldig mye etter. Spesielt i de to andre teamene som ikke Jon Kasper er med i,

14:05 --> 15:10

hvor vi bygger mer tjenester rett mot statistikerne. Klarer de å bruke det her? Hva er riktig abstraksjonsnivå? Når blir det for komplekst, og når blir det for enkelt? Eller når det kommer til ting som automatisering og den type ting. Du har sikkert en formening om det, du og Jon Kasper? Ja ja, og vi tilbyr jo tjenester mot de statistikkteamene òg, det er bare at jeg ikke er like teknisk, det er ikke terraform-moduler. Det er mer sånn uptin, altså sjølbetjening. Jeg ønsker å benytte meg av denne tjenesten, så slipper statistikkerne å få hendene skitne i ... Men hvis et statistikkteam kommer og sier at her er det en helt ny datakilde, her er det en eller annen aktør som har noe spennende data som vi vil ha, hvor mye tickets er det vel kanskje ikke, men hvor mye invovering må dere eller andre team få for å begynne å få det inn i plattformen, sånn at de kan bruke det?

15:10 --> 16:23

Spørre om det i en Jupiter notebook, f.eks.? Det varierer veldig. Hvis det er en komplisert datafangstprosess, så må du sette opp et produktteam eller noen med ulik kompetanse som kan hjelpe i å hente det inn. Hva er typisk en komplisert datafangstprosess? Jeg vet ikke, mobildata fra Selenor, ikke sant. Sånne kvitteringer. Bongdata var det et produktteam som holdt i, så da var det vel ikke snart. Så da var det vel ikke snakk om en generell tjeneste som var selvbetjent. Du hadde et mer ekspertteam, så. Og så har du helt andre typer datafangster, som bare er en filoverføring. Og akkurat der nå så tilbyr vi ikke noen tjeneste på Dapla, vi har det i veikartet. Men vi tilbyr en tjeneste for å hente inn fra API-er som skal være selvbetjent, og den har vi sett at den ... Den er litt for komplisert, kanskje, for brukerne. Så der skal vi gjøre en ny iterasjon på den og ... Fortell litt om den, da. Kan et statistikkteam si at her finnes et API, det er dette endepunktet?

16:23 --> 17:50

Forklar noe skjema, kanskje, og få hente det inn i plattformen? Ja. Da er det kanskje Jon Kasper som kjenner best til den tekniske biten på datakollektor, som vi kaller den. Ja. Så det er jo noe kode som de kan ta i bruk for å ... Ja, det er egenutvikla kode for å gjøre datainnsamling. Så man spekker opp et skjema og sier litt hvordan real trust-strategier og feilstrategier skal være, hvordan man skal synonymisere og behandle dataen. Men det er jo opp til hver enkelt dataeier å gjøre en vurdering om kilden er god nok og den slags. Det er ikke noe som plattformteamene har noe saying på. Med så mange statistikkteam tror jeg det er litt viktig at vi setter ansvaret der det skal være, og så får vi heller bistå på tjenestefronten. Og så skjer det også mer og mer at ... Vi titter jo mot open source-løsninger på det meste. Det er jo en uttalt strategi, og vi har noen interne arkitekturprinsipper som vi arbeider mot. Så et av de arkitekturprinsippene er å ta i bruk mer open source

17:50 --> 19:09

og ha erfaringsutveksling med eksterne. Hvordan har den kulturen vært i SSB historisk sett? Ja, det er litt vanskelig å forme seg, siden det ikke har vært så lenge. Men jeg har da inntrykk, iallfall da jeg starta i SSB, at den var ganske god. Man har jo åpen data. Man har allerede ryggmargsreflaks med det å dele. Det er jo andre organisasjoner som ikke har noe som helst. At den åpne kildekoden og åpne data kunne være en liten link. Ja, jeg tror vi kan si ... Jon Kasper jobber jo på den nye dataplattformen. Men jeg tror vi på den gamle plattformen, som vi har jobba på de siste 20 åra, så har vi hatt mye å gå på der, med å dele kode. Statistikerne har ikke hatt publik repor med kode og sånn, som vi har som målsetning nå. Jeg tror heller ikke utviklerne har delt. En ting jeg lurer på er: Hvordan håndterer dere kontakten med brukeren, for å finne ut hva slags behov de har, og hva det er liksom ... Du snakka litt om abstraksjonsnivå, hvordan finner dere ut hva

19:09 --> 20:29

som er riktig abstraksjonsnivå på plattformen, og hva dere skal lage av nye features? Ja, så vi har hatt, brukt en del referansegrupper, altså snakke med, få en gruppe brukere. Hva er det dere prøver å løse her, hva er egentlig behovet, liksom? Det kan ofte være ganske komplisert, fordi det blir veldig fordekt i løsninger, ofte. Men det er på en måte sånn vi går inn i det, og så lager vi kanskje en pukk, og lar noen brukere teste det, og så tar vi det derfra, itererer over. Hvor teknisk er det i Tweeters lager for statistikktimene? Må dere løfte det veldig, eller? Ja, altså ... Jeg kan jo fortelle om en helt konkret tjeneste. Sånn som måten vi håndterer data på i SSB. Så har vi definert noen permanente datatilstander. Data kommer inn til oss, og så endrer de seg hele veien. Vi har definert fire-fem permanente data. Den første tilstanden, rå data, sånn som det kom inn, den er det veldig strenge krav til, så den har ingen i teamet tilgang til.

20:29 --> 21:40

Som default. Det er noen på teamet som typisk er forhåndsgodkjent, som gir seg sjøl korte just-in-time-tilganger, med god logging og sånn. Men da måtte vi bygge en automatiseringstjeneste, for vi kan ikke bare låse dataene et sted de ikke har tilgang. Kanskje skru av maskinene også, da er det ingen som får tak i dem ennå. Og da tok vi en sånn runde og snakka med dem. Hva ville dere helst gjort her? Jo, de har jo noe Python-kode. Som de gjerne vil påføre de nye filene som kommer inn. Og så få det skrevet ned til der de kan ha tilgang. En av de viktigste tingene som skjer der, er saudonymisering og dataminimering. Fjern det du ikke har behov for å ta med videre. Så da bygde vi en tjeneste, vi kaller den for Kildomaten. For det er kildedata, kaller vi det, og så er den automatisk. Så de angir på en måte en filstie i en GCS-bøtte. Og så tar vi alle nye filer som kommer inn der, rigger en CloudRun-jobb,

21:40 --> 22:42

som prosesserer med det skriptet de sendte inn. Kan de konfigurere den? Hvor mye minne skal de ha? Og litt sånne typer ting. Men ... Men da trenger de noe skjemainformasjon for å kunne lage den koden som skal kjøre på dataene de ikke skal se? Ja, den typiske prosessen er i hvert fall ... Og det er kanskje litt modningsprosess, men mange datakilder tilbyr jo testdata. Men de er ikke vant til å jobbe med testdata. De stoler ikke på den helt. Og da er det ofte sånn at i begynnelsen ... Du kan gjerne se kildene og se hva som kommer inn og sånn, men det er ikke noen permanent tilgang. Den er maks noen timer hver gang, og så må du aktivt gjøre noe for å åpne den. Aktivt lagre den ned på disken din? Nei, det føler jeg ikke noe for. Jeg husker vi hadde litt det samme da vi begynte med dataplattformen i Nav også, og vi tenkte at det skal ikke være nødvendig å se dataene.

22:42 --> 23:51

For du kan jo få skjema, så kan du kjøre kode, og så kan du hente det til ditt utviklingshus. Disse statistikerne og datameldingutviklerne har veldig lyst til å se dataen. Jeg skjønner jo det godt, men det er jo noen åpenbare ulemper med den dataen som vi og dere har tilgang til, på at mennesker kan se dem. Så det handler jo om å finne balansegangen mellom hva man trenger og hva man bør gjøre. Og kanskje etter hvert lage verktøy som man kan trenge mindre og mindre. Og det er absolutt målsettingen, og det er de kravene vi må leve opp til òg, da. Altså, du kan ikke sitte med åpen tilgang til personidentifiserende informasjon, da. Det går bare ikke. Men disse lagene du nevnte, det var fem, det var rådata, og så får du først bearbeidet. Hva er de andre lagene, eller nivåene? Ja, så kildedata er rått, sånn som det kom inn. Neste tilstand er in-data. Det er typisk det som du har dataminimert, sardinomisert, kanskje flata ut, hvis det er en XML eller Jason. Og kanskje lagt på SSBs kodelister. Hvis kjønn kommer inn som M og K, så legger vi på 1 og 2.

23:51 --> 25:01

Det er veldig få ting som skjer i den overgangen der. Og så er det neste tilstand. Det er klargjorte data. Da har de typisk kvalitetssjekka, altså gjort all vasking av data, på en måte. Og så går det over til statistikkdata. Da skjer det jo koblinger med andre kilder. Da begynner aggregeringen også, og sånn sesongjustering eller de tingene, beregninger. Så siste tilstand er ut-data, og det er definert som åpne data. Da er det klart for Statistikkbanken på en gitt dato. Men sånn før det havner der, og når du sitter som et statistikkdeme, hvordan finner du ...? Du har jo nevnt at jeg legger på metadata som et statistikkdeme. Hvordan får du oversikt over hvilke datakilder eller data? Som finnes i SSB? Det er noe vi jobber hardt med nå, for nå er ikke det bra nok i det hele tatt. Både den løsningen for å fylle inn metadata ... Vi har jo masse krav på oss til hvilke typer metadata som skal ligge på dataene. Og de kan ikke alltid automatisk utledes.

25:01 --> 26:17

Så det er en liten manuell jobb der for Statistikktimen, og den løsningen lager vi nå. Og så rett etter det blir det en datakatalog. Metadataene er en Jason-storhet. Den er en Jason-struktur, og så skal vi bygge en Gui på toppen av det. Dere bygger katalog, bruker en open source eller noe sånt? Ja, altså ... Nå legger jo ikke jeg meg helt opp i hvordan utviklerne løser sånne behov. Så lenge det blir bra, så sier jeg liksom: Hva er det de trenger da? Jo, de trenger å finne data, og de trenger å se den informasjonen som vi i SSB har blitt enige om. Ja. Jeg syns det er gode produkter. Ja, jeg tenker vel den løsningen ... Den dukker opp når vi starter å jobbe med den! Men da ser du for deg en katalog, en selvbetjent interface hvor de kan gå inn og søke og finne ... Jeg kan gå inn på ssb.no og finne utdata, altså publiserte data. Der er det jo noe metadata. Tenker du noe sånt internt fra SSB òg? Ja, jeg tenker det. Og jeg tenker egentlig: Hvorfor skal han ikke være eksternt retta òg?

26:17 --> 27:32

Det er ikke noe farlig å søke i Metadata. Da kunne egentlig flere, særlig farskere, søke om å få utlevert mikrodata fra SSB. For dem hadde det sikkert vært interessant å se hva som fins inni de dype gangene i SSB. Nå sa du "mikrodata". Hva er det for noe? Mikrodata er jo den type data, og så er det også en tjeneste som SSB leverer. Den skrives med C, så det er vel "microdata". Men det ... Hvor er disse lydeffektene? Her! Å ja, du må ta den av òg. Bare fortsett. Mikrodata er en tjeneste som forskningsinstitusjoner og utdanningsinstitusjoner, departementer og sånn, kan bruke for å gjøre mer kompliserte analyser, men aldri se de underliggende dataene. Det er en kjempekul tjeneste. Det er ikke noe vi har bygd, det har vært et eget team. Men som lar deg gjøre regresjonsanalyser og alt mulig, men du får bare se sluttresultatet. Og den støylegger informasjon.

27:32 --> 28:39

Den veit på en måte: "Dette kan jeg ikke vise, så da støylegger jeg tallene litt." Uten at de endrer innholdet. Den var veldig fokusert på dataminimering. Du får kun de kolonnene du faktisk trenger. Og så er det vel òg noen søknadsprosesser og litt sånn, da. Men så er det veldig strenge krav for å sjekke inn data der. Det skal ikke være noe feil. Det er masse validering. Da skjer jo koblinger og alt på bakrommet. Ja, håndhever skjemaet veldig sterkt. Så heller på å undersøke om den tjenesten er noe som kan etableres internt òg. Om det er noe som det kan brukes for å ... Det er jo et gui oppi der, så da får man jo den oversikten. Man har jo med skjemaet beskrevet hver eneste variabel, så det er spennende arbeid som jeg håper øyenbryn prioriterer. Når kommer dette her Øyvind? Jeg har hørt mange signaler fra Tilmas og Moda at det må da komme snart nå?

28:39 --> 29:53

Vi har jo en årlig hack i SSB, hvor man får bruke fire-fem dager på å løse et program. Da valgte jo jeg, Jon Kasper og noen flere, å lage mikrodato. Til internt bruk i SSB. Så det er stor sjanse for at det blir prioritert. Det høres ut som du klarer dette på fire-fem dager. Det er jo bare å tenke på min fortjeneste. Nei ... Det er bra hvitt. Hjelper dere litt i fremgangen? Estimat: mikro. Men dere jobber også med noe som heter Onyxia. Hva er det for noe? Ja, jeg kan vel kanskje innlede litt der, Jon Kasper, og så ... ja. Så fram til nå, da, på DAPLA, dataplattformen vår, så har vi jo på en måte tilbudt sluttbrukerne en Jupiter de kan gå inn i og kode òg. Og det har det vært masse tilbakemelding på at nei, vi vil ha masse annet gøy også. Vi vil jo ha R-studio for de som koder i R, og de som har blitt litt flinke i Python, f.eks. Det er vel de vi fort har via code. Og hvorfor kan vi ikke få det?

29:53 --> 30:59

Og da har vi merka at vi har mangla en slags tjenesteplattform. Her kommer det noe nytt vi har lyst til å rulle ut til dere, med god tilgangsstyring og alt det der som skal være på plass. Og så har vi fulgt et prosjekt som Det franske statssikkerhetsbyrået har utvikla de siste fire-fem åra, kanskje. Det Open Source-prosjektet, som de kaller Onyxia, som er en slags sånn ... Datascience-plattformen, som er ment å kjøre opp på Kybernetis. Og som strømlinjeformer det å tilby en ny tjeneste. Det gjør det veldig enkelt. Vi har til og med hatt statistikere som har lagt ut nye tjenester. Hva er en tjeneste i den kondeksen her? En tjeneste er da noe vi ønsker å tilby til statistikeren. Som kan være liksom ... Det er typisk en form for grensesnitt. Det kommer en ny idé, vi vil gjerne prøve den. Eller en intern applikasjon. Den pucken på Datadock, som er med i datasystemet vårt, den er lansert der som en eneste.

30:59 --> 32:20

Rent teknisk er det jo egentlig bare en helmwrapper. Så det man egentlig konfigurerer der, er hvilke helmcharts som skal vises til en bruker. Og så får brukeren mulighet til å konfigurere. Bare at du har et veldig fint gooey på det. Så det gjør jo at vi klarer å levere tjenester som Jupiter, R-studio, VS-code ... Man kunne jo kjørt opp Doom hvis man vil det, ikke sant? Som vi har gjort så, for så vidt! Det har vi gjort. Som vi har gjort så, for så vidt! På en veldig enkel måte. Det gjør at vi som plattformteam òg får mye høyere fart på å kunne tilby de tjenestene som brukeren etterspør. Så det er egentlig et veldig spennende samarbeid. Det er jo ... Det er sånn man gjør. Det som er litt spennende med det, er at de gjør jo hele en greie her, open source. Så har vi vært relativt tidlig ute med å ta det i bruk utafor Frankrike. Så vi har fått et veldig godt samarbeid der.

32:20 --> 33:33

Så ja, bl.a. var vi på Fosdem i Belgia tidligere her i februar, og hadde et tack med dem der vi fikk implementert et par futures. Som vi ønska skulle være med inn. Så det er veldig artig å lytte på våre behov. Og det gjør at vi kan bruke ressursene våre på litt andre ting! Som mikrodata ... For dette er noe som kan ta over for Dapla, eller er det en måte å kjøre Dapla på? Eller er det noe som eksisterer ved siden av Dapla? Det er et akronym for dataplattform, men det er hele skysatsinga. For statistikerne vil det kanskje se ut som det er Dapla. Nå forholder de seg litt til Google sitt konsoll og sånn. Men vi egentlig tenker at de bør gjøre det i mindre grad enn de gjør nå. Og Nyxia tilbyr jo en filutforsker ... Det siste de kom med nå, var å kunne bare se dataene også. I nettleise. I nettleseren der. Og ... Det var da med DuckDB, da!

33:33 --> 34:52

Med veldig god fart på den visninga. For det er alltid et problem i nettleseren. Vi får mye klager på av statistikerne. DuckDB, den var ny for meg. Hva er det for noe? Det er sikkert bedre at John Casper tar den. Ja, så DuckDB er egentlig bare en sånn ... De kaller det vel en in process-ordlapp? Du kan legge det på toppen av en fil, parké-fil f.eks., eller du kan koble den mot databaser som Postgress, MySequel osv. Du kan også kjøre den in browser. Så det gjør den på en måte ganske fleksibel. Den har en ganske god ytelse og ... Spesielt på disse parké-filene. Hva er en parké-fil? En parké-fil er jo egentlig bare en filtype som ... Den er vel row-based, så du kan gjøre oppslag relativt fort. Det er vel neste versjon av Avro, det heter det. Er det ikke Columns Storage, eller? Er det jeg som er ute?

34:52 --> 36:42

Jeg kjenner til CSV, men det er en fil med data på et eller annet format. Å ja. Her er det jo sånn binær ... Mer binær, ja. Og ... Ja, det er en binærfil som inneholder alle dataene, da. Og den støtter at du embedder skjemaer og kan vel også legge noe tilgangsstyring inne i fila. Jeg ser på dokumentasjonene, og så er det bare "select from" og så en fil. Enten CSV eller ParkE. Det er så enkelt. Ja, så Parké er jo en sånn Apache ... Det stemmer ut ifra ... De har ducktyping som typestrategi. Vi kan godt prate litt om ... I SSB så har vi på en måte ... Enkelhet er et sånt arkitekturprinsipp. Det er en erfaring vi har gjort. Også når vi ønsker at team skal være autonome da, så kan de ikke liksom sitte og forvalte kompliserte databaser, og datavarehus og sånne type ting, så da … Det vi forsøker på i dappla, i størst mulig grad, er at statistikkteamene holder seg til parkerfiler. Og vi pusher ganske hardt på det også, for det er så enkelt, det er så intuitivt for dem å jobbe med, og man kan også ta den vurderinga selv om det kanskje hadde vært faktorer som talte for en database eller noe mer komplisert. Så kan man si: "Ja, men det vil også ha en kostnad, det at nå trenger vi IT-folk inn." Og det ... Det mener jeg er en ganske god strategi for å oppnå autonome team, når de autonome teamene er samfunnsvitere som skal kna data.

36:42 --> 38:01

Og så er det ikke alltid det går, det skal jeg være ærlig på. Vi har Big Quarry og Cloud og litt sånne ting også, men ... Da er det typisk, da må eksperter inn i teamet. Det må bli mer ekspertteam. Ja, for det er jo ikke bare å kjøre opp Big Quarry på lokalmaskinen. Det er ikke alltid det er like rett frem å dumpe inn masse data. Jeg skjønner det veldig godt. Det er valget på å ha det ... Keep it simple. Noe som jeg lurer på, når man jobber i SSB, har man noen favorittstatistikk? Ja, altså jeg har jobba mange år med sykefraværstatistikken. Det er et samarbeid mellom Nav og Nav. Den er jeg ganske glad i. Da flytter vi fila litt mellom Nav og SSB. Vi kobler på litt på hver vår side, og så publiserer vi hver vår statistikk. Jeg tipper en gang i fremtida så kommer vi til å publisere alle i SSBs statistikkbank, også Nav. Den statistikken syns jeg også er morsom. Tidligere i Nav hadde vi en diskusjon om dette. Jeg skåner for at Norge var dårligst i Norden på sykefravær. Så skulle vi prøve å ikke bli dårligst lenger, og da fant vi ut at det var mye lettere. Det var ganske få islendinger som trengte å bli syke.

38:01 --> 39:15

Så hvis man bare tenker litt utafor boksen, så kan man oppnå ganske mye. Ja, ja. Gi av målsetninger. Vi har jo en egen statistikksjef i Nav. Han publiserer masse gøyale statistikker på LinkedIn. Gjett hva som er riktig svar på dette spørsmålet? Nei, dette vil jeg jo vite! Nå må jeg vente. Ja. Hva med deg, Jon Kasper? Ja, nei ... Kanskje litt mer mainstream of favity, navnestatistikken. Jeg har et unikt navn, så jeg syns det er artig å vise fram at det ikke er mer enn fem i Norge som heter Jon Kasper. Oi! Jøss. Det hadde jeg ikke gjetta. Men vi begynner å gå litt inn for landing, og før vi avslutter, så har vi et spørsmål som vi stiller leserne våre, og det er om dere kan fortelle en gang ting ikke gikk helt etter planen, og hva dere lærte av det? Ja, det er jo knytta til det her replikasjonsclusteret vårt, det da, det kupernetiske clusteret, det var i staging-miljøet, heldigvis, testmiljøet vårt.

39:15 --> 40:30

Det er ofte en rutineoppgave. Det er å oppdatere en IP-whitelist for en av konsulentene. Så når man skal gjøre det, så er det standard prosedyre. Man oppdaterer jammelfilla si, så tar Atlantis og plukker opp den endringa og kjører en plan, og så må man aktivt godkjenne Procrasten før man kan kjøre en apply. Den gangen her var vel kanskje første gangen både ... Både den som committa inn koden og reviewery ikke sjekka den planen. Så idet man skrev Atlantis Apply, så ble staging-klusteret recrata, og alle PWC-er som hørte med, ble borte. Den var litt kjip, fant vel i etterkant ut der at ... Det var pga. at vi brukte en flytende tag i staging, og så hadde man i den ene submodulen bytta om på rekkefølga på en sånn liste, så counten hadde endra seg, og da hadde Google, kubinettis-ressursen, tenkt at alt måtte "recreates". Så den var litt kjedelig.

40:30 --> 41:43

I etterkant har jo Google slengt på en Delete Protection flagg. Så vi er kanskje ikke vår eneste. Det lå litt læring i at man må alltid se gjennom planen sin før man er klar gjennom den. Hvordan jobber dere med læring av feil i SSB? Der kjører vi post mortem, så vi har jo en prosess for når det oppstår hendelser. Så det å kjøre post mortem og ta læring av hendelsen ... Ja. Det er en viktig del av det. Det er godt å høre. Ikke sånn public shaming. Nei. Er det ellers noe dere har lyst til å si før vi runder av veien videre i går? Vi har jo touchet litt inn på det. Vi kan jo begynne med deg, Øyvind. Ja, altså veien videre. Vi har jo snakka litt om Onyxia. Det er noe vi jobber ganske mye med nå, å få det ut i brodd. Vi har på en måte en pukk ute, så alle kan teste. Komme med tilbakemeldinger og sånn. I tillegg så har vi jo hatt mange fruktbare samtaler med Nav

41:43 --> 42:48

om å kanskje ta i bruk Nav sin applikasjonsplattform NICE. Det har jeg veldig troa på, det. Ja, den vil jeg si ... Unnskyld. Men ja, den ville jeg kanskje si er mest spennende òg, da. Har jo kjørt en nice pilot her i 2023. Som vi har sett kan bære frukter. Så det å kunne samarbeide potensielt om plattform, det tenker vi bare gir mening, i stedet for å sitte på hver sin tue og lage omtrent den samme plattformen. Så veldig spent på det framover. Kanskje hvis dere kan bruke NICE, så kan Nada bruke Onyxia? Kan vi for øvrig si det, at akkurat når vi snakker nå, i mars, så er det ... Vi er nesten ferdige med å klargjøre hele prosessen rundt fullføringen av piloten og hvordan vi går videre. Men når det blir klart, så skal vi si det høyt og tydelig. Ja, vi gleder oss. Vi er spente.

42:48 --> 43:59

Tusen takk til Øyvind Bruers Gaspe og Jon Casper Sverja fra SSB, for at dere har vært med oss i studio i dag og delt så mye flotte ting. Audun, har du et høydepunkt fra den episoden? Jeg syns det er litt gøy å høre hvordan det både ... Man lager ... Når man lager plattform såpass likt, både når det er IT-utviklere og statistikere som er målgruppa, at det er mye av det samme. At plattformtankegangen og -tilnærmingen er fruktbar i begge leire. Hva med deg, Han Skritjan? Jeg syns det er veldig gøy å høre om disse open source-produktene her, og Nyxia. Og det at det er et samarbeid her på tvers av land, rett og slett. Ikke bare internt i Norge, det er jo kjempeflott, men her er det jo helt på en ny dimensjon, så det syns jeg er veldig kult, og heier veldig på SSB. Dette har vært en episode av Plattformpodden. Mitt navn er som alltid Hans Kristian Flåtten. Med meg i studio har jeg Audun Faukan Strand, teknisk produsent er vår eminente Tore Græsdal. Nyeste episoder finner du alltid på plattformpodden.no, eller i din lokale podkaster.

43:59 --> 44:11

Del gjerne episoden med en kollega og få en high five fra Audun neste gang du treffer ham. Ha det bra. God kveld! God kveld!