Episoden er transkribert av kunstig intelligens

00:00 --> 00:47

Velkommen til Plattformpodden, en podkast om applikasjonsplattformer og ikke minst teamene som bygger dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg Audun Strand. I denne sesongen utforsker vi plattformene i offentlig sektor. Men først, Audun, kan ikke du si litt om deg selv? Ja, det skal jeg gjøre. Jeg har jo jobba med plattformer. Det var mye morsommere å ha applikasjonsutviklere som brukere enn vanlige folk, for de sliter jeg med å skjønne hva driver med. Så jeg begynte å jobbe med plattformer i Finn for nesten ti år siden. Så jobba jeg med det i noen år, og så kom jeg hit i Nav for 6-7 år siden,

00:47 --> 01:31

der jeg fortsatte det samme og begynte å jobbe med NICE-plattformen. Så jeg har egentlig jobba med forskjellige typer plattformer i ti år. Hvordan begynte du å jobbe med plattformer? Jeg begynte som halve IT-avdelingen i Den norske turistforeningen. Og da hadde man ikke så mye ekstra tid, så da var det egentlig bare at alt måtte automatiseres. Og så fant jeg egentlig den lidenskapen for applikasjonen automatisering. Og siden så har jeg bygget plattformer for offentlig sektor med veldig mye bank og finans, før jeg begynte i Nav. Men nok om oss to. I dag er vi så heldige å ha. Vi har med oss Are Vattekar fra Skatteetaten her i studio. Hei, Are.

01:31 --> 02:24

Hei, Hans Kristian. Are, kan ikke du fortelle litt mer om hvordan du kom i gang med å bygge plattformer? Det kan jeg gjøre. Jeg jobbet i 15 år i en liten bedrift hvor vi hadde ansvar for applikasjon, applikasjonsutvikling, drift, infrastruktur. Og så kom jeg til Skatteetaten. I Skatteetaten var det et mye større fagmiljø, og vi så at det var et mye større behov også for å ha en større felles plattform. Så der begynte min reise i skatt for 13 år siden nå. Og i løpet av de siste 13 årene har jeg bygd applikasjonsplattformen til Skatteetaten. Fra den spede start. Så når du kom, så var det ingen plattform? Når jeg kom ...

02:24 --> 03:11

Da jeg kom hadde vi en plattform som bar preg av veldig mye manuelle bestillinger og fraværende automatisering. Og det er det som har vært fokuset, å tilby en plattform til utvikling, sånn at vi kjapt kommer i produksjon og klarer å løse samfunnsoppdraget på en god måte. Utrolig spennende. Men kan ikke du dra oss litt gjennom denne historien, som jeg tror startet i 2010? Det stemmer. Vi startet et omfattende moderniseringsprogram. Som het "modernisering av grunnlagsdata". Dette er på en måte finansopplysninger som banker rapporterer inn, A-meldinger fra arbeidsgivere og sånne ting, som vi setter sammen for å automatisk kunne beregne skatten din.

03:11 --> 03:59

Og da så man tidlig utfordringer med at infrastrukturplattformen var preget av manuelle bestillinger, og det tok lang tid å komme i gang. Det tok flere måneder å få i gang. Og dette måtte vi gjøre noe med. I 2015 så skulle Skatteetaten starte et nytt moderniseringsprosjekt som het Safir, for særavgiftsoppdraget. Og da så man jo veldig tidlig at det ble veldig dyrt hvis hvert prosjekt skulle etablere sin egen infrastruktur for alt som har med robusthet, skalerbarhet og sikkerhet å gjøre. Derfor ønsket man å innføre en horisontal skalerbar plattform. Istedenfor at hver applikasjon og hvert prosjekt måtte bygge dette inn i de enkelte applikasjonene sine på egen hånd.

03:59 --> 04:50

Da startet man med en utredning av Plattform as a Service. Og vi installerte etter en del vurderinger OpenShift og Ridgen i våren 2015. Da var Kubernetes i støpeskjeen, og det var en litt brokete start, for å si det sånn. Men vi kom i gang med OpenShift om prem, og har beholdt OpenShift om prem inntil nå. Ja, for du sier OpenShift. Da jobba vel jeg i Finn i 2015, og da gikk vi for Kubernetes. Hadde dere den vurderingen da, om dere skulle kjøre VanillaKubernetes eller OpenShift? Delvis hadde vi en vurdering rundt det. Vi har veldig mye RedHat om prem, så det var naturlig å se til OpenShift og hva det gikk ut i.

