Episoden er transkribert av kunstig intelligens

00:00 --> 00:47

Hei, og velkommen til Plattformpodden. En podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg Audun Fauchald Strand. I sesong én av Plattformpodden utforsker vi de beste plattformene offentlige i Norge har å by på. Men før vi introduserer dagens gjester, Audun, har du en favoritt-Pokémon? Det tror jeg må være Snorlax, og det er nok mest fordi den ligner litt på meg. Men også fordi Nice en stund hadde en operator som het Snorlax, som prøvde å skalere ned ting som ikke hadde trafikk. Hva med deg? Jeg kan jo bare disse 180 hørste, for det var da jeg levde.

00:47 --> 01:34

Ivi syns jeg er litt kul. Du gir ham en stein, og så kan han bli til masse forskjellige. Og med de nyeste sesongene, så kan han bli til enda mer, så det er veldig kult. Du har alle muligheter foran deg. Men i dag skal vi ikke snakke så mye om Pokémon her. I dag har vi med oss Mats Bø Bergman og Morten Linderud fra NRK. NRK topper omdømmestatistikken år etter år, og NRK Nett-TV ble nylig kåret til den aller mest populære strømmetjenesten i Norge, og banker alle de internasjonale leverandørene. Selger tre barn som sluker innhold fra NRK rått, enten det er Snøfall, Om i Advent eller Fantorangen. Så da er det ekstra gøy å ha dere med i studio i dag. Mats, som er den av dere som har jobbet lengst i NRK,

01:34 --> 02:31

kan ikke du begynne å fortelle oss litt om din bakgrunn og rolle i NRK? Ja, jeg begynte i NRK i 2013. Før det så jobba jeg i et annet firma som lærling, egentlig. Så jeg har fagbrev. Det er min bakgrunn. IT. Jeg ble vel ansatt i NRK som ... Jeg ble vel ansatt i NRK som databaseadministrator i utgangspunktet. Jobba med det i noen år, og så ble det mer over på driftsgenerell applikasjonsdrift, da. Veldig spennende, og det skal vi dykke mer ned i. Men før det, Morten. Du har ikke jobbet fullt så lenge i NRK, og har en litt annen bakgrunn enn Mats. Fortell om hvordan du endte opp i NRK. Ja. Bakgrunnen min er hovedsakelig en mastergrad ved Universitetet i Bergen, og jobba som utvikler i et par år. Litt drift, litt evops og sånne ting.

02:31 --> 03:24

Drevet mye med open source Linux-distribusjoner i ti år ish, og sånne ting. Og NRK er liksom ... Jeg kjente dere som jobba der og var ute etter noe større, sosialt og trivelig, samtidig som jeg er litt idealist. Så jeg syns jo at jeg er litt idealist. Å jobbe hos NRK og drive med deres ... Samfunnsoppdrag? Samfunnsoppdrag. Det sitter i veggene her i Nav, det å si samfunnsoppdrag. Ja, ja. Veldig spennende og kult, og det er jo motivasjon i seg selv å jobbe. Jeg begynte der i august i fjor, så jobba jeg der i seks måneder ish. Men litt Linux-distrikt? Det er vel en underdrivelse? Og du er jo maintainer for Arch, Linux, er du ikke det?

03:24 --> 04:18

Jo. Ja, nei, så jeg jobba med det i begynnelsen av 2016-ish. Så ja, snart kanskje åtte-ni år. Og gjort det som hobby. Ja, stemmer det. Men nå er det Linux-året, ikke sant? 2024 er året Linux kommer til å ta over. Med tanke på hvor mange spill du kan spille på Linux om dagen, så stemmer jo det snart. Steamdeck solgte million devices. Ja, det kommer til å skje. Men hvordan er plattformlandskapet i NRK? Vi har vel egentlig mange plattformer, sånn sett. For vi har jo flere forskjellige arbeidsområder, kanskje. Med radio og TV og web, og også de områdene hvor det sveises litt sammen.

04:18 --> 05:16

Hvor ting smelter sammen. Så vi har jo ganske mange forskjellige plattformer, ja. Dere jobber i nett? Ja, primært mot det som er nett. Eller web-applikasjoner. NRK.no, men omfavner det også nett-TV og nettradio, eller er det egne? Ja, eller det er egne team, men vi legger til rette for plattformene i bunnen som de teamene også bruker, da. Blant annet Kupernetis og moduler i terra-form. Gitterbactions, ja. Masse forskjellige småkomponenter som de tar i bruk. Riktig. Jeg ser jo for meg, og jeg jobbet med NRK tilbake igjen i liksom min første jobb her, i Turistforeningen, og laget ut.no sammen med et team fra NRK. Det sier litt om bredden i NRK, det er veldig mye forskjellig.

05:16 --> 06:09

