Episoden er transkribert av kunstig intelligens

00:00 --> 00:44

Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg min trofaste Audun Fauchald Strand. Og i sesong to av Plattformpodden løfter vi blikket og ser på ulike plattformer i bank, forsikring og handel. Men før vi introduserer dagens gjest, Audun, har du en favorittpodkast, bortsett fra vår? Har du en favorittpodkast, bortsett fra vår selvfølgelig? Bortsett fra vår, ja. I mitt vanlige liv er jeg interessert i fotball, og min favorittpodkast er jo When We Were Kings, som ofte har tre-fire timers episoder om enkeltsesonger i fotballklubbers tid.

00:44 --> 01:26

Og en gang hadde de en tolvtimersepisode om Messi, som jeg syntes var veldig bra. Så det er min favoritt, hvert fall. Hva med deg, Kristian? Jeg kunne aldri klart tolv timer med Messi, eller noe som er en annen fotballrealitet. Darknet Diaries er en podkast som er utrolig mye spennende. Og så er det veldig høyt redaksjonelt gjennomført, med hvordan de klipper og produserer de episodene. Utrolig respekt for den podkasten der. Men forhåpentligvis ikke så mye Darknet vi skal snakke om i dag. I dag er vi så heldige å ha med oss Rida Atif og Sigurd Falk fra Gjensidige. Gjensidige er et norsk forsikringsselskap som de fleste av oss kjenner,

01:26 --> 01:58

pensjon og sparing. Velkommen til oss. Av dere to er det du som har jobbet lengst i Gjensidige. Kan ikke du fortelle litt om din rolle? Først vil jeg bare nevne at fotball er også min interesse. Kanskje helt sinnssykt gal etter fotball. Jeg så en episode på Netflix, vet ikke om du har sett den Audun, men det dreier seg om VM og hvordan den reisen har vært. Utrolig interessant. Den må du se, den var bare en time, så det går an å se. Én time er litt lite, nei. Jo, vi falt i min reise. Jeg starta i Gjensidige i 7.17. oktober.

01:58 --> 02:46

Jobba jo i Finn før det, som jeg også vet at Audun har gjort. Og har egentlig vært interessert i ledelsesplattform hele tida og ønsket å gå den veien. Da jeg starta i Gjensidige, så var det det jeg gjorde. Og der har jeg vært siden. Og trives veldig godt med det. Og nå leder jeg jo Plattformtime i Gjensidige. Utrolig spennende og jeg gleder meg til å dykke mer ned der. Sigurd, før vi dykker ned: Hvordan endte du opp i Gjensidige, og hva er din rolle? Den første i min rolle er jo da Techlead i Plattformteamet. Jeg endte opp i Gjensidige med god hjelp av Rida. Det skal sies at jeg har vært i selskapet som konsulent noen år før jeg starta fast i akkurat når korona inntraff cirka.

02:46 --> 03:37

20.4.2020 ansatte Ida meg, og det var ca. akkurat da vi ble konvendert på hjemmekontor. Det er også noen spennende måter å starte den karrieren på. Men jeg har bakgrunn hovedsakelig fra som applikasjonsutvikler. Så jeg syns det var gutsy av Rida å ansette meg som techlead i Plattformtime, uten noen spesiell infrastrukturerfaring. Men jeg har alltid hatt den infrastrukturgleden, og alle hobbyprosjektene mine har jo vært preget av at jeg satte opp infrastruktur, og så var selve applikasjonen og så var selve applikasjonsbiten ganske nedprioritert og ble sjelden ferdig, da. Så det er bakgrunnen min, og jeg var veldig fornøyd med å være i Plattformtime i dag. Jeg skal være så ærlig å si at det er jo min bakgrunn òg, og jeg tenker at det er et veldig godt utgangspunkt

03:37 --> 04:19

det å ha den forståelsen for applikasjoner, og det å kunne sette dem i utviklernes sko, og bygge en plattform som passer for dem. Det er jeg veldig spent på å høre mer om. Men kan ikke du en av dere gi en intro. Plattformteamet i Gjensidige, hvordan ser det ut? I dag er vi elleve personer, og det er stort sett plattformutviklere. Vi har en skyarkitekt og meg selv, og så har du rene utviklere. Og som Sigurd sier, dette er jo applikasjonsutviklere som har gått en vei, og skal drive med infrastruktur, som er utrolig interessant. Og det var faktisk et bevisst valg fra min side da jeg startet å bygge dette teamet her. Men det har faktisk vært suksess,

04:19 --> 05:13

og kanskje det viktigste grepet vi har gjort for å lykkes der vi er i dag. Er det noe opptelling av elleve stykker i ett team? I vårt internettform? Ja, det er elleve totalt i vårt team. Så vi prøver å ikke ha for mye fokus på roller i teamet. Tanken er at alle kan drive med alt, at vi er en gjeng med plattformengineers. Men hva legger deg i plattform? Hva er Gjensidiges plattform? Hvordan ser den ut? Ja, den bygger hovedsakelig på Kubernetes, da, som så mange andre plattformer også. I tillegg til å fokusere på å tilgjengeliggjøre pass-tjenester i Asher, fordi det er jo Asher som er hovedskyen vår, og hele plattformen er skybasert, da.

