Episoden er transkribert av kunstig intelligens

00:00 --> 00:55

Velkommen til Plattformpodden, en podkast om applikasjonsplattformer, og ikke minst teamene som bygger de. I denne sesongen utforsker vi plattformene i offentlig sektor. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg Audun Strand. Tusen takk, Hans Kristian. Jeg gleder meg også veldig til å lage denne podkasten. Jeg har jobba med å lage applikasjonsplattformer i ti år snart. Og jeg tror at det blir gøy å høre hvordan andre organisasjoner også tenker rundt plattform. Helt enig, Audun. Jeg har også ikke like lang erfaring som deg. Og mye mindre erfaring fra Nav. Men også: Virkelig, dette her er så gøy! Jeg er også med i Nav og bygger denne plattformen som vi skal høre mye mer om i dag.

00:55 --> 01:45

Men i dag har vi med oss to gutter som har vært med hele reisen. Nemlig Jonny Horvi og Frode Sundby. Velkommen til oss. Tusen takk for det. Kanskje dere kan si litt om dere selv? Før vi begynner å snakke om NICE? Absolutt, det kan vi gjøre. Jonny Horvi heter jeg. Og jeg har vært med å bygge NICE siden vi starta. Og vært i Nav-systemet lenge. Så vi har alltid drevet med infrastruktur og syns det er gøy. Og prøver å tilby det til utviklerne. Så det er SAS. Frode Sundby heter jeg. Jeg har også vært med kjempelenge på den reisen her. Kom jo inn sånn rett etter Jonny, par år etter kanskje. Hvor vi ble med inn og så på den gamle applikasjonsplattformen vår,

01:45 --> 02:37

før vi etter hvert begynte å skjønne at Kubernetes var en greie. Så har vært med på hele reisen fra Jboss-app-server til Kubernetes nå, da. Utrolig kult. Det er et forbilde. Og jeg vet at det er veldig mange som ser opp til dere og det utrolig gode arbeidet som skjer i Nav. Men hvis vi begynner litt fra begynnelsen, da. Hva var det som fikk Nav til å tenke denne måten å bygge plattform på? Nei, vi har jo drevet med plattformer i Nav ganske lenge. Eller at man har hatt et sånn ... Man har hatt et skille mellom det som har vært plattform og det som har vært utviklingsarbeidet som er blitt gjort. Og så har man jo gjort alle feilene underveis.

02:37 --> 03:22

Så man har med det klart å bygge opp litt erfaring rundt hva funker og hva funker ikke. Og sett på ekte de konsekvensene som er når man gjør det feil. Så det har man jo tatt med seg. Og det har vært et ... Og det har vært et ganske konsistent team underveis helt fra starten som har drevet med dette og bygd det. Som har tatt med seg de erfaringene hele veien. Så det er kanskje litt av det. Man kan jo si at en forløsende faktor var moderniseringsprosjektet i 2012. Ikke fordi det gikk så himla bra, men fordi det gikk så himla dårlig, egentlig. At det man hadde bygget opp der, det var jo en slags applikasjonsplattform hvor man hadde samla én måte for alle utviklingstider.

03:22 --> 04:04

Og få rulla ut applikasjonene sine på en standardisert måte. Og det la jo grunnlaget for at man kunne jobbe raskere og mer effektivt. Men organisasjonen var ikke klar for det. Og det som skjedde etter modernisering, var jo det at det var noen direktører som måtte ta noen hatter og gå en tur. Langtur også? Langtur, ja. Men det som kom inn, det var jo da noe nytt lederskap med noen nye ideer. Om hvordan ting kunne gjøres. Og da var det mer den at man hadde bein helt fra toppen på at Nav kunne jobbe på en annen måte, at man kunne være mer effektiv.

04:04 --> 04:52

At man kunne gi mer tillit til utviklerne mine, gi dem mer ansvar. Og med at utviklerne får mer ansvar og mer eierskap, så vil de også kunne jobbe mer effektivt og bedre. Og med det hadde vi jo et godt tidspunkt. Et grunnlag for å kunne begynne på neste generasjons applikasjonsplattform som da var basert på Kybernetis. Så da laget jeg en spesifikasjon og satte den ut på anbud, og hentet inn tilbud og funnet noen som skulle bygge den for deg her da. Helt riktig. Jeg satt og skrev det som gikk rett på Doffin. Den plattformen som vi sitter med i dag, Nice, den ble født i slutten av 2016. Da hadde vi også blitt litt kjent med Audun,