Veldig mye som er på nett. Så det er jo ikke ... Kan dere gå litt inn i det? Hvordan er det å ha så mange forskjellige team og kanskje ... Er det noen utfordringer rundt det? Det var veldig store utfordringer til det. Det var vel en av grunnene til at vi gikk over i den plattformmentaliteten. Det er mer over på devops-kulturen og den type ting. Det er noen år tilbake at vi skifta fokus over på det, men da jeg begynte i NRK, var det en tradisjonell driftstype-struktur, hvor driftsavdelingen fikk overlevert en applikasjon, og så skulle det settes i produksjon av oss. Og utviklerne slapp litt ... Nå er det ikke vårt ansvar lenger, nå er det deres. Det funka jo greit fram til det tidspunktet, men da web begynte å bli veldig populært ...

06:09 --> 06:58

Og det ble mye applikasjoner som skulle utvikles i mange språk, så skalerte ikke det lenger. Så da måtte vi tenke nytt. Den plattformen som dere kjenner best, kan dere ikke si litt om hvordan den ser ut? Hva er stack-in? Stack-in, kort fortalt, er Ukubernetes, som vi bruker som kjøretidsmiljø. Spinner opp containere akkurat som de vil, med akkurat hva de vil inni også. Og så har vi støttesystemet rundt det, sånn SART Manager, og vi har et oppsett som gjør at vi får automatiske telesertifikater. Vi bruker også Ingress EngineX, så vi får automatiske inngreser på det som skal ut på internett. Og så bruker vi mye terraform.

06:58 --> 07:56

Så hele kubernete-stacken sånn sett er satt opp med terraform. Og så har vi databaser som vi bruker, mye av det er satt opp med terraform. Men mye av det legges også i applikasjoner, så de har sine egne databaser, så de har levd sitt liv for seg sjøl fram til nå. Er det sky eller annen form? Alt som er satt opp med terraform, det er sky. Det er noen få unntak, men det er vel ytterst få. Er det Ashore eller Google eller hvor? Ja, takk, begge deler. Ja, takk alt. Men har dere Kubernetesk onprime òg, så dere har i realiteten tre steder? Vi kjører et Kubernetesk cluster onprime også, som er satt opp på gode, gamle-måten.

07:56 --> 08:52

Det driver vi og titter på å få bytta ut med en litt mer moderne måte å sette opp på. Men ellers så kjører vi 50 kubenetisk clustere i Sky og litt rundt omkring. Såpass mange, ja. For da er det ikke ett for alt, da får teamene kanskje sine egne clustere? Ja. Så NRK har eget, og så er det plattformcluster som er en stor del av det, som jeg tror utgjør 25 i Sky, sånn cirka. Og så er det ... Teamene selv kan administrere. Med sine namespaces i disse clustrene, og så kan du bestille. Men da er det separasjon på det som er offentlig tilgjengelig, det som skal bak CDN, og det som er internt i praksis. Så det er forskjellige clustre i forhold til hvilken aksessmåte det er fra utsiden. Interessant. Men 25 clustre, hvordan er det?

08:52 --> 09:49

Fordi det er noen i Google, noen i Ashore, og så er det per miljø òg, eller hvordan? Per miljø, altså. Hvor mange miljøer har man da? Vi har egentlig bare to miljøer. Prod og non-prod. Stage og pre-prod. Så er det Ashore Services, to er vel billigstilssoner også. Så det er jo Northern Europe og EU West, er det ikke det? Er det to clustre da? Det er ikke et cluster på tvers av de to? Nei. Riktig, riktig. Men dette høres jo fort veldig mye fra utviklende ... Hvordan ser de 25 clustre, eller hvordan ser de det fra deres side? Ja, de ser faktisk 25 clustre. Så det er jo en fordel, og en ulempe. Fordi utviklerne blir veldig bevisst på hvor Work-Londons kjører.

09:49 --> 10:37

Men de må da ta stilling til hvor de skal kjøre hen, på forhånd. Og da er det geolokasjon som de primært må tenke på. Fordi vi har i Norge, og så har vi et annet sted. Basert på hva slags data de skal ha. Det har vi sikkert litt med, hvor er det de har sine databaser, eller hvor er dataene deres? Har de Nashore-databaser, så vil de antakeligvis kjøre applikasjonene sine i Ashore. Ja, eller også hvilke tjenester de konsumerer internt hos oss. Så hvis de skal snakke med andre applikasjoner som også kjører internt i NRK, så ... Vil det også veie inn for hvilke clustre de skal plassere seg i? Men det er viktig å påpeke at utviklerne selv er ikke nødvendigvis de som setter

10:37 --> 11:26

