Episoden er transkribert av kunstig intelligens, feil vil forekomme.

00:00 --> 01:09

Hei, og velkommen til Plattformpodden. Hei, og velkommen til Plattformpodden. En podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg har jeg Audun Faukastrand. Men dette er ikke en vanlig episode. I dag har vi med oss 100 år samlet erfaring med bruk av applikasjonsplattformer. Nemlig de to prinsipalene Johannes Brodvald og Truls Jørgensen. Kanskje vi en gang for alle får vite hva en prinsipal egentlig gjør. Men Johannes, hvis vi begynner med deg. Hvis du skulle skrevet en bok, hva ville den handlet om? Det ville handlet om hvordan å kode. God kode var deilig kode, deilig koding ... Jeg er glad i kode. Truls, hva med deg? Jeg har skrevet en liten minibok. Om hva som kjennetegner bra team i bra flyt, og hvordan ... I bra flyt, og hvordan man får til at team går i mer eller mindre samme retning,

01:09 --> 02:31

og samtidig opplever en form for autonomi. Jeg tror nok det ville vært ... Hvis jeg skulle skrevet en større bok, så ville jeg nok hatt det. Men i dag skal vi jo mest snakke om plattformer, og hvordan bruke plattformer er jo tanken. Og Johannes, hva tenker du er de viktigste tingene du, som en som liker å kode, serier trenger av en god plattform? Helst jo mindre jeg ser plattformen, desto gladere blir jeg! Når jeg koder og sjekker inn koden jeg har, skal den skli ut til miljøene som kjører på. Og der er jo egentlig samspillet mellom GitLab, for mitt velkomne, eller kildekodeverktøyet, byggverktøyet og plattformen det skal kjøre på, det er kanskje det aller viktigste. Så fra jeg har gjort en kjempebra endring, som brukerne mine vil bli skikkelig glad av. Vakker endring! Poesi! Så er det minst mulig friksjon, før jeg da får oppleve den skuffelsen brukeren gir meg, når de ikke er like begeistret for endringen som det jeg var. Det at du ikke ser den, er kanskje bra på happy path, men når det skjer noe, så vil du kunne se noe? Ja, det er kanskje en av de tingene som jeg får til.

02:32 --> 03:44

Og som jeg opplever med en god plattform, og som gjør livet mitt bedre, det er jo når vi har god mulighet til å jobbe med loggene. Så jeg er ikke komfortabel med Grafana, men jeg er veldig komfortabel med Kibana. Og for det første å sørge for at jeg kan produsere logger som jeg kan indeksere, eller egentlig søke gjennom, etter det jeg trenger å gjøre, og at jeg får tilgang til de loggene når jeg trenger dem, det er kanskje det aller viktigste. Sånn at jeg kan se hva som er problemene med systemet. Der er det også et fint grensesnett hvor jeg må gjøre noe på min side for å få mest mulig ut av plattformen. Hvis jeg skriver tull til loggene, eller data som ikke burde vært logget fordi den er for sensitiv, så blir det jo ikke bra. Så det er jo mitt ansvar, men så er det da det at plattformen, fra jeg skriver til SystemOut, til jeg kan lage et godt query i Kibana, til jeg kan søke etter akkurat hva som gikk av, hva som gikk galt her, at det har så lite friksjon som mulig der. Jeg har litt lyst til å be deg gå i skammekroken og tenke på hvor mye ekstra CPU du bruker på det, kontra å lage en telling i Grafana som bare teller ...

03:44 --> 05:07

Der hvor jeg våkner, er ofte når det er trøbbel og vi ikke vet hva som skjer. Så det er ikke tellingene. Tellingene er også viktig, men det er jo det der med hva i all verden som skjedde nå, og så kunne grave ned i det på et saklig vis. Du får jo bøttevis med logger i et noenlunde greit belastesystem. Men som en bruker av plattformen, hva foretrekker du av configuration over conventions? At sånn er det bare, by default, ellers at det må eksplisitt inn og slå på ting? Ofte føler jeg at man bygger systemet med litt for mye konfigurerbarhet i systemet. Når jeg bygger systemet, hva er det jeg trenger at miljøet rundt meg forteller, og hva kan jeg utlede selv? Så jeg trenger å vite at denne tjenesten her skal jeg gå mot en testversjon, her skal jeg gå mot en prodversjon, jeg skal bruke denne secreten, altså passordet, for å aksessere tjenesten i andre enden. Men da reglene som sier hvilken tjeneste skal brukes når ... Noen ganger kan man se for seg at du skrur sammen applikasjonen som en del av konfigurasjonen. Det vil jeg heller skru sammen med kode.

05:07 --> 06:17

Men det jeg veldig gjerne vil ha, og det jeg er veldig glad for der vi er nå, er at i plattformen, når jeg kommer inn i et namespace, og da deployer min tjeneste inn i et namespace, så har jeg config maps i det, så jeg har da konfigurasjon og ting som kan komme inn som environment-variable, som forteller meg hvor jeg er og hva som er rundt meg. Plattformen legger opp gode konvensjoner, sånn at jeg vet hvor jeg skal finne ut hvilket miljø jeg kjører på, hvilken cluster jeg kjører på, hvilket hostname jeg har, hvilken Active Directory-server jeg skal integrere med. At det ligger som en konvensjon i plattformen, det gjør jo jobben min mye enklere. Det er litt sånn Heroku, twelve factor apps? Ja, veldig. Jo, jeg trodde jeg kunne twelve factor apps for tolv år siden! Det er to av de elementene, at du får inn konfigurasjonen som environment-variable, og så gjør jeg det jeg trenger etter de environment-variablene. Da trenger jeg ikke noe mer enn kode. Så skriver jeg ut loggene mine til system-out, og så fanger plattformen det opp.

06:17 --> 07:38

Så det er jo to av de tolv faktorene. Du har jobba på begge sider av dette, du har lagd plattform og lagd obligasjoner. Hvordan gjør det deg ... Tenker du annerledes om bruken av plattform fordi du vet så mye mer om andre sider? Jeg tror kanskje det. Jeg er veldig takknemlig over å bruke en plattform, for jeg vet hvor mye jobb som ligger bak. I og med at jeg har vært med på å lage forløperen til Nice, så kjenner jeg også veldig godt ... Jonny som han var her, har vært her før, og kranglet mye med han. Det irriterende med Jonny, er at han har som regel rett. Hvorfor må du ikke si sånt på podkasten?! Men da elsker vi iallfall ... Vi var i fjor, det er her hvor vi prøvde å ... Vi prøvde å få ... Snakke med Nice-teamet om hvilke oppgaver man bør løse i Nav. Og Jonny har bestemt seg for at det som er det riktige for Nice nå, det er å lage en web-app som heter Konsoll.

07:38 --> 08:55

Og jeg er bare sånn: Det er det dummeste jeg har hørt! Utviklere kan da bruke terminal, inspisere og logge inn og sånn. Jonny var sånn: Jeg er høy i det du sier, men jeg kommer nok til å gjøre det likevel. Det har vist seg å være et helt fantastisk verktøy. Når du spør hva som er bra med en plattform, så kan du både se på en enkel måte hvordan det står til med appen din, men også hvor mye minner som bruker du, og hvor mye har du faktisk over. Overallokert, som jo ofte er betydelig i en kronerettskonting. Og den konsollappen bygges liksom ut og blir bare mer og mer verdifull. Det syns jeg er gøy. Litt sånn Conyas? Ja, ja, ja. Yes. Har jeg på en måte vært en ... Ja, jeg var med og laget det som var starten. Hva sto Aura for? Automatisk utrulling av applikasjoner automatisert. Det her lagde vi bare en kul ...

08:55 --> 10:09