04:52 --> 05:45

som kom med noen friske tanker fra Finn-systemet. Frode og jeg hadde akkurat vært på workshop med Kelsey High Tower. Kjørte Kybernetis til Hardway-workshopen der. Vi var proppfulle av selvtillit og tro på det vi skulle til med å bygge og lage. Så det var der vi starta med å bygge en plattform som var modellert rundt den nye måten Nav skulle jobbe på. Tidligere var det bygget rundt den gamle organiseringen, rundt at det var ... Utviklerne skrev kode, leverte fra seg artifakter, og så ble det overlevert til Nav. Da var det utelukkende konsulenter som skrev all den koden i prosjekter. Leverte koden over til Nav, som testa det, og så var det noen i drift

05:45 --> 06:30

som satt der i produksjon kanskje noen måneder etter at koden ble skrevet. Plattformen var jo nødt til å støtte oppunder det her, men når vi da lagde på nytt, så var det jo da mer enn med tanke på hvordan vi ville at det skulle være. Og da hadde vi støtte rundt det, som Frode nevnte. Det var ikke helt tull det med Doffin-greiene heller. Ikke at vi var ute og søkte, men de som hadde muligheten til å levere ei containerplattform på den tiden, de var hyppige og banka på døra og skulle ha møter med oss og fortelle om hvor fantastisk og hvor enkelt de kunne løse alle våre problemer. Så den kampen vi sto i, var vel egentlig mer sånn: Vi har en visjon og en plan og et mål om hva vi har lyst til å oppnå,

06:30 --> 07:05

og så var det mer å kjempe mot leverandørene for å faktisk ... Og litt internt i egene... Vi var flinke kjøpere og ville ha support på ting, men så kommer vi sånne gærne utviklerne og sier: "Vet du hva, dette vil vi gjøre skjær." Den visjonen du hadde i hodet da, da vi krangla med disse menneskene med fargerike hatter, hvordan føler du liksom at den har holdt seg? At visjonen har holdt seg? Som du så for deg at det skulle bli i 2016-2017. Er det sånn det har blitt?

07:05 --> 07:44

Det var som vi hadde en slags spåkule, så så vi inn i den, og det har blitt virkeligheten, på en måte. Vi hadde en sterk tro på at dette klarer vi å løse best selv. Det største salgsargumentet for organisasjonen var at da kan du jo få support. Men hvis det er sånn at vi har behov for support, da har jo vi gjort noe galt. For da kan ikke vi greiene våre. Så vi som leverer plattform, må også ha stålkontroll på hva det er vi lager. Hvordan det henger sammen og hvordan det virker. Det kan ikke komme inn noen fra utsiden og forklare oss hvordan vår plattform funker, og hvordan vi burde skulle kunne gjøre ting isteden.

07:44 --> 08:40

Det at man gikk inn i den prosessen med litt bondus og selvtillit, både fordi vi hadde bygget plattform før og visste at det kom noen fra Finn som også hadde gjort det før, gjorde at man da kunne gå ut på limpinn. Den supporten, det tar vi, og vi tør å gjøre det. Det hadde vært lett for oss å si at vi kjøper den pakka fra de med de hattene, og så er det trygt valg, uten at vi personlig risikerer noe da. Men vi er veldig glad i dag for at vi ikke gjorde det. Og jeg angrer ikke på det. For det var jo det de fleste gjerne gjorde. Veldig mange som gikk den ruten, etter det jeg har forstått. Å finne noe som markedet leverte.

08:40 --> 09:28

Men nå har vi jo snakket mye om denne mystiske og kanskje litt myteomspunne Nice-plattformen. Hvilken av dere drar oss gjennom? Hva er en plattform egentlig? Hvordan ser Nice-plattformen ut i dag? Ja, så utgangspunktet for en applikasjonsplattform ... Vår mentale modell... Vår mentale modell rundt det er det at utviklerne i Nav ... Det vi ønsker at de skal bruke sin tid og energi på, det er jo nettopp det å løse Nav-spesifikke businessproblemer. Og de er det massevis av. Litt av det som er ... Kall det konsekvensene av den nye måten å jobbe på. Det er jo at vi legger mer ansvar på teamene, rundt hele verdikjeden eller livssyklusen.

