Episoden er transkribert av kunstig intelligens

00:00 --> 00:50

Velkommen til denne bonusepisoden av Plattformpodden, en podkast om applikasjonsplattformer og teamene som bygger dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg Audun Faukalstrand. I dag har produsenten vår bedt om ordet. Takk for det, Hans Kristian. Jeg har sittet i kulissene i podkastinnspillingene våre og hørt på dere snakke om verdensarbeid. Dere snakker om mye relatert til plattformer. Selv om jeg har en del teknisk kompetanse, så er ikke jeg utvikler og kan ikke så all verdens mye om plattformer, så jeg har notert meg ned en liste over ord og uttrykk som jeg er litt nysgjerrig på. Jeg prøvde forrige uke å forklare til moren min hva Plattformpodden var for noe.

00:50 --> 01:30

Det er en liten spennende øvelse. Jeg prøvde meg på å si det at hun hadde et operativsystem på sin datamaskin. Og på den så kunne hun installere programvare. Mens en plattform handler mer om et operativsystem for en stor organisasjon. Hvor mye bomma jeg med den forklaringa til mor mi? Jeg syns du traff ganske bra. Det er i hvert fall et operativsystem for den tekniske delen av en organisasjon. Det er masse ting som skjer i organisasjonen som ikke er innenfor det vi tenker på om en plattform. Men for den tekniske delen, så syns jeg det er veldig riktig. Jeg har ofte hørt folk beskrive Kybernetes, som jo er den mest sentrale komponenten

01:30 --> 02:14

som operativsystemet til et datasenter. Altså mange datamaskiner. Og det passer egentlig ganske godt med det bildet du brukte. Jeg pleier gjerne å snakke om en byanalogi. Hvis du tenker på en by, så har du veier, strømnett, vann og avløp, og det er sammenlignbart med plattformen. Så har du husene, som er applikasjonene som bor i den byen, og de er litt forskjellige. Noe strøm ... Kan si ... Vann og strøm og ... Nei, men et kraftverk har gjerne forskjellige sikkerhetsmekanismer enn det en vanlig enebolig har. Og på den måten også som en plattform at det er forskjellige typer applikasjoner som bor på den.

02:14 --> 02:54

Alle er ikke like. Da benytter jeg anledningen til å hoppe litt langt ned i lista mi, for jeg syns det var interessant med noen ord som jeg for så vidt forstår, men ikke helt mestra. Jeg har notert meg load balancing, cluster og VPS og litt sånn forskjellig. Jeg går ut fra at det handler litt om datamaskiner som er involvert i infrastrukturen her nå, kan jeg stemme? Ja. Det kan jo bety litt hva eksempel, men hovedpoenget med nesten alle de applikasjonene og de applikasjonsporteføljene som de store organisasjonene har, er at det kjører på veldig mange datamaskiner. Du har ofte flere hundre datamaskiner i bånn.

02:54 --> 03:28

Og det drar jo på seg en del kompleksitet. Så et cluster er typisk flere datamaskiner. Cluster kan også kanskje være flere applikasjoner, men vanligvis pleier vi å si det er flere datamaskiner. Og så vil man kjøre flere av applikasjonene sine for å kunne være robust, sånn at hvis den ene går i stykker, så klarer fortsatt tjenesten å overleve. Hvis du har flere applikasjoner, og alle skal motta trafikk, så trenger du å balansere trafikken. Eller balansere lasten. Og der er "load balancing".

03:28 --> 04:12

Så det handler om å fordele trafikken fra brukerne over på forskjellige instanser av applikasjonen. Og dermed får du redundanse i sammenheng. Ja, for de kjører på forskjellige datamaskiner, og datamaskiner går stort sett i stykker. Det var noe du måtte ha et forhold til før plattform. Da visste du at min applikasjon kjører på server A, B og C. Og når jeg skal gjøre en ny versjon av applikasjonen min, så må jeg legge den over. Det er Kubernetes' mantra har vært å tenke på applikasjoner, ikke servere. Kubernetes' ansvar er å legge rett applikasjon på rett server. Hvis du sier at min applikasjon trenger å kjøre fem varianter, så vil Kubernetes sørge for

04:12 --> 04:51