R-en er da "utrulling", ikke sant? Det er språklig utrulling, er det ikke det? Det var ikke så veldig bra navn på den. Det var ikke så mange som brød seg på den tiden, heller om det matcha. Det var automatisk utrulling av applikasjoner, tror jeg. Ja, så det startet bare som en Maven-plug-in for Deploy, og så ble det laget en database som holdt miljøkontrigg, og så var det en webapp som het Basta, som sørget for selvbetjening av produksjoneringen. Og det her var jo, for sin tid, tenker jeg det var ganske bra, men det som var ... Det var litt flaks. Det dikterte jo at hver applikasjon som var på denne plattformen, måtte ha et skille mellom miljøkonfig og applikasjonskonfig. Sånn at alle applikasjoner forholdt seg kun til miljøting med hjelp av aliaser. Så da vi bytta plattform til inkluderende tidsplattform,

10:09 --> 11:20

var overgangen ikke så dramatisk. Hva er applikasjonskonfig i den sammenhengen? Føler jeg bare å ha miljøkonfig i det jeg lager? Ja, så miljøkonfig peker vi egentlig på ved hjelp av variabler. Sånn, ja ... Konfig innenfor dev og konfig innenfor prod. Det er det som overstyres, at navnet er det samme, men litt mindre ueiende? Du så fasit, da. Den applikasjonen hadde en alias. For det miljøet betyr det denne URL-en. Litt som DNS. Ja, på en måte var det det. Og så ved deploy blir da applikasjonskonfiguren, dette er aliaset, matchet med den reelle miljøkonfiguren. Og så blir da mercha inn, så i deploy så stemmer det. I NAV på den tida var det ca. 100 000 millioner testmiljøer. Røftlig. Hvor mange stjerner er det i Melkeveien? Jeg tror det var T1 til T10 eller noe sånt.

11:20 --> 12:26

Og T2. Ja ... Men ... Jeg har jo lagd plattform mange ganger, og en av grunnene til at jeg liker å lage plattform, er at brukerne er relativt uniforme. At det går an å skjønne det, fordi det er ganske likt. Det er de samme verktøyene man bruker når man lager plattform, som når man lager applikasjoner, f.eks. Men jeg har ... Jeg lurer litt på hvordan det ser ut fra andre side, er det problematisk å bruke en plattform når man vet så mye om hvordan det er lagd, at man egentlig kan gjøre det sjæl? Det må kanskje være frustrerende å bruke en plattform fordi man tenker: Dette kunne jeg egentlig lagd bedre og tilpassa meg selv bedre. Min app og mine er enda bedre. Det er egentlig aldri det jeg er kjent på. Jeg tenker at det har vært en sånn ... Da jeg sluttet å jobbe med plattformer, så var jo det fordi jeg tenkte at det var viktig å ...

12:26 --> 13:40

Få applikasjoner på denne motorveien som den plattformen var. Så det har heller vært å se hvordan vi kan lage applikasjoner som funker, og hvordan kan dette samarbeidet bli best mulig? Hvis du tenker på litt lengre sikt, så var det jo sånn at før vi hadde Kubernettes, så hadde vi gjerne Versal Machines, og så hadde vi en velkommen "puppet" konkurrasjon, som drev og mikka med dem, og da var det ofte mye sånn derre ... Puppet var kalt "puppet" av en grunn, det var altså fjernsyn i de maskinene. Det var mye koding i det, og mye som kunne gå gærent, og før det hadde vi gjerne disse applikasjonsserverne. Jeg har måttet jobbe med både Websphere og EblorJC. En ærefil rolle på mattestrukturer! Det vi hadde i de gamle plattformene, var at de kom med ganske mye mere. De kom med et verktøysett hvor de skulle løse en del problemer for deg, som var problemer vi kanskje ikke hadde. For ti år siden lagde vi den ER-en. Applikasjonspakken vår, så liten som mulig. Den kjører på en server med masse ting.

13:40 --> 14:41

Så hadde vi da den VM-generasjonen hvor du sier at: "Ja, nei, vi deployer jo noen script som har serveren mer rundt seg." "Og så har vi kanskje et service script som starter og stopper vår service, osv." Du jobbet jo noen gang med VMW-orchestrator? Nei, det gjør jeg ikke! For det er Broadcom-orchestratoren. Det jeg pakker som applikasjonsutvikler, inkluderer operativsystemet, serveren, hele greia. Så jeg har mye kontroll over det som går inn i mitt dokker-image. Plattformen gir meg veldig mye frihet, hvis du vet hvordan du bruker den. Hvis jeg har en plattform hvor jeg kan deploye et dokker-image, så har jeg all den friheten jeg trenger. Jeg har i hvert fall opplevd at noen utviklere har veldig lyst på å styre akkurat dette eller dette, og så er det bra for den store butikken at dette er likt.

14:41 --> 15:45

Database, f.eks., kan jo være litt sånn. Så vi er jo ... Jeg er veldig glad i Potts GSQL som database, og det er ikke sikkert at alle organisasjoner har standardisert på den ene databasen. Så det å kjøre en database på Litely, det forutsetter at du har gode rutiner for backup, og det er to ting som er viktig. Det er at du får tak i backupen når du trenger den, og at ingen andre får tak i backupen når du ikke skal ha den. Og det er overraskende vanskelig å løse. Det er litt motstillende, liksom. Som er noe det er lett og vanskelig å få tak i samtidig. Nettopp. Og der er det jo da at da du skal liksom si: Ja, nå vil jeg ha den nye databasen, f.eks. Det er klart at da er det noen som må gjøre en jobb som må gjøres godt, for at det skal bli bra. Så det som er utenfor applikasjonen der er jo avhengig av en god plattform, men der er det jo også mange oppgaver som rundt basistjenester som databaser og Kafka, og også nettverk og ...

15:45 --> 17:00

Det er en god del ting som jeg er glad for å slippe å forholde meg til, men som jeg må være ydmyk på, at et plattformteam har begrenset med kapasitet til å gjøre alt akkurat som smeger vi alle. Men er det ikke noe som var bedre før, altså? Ikke noe du skulle ønske du, eller dere, hadde mer tilgang til, eller kunne styre mer, eller ... Alt er bare kjempegodt. Mange tenker at vi er gamle, silrige farts, som vi egentlig er veldig positive ved. Nesten tvert imot. Jeg er formann i ... Queer Insights vennegruppe, som jeg kaller det for. Det er en stor fordel med det å ta i bruk skybaserte plattformer, som jeg tror kanskje har vært litt underkommunisert. I hvert fall er det min erfaring. Man snakker ofte om at man flytter til en sky pga. enten økonomi eller sikkerhet. Men det er også slik at disse store skytilbyderne konkurrerer jo ... La oss få påskedress, da. Så tilbyr alle påskedress. Men det de da konkurrerer på, er jo verktøy og tjenester oppå der.

17:00 --> 18:22

Og Curry Insights er et fantastisk verktøy som Google gir bort til alle ... Ikke gir bort, men altså ...! For en utvikler så er det plutselig et verktøy som plutselig biter lenger. Det har en ekstremt demokratiserende effekt på hele arbeidet rundt databaser. Hvor man før var avhengig av en DBA som gjorde spørringer for deg, så er dette nå verktøy som alle utviklere får, og alle utviklere kan da se på en inquiry, og her mangler det en indeks, legge på den. Og det gjør jo at man får et mer bevisst forhold til databasen sin, og også hva det koster, og hvordan man kan få ytelsene opp og kostnadene ned. Det passer jo til spørsmålet, for føler vi at vi har ... Det er naturlig at vi har nok kontroll, og det er vel det som du har sagt, Truls, at med plattformer som beveger seg, får vi stadig mer kontroll, og vi ser verdien av det. Men kanskje vi på plattformsida av bordet hadde blitt stormannsgale, den idéen at plattformen skal høyere og høyere, og vi skal godt over serverless, liksom. Dere skal så vidt få lov å putte inn litt Javascript og litt farger på toppen, men alt annet er service. Det er vel å gå for langt?

