Episoden er transkribert av kunstig intelligens

00:00 --> 00:43

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 som vanlig 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 gjester, Audun, hva er ditt favoritt? Hva er ditt favoritt-kommando-linje-verktøy? Dette måtte jeg tenke litt på. Jeg holdt jo på å velge CubeZet L, mest fordi det er så morsomt å snakke om hvordan du skal si det. Men jeg tenkte litt på hva som egentlig er det jeg liker best,

00:43 --> 01:23

så tror jeg jeg landa på Github sitt cell-i. GH, bare fordi det gjør en del ting som jeg alltid syns var komplisert før. Bare det å logge inn og få alle de riktige tokens for å håndtere git-kommunikasjon, det gjør det kjempeenkelt. Så det er mitt favoritt-cell-i. Hva med deg, Hans Kristian? Det blir jo selvfølgelig cube cuttle, som det heter. Det er det jeg bruker desidert mest til vanlig. I min Claim to Five på en CubeCon, så fikk jeg en av de, han heter Staffingeniøren i Google, til å lage en YouTube-video med han og flere andre om hvordan de skulle si CubeZt L. Og det var cube cuddle som jeg tror ble da offisielt riktig.

01:23 --> 02:06

Men nok om kødling. I dag er vi så heldige her med oss. Det er Erik Paulsen Skålerud og Sven Malvik fra Vipps Mobile Pay. Vipps ble lansert av DNB for åtte år siden, og i dag har nesten alle i Norge appen installert på sine telefoner, for enkelt å kunne sende og motta penger. For ett år siden fusjonerte norske Vipps med danske Mobile Pay, og i 2023 vippset vi hele 266 millioner ganger. Både Erik og Sven har lang fartstid innen IT, og begge to jobber i plattformteamet til Vipps. Og vi er kjempespent på å lære mer om hva som trengs for å kjøre en av Norges mest populære apper. Erik, kan ikke du begynne å fortelle litt om hvorfor du begynte i Vipps,

02:06 --> 02:51

og hva du jobber med? Ja, hvorfor jeg begynte i Vipps? Jeg var på NIC, Nordic Infrastructure Conference. Så så jeg at Vipps skulle holde en session. Og der på scenen sto Sven Malvik og en annen som jobba i Vipps da. Og fortalte om alle ting de hadde gjort galt i plattformen sin, og hva de lærte, og hvordan de fiksa det. Så tenkte jeg at det her var ganske forfriskende å høre et såpass stort velrenommert selskap snakke om sine fuckups i all åpenhet på den måten der. Så gikk jeg inn på hjemmesida og så at de søkte etter en platform engineer.

02:51 --> 03:37

Søkte og så sitter jeg her i dag. Kjempe. Det er jo en perfekt intro til denne podkasten og denne delingskulturen. Sven, hva med deg? Hvorfor begynte du i Vipps, og hva er din rolle? Jeg husker at jeg fikk en telefon fra en rekrutteringsperson og spurte om jeg ikke hadde lyst til å jobbe i Vipps. Jeg husker at den gangen var Vipps det kuleste selskapet i Norge. Så sa jeg: "Ja, jeg tar gjerne en prat." Så førte det ene til det andre, og så ble jeg ansatt. Og trives kjempegodt og jobbet der i seks år. Og elsker å jobbe i Vipps. Vipps Mobile Pay. Det er ikke så lett å huske alltid. Jeg kommer nok til å kalle det Vipps, i hvert fall i privat bruk fremover.

03:37 --> 04:29

Ikke si "kan du vippse Mobile Pay" meg", og sånn, tror jeg. Men du hadde jobba i seks år, og det er åtte år Vipps her. Har det vært en plattformtankegang hele tiden, eller har noe kommet etter hvert? Da jeg begynte, startet vi for så vidt med Eza. Så alle vi som jobbet der, hadde lite erfaring med Azure, nesten zero. Så da bygget vi plattform fra scratch. Vi kjørte kubanetisk på VM-et, kan du si. Altså ikke AKS. Og all det kunnskapen som vi har nå, lærte vi oss underveis. Med alle de feilene som vi gjorde. Når du starta med Azure helt blank, så gjorde du massevis av feil. Du har jo den onpram-tanken. Den hadde vi i hvert fall. Og så fikk vi jo mye inspirasjon fra Nice også.

04:29 --> 05:17

Men så også Vipps, begynte onpram, eller var det bare tankegangen som begynte? Vi var onpram, det var én stor monolytt i starten, som vi delte litt opp etter hvert. Så flyttet jeg over til Azure, og så kjørte jeg på VM-er der, på kubanetisk, men det var managet av oss. Det er sånn vi startet, egentlig. Så hadde vi API Gateway foran, men det var egentlig det. Veldig basic. Apropos API Gateway, du har skrevet en bok om Asher API Man-Rent, fortell litt om den, Svend. Ja, boka heter Mastering Azure API Management, og det var egentlig starten. Vi håndterte alle API-ene, det var sånn rundt 100, som en monolitt den gangen, og det var veldig vanskelig å vedlikeholde.