at den blir spredd godt utover de serverne du har til råde. Du trenger ikke å tenke på de underliggende ressursene. Jeg tror det er forskjellige navn på den samme tingen. Jeg har notert meg NODE, POD og Instans. Er dette egentlig forskjellige navn på samme ting, eller er det nyanseforskjeller på dem? Det er litt forskjeller. For det første så har Kubernetes sitt eget språk. Den har et API, som er sånn du kontrollerer de tingene som skal kjøre i Kubernetes. Der har alle de forskjellige tingene helt eksplisitte navn. I Kubernetes så er NODE den nederste datamaskina.

04:51 --> 05:32

De som er en del av clusteret ditt. Alle datamaskinene i clusteret er NODER. Og så er applikasjonen ... Den ene av applikasjonene har de som lagde Kubernete, bestemt at skulle hete POD. Ofte tenker man på at det er en enda mindre del som er container. En dockercontainer, typisk. Som er sånn du pakketerer en applikasjon fra når du har utvikla den, og skal starte den i datasenteret ditt. Men de som lagde Kubernetes hadde erfaring fra Google, og der fant de ut at en container var egentlig for lite. Det var veldig vanlig at du ville pakkettere noen containere sammen,

05:32 --> 06:12

én som var applikasjonen din, én som kanskje var infrastruktur. Derfor kom de frem til at i Kubernetes så skulle den minste delen du kunne lage, være en pod, som kunne være én container eller flere containere. Det gir deg en ganske stor grad av fleksibilitet i hvordan du definerer hva en applikasjon er. Å sette sammen og gjenbruke forskjellige deler. Og så har du en mye lettere kontrollmekanisme, for de containerene inni en pod deler skjebne. De starter og dør sammen, og er alltid på samme datamaskin og har samme disk. Når du sier container, så får jeg assosiasjoner til en sånn shipping container. Og jeg husker jo den gangen Microsoft begynte å snakke om

06:12 --> 06:50

at en skulle levere datasentre i form av fysiske containere. Henger det sammen med dette? Eller er det mer en metafor? Nei til begge. Det er ikke en metafor, men det har ikke noe med de containerne å gjøre. Men siden jeg ikke er så veldig god på å forklare hva dere containere er, så skal jeg se litt over på Christian, så skal han få lov å si hva dere containere er. Jeg vil absolutt si at det er en god metafor, for en container er jo faktisk veldig definert. Det er spesifikasjoner som sier hvordan en shipping container skal se ut. Sånne ulike punkter som du kan feste den inn på en kran, eller ta de inn på tog og lastebiler. Analogien er det samme i applikasjonsverdenen.

06:50 --> 07:38

En container er noe du pakker en applikasjon inni. Så der kan det ligge hva som helst. Det kan være sofaer og puter og mat eller hvem vet hva. Ulike programmeringsspråk, hvordan applikasjonen din er sydd sammen, spiller ikke så mye rolle. Du legger den inni denne containeren, pakker den fint inn, og så kan du shippe den videre. Så det er en veldefinert måte å ta en applikasjon fra et sted til et annet og kjøre den. Uten å måtte trenge å vite hva som faktisk er inni her. Tidligere måtte man ha installert rett versjon av rett programmeringsspråk eller -kjøretidsmiljø. Si at du skal ha en Java. Da kan den kun kjøre på en Java-server. Har du en .nett-app, så må den kjøre på en server som har .nett-installert. Mens med containere er det eneste du trenger, er konteinerkjøretidsmiljø eller dokker,

07:38 --> 08:23

som kanskje folk er mest kjent med, og også kubanetestøtte. Du pakker den inn i en konteiner og gir den til Kubanetes, så kan Kubanetes kjøre den. Hadde dere kun sett meg nå, hadde dere sett ei lyspære over hodet sånn. Det er en standardisering av utsida av den, sånn at det ikke kan passe inn hvor som helst. På utsiden er det det, og på innsiden er det kanskje den letteste formen for datamaskin. Det er på en måte en Linux-datamaskin, som er beskrevet, som inneholder applikasjon. Så har du den mellomlage datamaskinen, som mange har, som er de nodne. Og så har du ofte datamaskinene i datasenteret. De fysiske datamaskinene, de som er lagd av jern. Datamaskin funker ikke så godt som ord lenger.

08:23 --> 09:02

Så blir folk forvirret. Er det en virtuell maskin? Nei, for det er ingen virtualisering involvert. Fremdeles kjører applikasjonen din rett på den underliggende serveren. Den er bare avgrenset fra. Så den konteineren finnes egentlig ikke. OK. Det var bra du oppklarte det. For jeg tenkte nå virtualisering på konteinerbegrep, men OK. Det er en viss forskjell der òg. Det er det for å gjøre ting enda mer komplisert. Audun, jeg husker helt konkret noen episoder. Når jeg har klipt på dem, hører jeg at du spør gjentatte ganger til gjestene

