Hei og velkommen til plattformbaden en podcast om applikasjonsplattformer og teamene som lager dem. Mitt navn er som alltid Hans Kristian Flaatten og med meg i studio har jeg som vanlig Audun Fauchald Strand. I sessong tre av plattformpodden dykker vi ned I en helt ny verden av datapattform. Men før vi introduserer dagens gjester, Audun, har du et favorittoverføringformat?

Jeg tenkte litt på det. Det første jeg kan huske at jeg jobbet med, det var Corva. Gamle, gamle dager ved Ehout Beråt hånd. Det må være favoritten sin var det jeg traff på først. Hva med deg, Hans Kristian?

Vi har jo fått lov til å bli litt kjent med protokollbuffer, eller Proobuff. Ofte brukt I forbindelse med GAPC. Det er jo typ, men det jeg synes er veldig gøy, er at du genererer klienter for ulike programmeringsspråketene. Så det å ta det I bruk er sero-ført på en måte. Men I dag skal vi kanskje ikke snakke så mye om protokollbøffet.

I dag har vi heldige å ha med Luis Maurice von Dieffenthaler, og Kyrre Havik fra NAV. NAV jobber for å folk tilbake I arbeid og forvalte tretten av statsbudsjettet. Ikke alt til IT riktignok men har likevel en av Norges største IT avdelinger, og har fortsatt datasstemme I produksjonen som ble laget på 80-tallet. Lui, kan ikke du begynne å fortelle litt om din bakgrunn og hva du jobber med I NAV?

Jo, jeg er produktleder I NADA. NADA er jo plattformen for å kunne ta bedre valg I produktutvikling. Der har jeg vært I to år sammen med blant annet Kyre.

Kyrre, hva med deg?

Jo, hei Kret. Jeg jobber også I NAV med da Lui på Nata-plattformen. Jeg kaller meg ofte plattformutvikler. Og jobber sammen med Lui for å lage de produktene som vi ser man trenger på å lage en datap.

Lui tenker de store tankene, og så er det du som gjør det.

Det er hele måten jeg liker å se det på. Jeg lurer er helt enig, men jeg liker den da.

Du fører på en måte alle de store tankene som Lui er.

Du er. Men dere har flere I det timen bare der to?

Ja, vi er syv stykker nå. Og det har vi jo vært de siste to årene, etter at jeg kom inn I teamet.

Men det er to nye, er det ikke det?

Ja, vi har fått inn to nye utviklerne nå. Så vi har jo da kurre, vi har mange, vi har Petter, vi har Paul som er utviklerne. Og så har vi Veverjørn, som er data-scientist som bistår mye I drift også. Og så er det da meg som er produktleder I teamet.

Men dataplattform, hva er forskjell på en data plattform og et datavarehus eller en datasumpp?

Det vi på en måte er til for, er å hjelpe teamene I NAV til å kunne ta bedre valg med bruk av data. Og I NAV så har vi jo veldig, veldig mange team. Så vi har det noe sånt som en hundre og tjue produktteam. Så det vi må passe på å gjøre da, er at vi bygger en plattform som kan skalere, og da kan ikke vi gå inn å eie dataen, vi kan ikke gå inn å forstå logikken til dagpenger eller til sykepenger. Istedenfor så må vi da tilby verktøy som gjør at disse teamene selv kan ta ansvaret for sine data.

Det er jo på en måte et skille til hvordan data vareus er bygd opp, hvor man henter inn dataene og bearbeider disse, og aggreagerer de opp, og publiserer for eksempel statistikk eller styringsinformasjon internt I NAV. Men da tar man eierskap til de dataene som kommer fra kildene.

Men brukerne deres er folk som jobber I, eller nærmer de teamene som driver med produktutviklingen?

Ja, så vi har jo på en måte grovt sett en todelt masse av brukere. Så vi har de som er knyttet til produktteamene, og da er det både utviklerne, produktlederne, designerneene I disse teamene. Du har ledelsen rundt, så det er på en måte på den ene siden. Og så har vi da også mange brukere I datatimene som sitter I dataova, som da typisk bruker plattformen vårt til å kunne kjøre Air-jobber og til å kunne kjøre deb-jobbene sine. Og det er jo noe kurre jobber veldig mye med

I dag, så

det er

jo en elegant Valle.

Ja, minkarra, dras litt igjennom sånn teknisk sett, hvordan ser NatA-plattformen ut?

Jo, I mitt hode er NADA, eller datap-plattformen som vi lager, delt I to. Den ene siden er det vi kaller markedsplassen. Som er der man kan finne og få tilgang til data, altså den undersøkende biten. Og så har vi laget KnaDA, som er den plattformen hvor du kan kjøre analysejobber. Som er en ren Kubernetes plattform.

Så det er der du jobber med dataen, og så har man markedsplassen hvor man finner dataen og ber om tilgang og deler dataen så klart. Det er et skille jeg liker å si at vi har.

Hvis jeg da vil bearbeide data og bruke på den knadab, hvilke verktøy får jeg tilgang på

det? Knadab er bygd opp av hovedsakelig to tjenester eller to komponenter. Vi tilbyr Airfloo for å kjøre jobber, og så bruker vi typ Nobooks for å kunne jobbe med utforskende analyser. De

som ikke er så kjent med AirFlow, hva er det?

Er et dag, Dag, ser du en bukke. Jeg husker ikke hva det betyr, eller hva det står?

Det er vel.

En måte å lage hovedsakelig Python eller Pythony jobber som man da kan kjøre I et Kubernetes Kubernetes clu, som da enten kan kjøre periodisk eller ved manuell kjøring. Og da kan du lage et stort hierarki med jobbene dine og de at de bygger på hverandre. Mens Juppt Notebook, som er et pyton editor eller et verktøy I nettleseren din. Du kan da skrive pyton og kjøre kode, og så er den da cellebasert som betyr at du kan kjøre biter av uton koden din uavhengig av hverandre, men så lagres det som er utkjørt og outtden I minne. Sånn at du kan kjøre en bit I starten, og så kan du kjøre en lenge bit.

Så det er veldig lett å jobbe iterativt med den. Spesielt for analyser.