dette opp og bestemmer dette. Vi har det som heter plattformer i team, som er folk som tilhører plattform, men som er på utlån på tvers til teamene. Det jeg gjør hos NRK, jeg er plattformer i team hos det som heter Visuelle Historier, eller VH. Og vi er de som driver med f.eks. valget hos NRK. Spesialsaker, hvis dere så den. Den om å bygge ned Norge? Bygge ned Norge. Det er jeg som hoster infrastrukturen der. Jeg var spesielt imponert over infrastrukturen, faktisk. Det er journalister som skriver saken, og så er det folk fra teamet mitt som måtte designe saken, den uexiten-opplevelsen og hvordan den skal se ut. I samsvar med journalistene, og så er det jeg som sørger for at det her blir statisk.

11:26 --> 12:24

Du jobber i et team som har også designere, altså visuelle designere? UX bruker opplevelser og så utvikler de det. Da har vi gjort alt fra å designe Excel-artikler, som "Den natur død"-saken deres òg, men også folk som til valget i fjor drev med prognose, som funka veldig bra. Og så i leveransen fra Valgdirektoratet inn til oss å kverne ut den dataen. Både for framstilling på TV og framstilling på nett. Hvordan sikrer du som plattformer i team at du har nok kunnskap om plattformen? Sånn det funker, er jo at jeg må lære meg ting gående. Men mitt tilfelle var vel heller å ha overtatt et eksisterende oppsett, og så vedlikeholde jeg og sørge for at det fungerer på de stedene som plattform.

12:24 --> 13:11

Og så kan jeg gå tilbake til plattform, høre hvordan jeg har dette problemet, hvordan jeg skal løse det på god måte, og så implementerer jeg det i mitt team. Jeg tror plattform hos NRK i seg selv er 50 mennesker, og så er vel en, jeg kunne ikke telte over det, men jeg tror 5-6-7-8-9-10 personer som er plattformer i team, som er på utlån i de forskjellige teamene. Og det er folk som jobber fra Maskorama og driver med voteringsløsninga der, folk som driver med deployment-løpet på det teamet. Jeg tror det første som har dette oppsettet er veldig kult. Kaller vi det matriseorganisering? Ja, vi sier det. Men det er også litt spennende for min del også, for jeg kan være plattform devops,

13:11 --> 13:58

men hvis jeg mot formodning skulle kjede meg i det teamet jeg sitter i nå, så kan jeg bytte til et annet team og fortsette med plattform, men i en annen teamsammensetning og løse andre oppgaver. For å være kritisk journalist, er det ikke en fare for at de andre i teamet, de får et svakere forhold til Prod og plattformen fordi de alltid har deg? Kanskje, litt usikker. I mitt tilfelle så er det egentlig ikke fordi folk er opptatt av å kunne ting selv og ha tilgang til Kubernetes og sånne ting selv, så i vårt tilfelle blir det plattform detectinic. Det tekniske plattformarbeidet blir på en måte jeg som samarbeider med de andre på mitt team som også bryr seg om dette,

13:58 --> 14:44

og så må vi til sammen finne ut en løsning på tingen. Det er ikke sånn at de roper "Morten!"-ting her nede hver gang til? Nei, jeg satt jo med tech-leaden vår som kom til å måtte berre ... Nei, han kunne plattformoppsettet til NRK før, og så fikk de med en jævla flink type som gjorde at han ikke kunne dette så godt lenger. Så han har lyst til å prøve å sette opp alt på den nye måten. Så da satte vi opp noen datajournalistting sammen. Da har vi en tjeneste som heter Gorgon, som er hvor utvikler kan bestille namespaces og clustertilgang og sånne ting. Så vil den automatisk lage puller requests til f.eks. Valtre på Wort for tilgangsopprettelse, så du da kan bare plug and play med dyppement-løpet ut i sky.

14:44 --> 15:27

Så grensen til utvikleren er dette Gorgon? Hva kommer det navnet fra forresten? Vaktmesteren i Pompel og pilt? Nei, det har jeg ikke. Så det var vel et sommerprosjekt som ble utvikla, og så satte det prod. Og så vedlikeholdt det teamet som heter Bruker ... Utvikleropplevelse, som jeg jobber i. Er det en app eller et gitter? Hva er grensesnittet som ...? Det er en go applikasjon som er et API, og så har vi en frontend som snakker med API-et. Hva er det de får fra Gorgon? Da kan du opprette et namespace, og sette deg selv som eier av det,

15:27 --> 16:11

eller tilegne andre. Hvis du allerede har eierskap til namespacet, kan du sette andre til å være eiere. Du kan opprette precistent volumes, sånne ting. Alle de tingene som krever en cluster admin-rolle, kan du gjøre via Gorgon, uten å egentlig være cluster admin. Og da blir det jammen ligget bak det? Ja, så den lager en pulder-quest til det repoet hvor applikasjonen lever, og så kan utviklerne selv se på hvordan dette blir utforma, og så kan de godkjenne det når de har mulighet. Og hvordan kommer du før repo til clusteret? Flux, argo, hjemmekk?

16:11 --> 16:50