09:28 --> 10:20

Eller livssyklusen til applikasjonen. Det gjør at det er mye å forholde seg til. Alt fra kjøretidsmiljø til nettverksting til sikkerhet til absorbility. Det er mye å forholde seg til, og for at det her skal gå bra, og for at det skal være sikkert, så må de egentlig ha et bevisst forhold til det. Poenget med en akkresjonsplattform er jo nettopp å la disse tingene her, som ikke har noe med ... Det Nav-spesifikke gjør, er å la det forsvinne litt inn i bakgrunnen, og bare virke i praksis for utvikleren, sånn at de kan ha mest mulig fokus på sin jobb. Så er det viktig å understreke også at for en plattform at utviklerne ikke føler at det er en magisk knapp som de trykker på. De må fortsatt ha et visst forhold til det.

10:20 --> 11:05

Men en plattform kan være med og filtrere bort de tingene som de reelt sett ikke kan påvirke. Hvordan velger dere mellom hva som er magiske knapper, hva som må være helt eksponert og hva som kan gjemmes? Det handler primært om de use casene vi legger opp til. Vi ser mønsteret i bruken av de tingene som vi tilbyr. Det handler mye om å forstå de use casene godt, for å klare å skille på hva som er relevant og ikke. Eksempelvis kan vi ta kybernetisk, at vi vet at det utviklerne bryr seg om er at applikasjonen kjører, og at den har nok ressurser til å kjøre. Da kan vi eksponere ting som at du kan skru på CPU og minne,

11:05 --> 11:45

fordi det er noe som du har et forhold til, mens replikasettet som du bruker, eller hvordan det faktiske ingressobjektet ditt ser ut, det trenger du ikke vite så mye om. Du vil vite URL-en din, antall replikas og størrelser. Så da er det de tingene som vi eksponerer. Vi har skåna de for mye kybernete-spesifikt. Er det ikke ofte stort spenn i de utviklerne? Noen har vel lyst på å vite mye om hvordan ingressen funker? Og at den skal funke på en spesiell måte, kanskje? Absolutt. Og plattformen gjør jo at du kan ... Du trenger ikke å forholde deg til alle detaljene. Det holder å spesifisere en URL, og så er det det.

11:45 --> 12:31

Men hvis du vil, eller trenger, så kan du grave deg inn og gjøre ting. Vi har tatt noen valg på hva vi mener er det viktigste, men vi har ikke begrensa mulighetsrommet til utvikleren allikevel. Men det vi ser også, er at den kategorien som du beskriver, som er den ekstremt infrastrukturinteresserte utvikleren, som vi trodde at alle var. For vi er interessert i dette selv, vi syns dette er kjempegøy. Og vi som satte opp det her fra starten, så var det sånn, dette er jo helt fantastisk utrolig. Herregud, så mye natt! Det å forestille seg at noen andre ikke var interessert i det, det er kanskje en av de tingene som har lurt oss litt i en årrekke.

12:31 --> 13:11

Vi har tenkt og trodd at utviklerne i snitt har vært mer interessert enn det de kanskje i virkeligheten er. At de vil at det her skal funke. Og så er det selvfølgelig noen som er litt interessert. Men jeg tror det store flertallet egentlig er ... Ja, driter i det. Høres slik ut. Stort sett fornøyd med brød og smør, liksom. Det funker, og de enkleste tingene. Får jeg kjøretiden min, får jeg lastebalansereren til å virke. Det er greit, det. Utviklerne er interessert i å få applikasjonen sin ut. De underliggende tingene skal egentlig bare noen andre ta litt hånd om. Just works, takk.

13:11 --> 14:00

