Episoden er transkribert av kunstig intelligens

00:00 --> 00:45

Velkommen til Plattformpodden, en podkast om applikasjonsplattformer og teamene som bygger dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg Audun Fauchald Strand. Og i denne sesongen utforsker vi plattformene i offentlig sektor. Men Audun, hva har du drevet på med i det siste? I det siste har jeg klart å bevege meg både høyt og langt. Jeg har både jobba med Navs innspill til digitaliseringsstrategien, og jobba med å skru av prem og få Nav ut i sky. Men hvem skal vi snakke med i dag? I dag er vi så heldige å ha med Anders Pettersen og Endre Mikkelborg

00:45 --> 01:41

fra Oslo Origo, en digitaliseringsetat i Oslo kommune. Endre, vil ikke du fortelle litt om deg selv og hva du gjør i Origo? Jeg heter Endre Mekkelborg. Jobba i Oslo Origo i snart to år. Der jobber jeg som arkitekt, så jeg jobber litt på tvers av teamene i teknologiavdelingen. Så jeg hjelper bl.a. kjøremiljø, også med plattformutvikling der nede. Hva med deg Anders, hva gjør du på? Jeg jobber med infrastrukturutvikling, så det er hovedsakelig Terraform som vi holder på med. Jeg har jobbet der i ca. ett år. Jeg er i Team kjøremiljø, som er et team som bygger infrastruktur for de andre teamene i Orego. Det er spennende. Men i Orego, hvorfor begynte dere med plattform?

01:41 --> 02:40

Vi har jo team som jobber med en del forskjellige ting. De utvikler applikasjoner og løsninger, og vi må jo kjøre et eller annet sted. Vi valgte tidlig å gå og kjøre dem i sky, i motsetning til mye annet i Oslo kommune. Da var vi nødt til å finne en måte å kjøre det trygt og effektivt i AVS, som er der hvor vi har valgt å kjøre våre ting. Hvor lenge er det siden? Når begynte dere den prosessen? Vi startet rundt 2018, og får lagd en del systemer. Første måten vi tenkte vi skulle ut i sky, det var Var i 2020, hvor man bygde noe på kubernetes. Og så måtte vi ta et lite steg tilbake. Valgte å gjøre det for å finne en annen vei. Og den begynte vi i midten av 2022. Det er det vi kjører på i dag.

02:40 --> 03:46

For det er jo litt spesielt med, kanskje opp mot de andre vi har hatt på denne podkasten, hvor de har brukt kubernetes, eller har det som i bunn for sin plattform. Dere begynte med det, og så har dere tatt en litt annen løsning. Vil du gå litt dypere inn på det, Endre? Ja, jeg kan godt det. Det starta egentlig med at vi følger det oppsettet i AVS som heter AVS Organisations. Dvs. at teamene hos oss har hver sin AVS-konto å kjøre ting på. Og de kjører da helt separate miljøer, med færre applikasjoner per miljø. Og da ble det å kjøre kubernetes veldig mye greier for å kjøre få applikasjoner. Så dermed fant du: Kanskje vi skal gjøre det på en litt annen måte, med litt mindre overhead. Er det der terraformen kommer inn, Anders? Jeg vil kanskje si at det som kommer inn der, er vel den

03:46 --> 04:30

Den tjenesten i AVS som heter Elastic Container Service. Så bruker vi terraform for å konfigurere det meste rundt det. Når vi bruker terraform, så blir det mer bransjestandard. Dokumentasjonen er tilgjengelig på nett, og ikke så mye custom. Det er det vi har satset på med det. Hvilke ting utenfor ECS, er det det man sier? Elastic Container Service. Hvilke ting utenfor det er det dere bruker? Sånn i tillegg til det? Vi bruker Elastic Container Registry, som er for å oppbevare docker images. Så bruker vi ... Vi bruker jo for det meste AVS-tjenester.

04:30 --> 05:24

Lite on-pram og sånne typer ting. Så bruker vi RDS, Relational Database Service, i AVS. Som vi da tilbyr egentlig til teamene gjennom terraform-maler. Gjennom en golden path, som vi kaller det. Vi kan prate mer om det etter hvert, men vi har den tilnærmingen. Og så har vi lastbalansering med innebyggede tjenester i AVS. Så dere lager maler, men teamene skriver terraformen basert på de malene? Ja, vi genererer malene ut fra ... Ut fra en sånn rotjammel-fil. Tanken er at vi skal kunne regenerere de malene igjen og igjen.