05:13 --> 06:05

Så det vi fokuserer på, er å bygge HappyPat for deployment av applikasjoner på Kubernatus, og også gjøre det så enkelt som mulig å tybook alle disse pass-tjenestene i Asher, som eventuelt trengs for å kjøre disse applikasjonene. Hvilke av pass-tjenestene tilbyr dere alt, eller prøver dere å begrense hva som kan brukes? Ja, vi prøver jo å begrense, men vi har ikke noe ... Vi sier ikke at "dette er kun det vi tilbyr", vi lar utviklerne på en måte kunne velge det de ønsker, men så hjelper vi dem litt kanskje med ... Hvis de sier de ønsker seg en eller annen litt fancy database som er helt ny, og resten har sjappa og kjører på PostGas, så prøver vi å nudge dem kanskje dit hvor alle de andre er.

06:05 --> 06:55

Hvis det ikke er noen veldig gode grunner for at det use caset dem er spesielt bra, da. Hvordan jobber dere med teamene for å finne ut av hva dere skal bygge og hvordan plattformen skal se ut? Det er et kjempeinteressant spørsmål. Det har vært en lang reise for å komme dit. Det er Sigurd snakker om nå, det at man bygger et pass-tjeneste osv. Men det har vært en lang reise fordi vi snakker om et over 200 år gammelt selskap som er veldig tradisjonsrikt og veldig god på forsikring spesielt. Men de er også veldig tradisjonelle i forhold til IT. Det har de vært i mange år òg. Med det mener jeg at de er vant til å sette ut mye av driften til leverandører. Da jeg starta i 2017, så jeg veldig preg av det. Det er jo fint, det,

06:55 --> 07:45

men vi ønsket også noe annerledes, og det var sånn vi begynte å bygge en plattform. Som mange andre selskaper så snuste man på sky, sky var jo veldig hot rundt 2017, 2018, 2019. Og gjensidig også ønska å gå i den retningen. Og vi hadde jo en leverandør, som sagt. Vi fikk i oppdraget med å flytte oss til Sky. Da var det mange strategier man kunne velge mellom for vår del. Dere har sikkert hørt om Liften Skift. Det er ett av mange strategier, og det var det vi sto på. Det å flytte alle applikasjoner, porteføljen, ut i Sky. Uten å gjøre noen refakturering eller modernisering, as is, og så spinne opp i Vemør. Det var det vi gjorde, da. Men vi så ganske tidlig at vi fikk ikke noen praktiske gevinster ut av det. Vi var i Sky, men det føltes ikke som Sky.

07:45 --> 08:27

Og vi brukte ikke de teknologiene vi ønsket å bruke i Sky heller. Det var da den reisen starta. Det å kunne snakke med gjensidige, det å få forankra og beskrive hvorfor vi burde gjøre det, hva miljøet vårt trenger osv., det var en reise i seg selv. Men vi klarte heldigvis å banke det inn, at den veien hadde vi lyst til å gå. Så det var steg én. For det krever jo at man faktisk tar inn. Bygger et team, som du nettopp har gjort? Det var steg to, for vi innså at vi trengte å gjøre noe annerledes. Vi ønsket å ta litt mer eierskap, og det å bygge et team, for det teamet vi hadde tidligere, besto av syv konsulenter og to ansatte.

08:27 --> 09:10

De var delt på tre andre konsulenthus. De ansatte som var der, var rene driftere, ingen hadde ashocopinans i det hele tatt. Så da starta jeg med å bygge et team, og det ønsket jeg å bygge med fastansatte. Rett og slett fordi det er viktig kompetanse, jeg hadde en plan. Og også ønsket å konsulentkomvertere de som ønsket å være med på den reisen. Det målbildet. Vi skulle til Ski, vi skulle gjøre masse fancy, kule ting. Det var sånn reisen starta, og det var sånn jeg klarte å overtale Sigurd. Han var jo konsulent i Beck, men i ECD, så jeg hadde veldig mye prat med han, og ønsket å få han om bord. Så han var kanskje nummer to. Så han satt hos meg da.

09:10 --> 09:50

Så jeg klarte å konsulentekonvertere stort sett alle, nå er vi bare fastansatte, fordi det var viktig å ha den kompetansen internt. Visjonen om å ikke drive med liften shift var viktig for meg da. Når Ride har overtalt meg, og ser at her er det noe vi faktisk kan gjøre, og at vi faktisk kan begynne å tenke plattform og de kule tingene der, da. Hvordan angrep dere det, når dere hadde masse VM-er? Og en arkitektur som ikke var det dere ville ha. Fra et plattformperspektiv, hvordan fikk dere applikasjonene til å begynne å forandre seg, hvordan gikk dere fram da? Ja, jeg vet ikke, du kan kanskje si litt mer om Rida.

09:50 --> 10:37

Men det første vi gjorde, var jo egentlig å ikke tenke plattform. Altså vi begynte i et sånt landingssoneperspektiv, hvor hvert team skulle få sin landingssone i Asher, som skulle være satt opp med nettverk. Og tilgangsstyring og de basic tingene. Og så skulle du få lov til å holde deg der og spinne de tingene du trengte. Og da tenker jeg at vi gikk i den litt klassiske fella, og tenker at alle syns infrastruktur er like morsomt som det vi gjorde i plattformteamet. Som jo da viste seg å ikke stemme. Og det ble vanskelig. Og jeg tror nok at vi fort fant ut at vi hadde et stort kompetansegap. Som ble for tungt å fylle i organisasjonen