18:22 --> 19:37

Som sagt, jeg vil jo helst ha en docken-image som jeg kan ha full kontroll på. Så jeg vil ha base-imaget mitt, og jeg vil putte all min programvare på det base-imaget. Så jeg har jo ganske mye kontroll her, så ikke ta fra meg det òg! Alle verktøyene, ekstra ting og tang. Nei, jeg tenker det er en trade-off der. For vi hadde en liten diskusjon før vi kom inn her også, rundt deformant-jammel versus en mer nedstrippa en også. Det er plutselig minuser? Ja, altså det er jo ... Jeg har både forsøkt å lære meg kybernettet, så jeg syns jeg blir ganske flink, og så har jeg forsøkt å lære alle nivåer av ting til studenter også. Jeg er jo lærer én dag i uka nok, så jeg kommer fra giss-forelesning i fjor. Men der er det jo ... Når man har en litt sånn ... For opinionated, kanskje abstraksjonslag oppå grunnteknologi, så er det ofte gjort med tanke på at det skal være lettere å lære, og så blir det ofte vanskeligere å lære allikevel. Det er et godt eksempel at når jeg hører på andre episoder av Plattformpodkasten,

19:37 --> 20:55

så snakker man om med litt sånn abstrakte timer at man har en sånn type nizerator, eller en sånn type greier, og så vet jeg ikke helt hva det er, for jeg har ikke det hos meg, og så føler jeg at det jeg da slipper i gåseøyne, er å skremme, er å skrive en deployment yamble fil, altså beskrive deploymenten. Og så ser jeg på min deployment yamble fil, så hver eneste linje der har jeg en grunn til at er der. Og hver eneste linje der er en del av den kontrollen som jeg ønsker å ha ved mitt system, så jeg skjønner ikke hvordan det kan bli enklere, og hvordan det kan bli mindre. Men jeg kan jo forstå at ikke alle utvikler sånn: Hva er forskjellen på pod security context og container security context i min deployment yamble? Men her er en hottaik som var på trykk i kode 24 ... Jeg mistenker at mange velger Kubernetes for raskt og utkritisk? Jeg har hørt det før, men jeg aner ikke. Hvis jeg får docker-imaget mitt ... Og jeg kan få se loggen, så er jeg fornøyd, jeg. Jeg har fått Kubernetes-plattformen hvor jeg får lov å gjøre det, og da er jeg fornøyd med det. Hvis da det er noe annet som er billigere for dere å drifte, så vær så god.

20:55 --> 22:21

Jeg har en veldig god kompis som nok ville vært enig i det utsagnet, som er ... Men jeg tenker jo at dette er jo for noen virksomheter, sånn som Nav, så gir det absolutt masse mening. Fordi et av designene her er jo at vi ... Vi lever litt on pram, og så lever vi litt i en sky. Og det er en transisjon som kommer til å vare lenge. Og hvordan kan vi klare å gjøre det? Da er dette laget imellom verdifullt. Og det er også slik at vi har mulighet til å bytte framtidig skylevendør også. Det er også en stor verdi. Så jeg tenker for inningsvesenet ... For inningsvesenet Nav gir Kubernetes massiverdi, men er du en liten startup med to-tre utviklere og veldig begrensede midler, så er kanskje ikke Kubernetes det første du bør sette opp. Mitt perspektiv er jo fra en sånn ... leker meg rundt med ting å gjøre. Så jeg har kjørt noen Kind Kubernetes-plasser. Moderne, hva var det det het, Minicube. Hvor du da kjører Kind der Kubernetes sin docker, og det er det morsomt. Og det er det i Morsomflordal: Dokker ikke Kubernetes i dokker.

22:21 --> 23:29

Dukker inn dokker. Kjenner du hele det i en VM på maskina di i tillegg? Ja, vi gjør jo det på Bugledos-maskinen. Her kommer fordommene fram igjen! Men det for meg å sette opp en Kind cluster, den lille, enkle Kubernetes, det er jo kjempelett. Å spinne opp en dokkercontainer som kjører på min arbeidsstasjon og har alt jeg trenger der. Jeg kan også deploye en operator for å lage databaser automatisk og sikkert mye annet FSB også. Så for meg så skjønner jeg ikke helt hvorfor Kubernetes er så komplisert eller dyrt, men jeg regner med at dere som sitter og skal gjøre det på ordentlig, har et annet perspektiv enn det jeg har, så jeg må bare stole på det dere sier. Så du er liksom fan av å ha Kubernetes lokalt når du utvikler og kjører det opp? Spør litt på hva jeg gjør, men jeg kjører også opplæring ikke bare på høgskolen Kristiania hvor jeg underviser, men også for Soprasteria. Når vi kjører vårt lille Devops Academy, så skal vi prøve å sette opp et cluster.

23:29 --> 24:34

Da prøver jeg å få forståelse selv for hva som er basisen for det folk skal kjøre på. Da må jeg komme dypere ned enn de gjør, og da vil jeg gjerne sette opp et cluster som jeg har kjørende lokalt. Og så bruker vi ikke det clusteret på min arbeidsstasjon. Jeg lærer ikke folk å bruke clusteret på sin arbeidsstasjon. Men da får jeg en idé om hvordan dette funker med Operators. Dette er på ingen måte overraskende, Johannes. Jeg mistenker at de kanskje ikke er så representative som de kan være. Dette er mange år siden. Vi møttes også en felles kunde, da jeg også jobbet som konsulent. Og du gjorde det du kalte "beardnøkkelt soa". Ja! Det er mange år siden nå. Men det at du skal forstå ting skikkelig godt, det er in character. Hvis du prøver å lære bort Kuberneteske relativt ... Folk er det interessant å høre hva de syns om det. Jeg hadde jobba ca. ti år. Med backhand-utvikling i hovedsak. Aldri i fronten. Fikk ikke lov.

24:34 --> 25:45

Av god grunn. Jeg tenkte jeg brukte ti år med bitterhet over ting som ikke funka i Prod., til å begynne å lage plattform. Jeg kunne intuitivt skjønne hva som var bra og dårlig med plattformen, fordi jeg hadde hatt apper i Prod. Men hvordan reagerer nyutdanna på den type ting? Er den tilgjengelig for dem? Jeg opplever at Kubernetes-plattformen er ganske tilgjengelig. Vi har kjørt det mest i disse DevOps-akademiene. Hvor vi da har hatt folk med bakgrunn som ikke nødvendigvis er utviklerbakgrunn også. Både driftsbakgrunn, men også noen prosjektlederbakgrunn. Og da i løpet av den workshopen som vi kjører der, er det at vi har et lite prosjekt. Det er for å unngå applikasjonsteknologi, så er det basert på en React Fronten-applikasjon. De får et repostorhus som de skal klone ut av det. Det inneholder også templates for Kubernetes-konfigurasjon. Så har vi en GitLab-instans,

25:45 --> 26:52

hvor de får instruksjoner for hvordan de får satt opp en CUBCTL-token for å deploye det inn i et cluster. Og så har vi satt opp nok DNS-regler. Ingresskontroller i det clusteret til at de kan se sin tjenestekjede her. Det er da folk som ikke nødvendigvis har programmeringsbakgrunn og ikke nødvendigvis har noen driftsbakgrunn. Forklart riktig så er da modellen med namespaces, med deployments, med docker images, med BIL-pipelines, ting som de fleste kan forstå ganske enkelt i dag. Det er ikke sant. Jeg har lyst til å si en annen ting rundt det å bruke plattformer også, som jeg kom på da jeg så på deg. Husker du da du bestemte deg for å lage fronten-plattform? For det er på en måte også en plattform. Det er også et påbygg oppå nice-en, på en måte, som har enda mer opinions, og da gjør det enda enklere å komme i gang. Er det en type designsystem og komponentbibliotek?