05:24 --> 06:14

Og så kan de gjøre noe om tilpasninger. Så kan de jobbe ... Så kan de få oppdateringer av oss når vi forbedrer ting hele tiden. Jeg er ikke sånn kjempestødig terrorist, men hvordan funker de oppdateringene? Når dere gjør noe i malene, hva er flyten for at det skal treffe verden? Ja. Det er noe vi jobber med. Vi har også brukt terraform-moduler for å distribuere konfigurasjon. Vi så at det var vanskelig å treffe blink på første forsøk å finne riktig abstraksjonsnivå. Så har vi prøvd å ta et steg tilbake igjen og prøve å åpne litt mer på abstraksjonsnivået, sånn at du kan konfigurere mer selv. Da får man utfordringer med det.

06:15 --> 07:09

Nå prøver vi å finne en gyllen middelvei på hvordan ha fleksibilitet, samtidig som vi kan ha det litt sentralisert, og samtidig gjøre det enkelt. Der mye av utfordringene ligger med en sånn type løsning. For hvert team har på en måte sin account, og per account er det ett repo med terraformfiller. Og så er det litt viktig ... Det Anders var inne på, det å beholde fleksibiliteten. For ECS er jo en fleksibel måte å kjøre en container på. Og så kan vi gjøre det veldig rigid ved å si at du skal gjøre det sånn, sånn, sånn. Og så ha veldig få parametere å skru på og lukke det universet. Men vi har valgt å beholde det åpent, så de som har behov litt utover det helt standard,

07:09 --> 08:07

kan gjøre det. Men har man et standard behov, så får man veldig mye ut av boksen. Sånn at du kommer raskt i gang og enkelt kan oppdateres i forhold til ny ... Ja, det vi mener er best practice. Men hvordan forholder teamene seg til CSS, da? Teamene har applikasjonskonen sin i Trepo. Og der bruker vi Git of Actions for å bygge docker images. Og så har de da satt opp sitt eget sånn SR Repo story. Hvis vi skal gå litt teknisk inn på det, så bruker vi det som heter Reusable Workflows, så vi kan bruke gjenbrukbare workflows. Og så bygges det Docker image, pushes til AWS, og der liker vi å ha et skille.

08:07 --> 09:01

Sånn at applikasjonen og imaget er en egen ting. Og så da for å kjøre det, så bruker du egentlig bare taggen for å si at taggen skal kjøre her og der. Er det en fiks tagg, en standard tagg, som de bruker for at det skal kjøre der og der? Så når det bygges et image, så genererer vi tags. Og så sender vi den taggen videre til neste steg i løypa. Som vi har gjort det nå, så utfører vi utrulling. Med terraform. Så vi sender da den taggen inn i terraformkoden. Sånn at alt blir som kode. Så hele det kjørende miljøet er synlig som kode, da. Og så kjører vi terraformapply, og så blir da tjenesten aktiv.

09:01 --> 09:50

Ja, så når en applikasjon bygges, så blir det da selvfølgelig en tag, og så committes den tilbake til et rep og et terraformrett, og så kjøres det ut, eller? Ja. Spennende. Det er også veldig greit å rulle tilbake, for da kan du jo bare rulle tilbake den PR-en på Teleformrepo, og så blir SS instrumentert til å kjøre opp den gamle. Veldig lite magi, da, på en måte. Ja, men det liker vi. Vi liker at ting er vennlige her. Sånn er det, sånn fungerer det. Men det jeg har glemt å spørre litt om, er hvor mange team og hvor mange applikasjoner. Hvor mange applikasjoner per team er det vi snakker om her? Vi er nok gått mindre enn dere. Vi er elleve-tolv team, vi har et nytt team på trappene nå.

09:50 --> 10:44