05:17 --> 06:01

En liten endring i API krevde at vi deployerte alle API-ene med en gang, og det var ikke så lett, det var veldig vanskelig og litt skummelt. Så vi jobbet mye med dette. Microsoft den gangen syntes jeg var kjempekult. Inviterte oss også til Microsoft Byrth i Seattle og snakket om det der, så det gjorde vi. Så førte det ene til det andre. Så fikk jeg telefon fra Apress den gangen: "Har du ikke lyst til å skrive en bok om Happy Management?" Så sa jeg ... Jeg tenkte nei, men jeg sa ja. Kom korona, og så gjorde jeg det. Det er god timing. Absolutt. Er det mye jobb å skrive bok? Ja, det var veldig mye jobb.

06:01 --> 06:48

Du må skrive hver eneste dag, selv om du kanskje ikke har så lyst, så må du skrive. Det betyr mye disiplin. Så etter hvert er det veldig enkelt, for det er en haug med blokkpost. Og du får liksom, du får din stemme, din voice, som Aplus kaller det, relativt fort. Det kan ta to-tre kapitler, men da er du i gang, og da er det bare jobb. Men det er mye jobb. Men det gikk greit. Bruker dere APGateways fortsatt? Ja, vi har det. AGI Api Management. Det er et veldig viktig produkt for oss. Det er hovedinngangen til alle våre applikasjoner. La oss si 95 % av alle applikasjoner eller requestene går gjennom den ene av instansene som vi har i produksjon, og inn i AKS.

06:49 --> 07:43

Kan ikke en av dere si litt om hva er stacken? Hvordan ser plattformen ut? Stacken vår kaller vi jo WC, som står for Vipps Compute Environment. Vipps Core Engine. Jeg husker aldri det. Men det består jo av AKS, altså Asher og Kubernetes. Og så er det monitorering og logging rundt det. Grafana, Splunk. Pluss self-service-komponenter. Vi bruker backstage til det. Og så er det da et veldig stort antall pipelines i både Asher Devops og Gitarb som fyres av når ting skjer der. Og Apim, da. Selvfølgelig. Databaser er en egen del av det?

07:43 --> 08:25

De er ikke en del av compute-plattformen vår. Vi kjører ikke databaser i Bernetes i det hele tatt. Det kjøres i SVR og SQL av teamene sjøl. Så alt som har med data, persistent data, hvis vi alle sier det, ligger i teamenes egne subscriptions. Men har plattformen noe oppsett for det, eller automatikk for det? Bruker de selv Bicep, Arm, Terraform for å sette det opp? De setter det opp sjøl, men vi har lagd moduler, eller templates, bicep-spesifikt som vi bruker i selskapet. Som prøver å få det litt enklere å komme i gang, og litt "secure by default".

08:25 --> 09:22

Det der er noe vi jobber kontinuerlig med, og vil nok forbedre ganske mye framover. Så tror jeg jeg leste i sted at det går mer over til GitHub Actions og vekk fra ... Ja, det stemmer. Fortell litt om den reisen der, da. Vi har vært i Ashore DevOps veldig lenge, men så prøvde det enkelte team ut hvordan det funker med Github, de var kjempefornøyde. Plattformteam switchet til Github, og så prøvde vi Github Actions. Vi syntes det er enklere enn DevOps Tasks, så førte det ene til det andre, og vi bygget på. Nå er jeg storfornøyd med Github, og prøver å få alt ut av Ashore DevOps. Men det tar tid, for vi har mange team, 40-50 team. Alle har sine pipelines der. Og så får vi over en del ting.

09:22 --> 10:28

Hovedbulken kjører i Github, rett og slett fordi vi har én AKS-instans i produksjonen, og alle applikasjoner brukte før den ene task-groupen som vi har i DevOps, og vi bygde noe tilsvarende som vi kaller for VIP-service med AKS, som gjør at folk, eller applikasjoner, eller VIP-service, egentlig bare puller et manifest fra Github på å gjøre resten selv. Tilsvarende nice. Det er derfor vi fikk inspirasjon fra dere. Er det Flux eller Argo eller noe dere har laget selv? For infrastruktur bruker vi Flux. Vi pusher det manifestet, men derfra puller en jo imaget, selvsagt. Men installere applikasjonen, og så lage et innlegg i API Management.

10:28 --> 11:15

Altså deploye API-er fra AKS. Hvordan er grensesnittet som et team ... Når et team skal lage en app med API-management og den type ting, hva er det et team må gjøre for å få det? Da er det jo denne VIP-service, som ser litt ut som customize. Så du har overlays og alt det her. Da er det to forskjellige operators. Den ene deployer API-ting, og den andre ikke API-ting. Så de definerer jo manifestet i sitt repo, og gjerne da en git of action som sender det videre til de operatorene. Bruker dere native cubernatis resources, eller har dere lagd egne CRD-er?