Du sa både utforskende jobber og Nei, utforskende koding og jobber. Hva er forskjellen? Hvordan I arbeidsflyten til en data scientist? Er det disse kommer?

Inn? Når man jobber med analyse ved å lage innsiktsprodukter, så har man behov for å samle inn og finne ut hva som finnes av data, og hva jeg kan bruke for å lage et tilpasset produkt som gir den innsikten man ønsker å tilby noen. Og når man først har klart å sette sammen de puslespillbrikkene, som er det som jeg kaller den utforskende fasen hvor man da bruker hovedsakelig jpt note notebooks. Når man først er ferdig med den fasen og har laget pushetspillet, så er det jo kjekt å kunne oppdatere en gang om dagen eller en gang I måneden, litt avhengig av hva slags type innsikt det er. Det er jo kjekt at den kan settes på en måte I produksjon I anførselstegn, hvor man da kan få kjørt en periodis sånn at den blir holdt oppdatert.

Bare for skyte nå, så er det man sånn analysen man gjør utforskningen I en note, hvor man typisk da liksom henter inn data med pandda, så man knar dette og ser hvordan dette ser ut når man plotter. Da finner man sammenhenger. Og så setter man det typisk sammen til en eller annen rapport. Så vi har da noe som heter Catoo, som da kan deles på markedsplassen igjen. For du da har universelt utformet rapporter som ser bra ut.

Ikke bare

en eller annen data blåbær, men faktisk at det er noe som du kan lese.

Ja, det er en pen analyse, rett og slett, som kan brukes.

Men når du skal jobbe med data, så er jo data essensielt. Det å lage en djupt enbook hvis du ikke har tilgang på noe, er jo litt håpløst. Hvor henter man data fra?

Det er jo litt delt, altså vi kjører plattformen vår I GP, og der har vi jo Manchch &book, og vi har Cloud Comopser, som er Googless versjon av Airflow. Men vi har jo også veldig mye data som ligger onprem, så vi har jo veldig mye data I data-varhuset som typisk er interessant for disse datascientistene som ønsker å sammenstille data. Og det er der knrad da kommer inn I bildet. Vi har et eget cluster med åpninger til onplan, som gjør at man kan gjøre både den utforskende analysen, og at man også kan kjøre disse jobbene I onplan. Så, ja, kildesystemet er at du kan dele det I to basert på det som ligger I onplan, hvor du da må bruke knærne.

Og så har du da det som ligger I sky hvor du da også har en del analyseverktøy for å kunne gjøre det. Enten I GP, eller ved at man da kan bruke dashboardktøy som vi tilbyr da, I form av metabist, som er et Open-source verktøy vi har.

Jeg er forskjell sånn at det er mange typer lignende ting som ligner på datap. Du har nevnt at det varhus og sånn. Og hvordan jobber dere med å falle etter at du henger sammen, eller hvordan er det?

Ja, vi gjør jo på en måte noe på infrastrukturbiten, som ikke kan cirka en hundre og femti tusen ganger bedre enn meg. Men så er det jo også på en måte på Vi startet veldig med sånn data Mes- tankegangen. At nå skal vi kunne bruke data på kryss og tvers, og vi skal kunne koble data om ufør med data fra AP. Men det vi ser I praksis, er at vi har ikke de hjemland til å kunne få til den delingen. Så vi ser at de dataene som legges ut på markedsplassen, de brukes ganske isolert på markedsplassen også.

Og det er typisk et produktteam som henter dataene fra sine egne løsninger og flytter dette over til Big Cre. Og så gjør de analyser på det, og så er de litt sånn ferdig med det. Eventuelt så deles det da videre til statistikk. Eller så gjør man da analyser mer rent på dataene som ligger I dataova, gjennom knappene.

Og du sa I markedsplassen, er det en katalog, eller hva er det for noe?

Det er jo en blanding av en katalog og litt mer. Så der hvor en katalog er noe hvor du går og finner litt metadata, så har jo markedsplassen også en del funksjonalitet for å faktisk kunne forvalte disse dataproproduktene som legges ut. Så en produsent kan gå inn der og registrere dataproproduktene sine. De kan også pseudonymisere data nå gjennom funksjonalitet tilgjengeliggjort gjennom markedsplassen. Men det kan da også gi tilganger til folk da.

Så hvis du, Hans Christian, kommer inn og skal søke tilgang til noen data som vi eier, så kan du sende en søknad om tilgang til oss, vise til at du har hjemler til å kunne bruke dataene, og så kan vi behandle dette I markedsplassen, så har vi en integrasjon med IAM, som gjør at ting funker under panseret.

For NAV har jo en del skarpe data, så deles sensitive data om alle, og veldig mange av oss. Det godt å høre at sikkerheten tas på alvor. Jeg vil

bare skyte den at når vi I denne konteksten sier vi, så er det ikke at NADA kontrollerer hva og hvem som får tilgang til hva I datammarks. Da er det snakk I den kontoen som er at hvis NADA tilbyr data. F. Eks. Har vi dataproprodukter.

Vi deler data om hvor mange som bruker vår plattform, og det er data som vi eier og deler med andre. Så hvis Hans Christian er interessert I det, så er det oss som får søknaden. Men hvis det er for eksempel dagpenger som deler data, da er det dagpenger sitt team som tar ansvar for den. Så det er et tydelig skille der mellom hvem som har ansvaret for å godkjenne på en måte søknadene.

Men Louis sa litt om pseudonymisering. Kan vi si litt mer om den feature?

Ja, det er jo en feature som har jobbet med

Molly, ja.

Jeg er

veldig glad om pseudonymisering, så det er ikke så Men jeg har lyst til å spole litt tilbake, for kanskje det er en elegant overgang til hvordan vi har jobbet med plattformen også, fordi har snakket om at vi er til for at teamene skal kunne bruke data til å ta bedre valg. Og det var jo ganske stor ambisjon som vi hadde som en del av IT-ambisjonene. Og så var det konkretisert gjennom at man skal bruke data aktivt til tjenesteutvikling, og man skal behandle data som produkt. Og så ble vi plassert til å lage en plattform. Så vi skulle ta inn av den tekniske biten, sånn at hvis folk var gira på dette her, og de hadde muligheten til å kunne gjøre det, så skulle det hvert fall ikke vært inne å stoppe dem.