Det er veldig forskjellig hvor mye hvert team kjører av løsninger. De minste teamene kjører to-tre applikasjoner, det største teamet hos oss kjører mer 20 applikasjoner. Så der er det mer behov for ... Større klustermiljø og mer ... Hva er det som skal snakke internt, og hva er det som skal motta requester om mer sånn oppsett, som er mer vanlig i Kubernetes. Men det også får du ut i SS, med WPC og hvordan alt er satt opp for å ha det beskytta og kunne snakke med intern DNS og sånt. Kan teamene styre en god del av det selv, eller? Ja, sånn som det teamet som har den største porteføljen. De har en løsning de har hatt med seg helt fra 2014.

10:44 --> 11:42

De er nok lenger fram i forhold til Golden Path, som vi snakka om, for de har større behov enn de andre teamene. Så de har en del konfigurasjon som andre team ikke har behov for å komme til dem ennå. Men i og med at vi har åpna det og ikke valgt å lukke så mye som mulig, så ligger det mulighetsrommet. Hvor det teamet, i samarbeid med kjøremiljøteamet, finner ut hvordan vi skal gjøre dette, når vi går utenfor det som alle teamene kjører. Hvert team har hver sin konto, og til og med Container Registry kjørte i kontoen. Er det noe som er på tvers? Noe om overvåkning, som er felles for alle? Vi kjører jo AWS Organisations, så der er jo alle kontoene satt opp i en struktur med en foreldrekonto. Så det settes en del felles policyer og en del felles overvåkning derfra og ned.

11:42 --> 12:44

Men den generelle observabilityen som ligger i hver konto, den er separat. Så skal du følge requester fra ett teams løsning til en annen, så må du kanskje via et web-analyseverktøy, for du kan ikke følge request-ID-er på tvers av løsningene våre. Men en del overvåking av sikkerhet og alt sånt, det kommer via organizations som vi kan følge på tvers. Du snakket om at det var et nytt team på trappene. Vil du dra oss litt igjennom? Hva er det som må til for at et nytt team skal komme inn, bli ombordet på plattformen? Det å komme med et nytt team er en litt tyngre prosess enn det jeg vet dere har i Nav. Så vi jobber med å forenkle det hele tiden. Men der får de i utgangspunktet en tom konto, så er det avhengig av de personene og hvor erfarne de er.

12:44 --> 13:33

Noen tar ting på strak arm, noen trenger å få litt mer følging i starten. Da har vi gjerne erfaring med opp. Erfaring med å opprette noe vi kaller kosekrok, f.eks., sammen med kjøremiljø. Hvor det skal være en avslappa greie for å hjelpe hverandre. Hvor de får en introduksjon til det som vi kjører opp av infrastruktur i kontoene. Hvordan det henger sammen og sånt. Og også det å få satt i gang den første applikasjonen med called walking skeleton eller noe sånt, for å bare få noe opp. Nylig jobber vi med et sånt AWS101-kurs. Som går for de som er litt nye, både på infrastruktur og terraform, hvor de skal få en introduksjon av hva en lastebalanserer er,

13:33 --> 14:36

hvordan sertifikater håndteres, og samtidig få lov å kjøre det opp i en sandbox-konto og ta ned et miljø. Sånn at de faktisk alle kan føle på det å ta infrastruktur opp og ned. Vet du om alle i teamene har en eller annen form for forhold til AWS, eller er det noen som da Jeg regner med at det er noen som har mer kompetanse og ansvar, men har alle i teamet et forhold til AWS og de ressursene som kjører der? Alle har forhold til AWS, men i den daglige tralten, så er det jo ikke så mye infrastruktur du forholder deg til. Har valgt mye manage-løsninger som Anders var inne på. Og da er det ikke så mye som skal til for å holde det gående. Så innenfor team, ja. Noen tar mer eierskap til infrastruktur enn andre.

14:36 --> 15:40

Men vi prøver å tenke på at det skal fordeles på oppgaver og få andre opp og gå også, da. Det virker som om dere har ganske mye fokus på at teamene har mye ansvar og autonomi. Det er kanskje mer enn det jeg vil si at et vanlig team har i Nav på NICE. Var det bevisst, eller hvilke vurderinger gjorde dere for å komme dit? Ja, man er bevisst det. Vi jobber med en del sånne viktige valg i organisasjonen. Så pleier vi å uttrykke det via en sånn RFC som vi skriver, og blant annet. Den brolagte ... Den brolagte sti, eller golden path, det er også en RFC. Der står det det med at det kan føre til høyere kognitiv last, ikke sant. Folk gjør ting de ikke gjør til vanlig, og en del sånn overhead. Men samtidig så er det en del fordeler òg, ikke sant.