10:37 --> 11:23

til at man skulle drive på en sånn måte hvor teamene gjorde veldig mye av de tunge løftene selv. Når vi bygde dette teamet, var det ikke platform engineering som var fokuset. Det var egentlig å rampe opp Asher-kompetansen internt i teamet først. Vi visste jo ikke hva vi skulle bygge, men vi trengte Asher-kompetanse. Så det var det vi starta med, og da måtte man bygge kompetanse på det. Så var det fokuset vi hadde, først og fremst. Og det var også interessant, da. Dere begynte med landingszones, men nå har dere mer en ordentlig plattform. Hvordan ser den ut? Ja, den ... Stort spørsmål, egentlig. Men det er jo litt sånn, som sagt, at vi fant seg i at dette med landingszonene fungerte ikke spesielt godt i Gjensidige.

11:23 --> 12:10

Og det var grunnen til at vi begynte å tenke plattform som utgangspunkt. Og da var vi litt fram og tilbake på om vi skulle begynne å tenke litt sånn app. Vi skulle begynne å tenke litt sånn app-services i Asher i starten. Var inne på litt forskjellige function-apps og sånne ting, vi skulle bygge noe rundt det. Og så var vi litt rundt i andre selskaper og høsta erfaring fra de. Og basert på det vi snakka med andre om, så landa vi fort på at det var Kubernetes som var det riktige valget for oss, da. Så plattformen vår i dag ser ut ved at vi har bygd en del ting på Kubernetes. Alt fra montering, en del sikkerhetsmekanismer, deployment, egentlig hele den HappyBat man ofte snakker om for utviklerne,

12:10 --> 12:58

sånn at det skal være så sømløst som mulig å få en applikasjon, eller en container i dette tilfellet, til å spinne, og at du har full kontroll på den når den kjører i produksjon. Hva er grensenyttet som utviklerne ser av når de skal begynne med en applikasjon? Er det jam, eller er det et web-bap hvordan det ser ut? Vi er jo veldig githubs-drevet. Vært det fra starta av. Så grensesnittet er hovedsakelig github. Siden githubs er jo basert på at hele sannheten av både applikasjonen og infrastrukturen skal ligge på github, og vi synker infrastrukturen mot det som hele tiden er github, da. Så det er hovedgrensesnittet. Men så kjører vi også.

12:58 --> 13:47

Argo CD som githubs-operatoren som gjør selve deployen. Der har man jo også et GUI som jeg kan legge til har vært supernyttig. For en organisasjon som var helt blank for Kubernetes, og mye spørsmål i starten på hvordan alt dette henger sammen, replikkasett, podder, deployment, sånne typer ting. Å få det visualisert i Argo CD, som har dette GUI. Det har vært supernyttig. Men den konfigen, ligger den sammen med applikasjonen, eller har vi liksom etter repo for alt sammen? Det var ... Vi starta vel med at det lå sammen med applikasjonen. Og så ble det til at de fleste egentlig ikke likte det på githubs-veien.

13:47 --> 14:29

Hovedgrunnen til det er at man gjør så mye commit tilbake på ... Med en gang du gjør en endring på applikasjonen din, skal du ha et nytt tag på container imaget. Som committes tilbake til koden igjen. Så du fikk masse commits fra en eller annen bot, som sørga for at det der gikk rundt, med github-actions. Så måten vi gjør det på, er at som en del av teamene som blir onboardet på plattformen, er at de får sitt eget manifesterepo. Og der lever alle manifestene til alle applikasjonene til dette enkelte teamet. Og når jeg snakker om manifester, så er det fortere å tenke at ... Er det fortere å tenke at vi driver med 100 000 linjer i jammel?

14:29 --> 15:25

Det er jo også kanskje litt der vi starta ut. Vi hadde en tanke i starten på at teamene skulle få lære seg Kubernetesk skikkelig, og lære seg minst mulig av våre abstraksjoner. At de skulle kunne bygge Kubernetesk kompetanse, de som ønsket det. Det var nok også litt oss igjen som tenkte at alle syns det er kult med innforkstudier, selvsagt. Men så gikk vi over til å bruke JasonNet, fordi der har du mye større muligheter for å lage lekre abstraksjoner. Så vi har et sånt applikasjons-JasonNet-bibliotek, som er det vi anser å være en best practice-applikasjon, med sikre defaults og alt det der. Og så kan teamene bruke ...

15:25 --> 16:14

Vi bruker den til å deploye sin ting. Så jeg inkluderer egentlig bare biblioteket. Så trenger de for en enkel applikasjon å endre ... Altså sende inn fem til ti parametere, og så har du en applikasjon. Hva kan vi lage med den? Er det Kubernetesk ting? Er det API-gateways, databaser? Hvor langt har dere tatt? Mest Kubernetesk ting. Som går på det å hente secrets og få en identitet. Få selve deploymenten som håndterer podene og alle de kubeinstingene. Databaser og sånne typer ting. Og litt tilbake til det vi snakka om, pass-tjeneste i starten, det er mye terraform. Og der forsøker vi det, og det blir jo litt det andre grensesnittet