Så vi har jo jobbet med dette en del I år, gjort mye brukerinnsikt. Vi har snakket mye med folk både gjennom support, vi har gjort massevis av intervjuer, vi har gjort brukertesting, vi har hatt veldig, veldig mye kontakt med folk på ulike måter. Og det vi har erfart, er at det er en del som ligger utenfor hva vi kan kontrollere. Så det er en del problemer som går rundt det med at teamene må få tid til å kunne bruke data. De må kunne hjemlerler til å kunne bruke data, og egentlig alt av rettslig grunner på plass.

Så vi har I perioder gått nesten litt trist noen ganger, og tenkt at vi får ikke gjort noe med det her. Men samtidig er det jo noe plattformen kan bidra med. Så vi har på en måte prøvd å trekke på andre krefter I organisasjonen for å gjøre NAV mer datadrevet. Og så har vi da også sett at plattformen kan jo bidra med en del kule ting. Så rundt dette med compliance, altså det at man kan bruke data uten å se fødselsnummer, det er åpenbart noe plattformen kan støtte.

Fordi alternativ så må teamene selv håndtere dette ved at de anonymiserer det gjennom en eller annen algoritme, og ta ansvaret for at anonymiseringen er god nok Men det er jo også et koordineringsproblemer. For hvis da dagpenger anonymiserer på sin måte, mens sykepengeteamet anonymiserer på sin måte, så er det umulig å koble sammen disse dataene. Så det vi har gjort her, er at vi gjennom marked har sagt at OK, du kan peke på en tabell, og så kan du peke på en kolonne som skal senonym. Og så vil vi håndtere det. Så vi vil da dele en tabell med den kolonnen senonymisert hvor vi da bruker Sa to hundre og femtiseks til å til å anonymisere dette.

Og så har vi da oversikt over hvordan tabellene henger sammen. Så når da Turid har å gå inn og analysere dataene fra dagpenger sammen med data fra sykepenger, så kan han gå inn I markedsplassen og velge den ene tabellen og den andre tabellen, og si at: Jeg har lyst til å få disse tilrettelagt for kobling. Og så oppretter vi nye tabeller som er mulig å koble sammen. Så det gjør at man får sediserte tabellene, så det er ikke mulig å reidentifisere på tvers uten å direkte tilgang til tabellene. Så det er en feature som vi jobbet med.

Det var ganske artig å jobbe med det I høst, for da hadde vi et klart definert mål med det vi satt med og jobbet veldig systematisk med brukerinnsikt, og var mange som var ute og snakket med brukere. Gjorde brukertesting og fant ut at det vi trodde der sånn, det var helt feil. Så vi måtte justere. Og så har det tatt en god stund før vi har fått

det ut I produksjon. Så vi har egentlig ikke

fått opp de målingene som vi har ønsket. Og det er litt med at det er noen prosesser utenfor vår kontroll som tar litt tid, uten å gå veldig detalj på det.

Du snakket litt om målinger. Hva slags type målinger er det dere Hvordan måler dere at dere funker, at dere burde brukt og den type ting? Og hva er liksom de tingene dere prøver å oppnå seg for?

Beste eksempelet på det, er vel egentlig det vi gjør nå med kostnader, hvor det er forholdsvis enkelt å måle. Fordi det vi har slitt litt med på plattformen, som er litt paradoksalt at vi bygger en datap for at resten av NAV skal bli datadrevne, og bruke data aktivt til å ta ned usikkerheten I valg. Og så sliter vi litt selv med å finne de gode målingene. Så vi har målt hvor mange team som deler data på plattformen, og prøvd å følge det over tid. Men da har vi erfart de tingene som vi gjør.

Det tar ganske lang tid før det har en effekt på hvordan folk gjør ting annerledes. Så vi har ikke klart å bruke det ordentlig til å ta gode valg I produktutviklingen vår. Så jeg tror de målingene som vi har tittet på, er mer sånn: Hvor mange brukere er det vi har? Hvor mange ukentlige brukere har vi I dashbordverktøyene våre? Hvor team har vi som kjører Air I Knade?

Det er litt motiverende å se adopsjon. Men valgene våre informeres mye mer av det vi gjør av kvalitative innsikt når vi snakker med folk og finner ut av ting. Det er hvordan vi I teamet bruker. Men samtidig har vi brukt disse målingene til å få synliggjort: Hvor er det vi står I NAV? Hvor datadrevne er vi egentlig?

Hvor mange team er det som deler data på markedsplassen? Hvor mange team er det som har mer enn en aktiv bruker inne I dashbordet vårt ukentlig? Så kan vi da si noe om hvordan dette ser ut I hele organisasjonen, og synliggjøre dette til de som har en annen beslutningsmyndighet enn oss. Og kanskje få fram at det vi tror er problemene, er kanskje mer rundt compliance enn rundt verktøy.

Hvor datadrevet er en navn? Førtito. Vi har

førtito team som har delt data på markedsplassen, og har ikke en hundre og tjue produktteam. Og det er en ganske stor variasjon mellom de ulike områdene. Så vi ser at I hvert fall på produsentsiden, så er det noe sant. Og så har vi da cirka en hundre team som har minst en aktiv bruker inne I dashbordet vært enig. Vi har trettiåtte team som bruker EFlow.

Og jeg kan nok si, eller vi har trettiåtte EFlow.

Og vi har en hos tilsvarende med note også. Vi snakker jo litt opp I teamet. Det er frustrerende at du føler at du skal få et kjempeendring på kort tid. Men så tar det langt tid I en stor organisasjon. Men når vi ser oss litt tilbake, så har vi fått det mye kult.

Syns det.

Ja, det

er veldig mye spennende vi har laget.

Men kan du bruke NADA som et team uten å nødvendigvis dele med andre? Altså at man vil bare få innsikt I sitt eget data for å utvikle det produktet man er satt til å utvikle?