11:15 --> 12:05

Det heter kanskje ikke CRD, men ... Vi har egen VIP-service av appen. Ja, så VIP-service er en CRD? Ja. Så det ... Vi gir dem jo en kickstart, sånn at vi har en sånn ... Vi har en workshop de kan gå gjennom som viser sånne eksempler. Og så har vi jo en del sånne backstage templates for å profesjonere ... De trenger jo en identity, de trenger litt andre ting for å koble seg til clusteret og deployet, og for at appen deres skal stå og kjøre. Fortell litt mer om Backstage for de som ikke er kjent med det produktet. Jeg har ikke god historie, men Backstage ble jo lagd av Spotify, og så opensourcet de det. Vips tok det vel ganske tidlig i bruk, sånn sett. Og det har jo modna etter hvert.

12:05 --> 13:02

Vi bruker det jo mest for en slags service catalog over hva vi har, og en god del dokumentasjon, og self-service templates. Så det er jo en slags internal developer-plattform, men som også krever en god del innsats. Av oss sjøl, da, for å vedlikeholde og oppgradere og utvide, og du må kunne javascript, og det kjører i node, og litt sånn. Men det gir oss ganske mye verdi for pengene, for å si det sånn, i og med at det er gratis. Men med self-service template, det er jammel eller noe tilsvarende, som dere putter inn i dette, som ligner på customize? Så de, i teamets gitter-repo, så har de en del config som de får fra backstage, og så pusher de det inn i clusteret.

13:02 --> 13:44

Jeg er faktisk usikker på om vi profesjonerer jammel rett inn i repoen deres fra backstage, men vi profesjonerer i hvert fall og starter pipeline og det ene og det andre, sånn. Hvis du lager en applikasjon fra backstage, så får du alle de filene som du trenger, for å få synligheten i backstage, for det automatisk. Trykker man en knapp, så får du et repo. Selvfølgelig. Det profesjoneres da inn i backstage igjen som en ny service, så de slipper å gjøre den initielle der. Så lager de up-en sin, pusher kode, får noe ut og kjører ned AKS. Så kan de gå inn i backstage igjen og se mer om applikasjonen. Kan de få informasjon om hvordan den kjører, får de noe metrics?

13:44 --> 14:28

Fortell litt sånn om hvordan teamene jobber med day two operations med applikasjonene. I backstage har vi visualizer for Kubernetes der, sånn at de ser grønn og rødt lys der inne. Eller så er resten inn i Grafana for Matrix. Der er Vippservice som genererer default dashboard for dem med Golden Matrix, som vi henter fra LinkerD. Og logging bruker vi splunk i stor grad, så det er ikke så synlig andre plasser enn i splunk. Open tracing eller open telemetry? På vei. Når vi får tid. Ikke helt der ennå.

14:28 --> 15:19

Det er ikke noen liten undertaking, men det kommer. Men dere brukte linker de, sa du. Hvordan er dere fornøyd med det? Vi har ikke jobbet så fryktelig aktivt med det. Det vi var opptatt av, og grunnen til at vi installerte linker, De installerte linkene var at vi har HTTPS mellom servetjenestene. Det var det som var hovedgrunnen. Det er vel det de fleste har som hovedgrunn. Det kom en annen god grunn til å ha den, og det er observability-biten, som du ikke får i Kubernetes uten en service-mesh eller silium. Så for vår del er det jo primært akkurat det med observability-biten, å kunne få ut litt mer vettig nettverksstatistikk. Nettverksstatistikk for podene, eller containerne.

15:19 --> 16:02

Bruker teamene det, eller er det primært plattformtjenesten som bruker de metrikkene? Det er plattform, men teamene ser det i sine Golden Metrics. De har ingenting med LinkerDea å gjøre. Vi prøver å operere den helt skjult under radaren, sånn som det burde være i mine øyne i hvert fall. Men de får metrick-er. Riktig. For det var det vi litt opplevde også i Nav. Ja, det er mye god metrick der fra nettverkslaget, men at i realiteten ... Så ble det for komplisert for teamene til å få ut. Ja, jeg tenker at vanlige gjengs team skal ikke trenge å bry seg om en service-mesh. De skal bare være der. Det bør være som en baseline-ting. Det her er en del av vår plattform, og vi har Matrix, vær så god.

16:02 --> 17:06