Nei, det er vanlig deploy-pott, jeg holdt på å si. Om de kjører Q-set eller Apply lokalt på, eller om det er gitar-actions eller om de bruker argo eller flux. Det er litt opp til dem. De kan bruke flux, de kan bruke argo, de kan bruke gitar-actions ... Det er ganske mange muligheter. Hvert team velger dette selv i praksis. Og så er det støtta opp under med at plattform må tilby en del template-repoer, som de kan dra nytte av hvis de vil studere. Vi defolter til gitar-actions. Det er på en måte det vi anbefaler. Det har vi lagd en del workflows og actions til.

16:50 --> 17:40

Så kan de velge selv om de vil dra nytte av det eller bruke noe annet. Si at det er et nytt team som skal opp og gå. Hvor begynner de der for å komme i gang? Det kommer jo veldig an på applikasjonen. Men hvis det er en simpel web-applikasjon som skal ut, så er det i utgangspunktet bare å bruke. Så er det i utgangspunktet bare å bruke template-repo for å sette opp repo-et ditt med gitar-actions og de tingene du trenger. Så er det bare å gå inn på Gorgon og sette opp applikasjonen din der, og den lager PR-er der den skal. Så går ting automatisk på, når du merger den, så deployer den også til guvernettsklustere som du har valgt i Gorgon.

17:40 --> 18:23

Er det da noe abstraksjon, eller er det deployment for selve appen? Deployment for selve appen kan du også få via Gorgon, så du får en sånn least viable product-type. Som da blir en PR til de tre på, og så kan du bygge på det sjøl etter hvert. Men for å finne ut av alt dette, har det en nettside, intern side eller slack, eller går de til Morten for ...? For å komme i gang, eller? Det er litt varierende, egentlig. I de tilfellene hvor man har en plattform i team, så er det til den personen man går. Men det er ikke alle team som har de, som er mer selvgående.

18:23 --> 19:14

Og der har vi brukt confluence fram til nå. Vi ser at det er litt problematisk. Så vi ser på litt andre løsninger der, og prøver å finne en god måte å dokumentere på. NRK bør kanskje være god på sånn publisering? Hva med en sånn visuell journalisthistorie? Men det er jo også vidt påpekt at vi har jo et Kubernetesk kurs, og vi kjører intern opplæring på både Gorgon og hvordan Kubernetesk funker. Så vi hadde jo da et Kubernetesk kurs som går over én til to dager, som var på turné hos Bodø en tur, og så var det på Ospergen en tur. Så kan folk som deployer ting og driver teknisk der, få lære litt om hvordan Kubernetesk funker, så lenge du bor i en by som begynner på B.

19:14 --> 20:03

Bærum, Bergen ... Malstrand. Men det var Nett sin plattform. Så var vi litt innom snart om det finnes andre plattformer. Hvordan ser de ut, har dere noe kunnskap om det? Jeg har egentlig ikke så mye kunnskap om de, bare det jeg har toucha innpå, litt tilfeldig. Er liksom Kubernetesk plassert fortsatt og sånn, eller er det? Man ser på å bruke Kubernetesk til noen sånne, hva skal vi kalle det, støttetjenester. Sånn DNS og sånne ting. Men det meste der er satt opp med terraform, fordi det er mye hardware. Da bruker man terraform til veldig mye, og så bruker man også nettboks.

20:03 --> 20:55

Du tenker på IP-løsninga? Ja, la oss si det er nettboks. Lydmikser er det også som kan settes opp i terraform, eller hva? Nei, men da skal vi kjapt dit. NRK har jo noe som heter Innovasjonsdager. Vi setter av fire til seks ganger i året, så får NRK lov til å pitche ideer og prosjekter som de har lyst til å gjennomføre. Så kan du gå på en scene og forklare hva du har lyst til å prøve å gjøre. Så får du tre dager på å jobbe med et vilkårlig prosjekt. Da var det noen fra NRK Radio som sa at de hadde lyst til å finne ut av hvordan vi kan slutte å ha fysiske lydmiksere i praksis. Da satt vi og så litt på. På en skyapplikasjons- eller selvhosta løsning, som også eksisterer i Sky,

20:55 --> 21:33

som vi kan spinne opp lydmiksere på og koble sammen ting på. Da var det noen som satt med journalistinterface til lydmiksere, for de kan liksom ikke gi en full lydmikserbord til en journalist og anta at de nødvendigvis forstår hvordan alt det her funker, uten opplæring. Og så satt jeg og tenkte at en terraform-modul med tanke på at de har en fullt API, det hadde vært jævla fett, for da kan de jo bare ha en terraform-provider som moduloppsett. For å spinne opp lydmiksere. Og da er det ikke noen vei inn for å ha én lydmikser per studio spunnet opp i Kibernetes. Så hvis du trenger en tilfeldig lydmikser, så er det bare ny applikasjon, terraform opp, og så har du standard lydmikser-oppsett.