26:52 --> 28:06

Det har vi jo allerede. Jeg vet ikke om du har vært borti Vercella ... Hvor de bare kjører ut og front-end-applikasjoner er en first class citizen. Det viste seg at det var vanskeligere å finne de abstraksjonene der. Men at det er noe ... Kubernetes er jo veldig back-end-tungt. Ta et eksempel. Utrulling i Kubernetes, så har du det som er en progressiv utrulling. Du har noen av de gamle podene dine kjørende, og så har du noen av de nye. I en moderne web-frontend-applikasjon, så får gjerne CSS-en og javascripten en hash, hvor dette er lettere å cashe. Og den inneholder jo bare det den var bygget med. Så de gamle har de gamle hashene og de gamle css-ene, de nye har det nye. Så når du er i browseren din og skal laste applikasjonen idet du ruller ut, så får du gjerne nye HTML-er med referanser til nye sums. Og så henter du en fra den gamle, og 4:04, og du får en hvit skjerm ... Så den åpenbaringen ... For jeg er også gammel back-end-utvikler.

28:06 --> 29:17

At "oi, dette må vi jo for all del finne en bedre ..." Prøv en sånn "Kan du ikke bare", da. Gjør det! Kan du ikke bare stappe det i en 1Occer-image med en Engine X, og så skalere den ned til én replika, og så kjører du bare vertikal skalering? Blir det riktig? Du har kraftig boks og kjører på istedenfor. Det å serve sterkty content er ikke så innmari tungt, i hvert fall ikke i norsk sammenheng. Men når den går ned, så er jo alt nede. Det er ulempen. Den kommer jo opp igjen! Så det Wersell gjør, er f.eks.: "Å ja, her har du static-greier." Men det slenger vi på en sedan, for det er ingen vits i å serve det fra en Cubanetes. Det var litt det som var tanken der òg. Vi kom ikke så langt, men vi fikk opp en sedan. Reusable action, sånn at du kunne ta: Ok, her har jeg setic-filene mine, det slenger jeg på en sedan. Og så bygga jeg appen min til å si at ikke prøv å hente lokalt. Hent ifra CDM-en, der kan vi cashe det forever.

29:17 --> 30:33

Og der ligger jo alle versjonene. Jeg har vært litt sånn ivrig, eller halvivrig, betatester av denne plattformen. Jeg har liksom lagd noe greier, og så sett ... Ok, hvordan kan jeg få det her ut på enkelt mulig måte? Nå er jo ikke denne plattformen ferdig og ikke polert på noen som helst måte, men det er jo ... Det er veldig interessant å tenke hvor høyt kan og bør en plattform gå. For denne approachen rundt plattformen går jo mye høyere enn det Nice ellers gjør. På en måte, men på en annen måte ikke, for dette er det du har kommet fram til. Du trenger en CDM-mekanisme. Jeg har kjempedåte forslag. Jeg har ikke det. Hvis vi ikke har en CD, så lagrer du din egen CD. Men når det er gjemt for meg som bruker plattform, så er det noe som forenkler min hverdag. Da kan jeg sitte og jobbe i de verktøyene som jeg liker å jobbe i, og så blir resten håndtert for meg. Det er litt sånn som de høyeste nivå servelestingene, Lambda i AWS.

30:33 --> 31:42

Lime inn koden din her, så ordner vi resten. For jeg er jo litt i den campen. Absolute use cases, hvor det er å hon-crafte din egen dokka. Docker image, og det er kjekt og bra og nyttig, men jeg er nok mer i den campen som sier at hvis du har en Java-sak her, og du sier at det er Java17, så skal jeg klare å bygge et docker image for deg. Ja, bortsett fra at du ikke trenger lagring, for det finnes allerede en Maven-plugin. Som er den jeg bruker, som gjør den derre magiske tingen med å si: Du har et Java17-prosjekt, kanskje du har lyst til å bygge et Java17 dockerimer? Det er ganske komplisert kode for å ta 17 derfra til 179! Det er mange programmerere som gjør det. Plutselig har du Kator og Kotlin som en helt annen stack. Eller du har Node ... Det er jo hva du kjører på, det er runtimen. Det du snakker om der, er fra dokker-image til main-metoden din. Og den biten fra dokker-image til main-metoden, det er jo noe sånt som jib.

31:42 --> 33:03

Ja, sant! Nettopp! Så jeg har ikke bygd min egen jib ennå! Ikke ennå! Det var veldig så bra to starter for å forstå ... Men du har skrevet på vår lille plan her. Arkeologi, Johannes, hva vil du snakke om da? En av de tingene som det snakkes om, er nå er vi her som brukere av plattformen. Da er det interessant å se hvordan jobber noen av brukerne av plattformen. Når jeg skal gjøre min jobb, så må jeg forstå mine brukere. Og den verden som de lever i, og det økosystemet som de har rundt seg. Og et aspekt av det er at jeg har vel aldri opplevd å være på et prosjekt hvor vi ikke har hatt noe som er der fra før av. Enten som vi skal erstatte, eller som vi skal bygge opp og integrere mot. Du har kommet i Nav, dette er alt nytt! Jeg har hørt at dere har et selv ... Her er selv kobollkoden! Du har jo folk som polerer kobolkoden her hele natten. Men da er spørsmålet hvordan du finner ut av de tingene som ligger der fra før av. Når jeg skal finne ut av hva dagens system gjør i dag,

33:03 --> 34:17

så er det første jeg vil ha, tilgang til databasen. Så jeg kan begynne databasen i et testmiljø. Jeg har vurdert å melde fra, faktisk! Og da en instans av applikasjonen som de bruker mot et testmiljø. Og så begynner jeg å si: OK, jeg må jo faktisk forholde meg til den dataen som ligger i dette systemet. Når jeg går og gjør denne greia i det systemet de bruker i dag, hva skjer i databasen? Nå ble dette, denne kolonnen, oppdatert. Og jeg trenger å få oppdatert den på en annen måte. Hva skjer hvis jeg bare fikler ned i databasen? Men her er det noe som er litt rart. Kanskje jeg kan få den til å krasje. Så går jeg inn og pirker, så det er kanskje mer "demolitions" enn det er arkeologi. Men det å gå inn og grave i de systemene. Så én ting er å skaffe seg tilgang til testversjoner av de systemene som du har. En annen ting er å se ... Ok, dette systemet gjør et kall mot ... Gjør et oppslag mot en stedtjeneste som skal gjøre et adressesøk. Hva er det som har implementert den stedtjenesten? Hvor får den sine data fra?

34:17 --> 35:31

Hvis jeg da har tilgang til kildekoden for dette systemet ... Den kaller en metode, kanskje definert i et så oppgrenset sted, som har et litt rart navn. Perfekt, fordi det har et litt rart navn, så kan jeg gå til Gitlaben og søke gjennom alle prosjektene. Så finner jeg da: Å, her er et webservice-prosjekt. Hvor det navnet forekommer. Så kan jeg begynne å grave meg ned i det webservice-prosjektet. Så kan jeg si: Ja, det kaller en annen service ... Det kaller en type Hibernate-greie. Og så finner jeg da den Hybernate annotation på den. Og så finner jeg da ... Her var et databasetabellnavn. La meg se om jeg klarer å finne hvilket prosjekt, hvilket sted, i kildekoden hvor DDL-en for den databasen er definert. Så at jeg da kan skjønne tabellstrukturen. Tabellstrukturen til den dataen som det systemet som jeg skal erstatte for nye, er nedarvet der. Og så ser jeg da ... Så ser jeg på da den ... La oss ta et annet eksempel. Her ser jeg en melding som blir sendt gjennom et system som er avhengig av.