Ja, og det er det vi ser de fleste timene gjør. At de bruker gjerne egne data til å forbedre egen tjeneste.

Og at

det på en måte er fint Teamet som sitter med inntektsmelding I sykepengerbeløpet, de kan da bruke dataene sin til å se det: Hvor stor andel av inntektmeldingene er det som korrigeres? Og så kan de da se om de tingene som de gjør faktisk har effekt på den korrigeringsdelen. Og så er det mange flere konsumenter enn produsenter, og jeg tror at det vil jo være I NAV. Når vi har alle disse folkene ute på NAV-konter, så er det primært som konsumenter. Det er litt fint, for jeg tror konsumentene er litt når det er forsiktig med ordvalget.

Men det er litt enklere å dekke behovene deres, fordi de trenger dashboard. Alle konsumentene vil dashboard. Så vil data-scientisteneene noeopks.

Da er

de I en måte her på å dele den kompetansen på en eller annen måte. Mens på produsentsiden så ser det veldig annerledes ut. Der har du Kafka, postkre, du har orraical on premum, sikkert noen som bruker MongDB, du har hele spekteret. Folk gjør ting på en veldig forskjellig måte. Og det er også en annen profil som jobber med litt mer produksjon av data.

Så utviklerne jeg tror ikke vi sånn internasjonalt heller har et veldig klart svar på hvordan en utvikler skal få data fra påskekre over til Bigwre.

Så

vi har vært ganske forsiktig med å mene noe for hardt om hva den der golpften er, hva den der pwaMten er. Men heller sagt at dataprodukt for oss er en tabell eller View I Big CW med noen metadata rundt seg, som du kan analysere hvordan du kommer dit. Det finner du ut av litt selv.

Vil du gå litt inn I det, kanskje du, kure? For dette er jo ikke mastdata ligger jo ikke I BigQy. Det ligger jo, som Leo var inne på noe annet sted. Har dere sett noen typiske peterens, eller mønstre, for hvordan de får masse data over I Bigburye?

Ja, det vil jeg si. Vi har sett eller jeg tror det er en god blanding eller syner av hva vi har sett og hva vi er det fare og kanskje mener er en god måte å gjøre. Det ene ting vi er ganske tydelig på, er å skille mellom intern og ekstern data eller modell. Og det er for å unngå problemer som vi vet sånn historisk sett har vært utfordring med dataVAhus, hvor applikasjonsteam endrer sin interne modell I databasen fordi lærerne er nytt, har nye erfaringer og nye behov, men som gjør at det knekker da de som henter ut dataen, som bruker dem fra analytiske formål. Derfor prøver vi meg veldig tydelig på at når man deler data, spesielt på datammarik Passion, at man skiller mellom den interne modellen og den ekstern modellen.

Litt sånn som man gjør nå med applikasjoner som er API-er, så er det jo veldig stor forskjell på metodene som ligger unna API-er, og hva API-et selv eksponerer. Så det er jo det ene. Så det er jo modellen, hvordan vi skiller der. Så er det måten hvordan får man dataen fra A til B, hvor A ofte er postdre eller Kafka, og inn I datammarkssplassen hvor vi anbefaler Bigqure. Da er det noen flytter det ikke manuelt, men de gjør det parallelt.

Som de bygger opp data I påske, så bygger de også opp BigWi. Ellers så har vi det siste, kanskje år, ja, alle var det, sett på noe som heter Data Sremme, som er et produkt Google tilbehør. Vi er jo ganske sånn tungt investert inn I Google produkter. Og så med Kafka så er det er det også litt variabelt. Noen bruker sine egne Kafka Connect-applikasjoner som du kjører parallelt.

Ellers vet jeg at noen driver å eksperimentere med å bruke AirFlow og Kafka. Jeg vet også at folk bruker AirFlow og postgress I bikbur.

Men Airflow og Kafka, hvordan fungerer det teknisk sett?

Det som er litt interessant, for da blander man to forskjellige typer Det er jo to forskjellige typer teknologi, men altså to forskjellige tankegang. Kaffe er jo en strøm av hendelser, mens Air er mer som periodiske jobber. Måten jeg har løst på er egentlig bare at man leser x antall meldinger når man jobben kjører. Eller leser til den er tom og så tygger den gjennom og kjører den kanskje på nytt gjennom en time. Da leser den de meldinger som har kommet sin sist.

Det vil jo være en utfordring på hvis man har kaffakjøør som det er ekstremt stor last på, men foreløpig så har vi ikke det behovet I NAV da. Hvor godt og vondt.

Men Turid, du har jobbet både I applikasjonsplattformverden og I datapsplattform verden. Hva er likt hva er forskjellige og hva du liksom tatt med deg fra det endte til det andre?

Jeg har jobbet da også I NAIS, som er NAV sin applikasjonssplattform. Det er morsomt at du spør om det, fordi vi diskuterte det med en kollega tidligere I dag. Dette er jo klart definitivt som har lagt litt faringer, men

jeg er

veldig ganske bevisst på at vi ikke bygger på NAIS når vi skulle bygge knadde. Og det er mest for å kunne holde de avskilt, fordi det er noen små, men ganske sentrale valg som er forskjellig I forhold til hvordan du kjører en applikasjon og hvordan du kjører lastejobber. Og mest for å holde, jo flere kokker jo mer søl, så har I hvert fall jeg hatt et ønske om å skille det. Nettopp for at man ikke skal måtte legge begrensninger for å tilpasse for applikasjoner, for å lage begrensninger for hvordan vi kjører jobber. Og det ser vi også en del av disse produktene som tilbys.

Vi kjører jo knDA, kjører på Kubernetes og vi ser mye av den optimaliiseringen som er gjort for Kubernetes og mye av disse tips og triks og sånne ting handler om det å kjøpe applikasjoner. Det har merket vi spesielt når vi testet ut Google sin autPilot, hvor den skal gjøre alt med skalering av noder og sånne ting. At når folk kjører ti, kanskje femti småjobber kontinuerlig I løpet av en time eller to, så klarer ikke denne auto og scileær å skjønne hva som skjer. Fordi den jobben lever kanskje bare I tjue sekunder, og så skal den ned igjen. Da er den ferdig med å tygge den lille dataen.