16:14 --> 17:05

som utenriksministrene må forholde seg til, er jo det at vi lager moduler for de tingene pass-tjenesten gjør, som vi på en måte støtter. Det er typisk databaser, cash, storage accounts, key vaults, sånne typer ting. Så vi har ferdiglagde moduler for dem, som skal gjøre det så enkelt som mulig for utvikleren å forholde seg til det. Selv om vi ser jo at det er litt vanskeligere for dem å drive med terraform enn den githops-baserte flyten. Ligger den terraformen i samme team-repo, eller er det sentralt? Da har de sine egne repo-ord for det, så det lever litt på utsiden. Men det er på en måte sydd sammen til en viss grad, ved at vi har sørget for

17:05 --> 17:51

at den identiteten du får i Cubatsman-vestet, og det du får via den Best Practice-appen vi tilbyr der, skal være enkel å bruke mot databasene. Sånn at du kan ha et passordløst oppsett og alle de tingene der. Det Sigurd snakker om er veldig interessant, for det å "onboarde" teams har vært stort arbeid hos oss. Før vi bygde denne plattformen, så vi ganske tidlig at vi ønsket å teste med noen av de teamene vi mente var veldig modne til å komme til Sky og til vår plattform. Og strategien vår var jo å la dem få full autonomi i Skyen. Vi skulle bare sørge for at det var et fundament i bunnen.

17:51 --> 18:22

Og da vi pokka med ett eller to eller tre team, så jeg husker ikke feil, da innså vi ganske tidlig at det var en del gap rundt kompetanse i Asher. Og her måtte vi gjøre noe grep. Og det Sigurd snakker om, det å prøve å standardisere plattformen litt, det å lage en happy path for disse utviklerne, det å "onboarde" dem, holde dem i hånda og spinne opp den første tjenesten på test, og så ut i produksjon, det var et massivt arbeid. Og det krevde utrolig mye fra plattformteamet, altså vårt team. Og det er ikke nødvendigvis bare det tekniske, det var også ikke-teknisk også.

18:22 --> 19:04

Det å lage videoer, det å være i ledergrupper. Jeg og Sigurd misjonerte masse, vi snakka med mange ledergrupper for å fortelle litt om hvorfor vi gjør det. Det å få teamet til å prioritere den reisen, det å komme ut i sky, bygge kompetanse osv. Masse arbeid som vi er veldig stolte av når vi ser tilbake på det. Kanskje litt kort inn på en morsom historie med den misjoneringen vi gjorde i starten. Vi bygde en demo-app som vi kjørte i produksjonen, på gjensidig.no. Hvor du kunne ha en liten feature togel, og så fikk du opp en svær sånn demo, demo, danger zone-boks, da, på liksom gjensidig.no. Der hvor alle kundene var til våre møter.

19:04 --> 19:50

Og så kunne du trykke på en knapp som simulerte, jeg husker ikke hva det var, men i hvert fall simulere CPU-bruk til 10 000 samtidige brukere, da. Og så gikk vi til alle ledergruppene med dette, helt oppe i konsernledelsen, og viste dem for side oven: Her har du den knappen. Og så sitter de og bare rister på hodet. Og det var viktig for oss å vise dem hva moderne infrastruktur kan gjøre, da. For det var jo også litt av historien at vi kunne aldri ha trykka på denne knappen, hadde vi hatt kjørt på disse serverne vi hadde i det gamle datasenteret vårt, on-prem. Mens her så kunne vi da dra opp interface i argo cd og vise dem hvordan podene skalerte ut, etter hvert som jeg trykka på denne knappen her.

19:50 --> 20:30

Pass dere på å ikke vise regninga, da, eller? I starten var det ikke så mange som var så interesserte, faktisk. Det kommer etter hvert. Det kommer nå. Men det skulerer kanskje ikke at dere er rundt og snakker med alle teamene hele tiden? Er det noe dokumentasjon, er det noe sted hvor teamene kan gå for å dykke dypere og komme i gang uten å måtte involvere dere? Det har vi. Vi lagde en landingsside. Der har vi dokumentert masse, blogga til og med også. Faktisk tatt inspirasjon fra Nice, det kan vi nevne. Så der har vi jo lenket opp litt til teamene.

20:30 --> 21:15

Så før vi onboarder dem, har vi bedt dem lese litt opp på hva Ash dreier seg om. Se på noen videoer, vi lagde en kubanetisk-video for nybegynnere, faktisk. Så det har vært veldig nyttig. Og så har vi onboarda teamene som ønsket å spinne opp tjenester i sky. Vi hadde en strategi mot Liften-skiftet først. Og så har vi parallell bygd en plattform, en del som har blitt gap i dag. Men vi har sett at teamene har pekt seg inn mot den plattformen vi har bygd nå. Og vi har ingen driftsleverandør som sitter på andre siden og venter på oss. Det er plattformteamet og teamene. Det er vi som skal ha eierskap til her. Kan legge til litt der også at vi har superfokus på community-bygging.

21:15 --> 22:04