15:40 --> 16:33

Kompleksiteter som ligger i ett team, det smitter ikke over på andre team. Så dere kjenner jo det til selv. Har f.eks. det når hvis et team skal koble seg til Norsk Helsenett, og det krever veldig mye nettverksoppsett og gateways og you name it, for å få brukt de få IP-adressene som ligger der. Et team som ikke trenger det, har ikke det infrastrukturen. De har bare et VPC. Kjør appen din, så de slipper bilder unna. Så det er liksom pro cons, men ja, det har vært diskutert en del. Og så har vel dere flere organisasjoner sammen i Oslo kommune? De etatene som er litt mer separate enn vi, f.eks. Nav er i mye større grad én organisasjon. Og dere er vel også litt mer på utsiden av de etatene?

16:33 --> 17:22

Ja, vi er jo en etat, vi. Og vi er jo på utsiden. Og oppbygningen av Oslo kommune er kompleks. Det er den. Samtidig så ... Origo sitt oppsett, det er for Origos team. I hvert fall enn så lenge. Vi snakka før vi kom inn her at det er en annen etat som heter Uke. Utviklings- og kompetanseetaten. De også kjører systemer, men de kjører det på en annen måte. Og de kjører heller ikke i AVS, de kjører i Asher. Så har man Bymiljøetaten, som også kjører sine systemer, som er ... Proffe på sine områder. De kjører på AVS. Litt sånn som oss. Der kan vi dele litt erfaringer. Men det er komplekst og mye forskjellig i Oslo kommune.

17:22 --> 18:02

Jeg husker da jeg jobba i Telenor, så måtte vi skrive om et kjempestort system bare for at Oslo kommune skulle bli kunde. Strukturen var så komplisert at vi måtte misbruke Solar på måter ingen har misbrukt Solar på, verken før eller siden. For å klare å regne ut tilgangskontrollen på abonnementet til Oslo kommune. Enig i analysene om at det er stort og komplekst. Ja, det er det. Så ... Ja. Nei, ja, det er stort og komplekst. Hvor mange er det som jobber med rene plattformtjenester? Eller kjøretidsmiljø, var det det? Ja, plattformteamet kaller vi for "Team Kjøremiljø".

18:02 --> 19:03

Så vi er syv stykker. Så har vi TeamLead og så har vi TechLead. Og så har vi noe som kanskje ikke så mange andre har, og det er UX Designer. Kult. Jeg tror ikke det er så mange ... Vil du fortelle litt mer om rasjonalen bak det? Hvilken font man leser Terraformen i, sikkert? Så designer ... Vi har jo på en måte en litt sånn produktutviklingstilnærming til plattformen. Så vi prøver egentlig å utvikle infrastrukturproduktet som vi har, likt som alle andre produkter som er ut mot ... Som er ut mot innbygger. Så vi bruker designer for å få innsikt og ha brukerintervjuer. Det er også veldig fint at vi teknikere, hvis vi spør en utvikler, så kan det hende vi får et helt annet svar enn hvis en designer går og spør.

19:03 --> 19:54

De kan være mer åpne med en designer enn de er med en utvikler. Fra utvikler til utvikler. Så vi får utrolig mye innsikt gjennom det. Og jeg tror det egentlig er ... Jeg tror personlig det kan være nøkkelen til å finne noe av det beste innenfor infrastrukturløsninger. Er det jo litt kult, for vi driver med målstyring inni utviklingsopplevelser, som kjøremiljø er en del av. Vi jobber med OKR-er og mål, og det hårede målet vårt er at det skal jo være digg å jobbe med infrastruktur, selv om du er applikasjonsutvikler. Det skal i hvert fall være godt overkommelig. Hvordan måler dere "digg"?

19:54 --> 20:40