Men det klarer ikke denne noden å følge med fordi det tar for langt I å kjøpe en node. Da har jeg funnet ut at vi kan ikke drive med den type autusskaler. Vi må mye mer ikke nødvendigvis stødig noe, men de må være litt mer faste. Der har vi også en spennende debatt internt I teamet. Nå som vi holder på å fokus på å spare penger eller kostnadsbespinger.

Hvor vi da tenker I applikasjonsverden er det veldig fokus på at

man

requster lim på applikasjonen. Fordi den applikasjonen kjører døgnet rundt, så da er det viktig at man har kontroll på hvor mye koster egentlig en appen. Mens det vi har funnet ut når vi jobber, så er det mye bedre å ikke request og limits. Poenget er at da kan vi hive det inn hvor det er plass. Også om de døde, fordi noden fikk litt for mye press på seg, så er ikke det et problem, for den jobben vil bare kjøre på nytt igjen.

Og da vil vi også få lagt føringer på at hvis ikke jobben din kan kjøles flere ganger, så har du skrevet jobben din feil. Jobben din må tåle å kunne kjøre på nytt, og den må tåle å kunne peile å bli kjørt på nytt igjen av clusteret. Og da ved å ikke sette request og lelimits, så får vi på en måte satt av mye mindre plass enn det man egentlig trenger. Men siden ingen av jobbene kjører egentlig samtidig, så går det litt magisk, så bare overlapper det godt nok Så er det en litt finjustering vi ser vi må gjøre det blant annet på disk. Det er overraskende mye disk som brukes av jobber som ikke bruker disk.

En er

litt sånn nødt til vi drev å jobbe med nå. Men vi ser det at det motsatte av det som er anbefalt på applikasjoner, å be om the Quest og Limits, det tror jeg vi har fått en bedt på at det lønner seg ikke på jobber, da. Og kostnadsmessig. Men hva

er de største kostdrivende I plattformene?

Jo, det er også veldig morsomt, for der hadde vi hvor jeg hadde en bedt på at folk som ba om store node, eller mye RAM fordi de skulle jobbe med en utforskende analyse, Hvor de har kanskje jobbet to timer hver dag, og så hadde de bedt om det, og så endrer de ikke hvor mye du ber om. Men syn de kanskje bare jobber et par timer hver uke med den. Det betyr at den bare blir brukt et par uker. Jeg har tenkt at det var dyrt. Det som viste seg er at de som ber dem litt, bare jobbe hele dagen hver eneste dag fordi det er jo det som koster.

Så på en måte, det korte svade der, er jo at folk jobber er det det som koster da.

Da er

det en veldig god løsning faktisk. Vi bare får kunnet jobbe veldig mye mindre. Kanskje bare et par dibruk. Så hadde vi spart så mye penger. Det er sånn vi pleier å gjøre I staten uansett, så det kan ikke være så vanskelig å tilpasse.

Det er nok vanskelig å starte med en sånn type analyseplattform, det har en ganske dyr startkostnad. Det er begrenset hvor billig du kan få den er vår teori. Så vi ser jo det på kostnadene våre som etter å ligger på en tusen to hundre euro-dagen Det er en baby-eren.

Men hvordan gjør teamene oppmerksom på denne kosten?

Ja, og det er det vi jobber med nå. Så vi har på en måte følger litt etter NAIS, hvor de har en sånn fancy konsoll. Hvor vi prøver å selge på vanlige tradisjonelle metabase og grafane Dashboard. Og så er vi litt usikker på hvor stor effekt det egentlig er. Men så er vi også veldig usikker da, imotsent applikasjoner, som det er lett å se at det er applikasjonen din, trenger kanskje litt ekstra ressurser åtte til fire.

Fordi det er der folk er på jobb og bruker applikasjonen din, og så kan vi nesten skru den av etter klokka fire. Da er det ingen som er på jobb. Så ser vi at det jobber som kjører litt sånn støtt og stadig. Vi tok ikke det er så mye å hente da ved å si at det er limit eller quest. Da tror jeg hvis vi skulle gjort noe drastisk der, eller gjort noe I det hele tatt, så måtte man nesten sagt at koden din må skrives mer effektivt, sånn at du får ikke de en hundre gigene du bedt om fordi du skal tygge gjennom masse data.

Du får femti gig, og så må du finne en annen måte.

Klarer du med det liksom?

Ja. Jeg tror det er liksom hvis man skulle virkelig vært streng på hva man tilbyr og hvor mye penger de skal bruke, så er det nesten.

Jeg mister at vinningen fort går opp I spinningen da. For det koster jo menneskeetimer å gjøre koden mer effektiv også.

Ja, for det var det vi så med blant annet, vi tenkte vi skulle få ned og det var det vi snakket om. Vi har snakket litt om aktive team, hvor vi har sett at vi har folk som ikke bruker tjenestedesign, men de er registrert og ting kjører. Så viser det seg at vi betaler Å kjøre et team koster cirka under eller to hundre kroner I uka. For et team som både ikke er I aktivitet. Da er det å finne balansen mellom hvor tid skal vi bruke på å skru av det teamet, eller burde vi heller bruke tiden på å fokusere om hvor vi kan faktisk få ordnes større kostnader, så kan vi heller ta disse småkostnadene mot slutten.

Men bare alltid kjører for et team da. Når du har reist et team med et aktivt.

Når du

har vært et team, så får du jo opprettet et ditt eget område. Da kjører vi også opp en Air, altså basen I eFlFl, og så kjører vi opp basen der sånn at du har mulighet til å logge deg inn og sette I gang. Det vi ser er at det er noen som testet deg ut, så kanskje de prøver en uke, og så ser vi at dette passer ikke for oss eller av andre kroner, så blir det bare stående å kjøre. Da er det kanskje det at vi heller burde se på om vi kunne, istedenfor at vi skal passe på å følge opp teamet, at nå må du skru av ting som dere ikke bruker. Kanskje vi heller burde se på er det en måte vi kan egentlig bare kjøre opp ting idet de logger seg på?

Som en type, egentlig det man ofte gjør med functions.