Og det er jo egentlig noe vi kanskje anser som en del av plattformen. Altså at det er noe plattformen kunne ikke eksistert uten community rundt den. Så vi driver jo veldig mye på på slack, har åpne kanaler der som folk kan stille spørsmål, få svar. Vi har en policy i teamet hvor vi er veldig fornøyd med at ingen meldinger skal gå privat. Hvis folk kommer og spør spørsmål om plattformen direkte til en av oss, så skal responsen tilbake være at dette kan du ta i de åpne kanalene, sånn at de andre kan få nytte av det i tillegg. Og da har vi tatt tanken det at det finnes en kritisk masse for kompetanse i selskapet før den ballen begynner å rulle av seg selv.

22:04 --> 22:46

Og det jobber vi hardt med å oppnå på de tingene vi etablerer i plattformen. At det er nok folk som skal kjenne deg godt nok til at ... Til at det blir mindre behov for oss i plattformteamet, da. Det er interessant, for vi så også tidlig at plattformteamet ble flaskehals i miljøet. Fordi vi var de som bygde plattformen, hadde kanskje litt mer erfaring rundt Asher. Da var det vi som fikk alle spørsmålene, vi skulle hjelpe dem. Så det å skape den communityen, det å ha ambassadører innad i teamene, har hjulpet veldig. Slik at de kan spre kompetansen innad i sitt team. Og så er det andre som kan svare i slack. Det trenger ikke å være plattformteamet. Det har vi brukt masse tid på å bygge inn, da.

22:46 --> 23:39

Det er den tanken med ... Vi kom nok fra et sted da jeg starta i plattformteamet, der var vi litt sånn "closed by default, open by request". Supervanskelig for folk å samarbeide, og hvis du skulle bidra på noen kode, så måtte du inn i en eller annen jungel for å finne riktig person som kunne gi deg tilgang. Det var også noe av det første vi gjorde, det var strategisk å få på plass slack og github. Og sørge for at alt som blir oppretta i de to kanalene er åpent, med mindre det absolutt er behov for at det skal være lukket. Så vi har hatt en veldig sånn tro på denne tanken med det de kaller inner source på github, altså open source internt i selskapet. Og jobba masse med å etablere det og sørge for at riktig mekanisme er på plass

23:39 --> 24:35

for at det skal være så friksjonsfritt som mulig. Og samarbeide med team til team, men også team til plattformteam, som er oss. Så dere får faktisk noen contributions fra teamene inn til det som plattformteamet lager? Ja, vi har godt over 100 contributors på mange av repene våre i github. Hvor stort er Gjensidig? Hvor mange utviklere, mange teamer og mange apper? Vi er rundt 350 utviklere, altså i IT-utvikling. Ja. Mange apper, det er jo ... Plattformen i dag kjører vel over 400 egenutvikla applikasjoner i produksjonen. Hvor mange clustre og sånn har du der? Det er stort sett ett applikasjonscluster. Så vært i diskusjon rundt det også, hva som er smart.

24:35 --> 25:26

Men for vår del så har vi landa på at så lenge vi klarer å holde det, altså state late, altså stateless og immutable, infrastrukturelt gjør det, så er det ikke noe problem at det clusteret kan kjøre langt mer enn 400 applikasjoner, sånn som vi kjører i dag, fordi det er såpass enkelt å bare kaste det og spinne opp et nytt og få alle applikasjonene der. Men så har vi også et sånn tools-cluster ved siden av hvor vi kjører alt, og Grafanas observabilitetsdac, for eksempel, og Argo CD, og alle disse open source hvert døgn. Hvor litt uformell forskning viser at ca. halvparten kjører alt ett-cluster, siden halvparten kjører i clustere. Så det er enten-eller. Det er få som har ti. Men du snakka litt om observability etter at man hadde pløya.

25:26 --> 26:15

Hva er det plattformen tilbyr for dag to-operasjoner og den type ting? Ja, det er Grafana-stacken nå. Det er jo nytt for oss. Vi har hatt litt mer sånn Enterprise-stack tidligere. Men så har vi blitt veldig inspirert i platformteamet etter tid, og vi ser jo også ofte at open source-verktøyene våre er bedre enn Enterprise-verktøyene, som koster oss masse penger i tillegg. Så det er Grafanas LGTM-stack som brukes for observability. I tillegg til Faro, som var jo første samtale han holdt med deg, Kranz Kristian. Kan ikke du fortelle litt mer hva Faro er, for de som ikke kjenner det? Det er observability for fronten, eller Rum, real user, monitoring, er det hva det står for.

26:15 --> 27:04

Så du kan måle alt fra sidebesøk, exceptions som kastes i react-appene dine, brukerstasjoner, sånne typer ting. Og så integrerer jeg det med Grafanas-stacken. Det bruker vel lok i ... Bruker dere tempo for traces òg, eller? Ja, det gjør vi. Det er jo en ganske bratt ledningskurve, det å ta i bruk tracing. Hvordan har dere implementert det i Gjensidige? Vi hadde jo en tanke om at vi skulle ha full dekning av tracing som mulig. En tanke fra starten av da vi etablerte plattformen på Kubernatius. Så de fleste eller alle applikasjonene som kjører, har en sånn Open Telemetry-agent kjørende på seg. Og så er det som du sier, å ta det derfra til at folk faktisk kan