Da kan jeg være sånn gammel plattformmann og si at da vi prøvde å sette opp Zipkin i Finn i 2016, så fikk vi helt ingen til å klare å bruke tracing. Men det var gøy å sette opp. Ja. Men fortell litt mer om plattformteamet i Vipps. Hvor stort er det, hvordan jobber dere? Hva ser det ut i dag til dag? Så Vipps og MobilePay kommer med hver sine 350 mennesker. Det gjelder også plattform, så vi har vokst fra 10-12 ish til 2025 nå, så vi er veldig mange. Og vi har to plattformteam. Et team som heter DevX, de valuer experience. Og så har vi et cloud-team som jobber i hovedsak med infrastruktur og oppgradering av AKS. Og DevX-teamet jobber i hovedsak med Vippservice og med jobber.

17:06 --> 17:56

Tilsvarende for batches i AKS. Gjør utviklingsopplevelsen så enkel som mulig, det er det de er mest opptatt av. Det er også de som eier backstage, og vet ikke hvordan å holde alt dette og hjelpe utviklingsteamene så godt de kan, hvis de har startet med Andrewip Service Deploy, eller hvis de skal ha et nytt RePo og det ikke funker helt som det skal. Og det er det vi jobber med nå. Det siste året var vi opptatt av å merge Vipps og MobilePay som én plattform. Vi skal bruke Vipps' Azra-plattform, så alle brukerne må over. Konnektivitet til danske banks datasentre må være på plass. Det er det vi har jobbet med i hovedsak det siste året.

17:56 --> 18:48

Nå skal vi om ikke så lenge, noen uker, ha en big bang, og alle de finske brukerne skal Alt er på den norske plattformen. Spennende. I mars er det samme med danskene, da blir det tilsvarende norske forhold. Cirka fem millioner brukere. Fem-seks millioner. Det blir over en dobling av antall brukere? Ja, med Finland nå regner vi med ca. 25, og så kommer det 100 % etterpå. Så det blir veldig spennende. Har noen dere passet på å ta ferie på den dagen? Vi har jobba veldig mye med å prøve å oppgradere komponenter og AKS og alle de tingene så høyt opp vi kan før vi går inn i en freeze-periode.

18:48 --> 19:44

For å ikke introdusere noe nytt under "one platform", som det kalles. Det har vært en utrolig jobb av plattform generelt. Det har vært mye jobb, men vel verdt det. Fortell litt om kultur mellom Vipps og Mobopay, har det gått greit? Eller er det stor forskjell på det som før var to organisasjoner, men nå som det blir under ett hakk? Det er jo litt forskjell. Vi liker å si det går så greit og litt smidige og ta det et hakk veldig mye. Men den samme kulturen er ikke andre steder enn nødvendigvis, da er det litt mer strukturert, kanskje. Det er et lite gap der, så det tok litt tid å overholde det. Men jeg syns vi klarte det. Det funker ganske greit. Vi må tilpasse oss, og de må tilpasse seg.

19:44 --> 20:31

Begge to må vi jobbe litt sammen for å få det fint. Men det var definitivt en læring, og i starten var det definitivt ikke superenkelt. Det var en del frustrasjon i starten, men vi har blitt kjent med hverandre nå. Og jeg tenker det går ganske fint. Da jeg begynte i Vipps og kom fra litt sånn typisk norsk corporate IT, så trodde jeg jo at jeg hadde kommet til Texas. Jeg følte det var ingen struktur eller orden på noe som helst. Men det var jo det. Det var bare at du så det ikke. Teamene opererer såpass utonom, og alle gjorde hva de ville med hermetegnene da. Så det er klart at det å møtes på midten her en plass er nok en bra øvelse for begge parter i denne fusjonen.

20:31 --> 21:21

Det mange sa fra andre siden, for å si det sånn, eller fra MobilePlay, er at de gleda seg veldig til å kunne gjøre mer frie ting da. De var jo veldig underlagt bankregler, og det er ikke vi. Så det er klart at jeg tror det blir en bra løsning til slutt. Vi har autonome team i Vipps. De har hver sine subscriptions. I den subscriptionen kan de i teorien gjøre hva de vil. Og mange gjør også hva de vil. Så oppleves det selvsagt at det er litt kaotisk, og det er jeg veldig enig i. Vi må jobbe med det. For å ha helt autonome team, som ikke er Azra-eksperter,

21:21 --> 22:04

de tenker ikke nødvendigvis på compliance. Så Azra Policies er veldig viktige. Så pleier jeg å si at vi har et mål, og vi kjenner til rammene. Hvis du beveger deg innenfor disse rammene og går litt på kryss og tvers, så er det greit, men du må komme deg dit. Men det oppleves for andre, spesielt i MobilePay, litt rart også, for de er veldig vant til å ha den veien, det er kjent for dem, de skal gå den paten. Men det er ikke vi opptatt av, og det er en liten forskjell. De i MobilePay hadde ti forskjellige legoklosser, vi har 10 000. For dem føles det helt umulig: Hva skal jeg bruke,

22:04 --> 22:54