04:51 --> 05:40

Og gitt at OpenShift var mer modent, et større økosystem, bedre sikkerhet, en helt annen sikkerhetsmodell i OpenShift enn VanillaKubernetes, så gikk vi for OpenShift tilbake i 2015. Jeg husker det var en diskusjon som var mye mer oppe i dagen da enn det den er nå. Når man velger nye, så tror jeg det er vanligere, etter hvert som alle skyldevinnerne tilbryr Kubernetes. Det er blitt et enda vanligere alternativ å velge. Det avhenger litt av sikkerhetsmodellen din, men ja. Vi hadde veldig sterkt fokus på multitendency, å kunne isolere workload helt fra hverandre. Og det samme har vi gjort på den nye riggen som vi skal snakke mer om etterpå.

05:40 --> 06:33

Jeg tror det er viktig at vi tenker litt tilbake igjen på den tiden der. Jeg husker jo selv da var jo også diskusjonen Kubernetes eller Docker Swarm. Om Jesus. Det var ikke så selvsagt som det er i dag, at Kubernete skulle vinne, og det at man går for et kommersielt ... Et ferdig produkt, det var ikke veldig kontroversielt. Det var kanskje heller mer kontroversielt å skulle bygge det selv. I Finn hadde vi et kvarter der vi kjørte noe som het Sisko Cloud. Det var et oppussingsprodukt, men det var folk i Sisko som lagde det. Det funka ikke veldig bra, husker jeg. Det finnes ikke lenger. Men dere hadde OpenDrift Origin i 2015. Hvordan bygde dere på toppen av det?

06:33 --> 07:28

Hva var de neste stegene? Det var en interessant reise. For vi startet jo med å bygge automatisering I form av bæsj-script og sånne ting. Så så vi tidlig at vi måtte inn og gjøre noe mer. Vi måtte faktisk aktivt kode ned i OpenShift. Henge oss tett på plattformen. Det var da vi begynte å innføre disse kubernetes-operatorene. Lenge før det egentlig fantes noe operator pattern. Så har vi dratt automatiseringen derfra og bare bygd på og bygd på. Så vi har en veldig moden ... Moden plattform om Prem nå. Kan ikke du fortelle litt mer om hvor stor denne plattformen er blitt? Hvor mange er det som er med og jobber på plattform, og hvor mange team og applikasjoner har dere i dag?

07:28 --> 08:27

Godt spørsmål. Vi har i utgangspunktet mange plattformteam. Vi har ikke ett team som drifter plattformen og bygger den. Vi har alt fra ... Fra utvikleropplevelse, CID, det som er på en måte opp mot utvikling, til automatisering på plattform, sikkerhet i plattformen, applikasjonssikkerhet. Vi har en dataanalyseplattform som vi knytter tettere og tettere inn mot applikasjonsplattformen nå. Vi ser jo at det er egentlig én stor plattform. Analyse blir en veldig viktig del av ... Del av applikasjonsporteføljen vår. Og vi har selvfølgelig plattformdrift. Så totalt sett er vi vel kanskje 50 personer. Noe sånt noe. Jeg har ikke helt eksakte tall.

08:27 --> 09:14

Og hvilken del av den jobber du i? Jeg jobber som ansvarlig arkitekt for hele applikasjonsplattformen. Er det også analysedelen? Ikke analyse. Der har vi delt. Så vi har delt oss inn i tre hovedområder: Infrastrukturplattform, applikasjonsplattform og dataanalyseplattform. Det gir jo mening, det. Men Are, vil du dra oss litt igjennom fra applikasjonsplattformen? Sånn når et team skal i gang og få en applikasjon ut i produksjonen. Hvordan ser den reisen ut for det teamet? Det avhenger litt av type applikasjon, igjen. Hvilken reise de kobles inn på.

09:14 --> 10:14

Men typisk så blir de ombordet på plattform. Dvs. de får tilgang. De får satt opp et navnerom eller flere, med nøkler og sånne ting. Og så har vi kjøreregler på applikasjonsarkitekturen. Applikasjonsarkitekturen, som sier noe om hvordan du skal bygge en applikasjon for at den skal passe inn på plattformen. Og etter det så går veien ganske radig av gårde. Vi tilbyr et sett med tjenester, standardtjenester. Alt fra felles CICD-pipeliner, sikkerhetstjenester, automatisert utstedelse av nøkler ... Automatisert utstedelse av nøkler, tokens, identitet og sånne ting. Vi har integrasjonstjenester mot f.eks. ID-porten, maskinporten og andre IDP-er.