27:04 --> 27:56

bruke det til noe fornuftig. Og der er det litt som vi har toucha inn på før, det er kompetanse som må heves, man må vite hvordan man skal kunne bruke verktøy effektivt. Og der har vi ... Ida toucha litt inn på det før, vi har konseptet som heter Gap Champions. Hvor vi jobber aktivt med å kle på et stort subsett av utviklerne som er veldig interessert i plattform og infrastruktur. Dere har til og med lagd en egen kleskjede for å håndtere det. Ja. Maskot er vi. Ja, veldig fokus på lunch, faktisk. Ja, så det er kompetansebygging å være ute og spille inn videoer, holde foredrag internt, sånn type ting. Hvor mange sånne Champions har dere, da? Vi har ett per team.

27:56 --> 28:46

Jeg husker ikke hvor mange team vi har totalt, men det er i hvert fall ett per team. Den regelmessige meetups? Ja, så kult! Vi har Gap Forum, der vi inviterer dem, og andre som ønsker å være med. Der vi har forskjellige topiker som vi ønsker å kle dem på. Typisk Loki eller Grafana eller noe annet. Hvis de ønsker mer sparring med passasjeteamet, så kan de også kalle oss inn, og så hjelper vi dem med det også. Men målet er jo at de sprer det ut til teamet sitt. Da ser jeg jo at det hjelper å bruke open source tooling. Der det kommer til at folk skal lære seg verktøyet. Det fins så mye ... Det er stor forskjell for oss om du må grave inn i et eller annet dokumentasjonsdokument som ligger skjult på en eller annen leverandørs side, enn at du kan google,

28:46 --> 29:30

og det første treffet ditt er på Stack Overflow, der jo alle utviklerne ... Eller Chakipité, som har flere og flere brukere, som har tredd på masse open source things. Så det har vært et stort skifte å vie oss over til open source, som hele kjernen i plattformen. Men har dere en open source selv? Jeg skulle kanskje ønske vi hadde det, vi har kandidater som kunne vært det. Det er bare å gå inn og trykke på ... Vi mener det veldig lett! Det er en vei å gå. Vi åpna jo den nettsiden gap.incd.i. Ja, det er en vei å gå, for å si det sånn. Vi åpna jo den nettsiden gap.incd.io som Rida snakka om.

29:30 --> 30:21

Veldig inspirert av dere forøvrig, med nice.io. Det var viktig for oss å være åpne og dele om det, men også bruke det aktivt på rekruttering og employer branding og sånne ting. Men det var en lang vei før vi kunne gjøre det internt. Målet er å komme dit, men må ikke glemme at det har vært en reise ... Det har skjedd veldig mye på kort tid. Vi starta reisen i 2020 og har gjort veldig mye. Det er iallfall ambisjonen at vi skal begynne å open source, men vi er ikke der ennå. Men sånn type sikkerhetsverktøy, er det noe dere tilbyr til teamene som en del av plattformen? Absolutt. Der går det jo ... Det er veldig mye fokus på supply chain. Vi kobler også på fra repoer blir oppretta,

30:21 --> 31:19

og setter riktige policies på github-repoene. Signerer commit, sånne typer ting. I tillegg er det jo github advance security suite som tilbys. Og så har vi også skandere. Each step of the way. Så både på terraformkoden, på ... På jumble-koden til kubenettis, på konteinerne med applikasjonene, som utviklerne ser. Og så aggregerer vi all den informasjonen til et verktøy som vi kaller security score innad i Gjensidig. All sikkerhetsinformasjonen som vi enkelt kan hente fra github-sinapier eller kubenettis-inapier. Legger sammen, og så scorer vi liksom applikasjoner basert på det.

31:19 --> 32:03

For å gi incentiver til å f.eks. patche dependencies. Så får de en sentral oversikt. Både de som jobber rent på sikkerhet, men også de på teamene. Er det noe dere bygger selv? Det har faktisk Sigurd tatt initiativ til å bygge. Men vi har også innført Security Champ-en, like som Gap-champ-en. Vært veldig på security score og brukere for alt det har vært inn mot teamene. Relasjonen mellom sikkerhetsorganisasjonen og plattform, er det to adskilte grupper? Eller er det godt samarbeid der? Det er to avdelinger. Men når vi bygde plattforma, så har de vært tett på oss hele veien. Så de har sikkert vært tett innbygd i plattforma vår fra starten av.

32:03 --> 33:01

Så de har vært godt involvert, vil jeg si. Ja, absolutt. Men jeg vil jo si at plattformutviklerne hos oss, de har et supersikkerhetsfokus, for vi har ingen egne sikkerhetsutviklere i plattformteamet. Det er noe som alle er nødt til å ha et forhold til selv. Og sikkerheten i plattformen og hele den supply-chainen hvor en container skal ut til Kubernetes, og det skal signeres, og signatoren skal verifisere, og alt det der, det er jo sånne ting som er kommet på initiativ fra plattformteamet. Men også med samarbeid fra sikkerhetsgjengen, da. Men vi har på en måte ansvaret for sikkerheten i plattformen. Men sånn inn i Kubernetesk-cluster, da, har dere noen type policy engines? Har dere noe overlay-nettverk for kryptert trafikk, eller hvordan ser det ut der, da?