09:02 --> 09:42

om "Golden path" og om "day two". Hva betyr det? Så vidt jeg vet, så kommer golden path-begrepet, i hvert fall i vår bransje, fra Spotify. Sånn jeg tenker på det, så er det en måte å få folk til å gå i takt, og gå i samme retning, uten at du tvinger dem. Hvis du skal fortsette å snakke i overført betydning, så er det at man skal lage en veldig fin sti der du får lyst til å gå. Du kan gå hvor du vil, men se så fint det er å gå på denne stien. Hvis du gjør det, så kommer du fram. Hvis du oversetter det til plattform- og teknologibegrepet, så er jo ...

09:42 --> 10:18

Enten så kan du si at det er veldig mange måter å kjøre en applikasjon på, det er veldig mange måter å gjøre lastbalansering på, og det er mange måter å gjøre logging på. Så er det ofte et problem at utviklere liker å bestemme ting sjæl. Eller kanskje riktigere å si: De liker ikke å bli fortalt hvordan de skal gjøre ting. De liker å bli beskrevet liksom: "Her er problemet, løs det akkurat som du vil," "for du vil jo ha autonomi". Men f.eks. i Nav, som er så stort, så er det veldig bra at en del ting gjøres likt. Hvis du skal balansere det at ting skal gjøres likt, mot behovet som utvikler deg til å ha autonomi, så har vår erfaring vært at det å bygge en golden path og det å gjøre det lett,

10:18 --> 11:02

og gjøre det rett ... Ikke si "du kan gjøre hva du vil", det er ingen begrensninger her. Men dette er den lette måten å gjøre det på. Ja, for det er lett å gjøre rett og begrepa, har jeg hørt mange ganger. Og det er der det kommer fra. Vi sier lastbalansering, det gjør man sånn i Nice. Det trenger ikke du å tenke på. Du kan godt overgjøre det hvordan du vil, men hvis du bare skriver den én linja her, så får du alt ferdig oppsatt. Brolagt sti er også noe som andre bruker òg. Det var jo én vei som hadde brostein, den var den rakeste veien. Men så fantes det mange andre snirklete veier og landeveier som gikk over det fjellet osv. Men du ville gjerne gå på den brolagte veien, det var der det gikk raskest.

11:03 --> 11:56

Og du kan, hvis du har et behov, ta den lille detoren innom den lille landsbyen der. Du kan jo også kanskje si, hvis vi pakker på med forskjellige metaforer som er det samme, som jeg også har brukt, for det er gulrot og ikke pisk. Og så blei jeg alltid og så på at det går an å slå folk i hodet med en kjempestor gulrot også. Men det er mest for å få latter i salen, mer enn noen praktisk pluttydning. Det handler jo om å prøve å motivere folk til å gå den riktige veien, uten å si "du må". Når du snakker om brolagt og golden pass og sånne ting, så min uinformerte skepsis begynner da umiddelbart å tenke på uttrykket at veien til helvete er brolagt med gode intensjoner. Fins det noe sånt innenfor det her? Det vet jeg ikke, men det som i hvert fall kan være et problem,

11:56 --> 12:35

som vi også har erfart i Nav, er jo at innovasjonen stopper. Hvis alt blir likt. Vår bransje og den virkeligheten vi lever i, utvikler seg hele tiden. Det kommer alltid nye ting, og nye måter å gjøre det på. Så det er viktig at noen ganger så er det noen som har en åpenbaring, og som begynner å gjøre ting annerledes. Og da må det være mulig. Så det er veldig dumt å legge inn for mange begrensninger, for det er ikke lov å gå utafor stien. Da mister du en del innovasjon og gode ting som kommer. Og som regel når du har et monopol, hvor dette er det eneste måtet, så er den ikke spesielt god. Den er jo bare der fordi noen har bestemt at den skal være sånn.

12:35 --> 13:34