10:14 --> 11:08

Og vi har ikke minst massiv infrastrukturautomatisering for å kunne tilby en effektiv utvikleropplevelse i form av automatisert opprettelse av lagring, backup, nettverk, DNS, PKI. Alt det der er heleautomatisert. Men basically så har vi en golden path som vi tilbyr, og så kan utviklingsteamene velge om de vil kjøre på den ferdiglagte veien, eller om de har lyst til å gå på siden. Og de er velkommen til å gå på siden, men da må de ta ansvar på egen hånd for det vi ellers ville tatt ansvar for dem. Hvordan håndterer dere når det kommer et team som gjør noe annerledes? Så sier de de vil ha masse GPU-er eller en spesiell database som ikke tilbys.

11:08 --> 11:54

Hvordan går man fram da? Det er litt forskjellige modeller om prem og i sky. Men det er jo å identifisere behovet, og veldig ofte så vil da enten plattformer si: Dette er en tjeneste vi velger å tilby, for det er mange som vil ha den. Hvis det er en veldig spesialisert tjeneste, så kan utviklingsteamet få ansvar for den tjenesten selv, men da må de også ta ansvaret. Da er de ansvarlige for tjenesten på egen hånd. Hvis de velger å bruke plattformen, som jeg håper og regner med at de fleste gjør ... Det høres jo veldig fornuftig ut, det. Hvor langt ned i plattformen må de kunne? Hva er nivåer av abstraksjoner her som de må benytte seg av?

11:54 --> 12:51

For å igjen få denne applikasjonen hele veien ut i produksjon? De trenger ikke ha så veldig mye kunnskap om kubernetes, det har vi abstrahert vekk. Fordi vi så tidlig at hvis de knyttet seg for tett til kubernetes-versjonene, så fikk vi redusert farta på utviklingsteamene. For det kom nye versjoner av kubernetes, nye manifester. Nye manifester de måtte forholde seg til, så vi abstraherte vekk "wall of hammer"-en, ned i et sett med kontrakter. Så de har en byggekontrakt, en deployment-kontrakt og en kjøretidskontrakt. Er det tre filer som de har i gitt? Tre filer de har i gitt. Som automatiseringen vår plukker opp og genererer opp alt som skal til av bakenforliggende manifester. Så det er litt byggekontrakt òg, så de trenger kanskje ikke å by?

12:51 --> 13:45

De trenger kanskje ikke å lage en dokkafil for å bygge et image? Nei, de spesifiserer hva slags type dokker-image de vil ha. Java og en Java-versjon, eller Javascript eller Python. Da er det jo veldig mye vedlikehold som ikke teamene trenger å ta ansvar for. For det vet jeg jo fra andre plattformer at det å holde dokkafilene oppdatert kan være en god jobb. Vi så tidlig at vi måtte gjøre noe med de dokkefilene. Og generere de på siden. Og ikke minst: Hva hvis det er en sårbarhet i et dokker-image? Hvordan skal du få generert opp tusenvis av nye dokker-image fort som fy hvis du ikke har kontroll på hvordan de imagene er bygd?

13:45 --> 14:38

Men hvis teamet har lyst til å bruke siste versjon av Java eller Cott-Linda, må de vente på det? I utgangspunktet så må de vente på at det blir støtte til. Ja, det er jo en avveining det der med at hvor fort kan man gå, og hvor mye skal man få lov til å skyte seg selv i foten? Men disse tre filene det er snakk om, er det noe annet grensenytt mellom teamene og plattformen, eller er det hovedgrensenyttet? Har dere noen applikasjoner som også gir ...? Vi har både web-applikasjoner, dashbord osv. Hvor du kan gå inn og sjekke tilstand. Og så har de jo også mulighet til kubernet-SAPI-et. De kan gå rett på.

14:38 --> 15:27

De har kode på et eller annet nivå? Ja. Men det er ikke så veldig mange som logger seg inn der. Nei, jeg har skjønt at det er flere uttrykk enn jeg trodde. Som ikke nødvendigvis er så interessert i hvordan infrastrukturen funker. Det overrasker meg, men det er nok sant. Jeg tror det. Skatteetaten har 1100 ansatte i IT-divisjonen, hvor majoriteten av de er utviklere. Og det er de færreste av de utviklerne som ønsker å forholde seg til infrastruktur. Vi har sett at man må forholde seg til infrastruktur, men kanskje på et lavere nivå enn sånt spesialistnivå.