33:01 --> 33:54

Ja, det er mye policies som går på dette med sikkerhet. Sette riktig sikkerhet. Sette riktig security context, alt mulig av den type tingene. Det var vi veldig opptatt av å gjøre fra starten av, for vi visste at sånne type ting er sånn ... Du kan klare å sette de policyen til deny i starten, og så heller legge inn unntak. Men hvis du skal gjøre det dag to, så er det vanskelig å få de bort fra noe annet enn audit, uten å gjøre veldig store whitelister. Så det har vi jobba masse med. Og så er det et service-messe med linker, de som kjører der, som krypterer trafikken mellom podier og sånt. Du snakket om at det var ting som kom fra plattform ut til teamene. Har du noen eksempler på noe der dere har fanga opp behov fra teamene,

33:54 --> 34:40

som dere implementerte i plattformen? Ja, det er kanskje mest på observabilitet, hvor det kom på det. Å tilby alarmer av forskjellige typer. Og dashboards spesielt, da, for overvåkning. Og så er det jo også på ... Etter hvert, altså ... Vi har bygd ting veldig modularisert, så HappyPat-en er også en modularisert HappyPat. Du trenger ikke kjøpe inn til hele. Du kan kjøpe inn litt og litt, og det er også fint, for da kan vi utvide den litt og litt på en enkel måte. Så ting som "reusable actions" i Github har kommet litt sånn i etterkant. Og etter hvert blitt adoptert, da.

34:40 --> 35:27

For eksempel. Ja, sånn type ting. Jeg vet ikke om du har noe mer? Nei, jeg tenkte å se på dashboards. Det er sånn jeg ønsker de er. Dette ønsker vi å se på, så vi har hjulpet dem å visualisere de tingene der. Lage templates, default, og så kan de bygge videre på det. Det er vel det jeg tenker i farta, spesielt. Men ja, generelt så er jo de fleste som jobber hos oss opptatt av å ha det så enkelt som mulig. Så vi ser jo smerten som oppleves av og til på Slack. Og da forsøker vi på en måte å komme den i møte med enten forbedret dokumentasjon eller å gjøre små justeringer på happy patten.

35:27 --> 36:22

Vi snakker mye med miljøet vårt, så vi veit stort sett hva de ønsker, og hva slags behov vi trenger å dekke. Det gjør vi. Men sånn last og skalering, er det relativt forutsigbart, eller er det sånn at det plutselig peaker og man må skalere ut? Gjensidiges erkefiende når det kommer til last, er jo når vi skal betale utbytte til kundene våre. For da får alle en ... hva er det ... SMS om at nå har du så og så mye penger tilgjengelig her, og du kan logge inn på gjenside.no for å ta de ut. Og da kommer alle på en gang. Så det har jo vært en typisk ting hvor tidlig infrastruktur har slitt. Og man måtte gjøre grep som å spre smettene utover i tid og sånne typer ting for å redusere den trafikken.

36:22 --> 37:07

Ellers er det ganske forutsigbart. Folk liker å sjekke forsikringen i lunsjen, og nå rett etter at de slutter på jobb. Men sånn type skalering, da? Jeg regner med det er noe skalering på nodene, på podene, er det noe som teamene får ut av boksen i plattformen? Ja, type horisontal skalering og sånn, det kommer ut av boksen, ja. Hvis de ... Altså det kommer enable by default, for å si det sånn. Så kan du jo skru det av også. Men der er det noe kanskje litt sånn at vi ser det blir et mer ... Det er et mer større fokus på kosten òg, og det er flere som kommer til oss og snakker om at de ønsker å kunne skalere til null, for eksempel.

37:07 --> 37:45

Og vi vil jo det når folk ønsker å gjøre kostnadsbesparende tiltak. Så det er nok noe vi skal begynne å se på. Hvordan får teamene se kostnader? Er det noe dashboard som viser kostnader? Ja, vi bruker den portalen. Asher-portalen. Der har du tilgang til å se kostnader. Men vi har også laget en egen ParBI-dashboard, der man kan se det fra toppnivå. Fra ledelsens perspektiv, altså alt. Der du kan dypdykke ned til hvert team, og enda lenger ned. Det lagde vi for så vidt sammen med Microsoft. Er det sånn at hvert team får hver sin subscription? Eller er det tagging?

37:45 --> 38:28

Innad i Kubernetes er vi gode på å måle kostnaden på Asher. Det er i hvert fall med tags og ressursgrupper. Innad i Kubernetes er det litt mer tricky å komme like langt der. Der fokuserer vi mer på utilization. Av ressursene de reserverer. Så vi har nok vært på et sted hvor folk har over-requesta veldig. Og da har vi litt sånn ... Vi har skjermer på kontoret som viser litt sånn ... Ikke sånn wall of shame, men den viser litt hvilken prosent de ulike teamene ligger på. Når det kommer til f.eks. CEPU utilization. Og så har folk jobba med det, begynne å skru ned.

38:28 --> 39:09