Hvordan er grensesnittet mellom dere og utviklerne? Vi ber utviklerne våre om å levere en container, det er det vi sier. Gi oss containeren din, si "her er imaget ditt", og så gir du oss en liten beskrivelse av hva du vil at applikasjonen din skal være. Det vil si, eller hva trenger den. At vi har laget masse funksjonalitet for det vi ser på som nødvendige ting, og så kan de velge i en smørbrødliste av funksjonalitet. Så de leverer fra seg imaget sitt og en liten beskrivelse, altså manifest, hvor de sier: Jeg skal ha dette imaget, som skal kjøre med så mange replikas med disse ressursene, og så vil jeg gjerne ha en database, takk. Kunne jeg også fått en lastbalanserer. Det er grensesnittet

14:00 --> 14:39

for å få applikasjonen ut i verden. Vil nesten si at det er som en buffé. Men hva med date two, da? Da gjør det litt mer vondt, foreløpig. Vi har jo glatta veldig over og sagt at ja, men du sier bare at du skal ha så mange replikas og ingress. Og så kommer du til dag to, og da har jo vi lent oss på funksjonalitet som finnes fra før. Så vi sier jo: Her er Gcloud. Her er CubeCTL, vær så god. Her er namespacet ditt. Og det har de jo aldri hørt om før, hva er et namespace. Og så inn i namespacet så finner de podder og services og replikasett,

14:39 --> 15:31

ingresser og databaseinstance-ressurser, og det er massevis av greier som de aldri har sett. Så det er jo vi har lagt opp til at de må skjønne veldig mye på dag to. Og det er noe som vi har lyst til å gjøre noe med. Fordi alt vi lemper over på teamene av sånne ekstrating, det er jo mentalkapasitet som de må bruke på å skjønne et domene som ikke er applikasjonen deres. Så det vi kommer til å jobbe med framover, det er å ... Gjemme bort, eller ikke gjemme bort, men ta bort de tingene som ikke er relevante. Og gi dem den informasjonen de trenger som er relevant for dem med en gang. Uten at de må sette seg inn i det. Vi skal ikke fjerne muligheten for å gå inn i namespacet og se på ressursene, men vi vil i hvert fall for de som ikke trenger det,

15:31 --> 16:08

eller ikke har lyst eller behov, så skal de få den informasjonen de trenger. Uten å måtte grave så mye, da. Men jeg antar jo at siden denne podkasten heter Plattformpodden, så kan vi skrelle bort alle de som ikke har lyst eller behov, alle som hører på, har veldig lyst og veldig behov. Så hvis vi skal vise fram alt, hvordan ser det ut inni? Hvordan er det lagd, hvilke programmeringsspørsmål bruker dere, hva er liksom arkitekturen? Hvis du tenker nice ... Hvis vi tar dag to, sånn som det faktisk ser ut i dag, så er det jo som Frode sa, du må bruke G-clode og logge inn med det.

16:08 --> 16:50

Du har Cubicet L for å se ... Jeg tenkte på det dere har lagd. Hvordan det ser nice ut inni. Kjernen er jo et kubernettiskluster, og vi bruker GKE for hovedclusterne våre. Vi har noen clustera on fremdeles også, som kjører på noe flatcar noder. Men når vi har clusteret på plass, så er det liksom bånnpanna. Der har vi satt opp nettverk, vi har satt opp lastbalansererne, og vi har satt opp litt sånn grunnleggende infra. Og så, på toppen av clusterne, så legger vi på det som vi kaller features. Det er det som gjør nice til nice, som at det er mer enn bare et Kubernetesk cluster. Da legger vi inn alle de tingene som Jonny snakka om i stad.

16:50 --> 17:40

Altså det som utviklerne ikke trenger å forholde seg til lenger, men trenger allikevel. De får observability, de får abstraksjoner for å sette opp databaser, de får bøtter ut av boksen, de får sitt eget namespace og rettigheter, og alle de tingene. Og alle operaterne som vi har bygget for å få ... Kjøre disse tingene her. Det er alt skrevet i Go. Vi har vel kanskje en eller to som er i Røst, men Go er hovedspråket vårt. Hvorfor Go, egentlig? Økosystemet rundt det vi holder på med er jo veldig gå tungt. Pluss at det er jo, i hvert fall for veldig mange av de som jobber på teamet, er jo ... Jeg syns det er et velbehagelig språk å skrive i. Det er i hvert fall mitt personlige språk.

17:40 --> 18:38