15:27 --> 16:24

De må jo forholde seg til disse tre manifestfilene. Hvor finner de informasjon om det? Hvordan blir de kjent med plattformen hvis det kommer inn en ny utvikler? Vi har jobbet ganske mye med å ha brukerforum. Vi har ... altså ... Wikisider, vi har andre nettsider, vi har enabling-team. Alle team har en kontaktperson de kan forholde seg til og stille spørsmål. Så det er ganske lett å få tak i informasjon om hvordan vi skal bruke plattformen. Og eventuelt om det er nye ønsker på plattform, så har vi en veldig ren single point of contact-funksjon, da. Er det utviklerne som har de rollene, altså plattformutviklerne? Eller er det dedikerte team som er kontakt mot brukerteamene?

16:24 --> 17:15

Fra den spede start så var det utviklerne som hadde den rollen. Plattformutviklere vi alle rullerte på, og på en måte være på vakt. Så jeg hadde vakt hver torsdag. Og så har jeg hørt rykter om at man har et internt chattesystem i Skatt, men ikke Slack? Ja, vi har Mathemost. Onprem. Masse historikk rundt den. Skyløsninger var litt farlige en gang i tiden, så da etablerte vi en Onprem Slack. Altså Mathemost. Det å ha den type verktøy, og jeg antar jo da at det er mest mulig sånne åpne kanaler og communities rundt ulike deler av IT-utvikling og plattformer ... Utvikling og plattformer.

17:15 --> 18:12

Vi har på det største rommet vi har på chat, så er det vel nesten 700 brukere. Som er da utviklingsteam. Hvor de har direkte kontakt med stort sett alt av plattformutviklere. Og takhøyden er stor. Hvordan ligger dere an til veien til Sky? For dere begynte Onprem, men jeg vet dere har noe. Dere er på vei ut i sky, dere òg? Vi er absolutt på vei ut i sky. Vi har valgt vår første sky og landa på Asher. Der har vi satt opp en Vanilla Cubernettis-rigg. Dere lager en ny plattform for Sky? Ja, spennende. Vi bygde en ny, helt ny plattform basert på AKS. Det åpenbare spørsmålet er selvfølgelig hvilke deler fra den gamle plattformen.

18:12 --> 19:05

Enten konkret eller mer overordna, hva skal dere ta med dere? Og hva tenker dere dere skal gjøre annerledes? Vi har jo gjort oss opp en del erfaring etter å ha bygd plattform i åtte år OmPrem. Så alt det lure vi har gjort, det tar vi med oss. Og alt det dumme tror jeg vi skal la ligge igjen OmPrem. Hvordan ser dere for dere at utvikleropplevelsen blir seende ut i sky? Den blir nok ganske lik som det den er om Prem. Utviklingsteamene har i utgangspunktet lyst til å komme til en ferdig selvbetjent plattform. Og de vil ikke forholde seg til infrastrukturen nevneverdig. Så de ønsker at det skal være lett for dem å gjøre rett, og at de har mest mulig automatisering

19:05 --> 20:01

rundt seg, sånn at de kjappest mulig kan komme ut i produksjon. Får de da kanskje også tilgang på andre managed tjenester? Kan de benytte seg av managedatabaser og fillagring og sånne tjenester, som man gjerne får på rekke og rad i skyplattformer? Vi har tenkt å forholde oss til de store industristandardene, og at vi ikke skal ha ... Vi skal ikke ha for tette leverandørbindinger. Så det er en avveining mellom hvilke managed tjenester de kan bruke eller ei. Men tilbake til hva er det plattformen leverer? Vi leverer databaser, vi leverer lagring og den type standardløsninger, basert på skyens managed løsninger.

20:01 --> 20:40

Og hvis du har behov for en spesialtjeneste fra en skyleverandør, så er jo det mulig. Men da må teamet ta ansvar selv. Så vi bygger inn veldig mye på den paved roaden av standardløsninger som vi ser fornuftig at vi har, fordi det brukes så bredt av applikasjonsporteføljen vår. Så Golden path fortsetter liksom kanskje ikke helt samme passen, men prinsippet er der fortsatt? Prinsippet er der. Pathen vil endres noe. Vi må ta i bruk mer skytjenester og færre egenutviklede tjenester. Hvis vi kan kjøpe en tjeneste, så er jo det å operere og kjøpe tjenesten.