Vi opplever jo det i Nav at når vi tilbyr det til utviklerne, så er de ansvarlige, eller så blir det plutselig: Oi, ja, men sånn skal det ikke være. Nå må vi sette riktige verdier her. Vi begynner å gå inn for landing, men før vi har sluttet, har vi et spørsmål som vi stiller alle gjestene våre. Og det er om dere kan fortelle om en gang ting ikke gikk helt etter planen, og hva dere lærte av det. Har vi noen eksempler på det? Jeg har tenkt litt. Det er ett eksempel som kanskje skiller seg litt ut for min del, og det er: I starten var vi jo som en gjeng med nye plattformutviklere som lagde plattform, og alt skulle være "bleeding edge".

39:09 --> 40:16

Vi skulle gjøre så kult som mulig, og skulle også auto-oppgradere alt av kubenettspersoner. Vi skulle patche nodene automatisk, og det skulle skje på natta, og det skulle ikke være noe problem. Så vi var nok litt hissige på grøten der i en liten periode. Og vi hadde ... Vi hadde en hendelse i påska for et par år siden som også var et tilfeldig svar før plattformteamet hadde fått på en oncall-rotasjon. Hvor da gjensidige.dk, altså den danske siden vår, gikk ned. På grunn av at vi restarta alle nodene våre, som skulle få ny kubinettversjon. Uten at det var noen som da hadde satt og passa på plattformen, fordi vi ikke hadde helt kommet i mål med oncall-oppsettet vårt ennå. Og da tok det lengre tid å få den opp igjen enn det som var akseptabelt for selskapet, merka vi nok.

40:16 --> 41:07

Det er greit å finne ut hvor lenge det er akseptabelt å være nede. Så det var spennende. Men også veldig fint, for der fant vi jo ut nøyaktig hva som gikk. Og det var CMS-en vår, så det har vi jobba mye med etterkant for å få det opp til de standardene vi ønsker at ting skal være på. Så i dag ruller og går disse automatiske patchene. Jeg tror det er mange som kan relatere til at det er en utrolig deilig følelse å få ting oppgradert, og jo mer man kan automatisere. Men som du sier der, det er viktig å holde tungarbeid til munnen og passe på at ... Appene fortsatt er oppe, selv om man oppgraderer noen. Vi er jo egentlig en gjeng med applikasjonsutviklere

41:07 --> 41:52

som har blitt plattformutviklere. Så vi er veldig kompromissløse når det kommer til at vi har lyst til å gjøre så lite som mulig. Alt som kan gå automatisk, det liker vi. Kjempespennende, og det er veldig mye vi kunne dykket ned i her og fortsatt med. Men før vi gjør det, så er det noe dere vil legge til? Eller hva som er veien videre? Vi kan jo begynne med deg, Ridder. Veien videre, ja. Vi nevnte jo så vidt at vi har flere datterselskaper i dag. Og vi driver med plattformtjenester. Så det å enkelt kunne serve disse datterselskapene med vår plattform, det er vel en vei videre, men også kanskje tenke litt større i fremtiden.

41:52 --> 42:44

For vi har en god plattform i dag som kan brukes til mangt, ut i finans. Så det er en visjon vi har også. Som mange andre har testa ut, har jeg hørt. Så det er vel veien videre, tenker jeg, uten å dele for mye. Og så tenker jeg også at vi ønsker jo å ta ... Vi har ikke fullt ansvar for hele infrastrukturet vår i skyen i dag. Men vi er et internt team som får stadig sterkere kompetanse, så vi ønsker å ta mer og mer ansvar selv, så vi kan inkludere mer og mer av alt inn i plattformen. Det gjør liksom alt sømløst. Vi har vært på lufta nå i to år, mer enn to år faktisk, så vi er klar for et nytt steg nå. Og det å ta litt mer ansvar rundt nettverk, f.eks., eller databaser,

42:44 --> 43:20

det er mange ting her vi ønsker å utvide ansvaret for. Det er utrolig spennende, og her lukter det oppfølgingsepisode! Så hvis dere lytter på, har spørsmål, så send de inn, og så skal vi få de besvart ved neste korsvei. Jeg vil benytte anledningen til å si 10 000 takk til Rida Atif og Sigurd Fag fra Gjensidig E, for all den kunnskapen dere har delt med lytterne våre. Nå er jeg spent, hva er høydepunktet ditt fra den episoden? Det jeg syntes var veldig gøy å høre, hvordan de var såpass kompromissløse på det å være tett på brukerne sine. De hadde folk som var ute i timene, og de hadde jevnlige møter, og klarte å få informasjon om hva brukerne trenger. Det er det aller viktigste for å lage gode plattformer,

43:20 --> 43:59

er å løse problemene til brukerne. Hva med deg, Ann Sistian? Jeg syns det er utrolig gøy å høre hvor langt Gjensidig har kommet med det å dele kompetanse, det å ha den kommunikasjonen på tvers av organisasjonen. Jeg var litt inne før GAP kom i gang, og det er en lang vei Gjensidig har kommet. Så det er utrolig gøy å høre at vi sitter her og snakker om disse tingene. Kjempegøy. Hvis jeg bare kan få en lenge til, en til til: Det å bygge et godt team, Å bygge et godt team er like viktig som å bygge en bra plattform. Det er kanskje i seg selv å ha et bra team. Det var faktisk veldig viktig for oss. Det er en helt super avslutning. Jeg tror vi skal la det være siste ordet der.

43:59 --> 44:30

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