21:33 --> 22:05

Kan du ha 1000 millioner lydmiksere? Ja, og så vil alt være fast standard oppsett. Men det er jo ting som nå er veldig langt unna for faktisk å kunne bruke det. For det er mye problemer med tanke på latency og sånne ting. Men det var et kult detour-prosjekt å vite hvordan NRK ... . Radio og folk som driver med podkast-studio, jobber og tenker på teknologi. Så det var morsomt. Det er herlig nerdete. Det var en terraform-provider å få Dominos pizza, hvor du da kunne kjøre Terraform Applie og så bestilte pizza. Det er ...

22:05 --> 22:57

Jeg er usikker på om det egentlig er enklere. Men jeg er i en pizza hvis det er state. Må du kjøre Destroy? Har du en evigvarende state? Det er noen helt nye utfordringer der. Men etter at de har deployet en flott app som er på nett, hva får teamene muligheter til å følge med på den og være ansvarlig for den når den kjører? Vi har jo satt opp litt logging og metrikker og sånt i kubein-clusterne. Mye av det sendes bare videre til en data source hvor vi aggregerer alt sammen. Den er tilgjengelig i Grafana. Mye av grafene og sånne ting kan man finne i predefined dashboards i Grafana.

22:57 --> 23:44

Du bare velger hvilken cluster du vil være i og hvilket namespace, og så får du opp til den applikasjonen. Da får de Matrix, får de loggs òg inne i Grafana? Ja. Vi bruker Loki til logging, og så bruker vi ... Mimer til aggregeringen. Og så har vi begynt å se på tempoet også for tracing. Dere sa dere brukte både Ashore og GSB. Hvor vanskelig er det å få clustrene til å oppføre seg likt nok? Funker det å bruke terraform så det blir likt nok? Det funker ikke.

23:44 --> 24:28

Vi har satt opp to forskjellige moduler til det. Det er en for Ashore-oppsettet av Kubernetes, og en for Google-oppsettet. Og så har vi en Common-modul som vi bygger oppå der igjen, som er alle komponentene som skal inn i Kubernetes. Det er ikke spekakses, så er ikke det egentlig ute av drift snart. Det er litt uskikkelig. Er det vanskelig å lage de komponentene oppå? Eller blir det likt nok? Det blir likt på alle clustrene. Likt featuresett hva du får, ikke fra skyleverandør, men fra en del av Kubernetes-plattformen. Så bruker de gjerne terraform til å automatisere alt mulig annet

24:28 --> 25:10

inn i den skyplattformen som clustre bor på. Har dere noen ferdige pipelines eller terraform-moduler som teamene kommer i gang, eller er det de som starter med ... Nei. Grunn til det. Det er fordi mange av de som har tatt i bruk terraform for å konfigurere Kubernetes, ikke egentlig ... Eller de gjorde det før vi tenkte på at vi skulle gjøre det. Så de har bare kjørt sitt egletløp, og det var egentlig bare de to teamene som hadde lyst til å gjøre det på den måten, så da har de bare gjort det som de pleier. Men de bygger jo på hverandre, da. Så de har jo erfaringsutveksling seg imellom.

25:10 --> 25:53

Men hvis du har en app i plattformteamet sin, Kubernetes, og så ønsker du å ha ... Noen databaser eller buckets eller andre ting, får de det gjennom Kubernetes, eller setter de opp noe terraform på siden av? Nei, det settes opp med terraform på siden. Vi prøvde oss litt med postgressoperator på Kubernetes, men overhead-en på vedlikeholdet der ble litt for stor for vårt plattformteam på den tiden. Så vi gikk bort ifra den operator-type-tankegangen, egentlig. Alternativet ville vært crossplane, hvor du får CRD-ene i Kubernetes, og så kan du profesjonere ressurser inn i det. Ble det vurdert, eller?

25:53 --> 26:45

Nei. Men det er noe som vi revisiter hele tiden, sånn type ting. Vi har sett på Argo for å sette opp ressurser i Kubernetes, men siden vi har så mange, har det ikke vært like hensiktsmessig å gjøre det på den måten. Men crossplane er antakeligvis mer aktuelt. Er det stort sprik på hvilke andre ressurser applikasjonene trenger? De aller fleste applikasjonene ser veldig like ut, de bruker samme type relasjonsdatabase, eller hvor stor variasjon er det? Det er veldig likt. Vi har for det meste bare front-end-type applikasjoner som kjører på Kubernettes, og så har vi jo noen back-in-applikasjoner også. Litt mer snowflake-type deployments.

26:45 --> 27:34