20:40 --> 21:30

Jeg er enig i at det sikkert ikke er alle som er interessert i hvordan de ser inn i plattformen, men de som hører på podkasten er helt sikkert interessert i hvordan de ser inn i plattformen. Det er derfor det er her. Kommer dere til å beholde operator-greiene på i sky? Vi kommer nok til å bytte ut veldig mange av de operatorne vi har, med mer standard operator. Har æsjer egen operator, eller bruker dere crossplane, eller hvordan tenker dere å gjøre det? Veldig godt spørsmål. Vi har ikke gravd så veldig mye ned i detaljene rundt det. Enn så lenge så lager vi våre egne operatorer, basert på operator pattern og standard CRD-er, kontra det gamle regimet vårt, og vi fant på alt dette selv, for det var ikke tilgjengelig.

21:31 --> 22:03

Det går i hvert fall én generasjon fram, og så får vi se om vi skal gå ett hakk videre eller ei. Men æsjer mangler veldig mange operator. Men det dere lager, hvilket språk bruker dere? Oprateren er Coda i Go. Var det ikke Java i gamle dager? Jo, men det har vi forkasta. For dere hadde en sånn fragleperiode? Ja, det hadde vi. Men fraglene er også koda i go. Det er også koda i go. De har blitt skrevet om.

22:03 --> 22:45

Ja, sånn var det. Det er jo helt tydelig at dere to har lang historie. Men apropos den historien, har jeg CubeCon 2017. Hva skjedde da? Det var jo en veldig liten CubeCon-event. Det var vel kanskje 1000 deltakere. Ja. Audun var der, og jeg var der, sammen med Husbanken og Vegvesenet. Og så drakk vi øl. Første gangen vi møttes i køa, inn til i dag ... Jeg husker ikke om det var jeg som hørte noen snakke norsk. Men vi begynte å snakke sammen i hvert fall. Da skulle jeg begynne i Nav måneden etter eller noe sånt.

22:45 --> 23:31

Og det vennskapet der, det ble jo noe mye større enn bare dere to? Absolutt. Kjempestort. Det vi gjorde, var at vi lagde ... Vi fant vel ut at ... Fra mitt ståsted lærte jeg at det var mange andre i offentlig sektor som lagde det jeg hadde lyst på å lage i Nav. F.eks. CubeCon og Husbanken. Da lagde vi en slack som het Offentlig pas, og så lagde vi Fagdager. Vi var den første hos Skatteetaten. Ikke lenge etter den CubeCon. Jeg tror det var rett over sommerferien. Og det har jo vart siden. Det har det. Du så jo ikke helt omfanget av den lille praten vi hadde i køen,

23:31 --> 24:29

og hvor vi havna nå, men ja. Det var et skrikende behov for å utveksle erfaringer, tror jeg, på plattformsiden innenfor offentlig forvaltning. Det tror jeg jo det er definitivt fortsatt, og det er jo derfor vi har denne podkasten her. Vi begynner å nærme oss landing her, men du Are, jeg skal sette deg litt on the spot. Feil er jo sånn som alle gjør feil. Alt kan skje. Vil du fortelle en gang om når noe gikk galt i Skatteetaten, og litt hva de lærte av det? Det kan jeg gjøre. I utgangspunktet så har jo Skatteetaten veldig stort fokus på å lære. Vi skal bli bedre, og vi skal lære våre feil. Så vi har innført en post mortem-kultur basert på Google SRE, hvor vi oppretter et et mortem-dokument for stort sett alle hendelser vi har på plattformen.

24:29 --> 25:14

Og det er jo kun for å lære, ikke for å peke eller dele skyld eller noe sånt noe. Men det er for å lære å bli bedre. Og dere husker vel at skattemelding var litt utilgjengelig sånn på vårparten i år? Det var en plattform-issue. I utgangspunktet så ... Prøver vi jo å spare penger. Så vi skalerer ned infrastrukturen vår. Og så skalerer vi opp ved last. Skaler dere ned på hver skattemeldingsinnlevering? Nei, vi skalerer ned ... Skatteetaten har et årshjul med veldig variabel last på systemene. Så i mars/april så har vi plutselig en halv million samtidig på dag å bruke.

25:14 --> 25:50