Kom de inn med mye erfaring fra Go tidligere, de som er på teamet? Nei ... Bitte litt, kanskje. Men det meste er nok bygget til 2016 og opp til nå. Hvor mange er det på Nice-teamet i dag, og hvordan organiserer man det arbeidet? Det kommer litt an på hvordan du regner, men vi har delt opp teamet nå i tre grupperinger. Fordi vi er såpass mange at vi må prøve å gjøre noe for at ikke alle skal måtte forholde seg til absolutt alt vi driver med. Så der har vi kjerneteamet, som vi kaller det, som holder på med selve kubernetes, automatisering av infrastruktur, oppsett av nettverk og lastbalanserere. Og ja, kjerne-kubernetes, rett og slett. Og så har vi featuresteamet, som vi kaller det, som primært holder på med operatorene våre.

18:38 --> 19:26

Og det som er mer utviklernært, det som treffer brukerne våre rett i fjeset. Og så har vi en tredje gruppering som kaller seg for FrontEnd Plattform, som holder på å bygge utviklerverktøy som er retta mere mot frontend-utviklere. Så de får et CDN og snertne måter å få ut pakkene sine til det på. Plattformer ikke bare for tradisjonelle backend-applikasjoner? Å nei, da. Sikter på hele steiken. Hele plattformsteiken! Jeg var ikke helt ferdig med det forrige temaet. Men da fortsetter vi der! Ja, for det er vel bare å fullføre det bildet som du snakka om, da.

19:26 --> 20:15

Du har båndpanna, du har selve clusterne som vi setter opp med GKE i Google, og så har vi jo omprem-riggen vår, hvor vi egentlig får prosjonert VM-er. Som vi setter opp vanilja i cubernettet så på. Og alt det som vi utvikler på toppen, det som er vår hverdag som plattformutviklere. De komponentene vi lager der, som er operatorer, biblioteker, API-er, jobber. Alt det som til sammen utgjør den "nice"-opplevelsen som vi prøver å skape her. For det er ikke enkelt operator eller enkelt komponenter, det er hele opplevelsen. Det må sys sammen til å være en helhetlig opplevelse. Det er jo et av hovedpoengene med å lage en plattform, er å lage en helhetlig og god opplevelse for utvikleren.

20:15 --> 21:09

Og at de skal slippe å forholde seg til x antall subsystemer, og skjønne sammenhengen mellom de. Vi skal få det til å virke sammen. Men for å slå sammen både det tekniske perspektivet og det menneskelige perspektivet, hvordan koder dere? Det er organisert til disse teamene, så koder dere operatorer i går. Men hva gjør dere sammen, hvordan bestemmer dere hva dere skal lage, hvordan er hele utviklingsprosessen? Den prosessen er også et itrativt arbeid. Men vi jobber i stort i tre grupper som er delt inn på funksjon. Og de tingene som vi lager, det lager vi stort sett i team på to og to, eller kanskje tre og tre. Så vi jobber mye sammen, og vi jobber jo stort sett 100 % remote, alle mann.

21:09 --> 22:00

Så når vi vet hva som skal bygges og lages, så er vi en gruppe på to-tre mann som setter av gårde. Så det er ganske konsekvent, egentlig. Nå går vi litt inn for landing her, noe som jeg syns er utrolig spennende. Nå har dere jo malt et veldig flott bilde her, og kanskje litt for flott på mange måter. Men vi lærer enormt mye av når ting går galt. Kan ikke dere spørre litt på sparket her? Kan ikke dere fortelle litt om noe som gikk galt, og hvordan man lærte av det? Vi har egentlig en policy på at det ikke skal gå galt. Så bare gjør det riktig første gangen, det er jo veldig smart. Det er ikke så lenge siden vi hadde en episode hvor vi måtte komme og beklage oss og skrive et lite post mortem på at "hei sann, her gikk vi litt for fort fram",

22:00 --> 22:43

og "dette har vi lært av det". Det vi holdt på med da, var vi skulle gjøre et skifte av lastbalansererne våre. Og vi for vår del hadde et veldig tydelig bilde av hva det var som skulle gjøres, men det involverte også eksterne parter som måtte validere og sjekke opp og ... Veldig mange på utsiden som måtte gjøre et stykke arbeid. Og det gjør jo at jobben tar lang tid, og man mister litt fokus. Og det som skjedde var jo at vi hadde ikke fått med oss alle avhengighetene, så da vi gjorde flippen og sa at nå, og går det domenet til den lastbalansereren isteden, så mangla vi en del ruting fra forskjellige steder, litt sånn obskure steder. At vi da ikke hadde klart å avdekke alle de eksterne avhengighetene