Noen av de håndterer databasetingene sine helt sjøl i sine deployments, så de har databasene liggende som vanlige ressurser i Kubernettes. Og så er det noen som trenger mer gufs, som kjører på utsiden av Kubernettes i sine egne databaser. Men hva kjører foran nrk.no, da? Det er vel antageligvis noe caching, og så kanskje har man mulighet til å kjøre ... Front-end-applikasjoner som kanskje ikke kjører inn i Kubernettes òg, eller? Så NRK.no-opplegget er jo en komplisert beist i seg selv, men i praksis, det du ser når du treffer NRK.no, så treffer du først et av Kamaya-lag, og så går det til en CMS-publiseringsløsning,

27:34 --> 28:13

og mye av magien der er jo på en måte cloudlets og redirects og ... Fra ... eller en måte ... Eller lenker rundt til andre ressurser med Akamai i praksis. Så du får på en måte et helhetlig inntrykk når du besøker NRK, men mye av det du besøker når du trykker rundt, er jo av og til forskjellige applikasjoner som går forskjellige steder, og av og til treffer forskjellige Akamai-properties osv. Så det er jo en helhetlig, veldig sånn komplisert greie. Er det Akamai for streaming og sånn òg, eller? Der har vi flere leverandører. Ja, for der er det vel ganske mye greier som skjer.

28:13 --> 29:00

Ganske mye behov og krav og data. Jeg kan ikke det løpet, men det var vel kanskje Warners før. Jeg tror ikke det Warners-opplegget eksisterer den dag i dag, på akkurat streamingopplegget, men mye av dette går bare rett til streamingleverandøren i seg selv, da. Så vi selv er ikke de som når du går på NRK TV, så er det ikke vi som hoster CD-en, hvor du ser på strømmene, tror jeg, uten at jeg nødvendigvis har sett så mye på det. Men på sikkerhetssiden, da? Har dere verktøy rundt applikasjonssikkerhet, som dere tilbyr teamene, som en del av utvikleropplevelsen? Mye av dette er GitHub-templates, repop-setten, hvor du får standardisert CV-skanning

29:00 --> 29:48

med Aqua, TriveScan og sånne ting. Og så er det samme også. Så du får et Trivy-skann-oppsett for applikasjonene dine, det Trivy støtter, og så kan du bruke det. Hvordan dette ageres på, er selvfølgelig opp til teamene selv per i dag. Og så har vi begynt å diskutere litt mer en sånn Devsec-opps-læring på tvers i plattform, for å spre litt mer kunnskap på det. Jeg tror jeg har sett at det har vært noen Security Champions-meetup i regi her. Yes, det stemmer. Jeg kaller det "sikkerhetsmann i team", tipper jeg. Det er noen Security Champions-opplegg som er ute og går.

29:48 --> 30:41

Vi har ikke det på mitt team, så jeg er litt usikker på hvordan det står her på andre team. Men hvor mange team og applikasjoner kjører dere på plattformen i dag? Vi samler litt statistikker på skalaen hos NRK i praksis. Det vi fant ut, var ...Vi er litt usikre på forskjellen på team og applikasjoner. Det er ikke noe tydelig skille internt på hva som er ett team og deres applikasjon, og hvor mange applikasjoner som går til ett team. Teamet mitt har 300 applikasjoner som kjører på Kybernetis, og det er ikke 300 i team. Det er vanskelig å si hvor mange team og applikasjoner vi eventuelt har. Men for å ramse statistikken for moro skyld, er det at vi har over 1000 deployments på tvers.

30:41 --> 31:35

Vi har 600-700 image pushes til docker daglig, er det, fant vi ut. Og det er ikke alle som bruker akkurat det registryoppsettet til interns av NRK. Men det gjør at vi har et 6,6 terabyte med docker-images som lagres og distribueres. Og da er det 4000 reposteries på det registry, fant vi ut. Yes. Og så har vi dette på tvers av 3000 gitterbrepoer som ligger på Github. Er det noe open source i de rapperne? Det er noe sommer source, men vi kunne gjerne vært bedre på open source-ting. Det er bare å gå inn og bytte fra private til ... MIP!

31:36 --> 32:22

Vi har noen oppsource-prosjekter som Terraform Registry, for å pushe Terraform images. Self-fosta løsning på det. Og så har vi litt spennende prosjekter som Sofie, som er live video-redigeringsverktøy, som blir brukt hos NRK og andre steder for å drive live-redigering av sendinger. Det er vel scheduleren til TV. Så det er den som ... Hele sendeløpet for det programmet som skal lages, lekes innen Sofie, og så er det den som eksekverer. Kamerarobotene når de skal zoome inn og kjøre bort og se på en person, så er det der det kommer fra.

32:22 --> 33:03