hvordan skal jeg deploye det, hva er best praktis? Mens all den kompetansen lå i teamene i Vippsen og Vipps, og mye mindre. Man hadde veldig mange ekstremt sterke, flinke folk som drev de teamene og var tech-leads. Herlig ironisk at dansker hadde mye færre legoklosser enn dere. Det er ett subscription for det store clusteret pluss at alle teamene får hver. Hvordan har dere oversikt over kostnadene? Vi jobber mye med å få den synligheten på plass for teamene, at de vet hva de bruker nå. Så er teamene autonome, og de har sine utfordringer. De har hvert sine domener, som er helt annerledes for vår del. Så å få den synligheten for det. Å få den synligheten fordi de er opptatt av cost management,

22:54 --> 23:40

som vi ikke har i dag så mye, er en ulempe med å ha autonome team. Vi ønsker egentlig mer å gå til empower-team. Hjelpe dem å få den oversikten som de mangler i dag. Få inn også flere ager policies hvor det er ganske veldig tydelig at du faktisk ikke kan deploye den Lamogenie-scooen, men du må ta en Volkswagen. For det har funka like fint for vårt mål. Det er det vi jobber med nå. I Nav har vi ganske bra transparens på kostnader, men der ser vi noen ganger det motsatte. At folk bruker masse tid på å spare noe som beviselig er småpenger, bare fordi det er så tydelig for dem hva den koster. Så det er ikke alltid det er det beste å la alle få se alt, heller.

23:40 --> 24:25

Akkurat den tanken hadde vi også veldig ofte. Hvis vi alle er opptatt av cost management, så fokuserer de ikke på det egentlige oppgavet. Og fart framover er jo ofte stor verdi for selskapet. Ofte mer enn det du klarer å spare på å ha perfekt størrelse på databasen din. Vi har jo et prosjekt som starter nå, som er det her med Asher Landingsons. Så mye av det policyarbeidet går inn der, men etter det så må jo det gå sammen med det at vi lager bedre self-service-løsninger, og da med T-shirt-sizing, istedenfor å si skal du ha 1 eller 40 course. Og da velger du bare 40. Eller 20, eller noe sånt. Så det vil jo gjøre det enklere. Og så tror jeg det er med kost ...

24:25 --> 25:12

Det hjelper ikke så mange, for i Asher kan du fort ha 150 ressurser i en ressursgruppe, og så liksom: "Ja, den koster 10 kroner, det blir bare masse." Men å heller kanskje alerte team når en trend endrer seg brått. Noen har deploya noe til Prod, og så plutselig går kostnaden med 300 %. Hvorfor det? Ja, fordi du skrudde på debut-logging. Å fange de tingene tror jeg er mer viktig enn å prøve å spare ti kroner i måneden her og der. Og så er det også at ikke bare å kaste et problem, veldig ofte så tas ikke ned ressurser som ikke trengs lenger. Så det blir jo et sikkerhetsproblem, eller kan bli et problem, så de må fjernes. Og få den synligheten, det er veldig viktig. Men vi har ikke det på plass ennå.

25:12 --> 26:02

Og nevnte litt bicep-templets. Gjør det det enklere eller lettere at ting blir fjernet og ryddet opp, eller å gjøre det riktig for teamene? På en måte, for de krever at du legger inn tags som sier noe om når du sist var innom. Og reviewa det her. Så det var vel et mål en gang. Tror jeg stoppa litt opp når den fusjonen begynte, for da ble det mange andre ting å gjøre. Men det skal på plass igjen, definitivt. En sterk tagging policy, eller asset-inventar, som det da blir egentlig. For det er jo det Backstage skal vise ting etter, da. Hva som står på de taggene. Du har snakka om både Backstage og Kubernetes. Samtidig har dere en del tydelig Microsoft-teknologi.

26:02 --> 26:47

Hvordan balanserer dere Asher-ting og Native Asher opp mot mer sånn open source-kryssplattformteknologi? Det var et godt spørsmål det her med open source. Vi er jo der at vi velger det som er best for oss der og da. Men vi er under Finanstilsynets regler, og det gjør at det er ganske restriktivt hva vi kan bruke der ute av ferdige SAS- og PAS-løsninger. Microsoft er under i en avtale, og da kan vi jo bruke det vi vil. Eller så er det en ganske lang prosess å få godkjent sånne ting. Så hvis vi kan kjøre det sjøl, så gjør vi det. Hvis det gir mening. Men hvis det ikke gir noen mening, så gjør vi ikke det.

26:47 --> 27:32

Sånn som Grafana, det kommer kanskje fra Microsoft? Der var vi i Grafana Enterprise, men nå har vi flytta over til Microsoft. Så for dem har den akkurat samme løsninga kjørende. En ting som er morsomt med å snakke med dere, er at dere er et av de stedene i Norge hvor det er ganske mye trafikk noen ganger. Jeg har selv sittet på loppemarked og vært i sånn foreldre-kiosk-komité. Og da må det være ganske mye trøkk. Er det noen plattformelementer eller komponenter som hjelper til på det? Det er klart at akkurat 17. mai og TV-aksjonen er jo to veldig store dager for Vipps. Da, av erfaring, så har man jo da lært