Og du har ingen incentiver på å gjøre det bedre, egentlig, for det er ingen alternativer. Monopolsituasjoner som vi ofte ser i en del organisasjoner, den er i beste suboptimal. Ok, så det var litt med å trekke ut her at det er litt regler for hvordan en opererer. Hvis jeg snur på det, sier regler fra innsiden. "Zero trust" er et uttrykk jeg har lært nå. Men hva betyr det? Skal ikke jeg stole på deg? Du finner vel sikkert like mange definisjoner som du finner mennesker. Hva legger du i det? Jeg tenker det letteste er å si hva det ikke er. Hvis vi skal være ganske konkrete, og igjen trekke det tilbake til Nav, så handler det om sikkerhet, og kanskje hvordan du setter opp sperrer. I gamle dager, eller fortsatt litt nå, Men før lagde man en sikkerhetsmodell hvor man hadde såkalt perimetersikring.

13:34 --> 14:11

Du hadde en brannmur som var rundt applikasjonene dine, og hvis du var ekstra flink, så delte du det opp i forskjellige soner. Og så var det vanskelig å komme inn i sona, men hvis du var inni sona, så hadde du tilgang til alt. Og det ga en viss form for sikkerhet, men det var også faren med at du hadde lite sikkerhet innafor. Og så fant man, dette tror jeg kommer fra Google, Leo... De kalte det vel "Beyond core" og den type ting. Men de tok en ny måte å se på sikkerhet på, at du skulle ikke stole på noe. For i den sonemodellen stoler du på alt som er inni sona.

14:11 --> 14:55

Men hvis du snur på det og sier "jeg skal ikke stole på noen", så må jo hver eneste applikasjon ha sin egen lille sone rundt der det ikke er noe i. Og da må man sette på tilgang, så må alle applikasjoner definere hvilke applikasjoner du kan snakke med, og hvilke som skal snakke med deg. Så får du en liten brannmur rundt hver eneste del. Så kan du dra konseptet videre til hvordan utvikler skal få tilgang. Du skal ikke ha store VPN-er. Du skal liksom hver eneste ... Du skal aldri stole på at noen andre gjør den sikkerhetssjekken du mener skal gjøres. Den må være sammen med det du lager. Har du hørt om historien om den trujanske hesten, Tore?

14:55 --> 15:39

Det er litt det samme at du lurte deg inn forbi portene, og så var slaget over. Det var sikkerhetsbarrieren den dagen, den tiden. Mens i et zero trust-nettverk kan du tenke at vi har gjerne den ytre muren, men så har vi mange murer innvendig òg. Hvert hus har sin mur. Det nytter ikke bare å komme forbi den hovedporten, da må du fremdeles bryte ned dører Sprenge deg inn til der hvor du faktisk skal til syvende og siste. Så er det utgangsdør, og så er det til og med dør til doen. Hvert rom! Men døra til doen, der er det lås, for der er det ekstra viktig at ingen kommer inn. Du kan jo ha forskjellig ... Det betyr også at du kan i større grad velge

15:39 --> 16:20

hvilket nivå du skal legge deg på. Når du har mange barrierer, så kan du si: Dette skal alle ha tilgang til. Og så har du muligheten til å gjøre det, fordi det er noe som alle bruker. Tilbake til bymetaforen. Personboligene våre, de har vi låst på ytterdøra. Men så har de fleste av oss ikke lås på doen. I hvert fall ikke fra utsiden. Men så kommer du til Nav sitt kontor, hvor vi sitter i dag. Her er det ekstra. Her må du ha adjanskort for å komme inn på de ulike rommene opp i etasjene. På politiet må du gjennom sluser, og du har enda strengere rom. I hvert fall veldig få tilganger. Etter hvert som det blir mer og mer kritiske bygg,

16:20 --> 17:10

så er det strengere sikkerhet. Det er litt samme tankegangen der. Alle applikasjoner er ikke like. Det er en svær feiltakelse. Men her kutter vi alt over én kam, og den er kjempehøy. Det er så unødvendig. Jeg heller setter inn støtet der hvor det virkelig er ... Likevel tenker jeg at vi skader sikkerhet på alle applikasjoner, men så skal vi ha ekstra sikkerhet der hvor det trengs. Det er jo en veldig fin måte å drive skadebegrensning på også. Jeg hopper videre på lista mi, jeg har notert et ord her nå: "service mesh". Hva er det? Det er jo en måte å implementere, spesielt i reglene om tilgangskontroll til applikasjoner. Så jeg gikk glipp av en segway egentlig, å snakke om sikkerhet.

17:10 --> 17:50