Og den løsningen er open source, f.eks. Kjører de i Kubernetes? Nei. Men de har lyst. Men hva er den mest spesielle løsningen som kjører i Kubernetesk-løstrene deres? Vi har en som er litt spesiell, som er Mediekverna. Som kjører enkoding av video kontinuerlig, egentlig, hele tiden. Som da tar én type video inn, så lager de flere kvaliteter og sender ut igjen i andre enden. De kjører helt og holdent på Kubernetes, bruker Kubernetes' scheduling-algoritme for å schedulere jobber. Bruker den noe GPU her, eller er det ...? Ingen GPU, det er kun CPU. Og det er F5Peg som kjører på den.

33:03 --> 33:52

Den kjører i typisk "head of time"? Ikke noe "just in time"-mediakonvertering? Nei. Det er det som går til On Demand-innholdet. Riktig. Typisk på TV.nrk.no eller ... Eller alt, egentlig. Ja. Og alt mulig rart. Jeg ser for meg at siden nyhetsdelen og sånn, at det vil være en del sånne piker med trafikk når ting skjer. Har dere noe i plattformen for å håndtere det, eller blir alt det håndtert av CD-ene? Sånn som den fine saken om nedbygg av naturen og sånn, som ikke er viralt på et vis. Ja, der er det håndtert av Akamai. Så jeg tror Akamai hos oss serverer ... Var det noen som kom de siste 90 dagene, i forrige uke,

33:52 --> 34:47

så hadde de servert 4,5 Petabyte med trafikk, tror jeg. Den grafikken viste. Så mye av det er håndtert i praksis på cashing, men det er flere lag av cashing her også. Så CMS-biten casher litt, og så er det Akamai i front og sånne ting. Så internt hos oss så er det i praksis ingenting som må skaleres opp for dette her. Akkurat den Naturdød-artikkelen er jo da også holdt til som en statisk Java-skriftapplikasjon. Så det er ikke noe Kubernetesk der som egentlig kjører, for det er jo skrevet noen sveltegreier. Det er en single page-app, og så kan det bare gå rett ut. Men det betyr at uansett selv om dere er ...NRK ble eksponert for veldig mye variabeltrafikk, så merker ikke dere i plattformmagiene så mye til det? Nei. Hos oss er det bare å finne ut hva som er single point failure.

34:47 --> 35:38

Under valget er spørsmålet at vi må sørge for at databasen i bakhånden ikke får for mye ut, eller mot deg ikke får spikes i CPU og sånne ting. Det er viktig å sørge for at folk ikke kan finne måter å komme seg forbi cashinga hvor du kan sende vilkårlige forespørsler inn. Oppdaga dette tidlig og måtte teste for det. I praksis hos oss uavhengige av år ser du at CPU-grafen ikke toucher over 1 %, og så ser du bare trafikken sparker. Og så er det egentlig ingenting som skjer bakover. Det er jo mye prepp, mye CDN i praksis og mye smarte cashing løst. Men av og til så er det jo at NRK har sånne voting, at man kan stemme. Det er ting som ikke kan ligge bak cashing. Er det noe som kjører i deres clustre,

35:38 --> 36:19

eller kjører de andre steder? De kjører andre steder. Det er primært den innloggingstjenesten som blir berørt når du skal ha den avstemningstingen. Og det er ting som ikke kan caches. Ja, og så selve avstemningen. Selve avstemningen også, ja. Der er det vel ... Jeg tror de har primært brukt Firebase. Så det er køstemet til GSP, og så er det Firebase som er løsninga på den i dag. Men apropos Firebase, de har jo functions, Cloud Functions, Ashre Functions, er det noe som brukes i den delen av NRK som dere er kjent med, eller?

36:19 --> 37:03

Vi brukte i hvert fall en del Ashre Functions før. Problemet der var latency på å eskalere de opp. Og ned, egentlig. Hvis de er blitt brukt på dagtid, så er det ikke noe problem, da kommer de fort opp, men på morgenen f.eks. brukte den veldig lang tid på å spinne opp. Så det ble et problem. Cold Start-problemet er veldig kjent for de som har vært borti det. Ja, det var generelle problemer med det. For den baserte seg vel på disse VMSS, Virtual Machine Scalesets, som var litt buggy. Men skalering i Kubernetes, altså POD autoscaler, Node autoscaler, er det noe som dere har innebygget òg? Ja, det bruker vi. Så vi bruker det på Ingrid Senginexen f.eks.,

37:03 --> 37:46

så er det autoscaling, og samme med noder også, basert på litt forskjellige parametere. Kan appen også be om å få autoscaling på sitt replikkassett, eller? Ja. Så vi har vel sånn sett bare én nodepool på alle clustrene, og den skalerer også inntil et visst Så vi har vel sånn sett bare én nodepool på alle clustrene, og den skalerer også da inntil et visst punkt, selvfølgelig. Og det kan i utgangspunktet alle applikasjoner be om å få mer av, hvis de vil. Men vi har jo også satt limits i hvert namespace på hvor mye ressurser man kan bruke. Hvordan gjør dere da med kost og kostoversikt for teamene? Er det noe de har et direkte forhold til, Kommer det bare i én samlesekk, eller?