Functionsctions

sånn som man gjør med functions, som Funksjon as service. At man egentlig bare kjører opp tjenesten når folk faktisk ber om det. Og sånn som I AirFlow eller Jupyter notebooks, så er det veldig, vi ser jo når folk kommer på. Og da mener jeg at det kunne fungert med å kjørt opp ting da.

Det er en liten oppstartstid, men ikke så mye. Ja. Du kan jo bare vise, du sparer så mye penger på dette minuttet med venting. Du har

spart så mye. Jeg har ikke

kulere en timeprisen på å hente fast ansatte.

Men et alternativ vi har hatt her, er jo bare at den er dynamisk utenfor arbeidstid. Men så bare skrur vi ned. Så hvis du logger på klokka seks om kvelden, så vil det kanskje være minutt å komme I gang. Men alltid skrus på klokka åtte, så må den alltid være oppe mellom åtte og fire. Jeg tror det er mer penger å hente ved å spare på det da, enn at vi skal drive å jakte team som ikke bruker det.

Og så er det da de teamene som bruker det kanskje en gang I måneden. Vi kan jo skru det av, og så må de bare skru det på igjen en gang I måneden, det er kjempetent. Da tenker jeg det er bedre å finne dynamiske måter. Der tenker jeg at det er også mindre arbeid som er gjort for den typen da, fordi det er et mindre problem. Det er ikke et problem for applikasjoner på samme måte.

Da har jeg lyst til å spore, eller ikke spore da da, men Spor på en, kanskje et tema. En annen ting som vi ikke har snakket så mye om, som er en tjeneste som vi tilbyr på siden av det offisielle porteføljen vår er det vi kaller KnaDA-VM. Som er egne VM-instanser som vi kjører ved siden av Kubernetessklsklsteret hvor Eflovhy Hub kjører. Og det er fordi vi fant ut at det er en del produkter som ikke er så happy med å jobbe I nettleseren sin for å jobbe med kode, men heller vil jobbe på laptopen sin. Da har vi utfordringen med at de ønsker heller ikke å kjøre og laste ned, skap data og sensitiv data på sin maskin.

Så vi har funnet ut at mellomtingen der er å kunne tilby et sted hvor de kan kjøre på prosessene sine, altså de fleste jobber I Python, så vi kan Python cornolon, den kan vi kjøre I skyen sånn at jobbene kan kjøre der. Eller bebelsen av koden kan gjøres der, men så kan de kode lokalt. Så det vi da tilbyr da, er at kanaler og VM er egentlig SSA-tunnel for å kjøre I skyen fra den lokale maskinen.

Men jeg tror at Jpet-nettbook hadde noe sånt med Jpet-hub, at du kunne jobbe I editoren din og jobbe opp mot en sånn re måte.

Jo, og den har jo det, jeg. Men det er jo mange som bare bruker De bruker ikke juptur.

De bruker ikke det, jeg.

Derfor er det bare et halvt tilbud. Også er det jo som med alle andre ting, historikk her med hvorfor ikke bruke akkurat den tilbudet. Når dette plattformen egentlig ble påbegynt for

en hundre år siden.

Så fungerte ikke det rett og slett sånn nettverksmessig. Også har man begynt på en vei, og så er det liksom, det er ingen som hvis du jobber heller ikke I notebook, så har det vært ingen grunn

til å gå tilbake.

Men jo, for det som var Det som egentlig er grunnen til at det tok opp dette med knall av VM. Det var tilbake til det at det er et veldig stort fokus på hvordan man kjører applikasjoner I Kubernetes. Men det er betydelig mindre fokus på hvordan man kjører en data, markedsplass eller en analyseplattform. Og det er blant annet på hvordan kan vi på en god måte flytte disse knalla vedmene fra utsiden og inn I Kubernetes Hvordan kan vi kjøre?

Hvordan kjører Weber på Kubernetes-Etisk? Det er fullt

rart. Det gjør det også mye vanskelig å søke som generelt.

Da får du helt annen ting her. Ja.

For det høres litt sånn tullete. Og så har jeg blant annet snakket med Hans Christian om dette her. Hvor han tipser Han klarte å faktisk finne noe som vi driver å se på. Og det vi ønsker er jo et tilbud hvor de kan kjøre prosessene sine fra sin lokale maskin, uten at de har kobling til clustre. Fordi vi ønsker å skjule, eller vi ønsker ikke å skjule, men vi ønsker å skille det sånn at vi kan full kontroll på å øke nettkursettesklsteret.

Men

så ønsker vi igjen å fortsette å gjenbruke det clustere, så vi kan de samme mekanismene for sikkerhet og skallsikring og styring av det tekniske biten. Så da er spørsmålet jeg hvordan kjører vi opp sånne podder som kan kjøre koden mens da? Da har vi egentlig bare funnet ett prosjekt som er vel vedlikeallet person enn professor et eller annet sted. Også finner vi en hel haug av prosjekter som handler om å la folk kjøre opp ting I et curavesklosser. Det finnes det flere om hvordan du kan kjøre opp felles editoren og sånne ting.

Men da er det igjen litt skille mellom hva vi egentlig ønsker da, er å kunne jobbe kjøre prosesser rumot. Og at vi ikke ønsker da å eksponere Kubernetessklsklsklster, fordi på grunn av forskjellige nivåer av kompetanse og behov.

Hva var dette prosjektet med han på?

På tegne SSA heter det.

Så hvis noen har lyst

å være med og

møte hele livet, så

skal jeg få

det finne I media.

Moderne systemutvikling største for dem når ting ikke går an å Google, hva gjør du da? Men tilbake til nå hvordan når dere er en plattform, så har dere sett med bruker. Hvordan jobber dere med å kontakt med brukerne deres? Er dere jevnlig forum? Er det Slack?

Er det brevurer? Det

er egentlig mye forskjellig. Veldig mye brevurer, som ikke Raaen var. Vi har mye kontakt på Slack, og det er jo de brukerne som er på og trenger hjelp. Og der får vi feedback tyytter ofte. Og så er det der hvor vi veldig tett ord, men proaktive.