22:43 --> 23:22

for når vi skulle gjøre en ting, det gjorde jo at vi gikk på en smell, da. Vi vet ikke hva lærdommen er ... Rendyrke den om ikke å gjøre feil, kanskje. Du nevnte noe om post mortem. Hva, for de som ikke er kjent med den terminologien, var det for noe? Vil du si noe om hva det er for noe? Ja, det er jo helt blameless skal være, da. At man skal bare skrive: Hva var det som faktisk skjedde, og hvorfor skjedde det? Bare sånn for å kunne gi en oppsummering til resten av organisasjonen: Hva er det vi har holdt på med, og hvorfor gikk det galt? Og bare være åpen om at her var det noe rusk i maskineriet, gitt.

23:22 --> 24:13

Jeg får prøve å kanskje lære litt av det, se om det er noe findings på en måte. Når man står midt oppi det, vil man helst bare glemme det. Og det klarer man jo, men hvis man druer til å skrive sånn post mortem, så kan det hende du lærer noe. Det er utrolig kult å høre. Er det en kultur for å få det utover Nice-time i Nav òg? Vi er vel de som er dårligst på det. Kanskje ble det i det minste feil. Men før vi runder helt av, hva er det neste? Hva er neste store i Nice-plattformen? Vi har lyst til å fokusere mer på det å ... Vi kan kalle det grensenittet vårt ut mot utviklerne. Vi har nå starta et arbeid rundt noe som vi kaller for Nice-konsolla.

24:13 --> 25:07

Hvor vi tar sikte på å prøve å abstrahere bort mye av de detaljene som er uvesentlige. Og fremheve de tingene som er vesentlige og som er viktige og at de har et bevisst forhold til. Så det å utvikle den videre og få det til å bli bra, og få det til å bli en flate for oss for å gjøre nettopp det, det er en ting der det kommer til å skje mye. Adressere dag to, som du var inne på i stad. At vi ikke nødvendigvis må utsette 400 utviklere for hva er et replikkasett? F.eks. hvis det er noe galt med applikasjonen i dag, så blir man eksponert for det. Den rå plattformen. Da er det Gcloud auth: log in. Log inn mot Google. På med Nice Device, inn med CubeCTL, finner riktig kontekst, riktig namespace.

25:07 --> 25:55

Og så må du inn der og forstå litt Kubernetes, og du må kanskje tolke noen feilkoder. Crash do backoff, f.eks., det betyr det. Så du må vite hvordan du feilsøker, da. Mens med konsoll så kan man bare gå inn på sin applikasjon, vi kan se hva det er som er galt. På en veldig enkel måte vise helt konkret feilen. For ofte kan vi bare se det. Og det å bare fortelle det direkte til utvikleren, og la de slippe den runddansen pluss det å måtte ha kunnskapen for å fikse det, det tenker jeg er en fin ting. Her er det noe med kostnadsoptimalisering å gjøre også. For når vi har henta inn alle dataene om en applikasjon, hvor mye bruker du, hvor mye har du bedt om, hvor mye har du overalt?

25:55 --> 26:44

Hva koster dette her sånn? Så kan jo vi gi indikasjoner til folk om hvis du bare justerer denne biten av spekken din til dette, så sparer du så mye penger i måneden. Og det funker. Team tar tak i det når de ser at det kan justeres og spares, så hopper de rett på. Så det er kanskje et av de andre sporene, det med kostnad og det å vise frem. Hva er det du har bedt om, og hva er det du faktisk bruker over tid, og synliggjøre det. Det er ikke noe som er trivielt å finne ut av heller. Så det er plattformens ansvar å gjøre det tydelig for teamene. Hva er det dere ber om, og hvor mye av det bruker dere faktisk? Og gi dem de gode verktøyene for å kunne right-size ting.

26:44 --> 27:31