35:31 --> 36:43

Så finner jeg navnet på meldingen i noe kildekodested, og så ser jeg på commit-loggen ... Oi, Terje? Han kjenner jo jeg! Og så kan jeg gå og snakke med Terje. Hvordan var det den koden da var skrevet for 10-15 år siden? Og så forstå mer av hvordan ting er. Så arkeologi handler om å forstå en kultur. Forstå ved å se på hvilke etterlatenskaper, altså hvilke ting de har etterlatt seg. Altså det å grave i kildekoden i databasen, det å finne ut hvem er det ... Altså commit-loggen, for å finne ut hvem har gjort dette, hva har de gjort, hvilke data var viktige for dem. Men i Nav har vi veldig mye åpen kode, og alt er åpent internt. Jeg har vært konsulent før òg, og det var jo ikke alltid at kundene hadde ... Altså det var vanlig praksis. Hvordan opplever du at det er i dag, Jonas? Jeg tror det er større aksept for det i dag. På Dora.dev, altså devops, så er jo ... Så er det en av de nye capability-ene som har kommet inn der,

36:43 --> 37:52

som tror jeg heter code maintainability. Og den er egentlig bare at du kan finne koden. Altså at koden på tvers av systemene ligger et sted hvor du kan få tak i den. For det starter jo der, ikke sant? For vi har jo alle sikkert eller. De som er uheldige nok har funnet en konfluensside hvor det står dokumentasjon og et system som du skal erstatte eller integrere deg mot. Så står det noe i den dokumentasjonen, og er det sant det som står der? Så har du vært opptatt av den? Kanskje. Hvis du er heldig, så har det vært sånn. Det er i beste fall rikter! Jeg har hørt at dette har dette oppi, Jum, jeg er ikke helt sikker. Og så ser du på kildekoden. Og da vet du at det kanskje ikke er så lett å forstå, og det er kanskje ikke den beste ideen i verden, men det er nå engang sånn det er! Men der kunne man jo sette for seg at det var plattformkapabiliteter som hjalp til, så det ble mindre arkeologi og mer kart? Altså et faktisk levende kart over hvordan ser det et landskap ut?

37:52 --> 38:53

Jeg og Truls brukte en liten stund for et år siden på å kode ... Bruke info ... Tilgangskontrollinformasjon fra NICE på å lage en oversikt over hvordan alle applikasjonene hang sammen. Hans Kristian har jo begynt å gjøre det på en mye lurere måte med å bruke Open Telemetry, som faktisk ser på nettverkstrafikken, ikke tilgangskontrollen. Men uansett, det at du har plattformen, er et sted der du kan legge inn kode, som lager mye av dette for deg. Selvfølgelig ikke NeoC i kildekoden, men mye av det kan du løfte opp fra kildekoden. Du får se hvem denne applikasjonen snakker med, hvor mye og når, og hvorfor feiler det, og hvorfor feiler det ikke. Den bør være tilgjengelig hele tida? Jeg bruker jo ganske mye tid når jeg skal følge en sånn tråd for det, å ha det på telemetri, eller bruke tilgangskontrollen. Hvis ikke noen har et passord til det, så skal vi åpenbart ikke bruke det. Så det å finne ut hvem som har det, er jo en vei inn der. Og jeg tror at det er de færreste med ... Hvis du har ett eller to eller fem meldede

38:53 --> 40:19

ti års erfaring, så støter det nok på ganske mange vegger. Å grave igjennom på den måten som jeg er tvunget til. Sånn at det å få den skrudd på lyset ... Det er litt som du sa, Truls, med den der Query Insight. Det også å få skrudd på lyset, få gjort den informasjonen tilgjengelig for utviklerne. Husker dere? Nå er vi jo veldig heldige nå, hvor alt er på gitt. Og hvis du er skikkelig gammel, så er det possible version. Men husker dere? Ja. Fascinistisk låst på alt. Ja. Fascinistisk låst på alt. Hvis du skulle gjøre en endring i kode, som jo er noe av jobben vår, så måtte du låse opp det subtreet som en mibistisk analyst har åpnet opp for deg. Så Johannes, du skal nå gjøre ... Da har en annen som kanskje bor et annet sted, åpnet opp en bitte liten kodefil der som du løser den oppgaven. Hvis det da ikke stemmer, så må du bli kreativ der. Det her gjør jo også at det å drive arkeologi er nesten umulig.

40:19 --> 41:30

For de løsningene som vi har i dag, de er da ikke tilgjengelige. For det slo meg at det man tenker på som vanlige kapabiliteter fra en plattform, at arkeologi kanskje også bør være det. Fordi, som du sier, det ville alltid være sånn. Kanskje man kunne sett denne telemetrien, det er typisk runtime. Men det hadde vært interessant å sett hvordan det var før. Hvordan kunne du spurt deg tilbake på snapshots på hvilke avhengigheter som var? Det er en viktig del av å forstå historien til den koden du overtar. Utfordringen er at du ofte har en ikke-perfekt verden. Mye av grunnen til at du erstatter disse systemene, er at de var bygget på en dårlig måte, eller på en måte som du ikke er fornøyd med nå, i hvert fall. Det viktige med telemetriverktøyene er den graden de også kan benyttes på ting som var bygget på en måte vi ikke er fornøyd med i dag. Og så vil jeg bare få lov å understreke og si til alle at de må løse dora.dev. Det er kanskje den raskeste måten å finne ut av hva god kode og god koding egentlig er. Det er bare å lese til øyet blir stort og vått.

41:30 --> 42:41

Men hva er egentlig god koding? Hva kjennetegner betjenebar og godt håndverk? Det er mange måter å angripe problemstillingen på, men en viktig følelse du skal ha, er jo det at du kommer inn, og så sitter du og sier: "mm, ja, skjønner, ok, sånn." Det skal ikke være noen "lurer på hva dette er, oi!". Den gamle DS-stripa: antall Othofox preminents. Det er litt av den ... Så det jeg ofte tror folk overdriver, for å ta den, det er at man bygger ofte litt for mye fancy ting. Så man snakker om ... En av de eldste ordtakene vi har hatt, er: Premature generalization is the ritt of all evil. Det er Donald Knuten! Så tror jeg også premature generalization is the rit of all evil. Veldig ofte prøver vi å løse et generisk problem,

42:41 --> 43:54

som vi kanskje ikke engang har når engangsløsningen er enkel. Så for å snu på det lettere spørsmålet: Hvordan kan du skrive dårlig kode? Det er en god måte å skrive dårlig kode på, det er å generalisere for mye før du skjønner problemet. Da tenker jeg at du kanskje ikke er akkurat i the happy place, liksom. Kan vi gå tilbake til Kubernetes? For Kubernetes er en komplisert ting. Modellen og api til Kubernetes er komplisert, og da kanskje man går til det når man ikke trenger primiture generalization og optimization. Alle bruker gubernettis, men så skal du bare lage noe smått. Jeg tror det er et godt prinsipp der også. Sett fra meg som brukers synspunkt, så ser ikke gubernettis enkelt ut. Det som var en god abstraksjon, kan være at den har en bra surface-to-volume-ratio. Det er en lite overflate som du må forholde deg til, og så gjør den nyttige ting for deg bak. Hvis da overflaten til attraksjonen din er stor,

43:54 --> 44:54