Vi kan ha f.eks. en oppgavebasert brukertest hvor vi prøver å få i en oppgave til en utvikler: Prøv å sette opp dette. Så ser vi på sånn... På svarene vi får: Hvor lett var det? Er det masse som er vanskelig? Hvor høy kognitiv last? Så litt mer kvalitativ måling enn kvantitativ? Det har jeg ikke hørt om så mange andre som gjør det, men det er vanligere på normalutvikling. Men det er jo infrastruktur å jobbe så dev-hop som vi gjør. Det er jo nytt for mange. Men vi håper liksom at vi får med nok folk til at de syns det er gøy, Og får man til mestring og vekst,

20:40 --> 21:33

så er det jo en veldig viktig faglig økning i skyinfrastruktur og infrastruktur generelt. Det er jo veldig viktig erfaring å ha med seg. Så det å bli god på det og få litt mestring på det, tror jeg er veldig verdifullt for en CV også i dag. Men jeg tror at hvis dette skal fungere bra, så må det være godt samarbeid mellom plattformteamet og applikasjonsteamene. Vil du gå litt i det? Hvordan har dere dialog og kommunikasjon med applikasjonsteamene? Ja, det er vel egentlig kanskje annerledes. Jeg kan jo si litt på det. Vi nevnte jo kosekrokene. Nye team som kommer opp får veldig dedikert tid hos kjøremiljø. Sånn at man jobber i tospann og alt sånn. Vi prøver også å rigge oss sånn at når det trengs, så er kjøremiljøet eller meg

21:33 --> 22:19

eller en annen arkitekt på plass for å kunne være sparring. Det er veldig viktig det med hjelpekulturen for å ta ned frykt. Så fort du gjør et eller annet som er litt utafor komfortsona, så be om hjelp. Du skal ikke være redd for å be om hjelp, og du skal også få hjelp veldig raskt uten å bli blokkert på tid. Jeg har eksempel på det i går, hvor et av teamene våre skulle oppgradere produksjonsdatabasen sin, som var en helt ufarlig greie, og så plutselig så får du en sånn rar, en melding i terraform som bare "ok, jeg gjorde helt rette", bare tar henda bort fra tastaturet og tenker litt, tar kontakt med oss, vi sparrer litt på det. Det første vi gjør i dag tidlig, er å se på det sammen,

22:19 --> 23:20

og så få løst de problemene. For det er viktig at det skal være både det med kognitiv last, men også en trygghet og mestring i dette. Er det ofte at utviklerne får feilmeldinger i terraform, så må de gå til deg eller teamet ditt? Det er nok ikke så ofte, i hvert fall ikke på standardoppsettet. Men jeg kan jo egentlig, som du spurte om i stad, sånn hvordan kommer det et nytt team og bruker infrastrukturen som vi setter opp. Eller sammen, da. Så har vi en sånn golden path, som vi kaller det. Og det består av en nettside som ligger på km.oslo.systems, hvor det er guider og sett opp. Og alt mulig sånn. Så når vi da har kontakt med et nytt team, så avtaler vi møter. Og går gjennom dem sammen med alt det innholdet er, og tar alle spørsmål.

23:20 --> 24:18

Så tar vi det inn til oss, og så prøver vi å hele tiden forbedre ting etter hvert som vi fanger det opp. Og så har vi med da designer, som hele tiden har "se på hva vi driver med", med designerøyne. Som er noe helt andre øyne enn utviklerøyne. Så ... Det kom utrolig mye bra der. Og så har vi felles chatrom på Slack, hvor det er veldig lav terskel for å stille spørsmål, som Endre nevnte. Det tror jeg har vært en fellesnevner for alle vi har snakket med så langt i podkasten. At det å ha kort vei mellom de som jobber med plattform og applikasjonsteamene, er kjempeviktig. Og nøkkelen der. Den gode kommunikasjonen. Og det at dere har Kosekroken ... At dere har sånne Fora hvor dere kan samles og hvor de kan få hjelp, rett og slett. Ja. Også noe som vi kaller for superbrukerforum. Hvor ofte er det?

24:18 --> 25:03

Sjette uke, eller? Hvor vi har superbrukerne, eller de som er mest engasjert innenfor infrastruktur. Vi diskuterer litt forskjellige temaer. Hører på ønsker og tilbakemeldinger. Og at teamene også kan dele mellom seg, sånn at det ikke bare er Fra oss til dem, men ... Så snakka vi litt om når vi forberedte dette i går, at etter at vi har gått over til Managed-tjenestene, så har det vært ganske stille hos oss. Det er et eller annet med at lastebalansereren i AVS er stabil og god. Når du har satt opp de reglene og det sertifikatet som hører til, og DNS som peker på det, så gjør du ikke så mye mer. Det samme med en database.

