Velkommen til denne episoden av Plattformpodden, en podkast om applikasjonsplattformer og teamene som bygger dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg som vanlig Audun Fauchald Strand. I sesong to kikker vi utenfor offentlig sektor, og i dag har vi med oss Thomas Jansson og Jens Beck Sørensen fra Elkjøp. Men før vi sparker i gang, Audun, hva er det du liker best med å bygge plattformer? Det jeg alltid har likt best med å bygge plattformer, er at brukerne mine er utviklere. Det syns jeg er mye lettere å forstå og utvikle enn vanlige folk. De gangene jeg har måttet lage noe for andre mennesker, har det vært frustrerende. Men når jeg kan lage noe for utviklere, så syns jeg det er veldig bra. Hva med deg?
Jeg har alltid likt å se at andre får det bedre på jobb. Det å lage en god plattform har enormt mye å si for hverdagen. Når de er happy, så ender vi opp med bedre produkter, og så blir sluttbrukeren også mye mer happy. Men Thomas, kan ikke vi begynne med deg? Hvordan begynte du å lage plattformer i Elkjøp? I Elkjøp jobber jeg med mer enn bare plattform. Alt fra en plattform til frontend-utvikling. Plattformen vi har i dag, var den jeg starta med for to år siden. Som jeg regner med å komme inn på mer i løpet av podkasten. Jens, hva med deg? Jeg er ganske nyutvikler.
Jeg har kun jobbet på plattform. Jeg jobbet med Elkjøp i 15 måneder, og før det som psykolog, så det er ganske nytt for meg fortsatt. Men det er kanskje grunnen til at jeg liker meg veldig godt. Det er fordi jeg får bygge systemer, og har alltid kost meg i Linux. Og jeg føler at dataflyt opp mot Kubenetis er kjempeartig, da. Det er jo litt interessant, for jeg har jobbet med mange som har alternative bakgrunner, f.eks. kunst eller musikk. Det må være veldig nyttig. Teknologipsykolog ... "Denne moderniseringsprosessen går bra." "Vi skal lande med begge beina."
Er det noe du føler du får nytte av i hverdagen? Både ja og nei. På den ene siden er jeg glad for at jeg ikke får nytte av det. Fordi det var et virkelig godt lyst til å skifte fra. Data er litt enklere, for da får jeg tydeligere svar og kan mer konkret se hvordan en skal angripe. Og kanskje i formidling. Jeg har jobbet mye med formidling av kunnskap og informasjon. Så når jeg først skal presentere eller forklare eller være litt pedagogisk anlagt, så ligger det ganske nært for meg i den bakgrunnen jeg kommer fra. Men selve psykologifagkunnskapen har jeg liksom lagt meg litt på hob... Nå kaller jeg meg en hobbypsykolog, for det er det strengt tatt. Jeg tror det er en dimensjon som Jens kom inn med i teamet,
men det er jo formidlingen som er veldig viktig. For det hjelper ikke med en kjempebra plattform hvor man vet hvor man skal bruke den. Og der har Jens gjort en veldig bra innsats for å kommunisere ut hvordan ting skal fungere. Det er jo noen som sier "you build it, end it, come", og det er jo ikke tilfellet. Kanskje vi ender opp her med å utvide alle plattformer man designer? Nå må alle plattformene ditte også være en psykolog? Ekte tverrfaglighet er det når du også har psykolog. Og kanskje en fastlege! Det er helt sant. Alle behov er der uansett. Da er det psykologisk trygghet.
Men Thomas, siden du har vært lengst, hvordan bestemte dere dere for å lage plattform? Da vi bestemte oss for det, var jeg litt irritert på den eksisterende peipen. På den eksisterende pipelinen vi hadde for å få ut applikasjoner, som var en Asher Devils pipeline med masse adhoc-skritt. Så det var jo på en måte infrastruktur som koden, men det var ingenting som var deklarativt. Det var eksakt hvordan ting skal produksjoneres opp. Rett før jeg begynte i Elkjøp, hadde jeg begynt å se på Pelumi, , Pelumi, som er en motfestent terraform,
selv om man skriver som kode istedenfor mer jammelaktig. Det er sånt man gjør når man er i pappaperm, så man får masse tid til å se på ting. Jeg begynte med å sette opp en applikasjon for å se hvordan det kan være. Så kom Pelumi med noe som heter Pelumotimation SDK, som er hvordan du kan programmatisk kjøre Pelumi inn i en applikasjon. Det er et veldig bra fundament for å bygge en plattform. Det var der vi startet med, og da begynte jeg og en til å bygge det som nå er vår. Det er mer å gjøre plattformen tilgjengelig. Plattformen driftes av et SRE-team som dere begynner nå, men vi gjør den tilgjengelig da. De komponentene vi fokuserte først på, var egentlig å gjøre et nei-innspill.
Gjøre et nain-space tilgjengelig i Kuminetes for forbrukere, men også en Asher resource group som mapper mot hverandre. Som jeg presenterte på konferanse, så snakker jeg veldig om at ... Gi utviklingen så mye frihet de kan ha, men samtidig skal de kunne skyte seg selv i foten. Eller skyte noen andre i foten, hvis det er det verste. Da behøver vi i hvert fall å være i leiren. Så vi gir den utviklingen kredensialer til å kunne være som admin i sin nangenspace og i sin Asher resource group, men da må det være tilgjengelig til annen nangenspace. Du nevnte mye Pulumi, og så nevnte du også kanskje noen som kjente Terraform. Men Terraform tror jeg er kjent for mange av lytterne våre. Vil du si litt om forskjellen mellom Pulumi og Terraform?
For de er likt, men ikke det samme. Fundamentalt så er de veldig like. Hovedtanken er veldig lik. Men der Terraform kom noe mer fra at man skulle skrive det helt deklativt, statisk, nesten i en slags Martiap-fil, nå har de fått litt mer støtte for språk også, så har jo Pelumi som "code first", de begynte på en gang med .net og typescript og Python og Go, som man kan skrive. De bygger kodekomponentene av Go, og så genereres det bare SDK-er på alle språk. Det er programmeringsspråk. Jeg vil si at mer infrastructure er software snarere enn kode.
Er state management likt Terraform? Ja, du skriver koder som definerer din state, og så lager staten hvor det er, på ASHR-storage eller local filer. Det konseptet er ganske likt Terraform, at man har en state, og man jobber med den, men programmerer staten snarere. Det gjør det enklere at om det er noe som ikke er support i Pelumi, så kan du alltid gå in process og gjøre et API-kall for å patche en ressurs. Noe som man kanskje må gjøre etterpå om man gjør det med Terraform. Hvordan er dere organisert? Dere har denne plattformen som er mest Pelumi, og hvor mange er det som jobber med den, og hvordan ...?
Vi er to og en halv per i dag som jobber på den og utvikler den videre. Og så har vi litt support av Thomas som er innom av og til, og noen andre som har en finger med i spillet siden vi toucher på såpass mye viktig infrastruktur. Men PTS, så er det meg også en konsulent, og så en annen konsulent på 50 %. Så vi er relativt få. Det er jo mulig fordi vi har et team som jobber med selve driften av klusteret. Men vi har et team som jobber for å gjøre plattformen tilgjengelig for de andre teamene. Så dere koder plattformen mens den driftes i Tsjekkia? Da nevnte du Namespaces og ressursgrupper. Hvilke andre ting får jeg som utvikler? Veldig mye rundt Ashore. AD Apps. Hele ressursstyringen er en rolle.
Oppsatt av grupper og roller og app-til-app-kommunikasjon. Mye IM-verktøyer. Og så har vi et oppsett opp mot Akamai Gateways, sånn at du får kjørt applikasjonen gjennom der. Det er en CDM, sant? Kjempebillig, har jeg hørt! Det er ikke vi som betaler. Det vi gjør, er å opprette AD-grupper. Så vi kan også gjøre self-service for å definere hvilke medieteam. Og så oppretter vi det vi kaller Én miljø. Én miljø består alltid av dev.test og prod. Og alle dev.test og prod har en Namespace og en resource group. Og så oppretter vi credentials til disse miljøene.
Og så binder vi alt sammen med et Gitabre post-story, som du også oppretter. Og da kan vi injekte de teamene som skal ha tilgang til det. Det har vi også i Gitab og ADSynk. Og så setter vi inn de credentials vi bruker for å opprette Namespace. De blir med inn som secrets i Gitab. Så alt er i etterpost-ord, eller er det mange etterposter per team? Du oppretter det post-retoret også i det verktøyet som vi kaller Flash. Og da kan du opprette hvert team med eget repost-ord. Flash er bare etterpost-ord. Men da injekter vi inn credentials for å snakke med det miljøet som du har fått. Og du får noen team du har definert, satt også inn i det teamet som eier det.
Men når du lager en app, og så får jeg tre post-order, kommer det Plumikode inn i det repost-ordet? Nei, det er derfor vi injekter Gitab secrets. For da kan teamet velge fritt, og når de vil anvende, Plumikode. Nå bruker de ofte Pulumi for å spinne opp applikasjonen, men i og med at det ligger som Gitab secrets, så kan man bruke andre ting om man skal gjøre det. Sånn at du kanskje bare skal gjøre en cloud function, som en enkel sak, så kanskje du trenger hele Pulumi-verdenen til å gjøre det. Men da har du fortsatt tilgang til credentials uten å behøve Pulumi.
Men de fleste team anvender Pulumi også i dag. Er det noen Pulumi-kode eller noen spesielle apper som skal kjøre i Namespecial, som de kan gjenbruke, eller er det eksempler, eller hva er det man definerer for applikasjonen? Vi har gjort det ganske enkelt. Vi har hatt noen Gitab-templates. Vi har fem stykker nå. Så kommer ferdige oppsett på ... Anbefaler Pulumi. Det fine med templates er at vi deler koden. Så kan de tilpasse seg som de vil. Jeg vil ha den friheten innenfor et namespace og en organisasjonsgruppe.
De kommer ikke utenfor uansett. Det som er så fint med det, er at jeg snakket litt i sted om det å formidle hva alt dette skal gjøre. At de utviklerne som skal anvende det, de trenger ikke å forstå alle de leddene som beveger seg baki. De kommer inn til oss og bestiller det de skal ha, og så har de ferdig oppsatt sånn som jeg ellers oppliker det. Det er veldig fint. Hvor mange team er det som er på plattformen i dag? Vi har en snodig teamstruktur.
Det er feil å si hvor mange team vi har. Det er ganske mange postord som opptrer. Flash i dag er sikkert 100, kanskje. Men teamorganiseringen er noe vi bør jobbe med. Så da har vi det som kalles et core plattform-team, som jobber med Det kjennes til laget, som ideelt sett kanskje burde vært flere som streamer Line-team istedenfor, men det tror jeg er en helt annen podkast. Hvilken programmering? Hvordan ser en vanlig app ut? Vi har flere på kvelden. Stort sett, så nå har vi Frontend i Next. Eller Rect og Next er vanligst. Det var fem templater. Er det forskjellige programmeringsspråk,
eller er det en templat for å deploye til cloud function versus kubanetisk? De fleste templatene gjør jo mye av det samme, men definert i forskjellige språk. Don't net-template er next Yodas-template, så er det React-template og ... Noe som var en babaska et eller annet. Som en Closure-aktig template. Jeg svelter kitt. Men rundt sånn CICD, for å få bygget og få tingene ut, tilbyr plattformen noe der, eller må teamene sette det opp selv? Det må teamene sette opp selv, men i templaten er det også forberedt for det. Så la oss få ferdig i den templaten. Happy Path, om du vil gjøre Next IS-app,
så er det fem minutter, og du har en pipeline oppe. Er det fortsatt Asher DevObs, eller er det GitObations? Ja, det har migrert over nesten alt nå. Nesten alle i hele verden tror jeg bruker GitObations. Det er ganske universilt. Men når appen er ute, da, hvem er det som får ansvar for å forvalte den videre driften? Er det teamene selv, eller er det et annet team? Ja, TeametCen. Men vi har fortsatt det serieteamet vi bruker nå. Får de noe verktøy for overvåking, monitorering eller bath-practice rundt det, eller? Ja ... Vi har splump for logging, det vil vi ha i dag. Men vi ser på ... Vi har beredt oss mer på å skaffe noe for open telemetry for å få ordentlig tracing på saker også.
For det trenger vi, tror jeg. Det er mange som ser på open telemetry, og det ble jo nylig i General Level BTS at backen er komplett, og SDK-ene begynner å bli ganske velutvikla. Vi trenger noe rammeverk for å telle hvor mange som ser på open telemetry. Vi skal ikke se bort fra at det finnes. Men vi har vel en øyensplung for logging, mens vi har vel også noe grafarmark. Men vi ser på det litt igjen, på hva vi skal bruke i fremtiden. For vi som bygger den plattformen, så hvis alt går bra, så hører vi ikke noe mer fra de som benytter den. Den skal så fremt alt går bra, være ganske "fired and forgotten".
Dere har namespeed skipenetis, du snakka litt om Asher functions. Tenker dere at man kan bruke alt Asher å tilby? Har dere brukt andre skyer, eller prøver dere å begrense til noen kjernetekninger? Det er egentlig ikke noen begrensninger på hva man kan bruke. De fleste har historisk sett brukt Kosmos DB osv. Men det finnes mange tanker rundt hva man kanskje burde gjøre med det. Man har kanskje fastnådd litt i at med microservices-tankegang at alle tjenester skal ha en egen database, så tror man at en database betyr sin egen server. Det er ikke så veldig kostnadseffektivt. Om vi begynner å bruke mer postgres, som vi kanskje skal gjøre,
så bør vi kanskje se på et mer felles databaseutsett. Så tilbyr man kanskje et skjema innenfor en database. Kan man sette opp Kosmos DB med det også, eller? Ja, det er akkurat en terraform. Men dere tilbyr fungalitet for det også? Nei, ikke i lag. I dag så vi den flashdelen som var. Man må bare oppbevare ressursgruppen. Så må teamet selv bestemme hva de vil fylle ressursgruppen med. Og Cubinete kommer jo med ... Der har jo SRE-teamet satt inn link-ID i clusteret. Men ellers så får teamet selv bestemme hva som skal inn i Nangspace også.
Nå hopper jeg litt tilbake, men jeg kom på noe jeg lurte på. Hvordan tester dere Pulumi-kodene og sånn? Hva? Takk. Det er et planeringsspørsmål. Jeg så for meg kanskje at en av grunnene til det ... Det er jo et av pitchene til det, men jeg sliter med å se hvordan man skal gjøre det effektivt. For i slutten av den så må du nesten kjøre ... Si at du faktisk har ... Spinner opp. Og det er vanskelig å skrive enhetstest på å teste at den faktisk spinner opp. Du kan teste om du vil, så kan vi selvfølgelig teste rundt HUB-mapper, fronten-koden, ned til selve spesifikasjonen som skal brukes til å spinne opp ressursene. Men det har vi ikke gjort. Mest manueltesting.
Ja. Og litt junitaster på akkurat de programmene som vi skal kjøre. Jeg jobber i Finn. I Nav hadde vi satt opp et eget cluster, og så deploya vi to apper der vi skulle snakke med hverandre, og som hadde et endepunkt, som var testen. Ja, absolutt. Det går an å få det til. Og jeg tror vi kan vokse lettere med Pulumi, som er kode, men bare for lettere betyr ikke det at det er enkelt. Er det verdt det, eller? Kan vi leve med hommel-vel-testing på det? Men jeg ser for meg noen moduler i Pulumi som kanskje kan enhets-testing. En del av koden kan testes. Vi kan bli bedre på det, det kan vi.
Men siden Pulumi bruker programmetspråk i bunnen, hvilket språk bruker dere på plattformen, da? Det er en nextyordas front- og backend som bruker Pulumi, og alt er i typescript. Så det er hele hurven i typescript. Plattform i typescript. Dere skal ha applikasjonen i C? Ja, når vi har en del i tapescript, så. Så er det blandet. Men ... yes. Men jeg ser for meg at når det er salg og greier, så dere har kanskje en ganske variabel trafikk? Hvordan håndterer dere det?
Plattformen, igjen, så er vi to jobber med tilhandlerplattformen. Og vi har nok overdimensjonert ganske mye. Trafikken vi har i ren last ... Vi hadde peak i forrige uke. Vi var oppe hele tiden, så det var veldig bra. Jeg fikk en mail om at Black Friday var ferdig nå i dag. Nå er snart Black Friday ferdig. Det sitter jo sånn i uker, repetitivt. Men jeg tror vi overdimensjonerer litt. Og så er det mye krasjing. Har dere mye dynamisk på trafikken, eller? Jeg tror ikke klustrene er dynamiske i dag.
Men innenfor klustrene har vi koder for en del scaling. Men klustrene må manuelt eskaleres i dag, så de er litt overdimensjonerte. Men igjen så tror jeg at Norge er begrenset til hvor stort Norge er. Og trafikken vi har ... Det er ikke så ekstremt mye, det er mye kan det være. Men vi liker jo å tro at vi er ganske mye. Ja, men du kan kjøre ganske mye på RespyPie, liksom. Jeg husker jeg var på en CubeCon en gang, der Alibaba snakka om "Singles Day". Det var en halv million requests i sekunddelen på det verste, så det tror jeg var hakket i veien. Det tror jeg ikke vi får til i Norge, uansett hvor hardt vi prøver. Nå har vi snakket mye om hvordan plattformen er i dag. Hvor går veien videre for Hellkjøp?
Det var et bra spørsmål. Jeg har en tankevisjon som jeg hadde sett at vi gjorde fra starten. I dag kjører vi Pilumi som en del av next airy-apparatet. Men det gjør det også veldig vanskelig ... Når man skal prøve å lage noe i Akamai, så kan det ta sju minutter. Da passer det veldig dårlig om vi samtidig skulle gjøre en ny versjon av Flash. Vi dreper en prosess som allerede er i gang. Det burde vært å spinne opp alle de jobbene som skal gjøre noe som en kubinetisk jobb, som da kan bare kjøres, så er den ferdig, og så er den egentlig glemt etterpå. Det burde vi gjort fra starten.
Det samme som vi har gjort, er det med state management. Derfor liker vi oss 100 % bare på Pelumi State. Vi har lagret litt i databasen også. Så vi kan gi raskere svar og berike dataen litt. Det burde vært gjort fra starten, som vi gjorde litt senere. Så det var framtiden som jeg vet. Jeg er halvt om halvt inne i teamet, så kanskje gjensa noe mer. Jeg kom til å tenke på eldre ressurser som f.eks. har ligget i 12-15 måneder. Som vi har en state på hos oss, og så kjører vi en refresh på. Så ser vi at her kan det skje store endringer som vi ikke så komme. Det er også en problemstilling som, i hvert fall hvis jeg skulle ønsket meg noe,
at vi tidligere nesten hadde en oftere kjøring av programmene våre, sånn at vi så at vi ikke kommer helt ut av state. Og vi står i noen miljøer i dag som vi holder state på, som vi er redd for: Hva vil skje hvis vi kjører dette programmet? Vil vi ta ned et kjørende miljø? Belumin-koden kjører ikke en refresh på staten hele tiden. On demand. Så hvis den kan ligge og kose seg i over et år, og så har noen vært inne og trykket på masse manuelt, og så har du det gående, så kjører du ... Du kan ta den ned hvis du er uheldig. En forbedring som vi kan gjøre, er at om vi oppretter noe fra Fresh,
så burde man låse det for at andre skal kunne gjøre noe med det. Men det har vi ikke turt i dag, for det har vært en reise i to år. Mange har trengt tilgang til å gå inn iblant og gjøre noe på kortere sikt. Så vi har ikke kunnet låse ned så mye som vi kanskje ønsker. Man må begynne et sted. Dette har vi nå, og få det opp. Man kan ikke vente til alt er ferdig. Du har snakket litt med Akamai. Styrer dere det fra plattformen? Og hvordan og hva bruker dere Akamai til? Vi har satt opp avfall, så vi kan bestemme hvorfor jeg aker meg i DNS eller noe mer. Akamai er siste skansen av det jeg fortsatt ikke helt har koll på.
Du kan få din egen operasjon i Akamai, og da kan du få en fin URL istedenfor random ting. Så dere setter bilder og satter kassetter der òg? Det gjør vi også, men da er vi inne på e-commerce-siden. Det vi håndterer mest, er alle backoffice-separasjonene vi har. E-com-siden er nesten en hel episode i seg selv. Hvis jeg går inn på elkjøp.no, er det én stor monolitt? Eller er det flere applikasjoner? Hvordan er arkitekturen? Det er sånn helt overordnet. Nesten delt monolitt, kanskje. I dagens løsning er det en engelapersjon som er der. Kjørende på jeg vet ikke hvor mange podder som kjører service-rendering først osv.
Så har vi noen koremedia for CMS, og SRP Commerce har vi for Commerce-delene. Nå er jeg heldig som er med i et initiativ til å skrive om hele ekom-siden også. Men det får bli en senere sesong. Så du kjører på egen plattform? Ja, den kjører vi på egen plattform i dag. Men er det sånn fortsatt? Podden har kjørt i et luster som interminerer fra Flash. Så det er et eget kumulativt luster med veldig mye ressurser i. Det er kjempespennende høring, dette her. Og vi går inn for landing her. Det vi pleier å spørre om, er dette med at når ting går galt ...
Det skjer jo i den verden vi jobber i, så går ting ikke alltid etter planene. Men vi lærer utrolig mye av det. Det jeg har lyst til å høre, er en gang noe ikke helt gikk etter planen, og det var problemer. Det er veldig få sånne kyss med plattformen, faktisk. Det er ingenting som har gått virkelig galt. Å ta ned Prod et par ganger har vært galt nok for meg, men ikke noe som har påvirket organisasjonen. Annet enn å hindre arbeidet til noen andre i noen timer. Ja, det har vært veldig smidig. Jeg kan ...
Kan jo snakke om noen tidligere galt erfaringer. Relativt til CTVH, har det gått veldig smidig på Gjeldskjøp for det. Men det har jo tatt med Prod over seg andre plasser. Det har vi alle. Vi har tatt med Prod-miljøet i hele miljøet til GCP en gang. Jeg forundres over at du har vært smidig på just flashen sånn. Ja. Inntil videre har det gått veldig bra. Bare gi meg litt tid, si! Jeg merker jeg begynner å bli mer og mer modig, så det skal passe litt for meg. Hvordan er det du begynte i jobb i retten av plattform? Hvordan var det?
Min historie har alltid vært at jeg jobba ti år som back-end-utvikler, og hadde nok irritasjon og bitterhet som jeg kunne bruke til plattformutvikling etterpå. Men det å komme rett inn i plattformverdenen, hvordan er det? Litt flaks og litt sikting. Jeg gikk et hurtigkurs på noe som heter Academic Work i fjor. Og så ble jeg plukka opp av Elkjøpet underveis, og ble egentlig spurt hva jeg syntes var interessant. Og så sa jeg det jeg syntes var interessant, som jeg syntes oppsett og sånn er litt gøy. Og så fikk jeg plass på det teamet som jeg ikke ante noen ting om, og så måtte jeg lære meg typescript, og så måtte jeg lære meg hva Asher var, og egentlig lære meg alt fra bånn av,
sammen med Thomas og andre veldig flinke utviklere og seniorer som har hjulpet meg. Så det har vært en litt sånn hode først, stupe inn, og lære seg å svømme etter hvert. Så det ... Jeg hadde ikke trodd at det skulle være så gøy, men jeg elsker det. Veldig spennende å høre når ting ikke går helt etter planen, og det tror jeg alle kan relatere til. Jeg har også tatt ned POD og skapt problemer for mine kollegaer, og det er aldri kjekt, men vi vokser på det og lærer, og det tenker jeg er veldig nyttig å dele til alle der ute. Vil jeg bare avslutte med å si tusen takk til dere, Thomas og Jens, og så ... Stille spørsmål til deg, Jodin. Hva har du lært i dag? Det jeg tenker jeg har lært i dag, er at selv når du setter opp
automatisert infrastruktur med programmeringsspråk, så er det vanskelig å teste infrastruktur. Gå på deg, Hans Kristian. Har vi ulikt til å ta svaret ditt en gang til? For du sa ... Å ja, sorry. Akkurat det! Det er noe som er interessant med infrastruktur. Vi skjønte ikke det, men ikke for konteksten som bor der. Da kan vi ... Skal jeg bare ta svaret, eller ...? Du kan gjerne bare stille spørsmålet, du får det ofte så travelt. Audun, hva har du lært i dag? I dag har jeg lært at selv når man lager infrastrukturen sin ... Nå må jeg tenke på det en gang til ...
I dag har jeg lært at selv når man lager infrastrukturen sin med kode, og ikke med terraform, så er det vanskelig å teste infrastruktur. Det var forfriskende å høre om noen som har brukt noe annet enn terraform. Jeg er ganske lei av terraform. De problemene der skriver HCL-kode. Heldigvis er det veldig mye mindre av det i det jeg jobber nå med Nav. Men jeg har skrevet mye terraform før, så det var litt flashback. Og det er kult. Psykologisk trygghet har fått en ny definisjon når du har plattform hjemme med en tidligere psykolog fra, så det var veldig gøy å høre om. Jeg liker det når folk har forskjellig bakgrunn. Ikke alle har den samme bagasjen.
Med det så takker vi for denne episoden her. Tusen takk for at dere har lyttet på. Der finner du oss der hvor du finner podkaster. Husk å subscribe. Der finner du oss også på plattformpodden.no. Mitt navn er Hans Kristian. Med meg i studio har jeg Audun og teknisk podkastent Tore Græsdal. Ha det bra!