I form av at vi har for eksempel kurs. Vi kjører kurs I metabase, kjører kurs I hvordan flytte data fra påskegreet over til Bigcred. Vi har brukerforum, eller vi har hatt tidligere I hvert fall. Hvor folk kommer og deler sin erfaring med bruk av plattformen. Så det er egentlig ganske mange kanaler vi har til folk ute der.

Og det sånne refleksjonene vi har gjort litt der, er at vi er veldig I kontakt med de som er aktivert allerede. Så de som bruker plattformen vår, enten I form av at de er det I tanjeneninger som kjører en e-til-L, eller form av at det er en utvikler som flytter data fra posk til Bigkøy og kjører disse testene sine på hypostene, så er jo de allerede på plattformen. Så vi har liksom en bias I retning av de. Vi har ikke vært like flinke til å oppsøke og forstå de teamene som enda ikke er aktivert. Og forstå hva er det som holder dem igjen.

Så det tror jeg vi kanskje ikke helt har knekt den ennå. Selv om vi har jo vært inne I noen produktområder og snakket med ulike team prøver å spre det glade budskapet om data. Men ja, det er I hovedaktiv timene som allerede er på

med. En morsom ting med på en måte både brukergruppe, altså dataanalytiker og data Enginert, kontra applikasjonsutvikler er at mitt inntrykk av applikasjonsutvikler er ganske kravstuene. Det er jeg vel sikker fordi de har god erfaring med å være stille krav og be om ting, så ser man at de har god erfaring. Mens analytikererykkkere er på en måte helt på andre enden av skalaen, de er ikke vant til å be om ting, og definitivt ikke vant til få det tingene de ber om. Så de er veldig forsiktige, og du må litt sånn hale ut hva egentlig behovet deres er.

Og det er er veldig hyggelig å jobbe med, men det er også litt utfordrende, fordi det er lett at man ender opp med å tilby noe jeg eller vi tror de trenger, men så er det egentlig noe annet de har. De vil på en måte ikke være I veien. De vil ikke stille for høye krav.

-Altså føler jeg Gud som utvikler, nei.

Det er mye lettere å jobbe med noen som stiller krav og er tydelig. For poenget da vet du hva du hadde jobbet med og hvordan man kan jobbe med det. Mens noen personer som bare sier åh så flott at du gjorde det, bare at du gjorde noe. Så vet du jo, det er ikke sikkert at det gjorde at det var den riktige løøyøtet du kom med. Det er bare at du var fornøyd med en gang.

Så da var det sånn: okay. Okei. Det synes jeg er både spennende og litt frustrerende, og veldig morsomt.

Men bare for å skyte inn også, så har vi jo mange utviklere på plattformen vår også. Men de tror jeg er ganske happy med å gjøre greia sin. De skriver en niceapp for å hente data fra Kafka, eller de bruker nice Job til å få data fra et eller annet sted, eller bruker noen av de hvert enda våre.

Og så

er det lite ramaskyrk, fordi jeg tror de har såpass ukompliserte brukscaser. Hvor det bare er snakk om å flytte litt data fra et sted til et annet, og analysere det. Det tror jeg også er litt av grunnen, da. At utviklerne er ganske happy med det vi tilbyr, og det NAIS tilbyr også.

Vi begynner å gå inn for landing, men før vi avslutter, så har vi et spørsmål som vi stiller av leserne gjestene våre. Det er om det kan fortelle om en gang ting ikke gikk helt etter planen, og kanskje er enda viktigere hva det har lært av det.

Jeg kan ta min først. Vi kan ta en. Men I fjor sommer så hadde vi en hendelse på plattformen vår. Hvor vi hadde en sikkerhetskllipp på en test vi holdt på med. Og så hadde vi da et clutjør som vi ønsket å få slettet.

Men så skulle vi gjøre noen undersøkelser og utforske den glipperen som vi hadde gjort. Så det begynte at den ble liggende en liten stund. Jeg satt og ventet på å gå for å få slettet dette glasset. Er du fornøyd, nå har vi funnet ut det jeg vil Så snakker vi om bare slett den. Så når jeg da fikk den gåen så var det litt på ettermiddagen.

Jeg var veldig gira på å si at jeg kan liksom få rydd opp den blema. Og ved å være så gira på å rydde opp den blenda så klarte jeg å lage ny blende. For det jeg klarte da var å gå og slette. Jeg markerte feil plster når jeg skulle rydde opp I konsoll. Da sletter jeg da pryd-klsteret vårt.

Er jeg

lese bilen nå?

Det er helt flåseteset satt, det er bare å jobbe, men det er akkurat det det er. Det er bare å jobbe. Og det tenker jeg er fordelen, eller I hvert fall Det var nyttig eksperiment, selv om det ikke var et eksperiment, ved å se at det er helt riktig at plattformen vi tilbudt er egentlig bare et sted hvor folk gjør ting midlertidig. Det er ingenting som lever på den plattformen, bortsett fra når jobbene kjører. Så det betyr at det var ikke noe krise at vi slettet, eller de slettet plattformene.

Alle har slettet hele tiden, synes du det.

Selv om det føltes veldig sånn når jeg For det morsomme er at jeg oppfatter det liksom Jeg hadde trykket yes og skrevet Delete I denne bekreftelseboksen. Så ideen all sikkerhetmakning, men jeg var ferdig skjønte jeg med en gang: Vent litt. Dette er feil lam. Denne hadde en post fictionen ikke så godt. Så det var selve problemet.

Det vi lærte av det var blant som jeg sa at det er ingenting som kjører på plattformen. Database ligger på utsiden. Kildekoden ligger ved GitHub, dataen ligger alle andre steder enn hos oss, for vi har ikke noe data knyttet til den plattformen. Men det var en ting vi lærte som vi da ikke hadde backup av, var at vi hadde Airflow en mulighet til å hemmeligheter I Airflow. Og det var noe vi ikke trodde noen brukte.

Vi tilbyr noe annet. Og så var det Det var egentlig bare ett team som brukte det. De brukte det ganske aktivt. Og den nøkkelen som på krypterer de hemmelighetene, den hadde vi ikke tatt vare på. Han var egentlig en som var irritert, fordi han måtte legge inn alle evnensene på nytt.