25:03 --> 25:45

Hvis du ikke pusher absolutt det som er av limits, så surrer og går den, og den minor-patcher seg selv, og det er ikke så mye å gjøre. Så til det daglige, når man har fått ting opp og går i en konto, så er det mest det å rulle applikasjoner forover og bakover, som er det man gjør. Så du er egentlig fornøyd med det endringsvalget du tok? Det eneste jeg syns er litt dumt, er at navnet på den forrige plata, OK som et celi, syns jeg var veldig gøy. Det har vi. Ja, vi har et OKCLE. Det er het OKCTL før, nå heter det OKCLI. Jeg tror dere skrev alle eksemplene var OK i dag.

25:45 --> 26:31

Det heter OK nå, skjønner du. Teamene, eksempelvis, skal ta opp en database i dag. Så sier de: "OK. Get template. RDS Aurora." Burde ikke vært OK computer egentlig. Bare ekstrakommando for å ... Men dere er fornøyd med overgangen? Fra Kubernetes til Lasty Container Service? Ja, for vi var i en vond situasjon med OKCTL og Kubernetes. Fordi ... Ja, det var jo før Kubernetes også hadde stabilisert seg. Det var beta her og beta der, og det var veldig nye versjoner som kom hele tiden. Og du måtte oppgradere, og det var pakketert inn i det OKCTL-verktøyet.

26:32 --> 27:12

Som gjorde at når det funka, var det veldig bra. Og når det ikke funka, så var det utfordrende. Og det ble liksom ... Kjøremiljøet måtte være frampå og legge inn alt av ting som skulle på plass for å kunne oppgradere hele stacken som var den gangen. Og etter vi kom bort fra det og fikk på en måte forenkla og mer manage tjeneste, så er det lavere skuldre, ja. Så vi er fornøyd med den. Det høres ut for meg at dere gjør veldig mye riktig her med å gå over til mer manage tjenester, og at det har ført til stabilitet og en god opplevelse for teamene.

27:12 --> 28:08

Men det kan jo ikke alltid være så blå himmel og at alt går på skinner hele tiden. Kan ikke dere fortelle om en gang det gikk feil i plattformen, og litt om hvordan dere håndterte det? Og ikke minst: Hva lærte dere av den episoden? Nei, hva skal jeg si. Nå er det jo ingen verden som er perfekt, så det er jo tradeoffs på vår plattform også. Litt om hva som har gått feil. Vi har ikke de store trafikkmonstrene og sånt ennå. Men det vi sliter med i Origo, det er at vi er en del av ofte en større enhet. Så vi jobber bl.a. med systemet mot den storbylegevakta nå. Da har du Origos systemer, skal spille sammen med noen systemer som er satt opp i Utviklings- og kompetanseetaten,

28:08 --> 28:52

og som gjerne kjører inn i datasenteret hos Sopra Steria. Og det er mange biter som skal spille sammen. Så vi har jo opplevd, plutselig så virker ikke ting. Ingen har gjort noe som helst, og ingen tør å innrømme at noen har gjort noe som helst. Og det er veldig vanskelig å feilsøke. For noen må ha gjort noe en eller annen gang? Noen har nok gjort et eller annet, og så plutselig virker det igjen. Og da er vi på en måte ... Jeg har snakka med de teamene og sagt at det er veldig viktig å høste erfaring før det blir fullt trøkk på legevakta. Hva er symptomer, og hva var løsningen? Sånn at vi har læring på det, og drar med oss, for det er så mange biter som kan feile her.

28:52 --> 29:45