Og i mai/juni/juli osv. så har vi nesten ingen. Det er jo litt gøy, da. Ja, men det er en tunami som kommer. Og når den tsunamien kommer, så må vi skalere opp. Det gikk ikke fort nok denne gangen her. Vi klarte ikke å horisontalt skalere plattformen i takt med antall brukere som kom på. Og så så vi at en del av applikasjonene heller ikke hadde klart å deklarere hvor mye ressurser de egentlig trengte. Så de satt at: Jeg er en kjempeliten applikasjon...

25:50 --> 26:31

Jeg trenger nesten ingen ressurser. Men akkurat nå skal jeg bruke veldig mye. Og da får Kubernetes et problem. For hvordan skal Kubernetes klare å pakke applikasjonene sine på nodene, når applikasjonene ikke overholder kontrakten sin? Men de var innenfor, selvfølgelig, på Request og Limit, så det var ikke noe problem der. Det var bare et veldig stort gap mellom hva som var Request, og hva som var Limit. Og de kjørte stort sett på Limit hele gjengen. Og da går vi tom for CPU. Selv Skatteetaten.

26:31 --> 27:07

Men vi var jo ikke tomme for CPU i clusteret. Det var bare at noen noder gikk tom for CPU, og tilfeldigvis så lå de podene på samme node. Så da ble det inn med litt anti-affinity-regler, og så dytte poder fra hverandre, sånn at de lå på forskjellige noder. Da man føler at man lever. Ja. Og så lærte vi. Eller så syns jeg det gir mening det der med å at du får melding ... Nå er det din tur. Nå kan du ... At ikke fem millioner brukere skal inn akkurat samtidig. Da ber du om problemer. Da ber du virkelig om problemer.

27:07 --> 27:41

For den tsunamien som kommer, den er stor nok. Selv om vi sender ut SMS i ro og mak. Ja, for det er sånn det fungerer. Det sprer SMS-en utover. Nå har hele skattemeldinga blitt så bra at jeg gidder nesten ikke å sjekke. Så jeg hjelper til med å holde lasten deres nede. Det er mange som faktisk logger seg inn den dag i dag. En oppfordring til alle damer: Ikke sjekk selvangivelsen! Ikke tre timer før innleveringsfristen går ut.

27:41 --> 28:31

Tenk bare "ikke sjekk med en gang"! Du Are, det har vært en fryd å ha deg her i studio og snakke med deg. Har du noe helt siste på tampen? Ja, hva er det vi skal jobbe videre med nå, da? Det er jo å utvide, bygge en større hybridplattform. Vi kommer til å beholde datahallene våre i lang tid. Og vi skal bruke sky, og vi skal kanskje bruke flere forskjellige skyleverandører. Men vi må ha en plattform som fra et utviklingsperspektiv kan oppleves som en mer eller mindre homogen plattform. Sånn at det viktigste er jo at vi klarer å levere på kost, på tid, til samfunnet.

28:31 --> 29:14

Og møte de forventningene som samfunnet har til etaten. Kjempebra. Igjen tusen takk for at du tok deg tid til å være her sammen med oss i dag, Are. Og da er jeg litt interessert i hva ... Hva tenker du Øydun, hva sitter du igjen med? Jeg syns det var veldig morsomt å høre om den varierende lasten, bl.a. og hvordan man må løse det i plattform. Da jeg jobba i Finn, var en av de morsomste tingene når det var mye trafikk. Og det å løse problemer som kommer av plutselig mye trafikk, det syns jeg er gøy å høre om. Og hva med deg, Hans Kristian? Hva har du lært? Jeg har jo lang erfaring fra å bygge plattformer i bank- og finanssektor.

29:14 --> 29:56

Jeg vet jo hvor mye krav og regelverk man kommer borti når det gjelder alt som har med tall og penger. Så jeg syns det er utrolig befriende og fascinerende å høre hvor langt skatteetaten har kommet. Og ikke minst hvor de fortsetter. Det er ikke ferdig her. Og det merker jeg jo selv. Litt som du nevnte, Audun, skal inn og sjekke skattemeldingen. Det er jo riktig. Alt er liksom allerede. Du kommer til duk og dekket bord, og det er så herlig. Det er akkurat sånn vi ønsker det. Så det var veldig, veldig gøy, ikke minst å høre at her er det på god vei videre.

29:56 --> 30:21

Om i det så runder vi av denne episoden av Plattformpodden med Hans Kristian og Audun. Teknisk produsent har vært Tore Græsdal. Takk for oss. Ha det bra! Takk for følget!