For der er det utrolig mye å spare. Det tror jeg ikke handler om at de ønsker å sløse, eller at de bare tar i. Det er rett og slett fordi den informasjonen er godt gjemt. Og så lenge ting funker, så har man ikke noe incentiv for å se etter heller. Så det å få det fram og få det vist fram, det tror jeg man kan spare mye penger på. Du nevnte NiceTways, hva er det? NiceTways, ja. Det er noe som vi har laga sjøl da! Det er en mekanisme vi har laget for å kunne koble seg til ... Seg til interne ressurser, sånn at vi kan jobbe fra laptopene våre. Så f.eks. når du sitter med backen din, eller Vegard sitter med Linux-en sin,

27:31 --> 28:20

så er det et poeng at vi skal kunne kommunisere med clusterne, og gjøre ting mot de eventuelle interne domener som ikke er eksponert på internett. Så det er en måte for oss å jobbe fra laptopen vår. Så måten vi gjør det på, er jo ... For man ønsker jo en eller annen form for klientsikring. Være trygg på at devicen er så sikker som den kan være. Så tilnærmingen der er at vi bruker noe som heter Collide, som egentlig gir oss ... Den gjør en del basisjekking av laptopen, ser at ting er satt opp på en solid og god måte, men den gjør det ikke for deg. Den sier bare hvilke settings er det du bør ha, forklarer deg hvorfor du bør ha det, og gir deg disse instruksjonene på en ...

28:20 --> 29:03

Eller en lettfattelig måte. Rett på slack, egentlig. Så dette har vi kobla opp mot NiceDevice. Så hvis det er noe som er galt og graverende, så kan man basert på det kutte tilgangen til det, så du har fiksa det. Så i bunn og grunn så er jo egentlig NiceDevice bare en VPN-tunnel. Og grunnen til at vi har VPN-tunneler er jo det at alle clustrene våre er helt private. Vi eksponerer ikke noen IP-adresser eller noen ting, og de interne lastebalansererne og sånne ting. Så du kommer til da de helt interne tingene fra en ekstern maskin. Det er viktig å presisere at det er mikro-WPN-er. Vi bruker Wireguard under panseret, og oppretter egentlig en liten tunnel per person og spesifikk tilgang.

29:03 --> 29:55

Så det kan vi skille på at du er Hans Christian, du har disse og disse tilgangene, og da får du disse tilgangene hvis du ber om det. Det er også just in time. Du har ikke en kontinuerlig link open, det er hvis du ber om det for spesifikke ressurser. Noen av våre tusener på tusener av lyttere, antar jeg da. Har lyst på å lære mer om NICE. Hvor går de da? Vi har veldig glossy side på nice.io, og så er det mer info å få på dock.nice.io. Hvis man har noen spørsmål, hvordan kan man da få kontakt med dere? Vi har lagt ut noe kontaktinformasjon på nice.io. I tillegg til det kan du bare lage et issue på githuben vår: github/nice. Dette har vært superlærlig. Tusen takk Jonny og Frode for at dere kunne komme her i dag

29:55 --> 30:37

og dele denne erfaringen. Jeg håper vi får høre mer fra dere, for det er jo masse som er usagt om denne plattformen her. Vi kan bable i timevis, vi. Så litt skraper jeg over flappa. Audun, hva var dine highlights? Det jeg føler jeg har lært her, og som jeg fortsatt er litt skeptisk til, er at det finnes utviklere som egentlig ikke er interessert i hva som skjer nede i plattformen. Det syns jeg er spennende å tenke på. Hva med det, Ansistian? Hva har du lært? Jeg syns det er utrolig gøy å høre dette som gjøres rundt konsoll, og ikke minst dette med kost, hvordan vi kan bruke pengene på en fornuftig måte. Og ikke minst kanskje det er noe miljøhensyn her.

30:37 --> 31:12

Kanskje vi kan spare miljøet òg, hvis vi ikke lar ting gå på tomgang. Det er jo det vi skal, vet du. Vi har jo CO2-data. Det vil vi vise fra. Tusen takk for at dere var med oss i dag, Jonny og Frode. Mitt navn er Hans Kristian. Med meg i studio har jeg Audun. Og teknisk produsent er Tore Græsdal. Takk for oss. Ha det bra! Ha det bra!