37:46 --> 38:27

Vi har prøvd å flytte kostansvaret opp et nivå, bort fra utviklerne egentlig. Og sette det mer på de som er produkteiere. Det er en rutine som vi prøver å strømlinjeforme nå. For det har ikke vært så mye av før, det har liksom bare alt vært å få det ut i sky, på en måte. Og så begynner man nå å skal se litt på strømlinjeforme. Den prosedyren, da. Har det en utviklerportal hvor du kan komme inn og se: "Her er mine applikasjoner. 300 applikasjoner i timen mitt." Eller er det at de må inn i CubZtL og finne det? Ja, de må inn i CubZtL, ja.

38:27 --> 39:11

Vi nærmer oss slutten og går inn for landing. Da har vi et spørsmål som vi alltid stiller gjestene våre, og det er at vi lærer enormt mye når ting ikke går helt etter planen. Kan ikke dere fortelle om en sånn hendelse, og litt om hva det er? Hva lærte dere av det? Ja, vi har mange eksempler av det. Det er stadig vekk at ting ikke går som planlagt. Helt i begynnelsen da vi begynte med Terraform og Cubernettet, så var det jo en bratt læringskurve, kan man si. Og da var det tre anledninger at vi klarte å slette clustrene våre. Det var veldig gøy. Når vi kjører Terraform Apply, så ser han "replacing resources".

39:11 --> 39:49

Og så tenker du at alt ser fint ut, fordi det var 190 ressurser han skulle gjøre noe med. Så tenker du det var greit, og så ... Det var litt gøy å kunne gjøre det første gangen. Men tredje gangen er det kanskje litt vanskeligere å holde entusiasmen oppe. Her skal vi lære av våre feil. Det stemmer. Da fikk vi det vi kaller for Keos Monkey Club. Hvor alle som klarte å gjøre en sånn blunder, fikk bli med. Han som fiksa Mott, satt hos tannlegen mens han fiksa det, ikke sant? Jo, det stemmer. Fordelen med Terraform er at det kommer fort opp igjen.

39:49 --> 40:39

Men har dere noen type post mortem som dere jobber etter når ting går galt? Fortell litt om hvordan det er implementert i NRK. Vi bruker egentlig den, er det ikke Google som kommer med den? Det bruker vi også i NRK. Det fungerer veldig. Hvor vi går igjennom hva som gikk feil og hva vi kan gjøre for å fikse det neste gang. Er det andre team i NRK som også bruker det, eller er det mest i plattformteamet? Det instastieres egentlig fra Bifrost, som er overvåkingssentralen i NRK. Så de får inn alle feil, og så er det de som maser på de som har hatt feilen, og må ha en post mortem i ettertid. Det er kjempespennende. Det er mye her vi kunne ha dykket ned i,

40:39 --> 41:34

men vi må nesten runde av og lure på om det er noe dere vil si før vi avslutter. Vi kan jo begynne med deg, Morten. eh ... Nei, plattform er spennende. Variert av hva som kommer. Nei, jeg vet ikke hva jeg har ... Nei, jeg tenker jo ... Jeg syns det er veldig bra at dere lager et norsk IT-pålerkast. Det er jo ikke verdt så mye av det. Så det er veldig morsomt at dere har dette og inviterer NRK og offentlighet til å snakke om det. Hva med deg, Mats? I RF, Kartverket, som dere hadde på besøk, så ser vi også på Google Anthos, eller Google GKE Enterprise. Så det er noe vi ser på i forhold til on-pram kubenets-clusteret. Veldig spennende å høre, Mats, og det er mange muligheter for å invitere deg tilbake.

41:34 --> 42:16

Så hvis dere som lytter på har spørsmål, så send det gjerne inn til oss. Tusen takk til Morten Linderud og Mats Bø Bergman fra NRK for at dere tok dere tid til å snakke med oss i dag. Audun, hva var høydepunktene dine verdt for denne episoden? Jeg syns det var morsomt å høre om hvordan det var å ha cluster i både Asher og GCP. Selv om det er samme teknologi, så er det en del spesialtilpasninger du alltid må gjøre. Hva med deg, Hans Kristian? Har alltid vært en leser av NRK ennå. Det å få mer innsikt i hvordan plattformen og hva som skal til for å hoste den nettavisen og alle de spennende seriene på NRK, det er veldig gøy å høre. Det var mine høydepunkt.

42:16 --> 42:48

Igjen, tusen takk for oss! Du har hørt en episode av Plattformpodden med Hans Kristian Flåtten og Audun Fauchald Strand. Teknisk produsent har som vanlig vært Tore Græsdal. Siste episode finner du som alltid på plattformpodden.no eller i din lokale podkastapp. Hvis du har spørsmål eller kommentarer, post gjerne på vår LinkedIn-side. Takk for følget, og ha det bra!