Vi har jo også opplevd, du spurte om en konkret feil, det at vi hadde ... Vi hadde helsedata som skulle rutes ett sted, som har blitt mappa feil og ble ruta i en eller annen testbase midlertidig, som vi heldigvis fant veldig raskt. Men igjen, det er fordi det er mange systemer og mange parter som er involvert her da. Jeg tror alle som lytter på podkasten kan kjenne seg igjen det at det er store komplekse og ikke minst distribuerte systemer vi jobber med, og det er mange aktører som ofte er inne. Jeg syns også vi en gang skal lage en spesialepisode der vi bare forteller om feil som har skjedd med prodata i dev-systemer. Men Anders, hva er det neste som skal skje i plattformen? Det som vi holder på med akkurat nå, er egentlig å forbedre observability.

29:45 --> 30:34

Vi har satt opp opprinnelig, sa vi, å bruke mest Cloudwatch, som ikke er kjent for å være det aller beste systemet. Så nå holder vi på med det. Og få satt opp ordentlig Grafana og Matrix. Så tar vi det først, og så tenker vi at vi fortsetter kanskje med tracing og bedre loggsøk, da. Men det er jo veldig fint om man får det man vil ha med Matrix og Tracing før logging, så vi tar det først, da. Og uansett så har vi det i Cloudwatch. Så driver vi og vurderer litt om vi skal gå for Prometheus eller Cloudwatch Metrics eller ... Så er det litt kostnad med det, og det er ganske dyrt å ha Matrix i AWS. Men mye av det, dere ser fortsatt på Holstad der, ikke sant?

30:34 --> 31:22

Ja, da kan man jo velge å bruke ... For Amazon har det de kaller for Managed Service, og da er det på en måte at de manager en open source-løsning for deg. Bare skriver om hånden din litt noen ganger, husker jeg. Open search, eller? Ja, og Istio! Som var veldig mye utstyr på. Så de har da Amazon manage Prometheus, og de har Amazon managed Grafana, som du kan sette opp for å komme raskt i gang, da. Og så tenker jeg at det blir litt vurderinger på om vi skal kjøre det selv, eller hva vi gjør. Så tanken er jo at det skal bli veldig lett å se hva som skjer med de kjørende applikasjonene.

31:22 --> 32:09

Og gjerne også litt sånn bruksdata også, da. Du ser hvilke handlinger som foretas, og ikke bare CPU og minne, liksom. Det ser faktisk konsekvens ut i verden. Kan jo også nevne, vi driver akkurat nå og jobber med en ny iterasjon på ROS-vurdering, da løsningen, hvor man bare må ta ROSA fra AVS på organisasjonsnivå, og så på den brolagte stien og de komponenter og oppsett på. Kjøremiljø. Og at teamene etterpå kan rose, basert på den igjen. Jo nærmere du ligger den brolagte stien, jo lettere blir ROS-jobben din i ditt team. Risiko- og sårbarhetsanalyse. De er nok gode på det her i Nav òg.

32:09 --> 32:56

Absolutt. Jeg har sjelden en dag hvor ikke ROS og/eller PVK nevnes, vil jeg si. Også i dag. Og så jobber vi fortsatt i sluttfasen av den nye AWC01 som vi snakka om. Legge til rette så alle som har lyst i Sandbox-konto, kan sette opp en komplett infrastruktur og ta det ned igjen, som å øve og få ... Tusen takk for at dere tok dere tid til å snakke med oss i dag. Anders Pettersen og Endre Mekkelborg fra Oslo Origo. Audun, nå er jeg spent. Hva er dine highlights fra ...? For det første er jeg veldig glad for at de har beholdt OK og selvlige, for det har jeg fortalt om mange allerede, og liker godt navngivning på det. Men det jeg syns det var morsomst å høre om, var jo brukerfokuset.

32:56 --> 33:39

Og det å ha en UX-designer med i plattformteamet, og hvor bra det funker. Det tror jeg mange kan lære av å gjøre likt. Hva med deg, Hans Isand? Jeg syns det er forfriskende å høre om noen som ikke har valgt Kubernetes. Jeg er jo veldig fan av Kubernetes, men det betyr jo ikke at det er det eneste rette for alt og alle. Høre hvor bra det fungerer med AWS og de tjenestene der. Det var høydepunktet mitt. Og med det runder vi av denne episoden av Plattformpodden med Hans Kristian Flåtten og Audun Fauchald Strand. Teknisk produsent er vår eminente Tore Græsdal. Takk for nå.

33:40 --> 33:48

Ha det bra! Takk for påsynet! Takk for følget!