Ja, på en måte, men det hadde blitt komplisert det, sikkert. Fordi når man da skal definere disse reglene, så må man det. Man må på en eller annen måte ha noe software som kan implementere definisjonene, som faktisk kan stoppe. En service mesh-gjør er å lage et sånn lag i nettverket, der du kan lage de reglene som opererer på applikasjonsnivå. Vanligvis pleide man å ha den type regler på nettverks- eller IP-nivå. Men i en verden hvor du har disse containerne, og du har flere instanser, og de er mer dynamiske, de hopper rundt fra datamaskin til datamaskin, da vil du egentlig snakke om applikasjon A skal ha tilgang til applikasjon B.

17:50 --> 18:22

Og da måten de har gjort det på, er jo da å bruke ... Det er allerede blitt flere forskjellige måter å gjøre det på. Enten så kan du lage nye containere inne i poden, eller så kan du bruke finurlige mekanismer i Linux-kjernen. Men poenget er at du trenger en eller annen proxy, som all trafikken inn og ut av applikasjonen går gjennom, og en mulighet til å lage regler for den proxyen. Og proxy-en, jeg vet ikke hva jeg vil. Det er en mellomdatamaskin som ... Så det du egentlig bare trenger, er å sette regler. Du lager veldig mange bitte små brannmurer

18:22 --> 19:06

som du konfigurerer mye mer spesifikt for hver applikasjon. Og så kan de gjøre en del andre ting òg. F.eks. retry, og det å prøve på 91. Her snakker vi om en ganske avansert funksjonalitet som ikke så veldig mange bruker. Og jeg tror nok for veldig mange så er service-mash litt overkill. Den andre tingen som er veldig nyttig, er at når du har et sted hvor all nettverkstrafikken går gjennom, så kan du telle. Du kan telle feil og trafikk og antall requester på en helt uniform måte, så du slipper å lage den logikken på alle steder. Du har den bare ett sted. Disse containerne kan være Java, Python, Node IS, ulike programmeringsspråk.

19:06 --> 19:46

Så det å ha standardiserte måter å kontrollere en del av den trafikken og kunne forme den, kan være nyttig i en del sammenhenger. Jeg har også notert meg et ord, og jeg forstår ikke det ordet som gjør det vanskelig å bygge en Segway. Men operators og også jammeldreier har vært nevnt noen ganger. Da begynner vi å komme på ganske komplisert Kybernetis. Men skal vi se hvordan vi klarer å komme oss til Operators, da. Kybernetis hadde jo det API-e, som styrer hvordan applikasjonene kjører. Hvordan de deployes, hvordan trafikken rutes, alt det der. Det kan man enten bare bruke enkelt, eller så kan man lage kode

19:46 --> 20:33

som snakker med det API-et. Og det er egentlig det operators er. Det er applikasjoner som styrer Kybernetes. Sånn at du kan automatisere det du har lyst på å gjøre ofte i en sånn verden. Hvis plattformen din har en veldig komplisert deployment-mekanisme, du må kanskje deploye ... Du har en global tjeneste som skal deploye klokka åtte. På lokal tid. Så trenger du noen kode som kan tidssoner, og som styrer disse kallene, og som jobber i Kybernetis og deployer her og der. Eller du skal ha deployer sakte inn i ett cluster, så det ikke går ned. Det er egentlig bare en måte å automatisere

20:33 --> 21:11

driftsel og deploy og operasjonslogikk på. Men det er et uttrykk som jeg liker å bruke: livssyklus. Det tar mer enn bare å deploye applikasjonen. Det Kybernetes er ganske god på, er å se mens den applikasjonen kjører, eller mer spesifikt, hvis den ikke kjører, hvis den møter på et problem, så har Kybernetes mekanismer for å gjenopprette. Det er ikke sånn veldig superavanserte, men prinsippene er det samme der. Med en operator så tenker du også den livssyklusen. Du nevnte dag to. Hva skjer de dagene etter den er gått i produksjon og ute og kjører. Det å ha systemer som sørger for at det er operator.

21:11 --> 21:51

At det er god helsetilstand, istedenfor å ha veldig dyre mennesker og mennesker som er feilbarlige. Vi skal sove, vi skal spise. Vi kan ikke sitte og se på en monitor 24/7. Men det å ha systemer som har ansvaret for å forvalte systemene våre. Det er der den operator-tankegangen kommer inn. At vi som administratorer eller plattformutviklere kan sitte i vanlig arbeidstid og kode disse mekanismene, og så kan de kjøre 24/7 og gjøre den harde jobben for oss. Sånn at vi slipper å måtte stå opp natt til julaften for å fikse et eller annet driftsproblem. Det tar plattformen i større grad hånd for oss. Det hadde egentlig vært fint, for da kunne du sett nissen.