så du må gjøre mye for å kontrollere attraksjonen, så er den ofte ikke så verdifull. I det tilfellet så er jo da den, når jeg kommer inn og leverer noe på en kubernettplattform, så er det et enkelt grensesnitt for meg. Så der er du vellykket, da. Men fra management-siden så har jeg hørt flere enn dere som har sagt at de strever litt, så da regner jeg med at det er andre steder du har mer kompleks. Da er det litt uheldig, for de har pakket inn et så vakkert brukergrensesnitt, og så er det så komplisert bak det. Gitt er jo ikke heller nødvendigvis veldig intuitivt. Det har jo blitt det etter hvert, men opprinnelig var det ikke det. Jeg vil si bare høyre, gitt. Jeg har skrevet mitt eget eglitskbibliotek! Velkommen til Johannes historie. Alt skal forstås! Hvis vi går på "Gutthub"-brukeren min,

44:54 --> 46:20

og så søker du etter "silly jayget" ... Jeg bare spør Truls eller jeg også hvis jeg har noe jeg ikke skjønner. For det første er jo veldig mye av det her egentlig definert på Dora. Men jeg tenker jo hva vi mener er bra kode. Utover det. Det er båndpanna. Så tenker jeg at for Nav, og jeg tror også for en del andre virksomheter, så finnes det noen andre kvalitetsegenskaper som er bra å tenke på og optimalisere for. Det som vi sier veldig mye når vi snakker om teknisk retning i Nav, det handler jo om at den koden du skriver, den skal leve lenge. Det kan hende at ... Det er folk som skal lese den koden du skriver i dag, som ennå ikke er født. Og hvilke kvalitetsegenskaper bør du da optimalisere for? Er det å uttrykke deg mest mulig elegant og skrive mest mulig clever code, eller bør den koden være mest mulig obvious? Og svaret gir seg jo selv. Det her bør jo være: Mest clever. Det er et enklere og relatert prinsipp, og det er ...

46:20 --> 47:33

Det hender jeg kommer over i skalakode. Men altså, her hadde dere jo en umiddelbar reaksjon. For 15 år siden var det mange som tenkte at skala er sikkert en god idé. Det blir sikkert noen greier. Men i det lange løp så er det en god del teknologier og språk og rammeverk som viser seg ikke ... Så jeg tror også hvis du hadde skrevet et "stay me groovy", så hadde du kanskje ikke vært superfornøyd akkurat nå. Så tenker jeg da ... Jeg er jo såpass gammel at jeg fortsatt trives i Java, og så er det veldig mange som er over på Kotlin. Hvordan vil vi tenke om Kotlin om 15 år? Enten så vinner du, eller så gjør du det ikke, og da blir det kanskje neste skala. Dette har vi jo snakket om mange ganger før! Jeg tenker jo at det kan fort hende at du kommer til å få rett i at også Kotlin kommer til å være en blipp her. Men jeg tror likevel at den ...

47:33 --> 48:45

Det å migrere bort fra Kotlin er ganske enkelt, fordi at du har billder. Det blir færre muligheter til å skyte deg sjøl i foten. Så jeg er ikke så bekymra for det. Og selv om koden skal leve lenge, potensielt, så er det sånn hvis det viser seg at den må skrives på nytt, så må vi også rigge oss for det. For det er en del av det å ha endringsdyktig software. Det er veldig gode perspektiver. Det grunnleggende ... Det er å huske at det er mange trender som ikke kommer til å være der. Som er her nå, men ikke kommer til å være der nå. Embracer! Han gjorde det, ja. Vi spar jo nemlig skoballutviklere opp av graven for å hunke dem inn igjen. Det er litt sånn pensjonssparing. Det blir Wossom neste uke! De som ikke lærer historie, er dømt til å gjenta det.

48:45 --> 50:14

Hvilke ting kommer til å bli repetert en liten stund? Ut fra toppen av hodet, selv om jeg ikke er langt ned like gammel og grå i håret ... Det svinger jo veldig! "Skal kompeteringen jeg gjøre, på fronten, eller klienten?" "Eller på serveren?" Så svinger det frem og tilbake der. Vi lærer tydeligvis ikke. Det er en overordnet trend som er at nå må vi bygge noe bedre attraksjonsnivå. Nei, det har blitt så mye attraksjonsnivåer! Vi må kaste alle disse attraksjonsnivåene, og så begynner vi å bygge noe enkelt. Det er noe jeg ser på det lille og det store. Vi kaster det og bygger noe enkelt, og så blir det komplisert igjen. Man kan i hvert fall se for seg at etter hvert som skyleverandørene vokser oppover, så kommer man til å holde på plattformlaget. Det hjemmelagde plattformlaget. Det er så lite igjen imellom at det å bare la teamene velge sin egen lille del av skyen å bruke, kanskje egentlig er bedre. Det kan jeg fort se for meg kan skje, da. Ja, det er en reell fare det, Audun. Hvis du ikke har tilstrekkelig med ... Hvis du tenker på hvor mye hyperscalerne legger i effort på å bygge tjenester,

50:14 --> 51:22

og så skal de jo ha penger igjen fra det. De gjør det ikke gratis, men kontra hvor mye en middels stor organisasjon kan legge inn i å holde sin plattform konkurransedyktig. Jo mer kode, jo flere bugs, jevnt over. Den skyen går jo begge veier. Når du har en harpeskuelle-plattform som har mer kode i seg, så er du utsatt for mer kompleksitet. Personlig så har jeg ikke så mye entusiasme for ... En type "function as a service"-plattform av opposisjonslaget. Det er noen som har dokker som opposisjonsnivå fortsatt ... Ja, Johannes har jo det. Det er ikke helt "functions as a service", men det er samme nivå som du vil ha, bare at du kjøper alt under. Og da blir jo noe av spørsmålet kostnadskontroll av dokker. Jo mer du gir fra deg renta, jo mer gir du fra deg. Desto oftere virker det som folk gir fra seg kostnadskontroll.

51:22 --> 52:27

Så det har vært eksempler på folk som har brent seg på Firebase, som er veldig gode for å komme i gang, men som plutselig hadde en litt annen prisskalering enn det man forventet. Det lønner seg å kjøpe i staten, for da er det uendelig med penger. Ja ... Oljepenger. Men havner det litt ned på hvor du befinner deg, på eventdrevet arkitektur? Hvor happy du er med, eller om du ser for deg av min functions as service? Nei, jeg tror ikke det nødvendigvis. Eventdrevet arkitektur har vært en sånn ... En stadig tilbakevendende hodepine. Første gang jeg jobbet med noe eventdrevet, var på 90-tallet. Message Queue, MSMQ. Det som da skjer, er at man prøver å gå i en mekanisme hvor du ser at ting er eventorientert, og så er det du egentlig trenger å gjøre, presentere til brukerne eller systemene rundt et bilde av

52:27 --> 53:40

hva er tilstanden etter alle disse eventene. Men så blir systemene såpass orientert rundt at nå spretter noe her, og så skjer det noe der. Og så har du da det som jeg noen ganger kaller flipperspillarkitektur. Og så ser du hvor du har kontrollen, hvor er tilstanden. Det er ofte fordi man ... Jeg har sittet med Redux-applikasjoner og Kafka-applikasjoner. Og med Rabbit-applikasjoner. Det er ofte det at du velger eventer på for lavt nivå. I Redux at du har hatt en event der vi startet å fette noe fra serveren ... En annen event er at vi fikk det tilbake fra serveren. Og jeg tror da den derre med god bruk av eventhåndtering, der tror jeg vi går de samme hullene år etter år. Det er interessant å se motreaksjonen til det også. Du snakket om Reactor Redux, og så ser du liksom HTMX, som er nå liksom ... På hipsterhimmelen, da.