27:32 --> 28:11

at det er noen ting man kanskje burde manuelt skalere opp før de dagene. For ting som Apinn bruker 45 minutter på å skalere ut... Det er en veldig lang prosess. Det hadde vært lang kø i den pølsenikkasen på 12. mai. Ja, eller akkurat rett før TV-aksjonen har et stunt. Hvor mange klarer å vippse innen ett minutt, så blir vi bare D-doser? Der har man jo lært av erfaring, så der er det jo ferdige planer for at man skalerer ut den og den komponenten, og microservices kanskje går fra 3 til 12 før disse tingene starter, noe manuelt. Noe er automatisk.

28:11 --> 28:59

Så der har jo det gått veldig på skinner nå, da, i siste 17. mai og TV-aksjonen. Men så hadde vi også en fuckup med 17. mai, for det var rett før korona, hvor Vipps var nede en halv time. Og der var den AJA-searchen for å få opp de organisasjonene, tippe inn organisasjonsnummer, og så får du selskapet. Det har jo ikke fungert. Fordi alle skulle plutselig klokka tolv tippe inn telefonnummer og få opp organisasjonen, og der baka den AJA-search. Den var blitt glemt å skalere opp. Det tar en halv time å få den skalert opp, derfor var det en halv time det var litt vanskelig!

28:59 --> 29:41

Hvor har det vært flaskehalser tidligere? Hvor er de kritiske elementene for å få gjennomført en betaling? Vi har jo tre hovedkomponenter. AJAUp Gateway, APM og AKS. De tre vet vi om, og de skalerer vi opp. Det som kan skje, eller det som har skjedd, det var connectivity til en database. At det er et team som ikke passet på at det faktisk må skaleres der. Da kan det stå opp flasker, men ikke foran AKS. Det har vi egentlig, bortsett fra den ene gangen, ikke opplevd.

29:41 --> 30:32

Og det har vi ganske god kontroll på. Men vi vet ikke hva teamene gjør, for de er selv ansvarlige. Hvis du har 40 timer som alle må sjekke, dette med skal-eva-het og trykk på 17. mai, det er det som er utfordringen ... Connection-pulling har jo tatt ned IT-systemer siden middelalderen. Vipps har et change-regime som er involvert i endringer som ikke kan gå gjennom automatisk hvor noen må godkjenne det. Da sitter jo folk i det ... De approvers av det er jo de samme som styrer den kommandosentralen vi har, som passer på ting hele tida. De er klar over endringer litt før de kommer. Vi må ha kjempegod reaksjonstid for å trykke fort på dette.

30:32 --> 31:15

Da følger de litt ekstra med, eller kanskje sier fra.... Men hva er typisk det som må gjennom change management approval-prosess? Det er et godt spørsmål. Det er litt forskjellig fra team til team og hva som er definert. Fra Finanstilsynet og Dunty Plating? Ja, alt skal logges av endringer. Jeg må prøve å ikke få det her til å høres kjedelig ut. Men man har fått lagd mange gode sånne templates, så da blir det da en standard change. Jeg husker aldri fortsatt hva de to skal ha valgt, men det er den som lar meg putte inn en template, det er den jeg bruker mest. Da har vi jo definert litt hva er de standardtingene.

31:15 --> 32:00

Som fra plattformens del, så har vi da infrastrukturendringer. Og disse standard changene er altså fullautomatisert. Så hvis du tekker en issue på riktig måte, så lages en change request automatisk, og ferdig. Ja, det er det propello som ... Ja, vi har mange rare navn for intervjuer. Propeller var kjempebra. Høres ut som du går fort og rett fram. Ikke standard - da møter du i et møte på morgenen og forklarer hva du skal gjøre. Så sier de ja eller nei. Tilbakemelding. Hvis de sier ja eller nei, pleier det å være happy path. De som sitter der i Change Management, jobber delvis også i Plattform Cloud-teamet.

32:00 --> 32:44

Det er en veldig grei prosess. Det var superskremmende for meg i første omgang. Men du må vise kortene litt og tenke litt igjen på hva du skal gjøre. Men hvor stort er det til at dere har ett cluster i Prod? Hvor mange namespaces, deployments og ting er det der? Namespaces ... Rundt 70. Ikke så mange egentlig. Deployments 450-ish. Da tok jeg vel med alt i systemet òg, da. Og dette er da før resten av Norden skal det være vi har kommet på? Begge deler. Vi har jo litt Goinernew som er sånne migreringsapper og jobber som å hente masse data hit og dit.