Men det gjorde at mange andre lærte om denne tjenesten som efla å tilby, så nå er det mange som bruker det. Og vi har satt jo jo ikke glad for at jeg gjorde det, men vi lærte ganske mye nyttig av det da. Som jeg tror ikke vi hadde oppdaget. Som jeg tipper hadde vært et mye større problem hvis det hadde

skjedd til

sommeren nå for eksempel, hvis mange flere hadde tatt det I bruk og vi ikke hadde hatt denne knekken.

Hvis han lyttet på plattformbollen din når du vil si til

han

han

prøvde å endre noen misjon I Pskerre I går, og det tror jeg var greit. Men jeg har en blender jeg gjorde da jeg var med på et intervju. Det var faktisk den forrige jobben. For her var jo intervju I koronaperioden, så da kjørte vi alt digitalt. Og så var vi da

Hva var du på intervju? Nei, nei.

Det var

ikke til nå. Jeg intervjuet en kandidat. Så skulle jeg bare dra inn en presentasjon, og snakke litt om hva vi egentlig driver med, og prøver å selge inn dette. Jeg følte at ting gikk ganske bra, og hva var liksom I flow. Og så fortsatte bare praten, uten at jeg tenkte på at jeg delte skjerm.

Og så tenkte jeg at oi, nå har jeg pratet veldig mye. Kanskje jeg skal slippe til de andre fire som er flytt I også. Så I stedet for å si det høyt I intervjuet, så dro jeg opp Teams, som jeg da brukte, og skrev en melding til de andre. Og brukte veldig farget språk. Og sa at nå må dere bare be meg om å holde kjeft, for nå ble jeg vær.

Vi ser par I andre ord også. Og så kommenterte kandidaten tørt at: Ja, jeg tror ikke de kommer til å be dem om å holde kjeft, men du kan gå ti ordet videre til noen andre. Så lærdommen fra det intervjuet, det er jo at man ikke skal dele hele vinduet. En applikasjon. Det var litt ubehagelig der og da, men

man kommer

seg videre.

Det er utrolig spennende å høre om både hva man lærer av feil, men ikke minst hvordan NAV blir mer datadrevet med Nad-plattformen. Før vi runder av, er det ellers må jeg si: Hvor går veien videre for Nardo og NAV?

Vi har jevnlig diskusjoner I teamet, og det er litt sånn tilbake til den der litt sånn triste stemningen som vi snakket om. Og vi ville jevne mellomrom. Finner ut at det ikke er alt vi får til å påvirke. Men jeg tror vi er der at vi har en plattform som er bra, som funker bra. Vi ser det på feedbacken som vi får.

Og vi ser det på aktiviteten blant timene som vi har tatt I bruk. Så vi er litt mer sånn at vi venter litt på adopsjonsjonen. Og så gjør vi litt sånn fikser og gjør ting bra. Og så prøver vi å ekstra fokus på dette med kostnader akkurat nå. Og vi venter litt på den muligheten som vi tror kommer litt utenfor teamet.

At det enten skjer et eller annet annerledes rundt etterlevelse, at vi for eksempel får noen andre hjemler til å kunne bruke data, eller at det blir mer kostnadsfokus som gjør at det blir mer trykk på å få løftet mer over til plattformen vår. Men vi har sånn diakan, veldig klar strategi for hva vi skal gjøre de neste årene framover. Så på særlig det skal være.

Nå har

vi kanskje strategklæ hvis vi kommer på det.

Det er veldig godt det Louise sier. Vi har en spennende utfordring I forhold til det eksterne. Så jeg kom på en spennende ting internt, vi har snakket litt om, er det for teamet vårt En ting vi mangler I teamet er på en måte en frontend utvikler, og for så vidt også en designer I forhold til at vi har en datam markedsplass, som er jo hovedsaklig en tradisjonell applikasjon. Men så er vi egentlig en gjeng med plattformutvikler, og der har vi en litt sånn utfordring. En ting vi har snakket litt om der, er at det fins open source-tjenester som tilbyr egentlig en datammar markedsplasssplass hvor man kan få de, enten de som de kan tilby, enten en frontend eller en backend eller begge deler, og det er en sånn spennende ting som vi har snakket litt om.

At kunne vært interessant å se, kanskje vi kunne byttet ut på en måte en bit av markedsplassen, sånn at det var en mindre ting for oss å vedlikeholde å kontroll på. Også kunne vi heller bygd på det de små endringene som vi har behov for, istedenfor at vi skal kontroll over en hel markedsplass. Det er ikke noe som at vi ser at det er den veien vi skal gå, men det er en interessant ting vi har lyst til å snakke mer om. Som hovedsakelig egentlig bare på å påvirke oss internt.

Nei, veldig spenn. Tor, her er det jo høres ut som at det kommer fremtidige episode hvor vi kan høre mer om NAV sin reise til å bli mer datadrevet. Jeg vil si tusen takk til Lui Mois Diffentaler og kurat Havik fra NAV. Hvis du ønsker å lære mer om datap til NAV, kan du gå inn på Docs. Knadda.

No. Audun, nå er jeg spent. Har du et høydepunkt fra denne episoden?

Jeg synes på høydepunkt I dag var å høre om personlighetsforskjellene mellom utvikler og analytikere. Det synes jeg noen bør forske på, rett og slett. Hva med deg, Christian?

Du syns det var veldig spennende for dette med request og Limits. At takepo1, ikke bruker det, for det

er jo det som jobber

med plattform. Bruk det, ikke så mye Limit, nødvendigvis. Eller hva får ikke se på U Limit, men definitivt request. Som regel også memorile mitt. Så den tar jeg med meg videre.

Det var gøy å gjøre. Dette har vært nok en episode av plattform podden. Mitt navn er som alltid Hans Christian Flott, med meg har jeg Audun Fakalstrand, og teknisk produsent er vår eminente Gredal. Nyste episode finner du alltid på plattformpoden. No, eller I din lokale podcastapp.

Del gjerne episoden med en kollega, og få et skjevt smil fra Audun neste gang.