53:40 --> 54:48

Det er en rekal motreaksjon til hvordan man har tenkt rundt front-end-skoling. "Du trenger ikke å bygge noe lenger." Det er service-side rendering. Her tror jeg et sentralt problem med plattformtankegang ... Nå er du ... Ja, jeg er jo blitt varm! Når man blir for opptatt av verktøyet, og for lite opptatt av hva verktøyet skal brukes til, så blir det ofte dårlig bruk. Hvis du er veldig opptatt av å bruke Kafka, men er ikke helt sikker på hvorfor, da får du en applikasjon. Denne flipperspillballen som spretter rundt fra et sted til et annet. Hvis det du sier er at vi ønsker å modellere det som skjer for brukerne våre, det at da noen har søkt om foreldrepenger, eller det at noen har fått lønn denne måneden, eller at noen har fått en ny jobb, eller at du har fått innvilget en søknad, det er hendelser.

54:48 --> 56:00

Da er det ikke så viktig om de hendelsene havner på en Kafka-kø, eller om de havner i en databasetabell som heter da ... Søknad Event. Det som er viktig, er hvordan du bruker ... Altså hvordan du forstår brukernes verden i form av event-abstraksjonen. Og så kan du bruke event-mekanismen. Men hvilken event-mekanisme du bruker, kan også være avhengig av settingen. Så i de applikasjonene som jeg har bygget de siste årene, er vi ganske opptatt av å ha web-grensesnitt som oppleves realtime. Hvis jeg markerer noe i min web browser, i min mobiltelefon her borte, så skal du se det med en gang. Hvis man er så heldig at man får lov å bruke Jira som task, og så har noen gjort en endring på en Jira-task, og så får du opp en bit ned i hjørnet sånn ... Noe har endret seg i Fresh her. Kan du ikke bare oppdatere guet for meg, så tilstanden jeg har, skal være tilstanden du har.

56:00 --> 57:02

Er ikke det Firebase, value-propen? Jo, og Firebase er en teknologi som kan enable den. Men hvis ikke du har et forhold til hvilke eventer som skjer i min applikasjon, som er de som skal gå over i ventekøen, så blir det ikke bra uansett. Det er den biten som er viktig. I den sammenhengen bruker vi en form for resourcing på dette, hvor jeg sier at jeg har registrert et nytt bilde eller har oppdatert statusen på noe. Den eventen skal gå til deg. I den sammenhengen er Kafka ikke en veldig relevant ting å snakke om her. Vi snakker om "last mile", vi snakker om fra en back-end til en front-end. Så i dette tilfellet snakker vi om en websocket og Firebase, som du sier. Det er en veldig mye mer relevant ting å snakke om. Alternativt at man lager en egen event-mekanisme oppå websocket, som vil være det som du har der. Så det å modellere domenet sitt, altså det å forstå domene-eventene, det å ha den fokus på det arbeidet rundt det, er adskillig viktigere, tror jeg,

57:02 --> 58:13

enn det å lære seg verktøyene som du bruker for å implementere det. Komme på plattformen og si at appen er hvitt i den plattformen ... Det er ganske dramatisk! Det er det som handler om brukerarrangement! Det som er så innmari irriterende med brukere, er at når du snakker med brukerne, er de opptatt av andre ting. Nei da, vi er ikke ute etter plattform! Der bruker han opptatt av akkurat det samme som du er! Da er det mye enklere! Det er det du tror, da. Men det er jo ikke alltid sånn. Jeg kjenner jo igjen den biten der. Det er ofte gøy å jobbe sammen med plattform, eller ta en plattform, skifte nøkkel ... Fordi at man ser seg selv i speilet veldig fort. Men jeg trives veldig mye bedre med å ha brukere som er veldig forskjellige fra meg selv. Det er mye ... Jeg liker å by på meg selv, da! Du er kanskje et bedre menneske enn meg, du også. Det hender at det er innmari frustrerende også. Men du får jo en helt annen ... En helt annen følelse av hvordan man ... Altså hva brukerne faktisk trenger, da.

58:13 --> 59:33

Jeg kan ikke snakke så mye om prosjektet jeg er på nå. I forrige prosjekt jobbet vi med verktøy som brukes når man gjør ... Verktøy som brukes når man søker redning ... Finne personer som har gått seg vill, eller båter som har havarert. Den type problemstilling. Og da sitter jo vi ... Når vi lager applikasjonene og støtte for dem, så har vi et bilde av hvordan brukerne er. Men det som da var utrolig viktig, og som var liksom ... Da jeg merket at korona var over, var da vi fikk et ordentlig treff med brukerne våre. Redningsøvelse på Svalbard, som var Northern Arctic Rescue Exercise. Hvor det var ... Man skulle da evakuere 150 personer, 150 markører, fra en båt som skulle simulere et cruiseskip. Som skulle spille rollen som et cruiseskip. Og du hadde da Kystverk og Kystvakta, Røde Kors ... Du hadde ... Disse Sea King-helikoptrene som var involvert. Og du hadde også lokal helikoptertjeneste på Svalbard. Og du hadde da lokalmiljøet på Svalbard, og den funksjonen som de har i en kriseberedskap.

59:33 --> 00:59

Altså sysselmester og all den type ting. Så da er jeg her, da. Og da får vi lov å snike oss inn, som markører. Så jeg har da på meg sårmaske. Og så sitter jeg da i ... Så blir jeg rigga opp i røykdykkerdrakt. Og så sitter jeg da i maskinrommet på en av Kystverkets båter. Mens da brannalarmen går, og så er det en som sprayer røykmaskin inn i rommet. Og så merker jeg da sånne ting ... Så jeg skulle simulere en røykdykker. Og så simulerer jeg da en røykdykker som hadde gått seg vill, og nå måtte reddes. Det var ikke så vanskelig? Du var vel litt "lost" i den settingen der? Ja, men så viser det seg at den tanken du har som røykdykker, den veier ganske mye. Og det å prøve å sitte med en tung tank på ryggen, det er ikke så lett, for du får ikke hvilt den på noe. Så du ender opp med å bli liggende litt sånn ... Så får jeg jo da snakket med og sett på, observert da, disse folka som skal forholde seg til informasjonsbildet vi skal understøtte. Og der er det den tanken med: Hva slags informasjon er det de utveksler?

00:59 --> 02:17

Hva slags horisonter er det de har? Det som er overraskende innenfor en beredskapssetting, er at det ofte er veldig mye venting. Ofte forventer du at fordi det er en kritisk situasjon ... Så forventer du at ting skjer, og det er mye, men det er ofte at du må sitte og vente på noe, det er ofte at du ikke vet hva som skjer. Og det det å være der sammen med brukerne, det også da være i det der maskinrommet med solidsminke og hele greia der, jeg lærte så mye om hvilken kontekst brukerne er i. Eller ikke minst så mye om hvilke ting jeg ikke engang visste at jeg tok feil om. Det er et spørsmål som du ikke engang tenker på å spørre, fordi det er så åpenbart fra den konteksten du er i, at du ikke tenker på dem. Du står aldri i en kravspesifikasjon! Og du får aldri høre det når du snakker med folk, for for de som sitter der, er det åpenbart. Og for deg tenker du ikke på det engang. Den tingen som har skjedd i plattformverdenen i det siste, er det fokuset på å snakke mer med brukeren. Og bli mer produktorientert, og tenke litt mindre hva det er jeg trenger

02:17 --> 03:25