32:44 --> 33:29

Vi har vel forecasta ... Det er litt vanskelig å si, fordi bruksmønsteret til f.eks. finlendere er veldig annerledes enn nordmenn. De logger inn ganske mye mindre enn det vi gjør. Men vi bruker det flere ganger og er innom der og ser litt. Lite connectivity i badstua kanskje, men det er det. Så vi har vel stipulert at vi kanskje går opp ca. 50 %. Litt av poenget med en skalerbar plattform er jo at hvis du skal ha 100 % flere brukere, så skal du helst ikke måtte bruke 100 % mer på infrastruktur. Vi får litt stordriftsfordeler. Men remains to be seen, egentlig. Ett cluster, har det hatt noen vurdering i det? Det er 50-50 i verden,

33:29 --> 34:18

om du skal ha ett cluster eller 1440 cluster? Vi har tenkt mange ganger over det. Men vi er fortsatt veldig usikre. Vi har hatt alltid ett cluster, og det fungerer. Så det var litt vanskelig å få oppgradert AKS, med tanke på at i AKS må du oppgradere control plane til aller først. Og så var vi litt smårett. Hvis det ikke lar seg oppgradere, og så klarer du ikke å håndtere incidents og gjør en redeploy, så veldig ofte så redeployet ville spinne opp en ny cluster og switche over til den nye clusteren. Altså big bang, på en måte. Men det har alltid gått veldig fint, så et cluster har aldri hatt utfordringer eller problemer.

34:18 --> 35:02

Så hvis vi introduserer flere clusterer og må gjøre flere oppgraderinger, Det blir mye mer jobb. Men hvis det skjer noe, så har du jo mindre problemer da. Så litt sånn usikker: Skal vi gjøre dette eller ikke? Enn så lenge så sier vi: Det vi har nå, et cluster, det er perfekt. Det er en viktig distinksjon her. Vi har ett cluster, ja, men vi har veldig ofte to. Vi driver blue-green, og det er jo vår også slags DR. Det å teste det, at vi får flytta alt over og ingen merker noe. Og det har vi gjort siden jeg begynte i februar i fjor. Vi har i hvert fall gjort det fire ganger, kanskje fem?

35:02 --> 35:36

Er det bicep dere bruker for å sette opp løster? Ja, det er bicep som provisjonerer første biten, men alt den gjør er å lage cluster og dytte inn flux, og så gjør flux resten. Det har gått enormt med tid inn i flux, altså få den timinga og dependencies og alt satt opp. Men nå funker det bra, altså. Du plukker inn alle appene til teamet nå? Nei, vi har ingen apper in flux. Det var to apper der, og de gikk sin vei. VipService er ikke gitt opp sånn. Men hvordan kommer de fra ett cluster til et annet? Da bruker vi Velero.

35:36 --> 36:24

For ting som ikke er lagd i VipService, så er det jo den operatoren som restorerer dem sjøl. Basert på en eller annen sannhet som ligger en plass. Jeg kan ikke det godt nok, men den plutselig bare dunker inn. Du får inn VipService, og så sjekker den mot en south of druth hva som skal kjøre i mitt cluster, eller dette clusteret. Men er det ett namespace per team? Det har vært det. Først var det ett namespace for alt. Det ligger det fortsatt litt i. Veldig gøy å styre sånne notations på en helt namespace. Vi lager vår egen implementasjon med namespace. Kalte det Terje. Så gikk man over til team-based namespace.

36:24 --> 37:11

Nå ser jeg mer og mer produkt-namespace pop opp. Vi sa i starten at hvis du har et team-namespace, det er greit, men vi foretrekker domenespesifikke namespaces. Hvordan gjør vi tilgangskontroll på folk da? Når det er team-based namespace, så gir vi jo teamet tilgang. Da dukker det veldig fort opp at noen andre skal inn. Vi har IAM-regime... Regimet med hvor det lages grupper og vi lager arbac og så videre og så videre. Så det er klart at domenespesifikke namespaces er vel i hvert fall min sterke anbefaling. Hvis noen hører på dette og tenker vi skal begynne med Kubernetes ... Gjør det fra start, det vil spare deg mye trøbbel i the long run.

37:11 --> 37:45

Ja, det blir kanskje litt flere namespaces å holde på med, men jeg tenker upsideen er så mye sterkere enn downside. Teamene har tilgang til sine namespaces? Kan de sitte på kommandolinjen og se inn i namespaceset sitt? Det får de ha full tilgang til, fullt forward, alt. Utrolig spennende dette her. Vi begynner å gå inn for landing, og det har vi allerede snakket om når ting går galt. Men det jeg er spesielt ute etter her å spørre dere om, er: Hvordan har dere en prosess for å lære av når ting går galt? Hva gjør dere etter sånne hendelser, og hvordan jobber dere med det?

37:45 --> 38:27