21:51 --> 22:38

Ja, det er kanskje et godt poeng. Vi begynner å nærme oss at vi skal gå inn for landing, men jeg har også notert med et par ord som jeg tror kanskje rett og slett er produktnavn. Kan jeg bare liste opp litt veldig kjapt flere navn, og så kan dere oppsummere hva de gjør. Terraform, Istio, Antos, Prometheus og Crossplane. Er alle disse produktnavn? Ja. Kan du si med én setning hva hver av dem gjør? Terraform. Infrastruktur, automatisering. Og så Istio? Det er én implementasjon av et service mesh. Jeg har faktisk dette her, GKE. Det er Google Cybernetics Engine. Det er Google sin host av kybernetisk tjeneste.

22:38 --> 23:20

AKS i Asher og EKS for Elastic i Amazon. De var for seint ute, så de fikk ikke annet. Og så Antos? Det er vel den Enterprise-versjonen av GKE. Den dyre versjonen, som også kjører på on-premise-clustere. Ja. Og så hadde vi til slutt Prometheus. Prometheus er egentlig en database, som lager tidsserier. Den tellinga du gjorde i ... Proxy in this series measure, for å telle nettverkslag ... Nå blir det lang setning, Kine ... For at du skal kunne bruke den tellinga til å sende data, må det lagres på en spesiell måte.

23:20 --> 24:03

Du må lagre masse tall etter hverandre. Det er Promithius. Den er spesiallagd for å lagre masse tall. Og så har du et matematisk spørrespråk, så du kan lage grafer. Du kan f.eks. få en graf over trafikken eller en graf over feil inn i Grafana, Som er kanskje det vanligste dashboard-applikasjon for å vise Promithius-data. Det Audun prøver å si er aggregerte med trikker. Ja takk. Ja visst. Og så sa jeg sist et til, og det var crossplane. Det er en operator. Så det er noe du installerer i Kubernetes-clusteret ditt for å utvide vokabularet for å kunne automatisere infrastrukturen. Så du kan få opprette databaser på skilleavhengigheten. Da tror jeg at jeg sier tusen takk for meg og spørsmålsrundene her nå.

24:03 --> 24:55

Jeg vil oppfordre lytterne til å sende oss spørsmål hvis det er noe jeg har greid å dekke her. Så skal jeg gi dere ett avslutningsspørsmål som dere kan ta på slutten, og så tar Hans Christian avslutninga her nå. Hvis dere nå hadde blitt teleportert inn i ei bedrift som ikke var moden til å kjøre plattform, og dere skulle kanskje presentere for et styre som ikke hadde helt digital modenhet, hva i all verden ville dere da ha sagt? Da hadde jeg begynt med å fortelle litt om hva som står i en av mine favoritt-hitterbøker, nemlig Accelerate, som kort fortalt sier at det er en av forskning som viser at hvis du er god på å endre koden din ut i produksjonen, så korrelerer det med hvor bra butikken din går.

24:55 --> 25:44

Altså hvis du er god til å deploye og god til å teste. Du deployer ofte. Og hvis du ikke er moden, så er det ganske vanskelig. Nav var jo der for en stund siden, der vi endra deploya fire ganger i året. Så da handler det om å prøve å finne ut hvordan kan vi begynne å gjøre det oftere? Og det er det plattform er. Plattform er jo å lage verktøyene som gjør at du kan få til det. Ja, jeg hadde sagt at demotiverte ansatte lager dårligere produkter. Og i dette veldig konkurransepregende markedet som vi er i nå, så er utrolig kamp ... Hvis du vil ha de flinke folkene, og de skal lage gode produkter, så er du nødt til å tilby de gode verktøyene og en god måte å jobbe med applikasjonsutvikling. Det er selling point for plattformen.

25:44 --> 26:22

Med det avslutter vi denne bonusepisoden. Tusen takk til dere som har lyttet på oss i dag. Mitt navn er Hans Kristian Flåtten, og med meg har jeg Audun Faukan Strand. Teknisk produsent er Tore Græsdal. Lik og subscribe der hvor du finner podkaster. Vi er på LinkedIn. Følg oss på plattformpodden.no. Tusen takk for oss. Ha det bra!