som plattformutvikler, og litt mer hva brukeren min trenger som plattformbruker. Det er ikke sikkert man trenger å ha på seg sårmaske for å finne ut det som plattformbruker. Men det å være veldig god på å spørre, og ikke bare bruke egne erfaringer, men å spørre teamene hvordan kan vi hjelpe, det er kanskje den aller viktigste tingen man kan gjøre som plattformteam. Og jeg må også merke at du kommer ikke nødvendigvis helt i mål. Ikke nødvendigvis helt i mål med å spørre heller. Self-reported experience, det der å spørre folk hva de er opptatt av, det er ikke alltid du får det riktige svaret. Vi brukte ordet arkeologi tidligere. Det er et ord fra sosialantropologien, og et annet ord jeg også er veldig glad i, som er etnografi. Og etnografi handler om å studere mennesker i sitt daglige miljø. Altså der de er til daglig. Og gjerne uten en hypotese som du har. Men du gjør en passiv observasjon. Og det er en ganske kraftig måte å angripe brukerstudier eller forståelse av folk på, for du prøver å legge fra deg fordommene, og da observere hva som skjer istedenfor.

03:25 --> 04:41

Og da tror jeg at du også som plattformutviklere ... Når du spør meg: Hva er det dere trenger fra plattform, så vrir jeg hodet mitt i retning av: Hvordan var det i dag? I retning av hvordan var det jeg agerte når jeg var og skrudde på plattform sist? Så hvilke dager i uka er det som ... Eller hvilke dager er det hvor jeg har mest med plattformen å gjøre? Men de dagene hvor plattformen fungerer best, er de dagene hvor jeg ikke tenker på plattformen. Det gjelder jo alle systemer. De dagene hvor du ikke tenker på systemet, er de dagene hvor systemet har gjort en god jobb for deg. Det er også de dagene du ikke får høre om når du spør brukeren. Nå tror jeg du må si landing snart. Ja, jo da, jeg skulle bare skyte inn med de sånne her ... Det er jo den der lytterbruker, men ikke lytterbrukeren. Jeg husker egen opplevelse: Kan vi få Postgress? Ja, så klart ... Men hva er det jeg skal ha der? Det er jo en flott database, ingen er veldig fan av det. Prøv å forstå use casen. Jo, de hadde noen binary blobs som de trengte å lagre et sted.

04:41 --> 05:56

Og Postgress hadde noe sånn native som var binary, om vi ikke liksom ... eh ... Observer hva det er ... Hvilke utfordringer er det de har i det daglige? Hva prøver de å løse? Og hva vil de oppnå? Kjempe ... Det handler jo ikke om å levere den løsningen de ber om, men forstå det problemet de har. Ja. Jeg tror det kan bli nesten sånn famous last words, men vi har jo et sånn vanlig spørsmål som vi pleier å stille. Når ting gikk galt ... La oss si fra ... Nå er jo ikke det å lage plattform, men fra applikasjonsutviklingen. Og bruk av plattform når det hits the fan. Om det har en opplevelse. Hvordan var dere lært av det? Kan bli litt mørkt. Ja, kjøpp det! Vi vil ikke ha sånn der PG ... Det er veldig mange barn som øver på denne borda. Det var den mandagen hvor en av superbrukerne mine ringte og sa: "Fikk du med deg den dødsulykken som skjedde i Vinnerhelgen?"

05:56 --> 07:14

"Jeg tror vi fant en bug i systemet deres." Og det er jo ... Ja. Og det var da en ... Jeg kan si at heldigvis så var ikke den feilen som jeg hadde der, innført. For jeg hadde innført den feilen for ca. 8 md. før den hadde ligget latent i ca. 8 md. Den feilen var ikke avgjørende for utfallet i den ulykken. Og det andre er at når man jobber innenfor et sånt ... Så er det jo én ting som folk vet, er at om vi ikke er her, så redder vi ingen. Hvis vi ikke klarer å redde noen, så har vi prøvd, da. Men da gikk jeg tilbake igjen og så prøver jeg å grave inn, for det første: Hva var det som skjedde? Som tar ganske kort tid. Og så prøver jeg å si: Hvorfor var det testingen min ikke lykkes i dette tilfellet? Det tilfellet var pga. kommunereformen. Da hadde vi slettet all data som hadde assosiasjoner med kommuner, fordi de hadde endret seg. Og testdatasettet mitt var ikke oppdatert.

07:14 --> 08:30

Når du er inne på Five Wise, det å gå tilbake igjen ... Hvorfor var ikke testdatasettet mitt korrekt? Og hvordan var det feilen var i dette tilfellet? Det som var feilen, var at når man søkte etter data basert på kommune, så fant jeg ikke kommunen. Så jeg fant ikke data. Da ignorerte jeg det at jeg ikke fant data. Jeg burde ha skriket høyt ut og gitt en feilmelding. Fem år før feilen inntraff, skrev jeg det som har vært min mest populære bloggpost noen gang. Som handler om hvordan du da ikke skal svelge feil. Så jeg lærer jo ikke av mine egne feil heller. Det var en historie om den feilen jeg tenker mest på, som jeg har vært involvert i. Blir det like mørkt, Truls? Nei, det ... Jeg tror ikke jeg har sånn ... Du skriver jo ikke feil, du! Det er veldig mye mer effektivt, da. Jeg har jo masse feil også, men hva som kan være relatert til plattformer, kanskje. Som bruker av plattform ...

08:30 --> 09:52

Det tenker jeg på da vi skulle lansere forskudd på dagpenger under korona. Det er jo nasjonalkrise, 400 000 permitterte og sånn, og ... Sense of urgency var ekstremt sterk fra toppen av det poliplitiske Norge helt ned til oss på gulvet i Nav, hvor vi satt og lagde løsning. Det hadde ikke så mange dager på oss heller, men vi bygde jo det vi rakk. Men det var jo ikke alt vi rakk! Men det var jo ikke alt vi rakk der. Så idet vi lansa, så lansa vi jo da med tings vi måtte fikse mens trafikken gikk inn. Vi hadde dashbordstopp, så vi så på dashboards i Grafana på hvordan trafikken gikk inn og ut og sånn, men det som viste seg, var at Skatt kjørte vel en batch eller noe sånt. Det hadde vi glemt å avsjekke med dem. Så da vi gikk live, så begynte vi å ... Var på forskjell fra Vega og Dagbladet?

09:52 --> 11:07

Ja, men nå kan du søke om forskrift på dagpenger. Da begynte trafikken bare å spike opp. Og det hadde ikke vi avklart med skatt, da. Den batchen som de kjørte da, den okkuperte jo det grensene vi hadde mot dem. Så vår Kafka-lag bare økte og økte og økte. Og da var det ganske sette, da. Hva gjør vi nå, liksom? Det vi måtte gjøre, var bare å skru trafikken ned. Force den ned helt til vi så at Kafka-lagen begynte å gå ned igjen. Og så var det noen, antakeligvis, som snakket med noen, på et eller annet nivå, som sørget for at den proppen i systemet gikk over. Men det husker jeg som en sånn vekt. En veldig skummel episode, som jo endte bra, men som også var ... Hvor mye plattformen hjalp oss i det? At vi hadde monturering, vi hadde overvåkning, og vi kunne skalere poddere opp og ned, sånn at vi også avverga en sånn type krise.

11:07 --> 11:48

Vi runder av der og sier tusen takk til Johannes Boddvold og Truls Jørgensen, for at dere har delt så utrolig mye innsikt fra en applikasjonsplattformbrukers perspektiv. Og kanskje litt annet også! En digresjon innimellom. Dette har vært en spesialepisode av Plattformpodden med Hans-Christian Flåtten og Audun Faukal Strand. Teknisk produsent er som vanlig Tore Græsdal. Det finner du alltid på plattformpodden.no eller i din lokale podkast-app. Følg oss gjerne på LinkedIn. Ha det!