Du tenker på incidens nå, eller? Ja. Vi kjører alltid en post mortem etterpå. Så vi setter oss ned etter at vi har hatt en incident og funnet ut av rotårsaken, selvsagt. Begynner å prøve å lære av det. Så har vi et post mortem hvor vi deler alt det vi har lært de siste dagene, og prøver å få det implementert. Trenger jeg oppfølgingsmøte, så blir det der. Men det er viktig at de tingene ikke skjer igjen, som den ene fuckup-med-asha-search-skalabeiden. Det skal ikke skje igjen, og det fikser vi. Var det helt naturlig for organisasjonen å gjøre det? Veldig mange har snakket med ...

38:27 --> 39:14

Det er jo litt sånn at vi må ikke snakke for mye, det er litt pinligere ting. Nei, det har vi alltid hatt. Kulturen er veldig sterk, at vi skal lære av feilene. Vi har en fuckup-kanal i slekt, og det er oppfordret at vi skal bruke den masse. Hvis det er en fuckup. Det gjøres også regelmessig. Det er viktig for oss å være synlig og transparent med feilene våre. Det er derfor vi går ut på konferanser og snakker om disse tingene. For det er erfaringene som folk er mest opptatt av, og det er mest spennende. Det er ikke spennende hvordan jeg implementerer og konfigurerer kjeder, men det er veldig spennende hva som gikk galt med kjedene da vi brukte det.

39:14 --> 39:58

Jeg er helt enig i det. Og det er så viktig å få frem den næringskulturen. Er det ellers noe dere vil si før vi runder av? Vi kan begynne med deg, Erik. Jeg var på CubeCon i Amsterdam sist, og en ting som slår meg når det gjelder dette plattformområdet som vi jobber innen, er jo at det er nå hundretusenvis av forskjellige lure verktøy og plattformer og løsninger man kan implementere. Jeg tror det er veldig spennende å se hvor det her er om la oss si tre år. Hvem står igjen, og hvem er markedslederne? Jeg føler vi er litt der hvor virtualisering var på et visst punkt. At det nå kommer til å bli en sånn ...

39:58 --> 40:42

Det er veldig mange startups og veldig mange lure produkter, men hva som står igjen om noen år. Jeg tror mange selskap, sånn som Nav med Nice, dere har gjort en fantastisk jobb med å lage alt det dere har, og vi har mye custom. Om vi har mye custom internt. Om de som starter i dag, kanskje burde se på hva som finnes der ute allerede, og sånne ting som Argo, og kanskje utvide det med sin funksjonalitet, istedenfor å starte helt fra scratch. For kybernetisk er tungt, i hvert fall å begynne å skrive Operators. Hva med deg, Sven, noen siste kommentarer? Det er som jeg syns er viktigst,

40:42 --> 41:37

når du starter i Ski, og jeg har erfaring fra Azure, at du har mye kunnskap om Ski og Azure før du starter. For det er så mange spørsmål og knapper du kan trykke. Og det er så enkelt å spinne opp ting. Men er du da compliant, f.eks.? Kostnadsmessig. Og alle disse spørsmålene må du kunne besvare før du går inn i Ski. Ellers blir det dyr, og kjempevanskelig å komme ut av det etterpå. Det er egentlig den største læringen som jeg har. For vi var veldig naive i starten, og det betaler vi fortsatt for. Det er helt klart at vi må ha Vipps mobilpay tilbake igjen her i studio, og snakke mer om migreringene, og mye mer om det som skjer på det tekniske på baksiden.

41:37 --> 42:19

Tusen takk til Erik Paulsen Skålrud og Sven Malvik. Har du noe høydepunkt fra denne episoden? Jeg syns det er veldig gøy at vi i Norge klarer å ha noen ting som er så store at de må skalere opp manuelt før det skjer, og ikke bare raust satse på at skyldleverandørene løser alt for seg. Hva med det, Tristan? Jeg syns det er veldig gøy å høre hvordan man kom fra DNB og denne stormonolitten, og som har blitt så smidig og i hvert fall er norgesledende, om ikke i verdenstoppen når det kommer til betalingstjenester. Det er utrolig gøy å høre.

42:19 --> 43:00

Og så er det spennende å høre om det som ligger veien videre med full integrering med Mobilepay og Vipps Mobilepay. Så det blir veldig spennende å høre med. Og jeg håper at hvis lytterne våre har spørsmål, send det inn, for vi skal definitivt ha Vipps Mobilepay tilbake igjen. Og med det så avslutter vi denne episoden av Plattformpodden med Hans Kristian Flåtten og Audun Fauchald Strand. Teknisk produsent har vært Tore Græsdal. Nyeste episode finner du alltid på plattformpodden.no eller i din lokale podkastapp. Følg oss gjerne på LinkedIn.

43:00 --> 43:10

Takk for følget, og ha det bra!