Episoden er transkribert av kunstig intelligens

00:00 --> 00:46

Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Christian 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 dykker ned i plattformer innen bank, forsikring og handel. Men før vi introduserer dagens gjester, Audun, hva er ditt favorittbrettspill? Det er et ganske godt spørsmål. Jeg pleier ofte å tenke at det er ticket to ride, men egentlig så er det et spill som heter Stratego. For der er jeg på en kjempelang, ubrudden liste av seire i familien min. Så det er egentlig ingen lenger som vil spille med meg, men det syns jeg er gøy.

00:46 --> 01:31

At jeg kan vinne. Hva med deg, Hans Christian? Jeg tror mitt må være Settlers of Catan. Det er et sånn strategispill hvor du skal være en nybygger på en øy, og skal oppdage verden og trenger ressurser for å ... Fortsette å bygge deg ut og ta rotter på de andre spillene. Jeg har hatt så mange timer på hytta med det spillet der. I dag er vi så heldige å ha med oss Markus Nordstrønen og Didrik Finnøy fra Bulder. Bulder er en heldigital og mobil førstopplevelse fra Sparebanken Vest, som skilter med at du ikke trenger å ringe banken hvert år for å få riktig rente. I 2023 endte Bulder på hele 47 mrd. i utland. Det er ganske enormt. Didrik, kan ikke du begynne å fortelle litt om hvorfor du begynte i Bulder,

01:31 --> 02:13

og hva du jobber med? Jo, så i utgangspunktet så var jeg en datamann, jobbet med maskinlæring gjennom konsulentbransjen. Så var det tilfeldighet som førte til at jeg ble kastet ut i et stort plattformprosjekt i offentlig sektor. Jeg var der i seks måneder, og så søkte jeg meg over til Bulder som plattformteam. Motivasjonen for å gjøre det skiftet lengtet jeg litt at alle fotballspillere, alle fotballspillere har lyst til å spille for det beste laget, og min oppfatning var at Bulder var helt oppe i toppsjiktet. Så jeg satte inn søknad, og så sitter jeg her tre og et halvt år siden. Utrolig spennende. Markus, hvorfor begynte du i Bulder? Hva er din rolle?

02:13 --> 03:13

Min rolle i Bulder er rett og slett teknisk leder, så jeg sitter ansvarlig for alle utviklerne som bygger Bulder. Og min vei inn i Bulder ... Og min vei inn i Bulder ... litt tilfeldig, men samtidig veldig gøy. For jeg jobbet i en konkurrerende bank på tidspunktet da Bulder oppsto. Men så kom jeg i kontakt med de som ønsket å få realisere Bulder. Ta det fra powerpoint til produksjon. Ble veldig giret på måten vi tenkte å gjøre det. Måten jeg så på menneskene, måten jeg så på prosessen for å få levert ting på en god og effektiv måte. Kundeverdi. Som trigget meg veldig. Derfor slengte jeg meg på den bølgen. Og har ikke sett meg tilbake. Det har jeg ikke. Utrolig spennende.

03:13 --> 04:13

Men kan ikke du dykke litt ned i det, Markus. Hvordan er Bulder strukturert? Ja, når du snakker om Bulder, så vil jeg snakke litt om arkitektur. For Bulder er bygget veldig mye rundt det som treffer kunden. Så vi har vår app. Vi er app-sentrisk. Vi har en rimelig avansert back-in for front-end. Og så kobler vi oss mot Sparebanken Vests åpne bankingplattform, og igjen under der Tet og Evri som bankkjerne. Det vil si at vi har veldig sterkt fokus på det som treffer kunden. Vi har organisert oss i forhold til det. Vi har i Bulder ... er vi 47 mennesker akkurat nå? Og skal egentlig ikke bli så mange flere. En sånn perfekt størrelse for en organisasjon.

04:13 --> 05:07

Og av de 47 er det 20 utviklere. Så ganske teknologidungt. Og så har vi markedsføring. Produktutvikling. UX har vi med. Og så har vi rådgivning. Så det er alle de flatene som treffer kunden, har vi full kontroll på i Bulder. Og når vi er såpass små, så er vi også i stand til å jobbe veldig tett. Så tverrfagligheten som vi får til i Bulder mellom alle stedene der vi møter kunden, Gjør oss i stand til å se helheten i kundeopplevelsen på en ganske annen måte enn jeg har vært med på tidligere. 47, hvor mange av de er utviklere? 20. Og hvor mange av de jobber med plattform? To.

05:07 --> 06:01

To! I det minste plattformteamet vi har møtt. Det er spennende. Og gjerne komme litt om hva man legger i plattform. For plattform er jo sånn som gjerne dere tenker plattform. Gubernetes og nedover, holdt jeg på å si. Men vi har en applikasjonsplattform. Vårt mål som IT-leverandør i Bulder er å lage de plattformene som trengs for at vi skal lykkes med våre mål og skape kundeverdi. Så det er applikasjonsplattformer vi bygger også. I tillegg til det som treffer kunden. Så hvis du tar det med i regnestykket, så er det jo to som jobber rent med plattform, og så har vi fem utviklere som utvikler back-end-plattformen vår.

06:01 --> 06:53

Og vi har også en del fullstekk-utviklere som jobber i hele sjiktet. Men Didrik, kan ikke du fortelle oss litt mer om arkitekturen i Skyplattformen, da? Jo, så i all hovedstokk så består det av Google Cloud Platform og Github. Det er en Kubernetesk cluster, litt serverless-funksjoner, litt databaser rundt omkring. Og ja. Det er det hele. Det er en ganske enkel stekk, egentlig. Fra plattformperspektivet så skjer mye av kompleksiteten inni koden til utviklerne som kjører på dette. Men hvis jeg hadde begynt å være utvikler hos dere og skulle lage en ny applikasjon eller en ny funksjon, hva måtte jeg gjort for å få til det? Vi har en sånn filosofi som motiverer mye av valgene vi tar med plattformen.

06:53 --> 07:43

Og det er at du som utvikler skal minimere hvor mye du trenger å forholde deg til plattformting. Så målet vårt er egentlig at du jobber på vanlig måte, og så det du trenger fra plattformen, skjer som en bieffekt av at du jobber på vanlig måte. Derfor er vi veldig glad i denne gitups-strategien. Så det du egentlig gjør, er bare å lage pull-requester og pushe kode til github, og så vil ting skje av seg selv. Vi er veldig motstandere av å tilføye ekstra kompleksitet, ekstra ting som du må gjøre. La oss si at når du skal rulle ut et testmiljø, du skal rulle ut en kodeendring, så vil ikke vi at du skal måtte trykke på noen ekstra knapper. Vi vil at den endringen skal rulles ut når du er klar for den.

07:43 --> 08:27

Måten vi gjør det, er at vi sier at når du lager en puller quest, da er du per definisjon klar til at koden skal ut i testmiljøet. Så alt du trenger å gjøre, er å åpne en puller quest, og så er din kode ute i testmiljøet. Det samme gjelder når du skal ut i produksjon. Når du får godkjent denne puller questen, og den blir merget, da er du per definisjon klar til at koden skal ut i produksjon. Og da går den ut. Så det er ingen ekstra knapper, det er ingen ekstra ting du må huske på å gjøre. Det skal bare skje som en bieffekt av at du jobber på vanlig måte. Men hvilke deler av plattformen eksponerer dere da? Sier man noe om hvor mye minneseppu man skal ha, eller hva slags type database?

08:27 --> 09:22

Noen må man vel se av plattformen? Ja, selvfølgelig. Dette er det jeg kaller kontrakten mellom oss og utviklerne, og det er hjemmelbasert. Det er steder på GitHub hvor du skriver hjemmelkode for å spesifisere hvordan plattformen skal behandle koden din. Det som er fint med løsningen, er at hjemmel er nesten dokumentasjon i form av kode. La oss si at du trenger å beskytte et endepunkt på internett bak en reversproxy. Alt du trenger å vite, er hvilke andre steder vi har gjort dette før. Andre mikrotjenester gjør dette som vi prøver å gjøre. Så kan du lese hjemmelkoden og mer eller mindre copy-paste det inn i dine filer. Vi bruker ganske lite tid på å hjelpe utviklerne med å gjøre ting som har blitt gjort før,

09:22 --> 10:15

pga. at de har blitt coachet til å finne relevant hjemmel, kodesnutt og kopiere den inn der den skal ligge. Så driver vi kontinuerlig og itererer på innholdet i hjemmelfiler eller strukturen for å gjøre de så ... Enkel som overhodet mulig. Hvis dette er Kubernetes, da eksponerer dere Kubernetes-apiet, eller har dere egne CRD-er, abstraksjoner, ting oppå der? Det er Argo CD, rett og slett. Kubernetes-apiet er eksponert i test- og dev-miljøene, så de som vil, kan dykke så dypt de bare har lyst. Men hovedsakelig så jobber du bare mot Github, og så kan du gå inn i Argo CD Ui og få en visning av

10:15 --> 11:04

hva som er utfallet av det du har skrevet i hjemmelfilene. Men den hjemmelen de skriver, er det en Argo CD-ressurs, eller er det noe custom som dere har laget? Nei, altså, plattformteamet ... Vi har en del helmcharts som vi eier, og det er da disse. Vi prøver å gjøre så brukervennlig som mulig. Så de skriver input-verdiene til disse helmchartene. Når de kryssrefererer og ser på hjemmelkoden til andre repoer, så er det input-verdier til de samme helmchartene. Så vi har et par store paraply-charts som egentlig alle bruker. Og mesteparten skjer gjennom de. Målet er at du skal kunne copy-paste.

11:04 --> 11:50

Eller kunne lese veldig få linjer med hjemmelkode for å skjønne hva du skal skrive for å oppnå det du trenger. Men det er ikke bare i GKE ting kjører som konteinere. Dere har litt funksjoner òg, har dere ikke det? Jo, vi blir på en måte tvunget til å bruke det som heter Google Cloud Functions. Og grunnen til at vi bruker det, er ... I utgangspunktet var det pga. at ... Vi har en databaseløsning som heter FireStore. Og vi har en eventdreven arkitektur basert på dette. Så når ting skjer i FireStore, så skal det trigge PubSub-meldinger og det skal trigge funksjonalitet som kjører i Kubernetes.

11:50 --> 12:43

Så serverless-løsningen er egentlig bare en sånn mottaker/meldingspusher til Kubernetes. Vi ønsker å gjøre mest mulig i Kubernetes pga. at der har vi en mye bedre utvikla opplevelse. Det vil jeg si er mest takket være open source-verktøy. Når du lager CI-løsninger for cloud functions, da er det egentlig terraform. Det er det eneste du har å velge mellom. Mens når vi snakker argo, CD og det andre økosystemet for hva du kan gjøre i Kubernetes, så ender du opp med mye bedre brukeropplevelse. Kan du si litt om hvilke open source-systemer dere bruker, utenom Margo? Ja, kanskje favoritten med nof-tiden er monitoreringsløsningen. Da har vi nylig gått fra Prometheus til Victoria Metrics. Den er helt nydelig.

12:43 --> 13:37

Vi bruker AsCert Manager, vi bruker External Secrets for å hente hemmeligheter fra hemmelighetsløsningen vår, som er Google Secret Manager. Få de tilgjengelig for koden. Vi bruker Celium Service Mesh. Det har vært Isteo, men nå ... Vi har ikke tatt Celium ut i prod ennå. Det er neste uke, kanskje. Men vi hadde en runde på kostnadsreduksjon i fjor og oppdaget at halvparten av computer-minnet vi betaler for, går til Isteo. Så har vi også en oppfatning om at det er Celium og sidecarless service. Så kult. Men fortell litt mer om Victoria Metrics, for det har ikke jeg hørt om før. Oi, ok. Det begynte med at vi hostet Prometheus selv.

13:37 --> 14:30

Det var sånn det var da jeg begynte i Bulda. Det var upopulært blant mine forgjengere. Jeg fikk aldri helt opparbeidet denne misnøyen med det. Så i min tid endret vi til "Google manage Prometheus". Prometheus kjører i Google-skyen istedenfor at vi drifter den selv. Så oppdaget vi at her betaler man per API-kall. For en monitoreringsløsning, så er det veldig mange API-kall. Monitoreringsmessig så er vi så litene som man blir. Vi har kanskje 100 mikrotjenester, og i rent volum hvor mye data som samles inn, så finner du ikke folk på internett. Du finner ikke folk på internett som er like små som oss, nesten. Men likevel betalte vi 10 000 kr i måneden til Google for bitte lite grann monitorering.

14:30 --> 15:14

Så tok vi valget om å gå over til Victoria Metrics, som er et open source-alternativ som oppsto pga. den generelle misnøyen som folk har mot Prometheus. De har egentlig bare optimalisert for å være god på det som Prometheus er dårlig på. Det er helt vanvittig skalering på det. Vi måtte økt monitoreringsdatamengden vår 250 000 ganger før vi hadde hatt behov for én til pod med Victoria Metrics. Så det er ekstremt performance. Det er bakover kompatibelt med Prometheus. Og i tillegg så er det et rikere query language, så alle som har prøvd å skrive alarmer eller spørringer i Prometheus,

15:14 --> 16:07

har opplevd hvor vanskelig det er. De vil finne ... Bedre opplevelser med Victoria Metrics. Veldig spennende. Hvordan får Victoria Metrics til å hente de metrikene? Skraper den på lik linje med Prometheus? Ja, han fungerer på lik linje som Prometheus, han bare gjør det mye mer effektivt. Jeg har ikke satt meg inn i hvordan de får det til, jeg har bare bekreftet at det stemmer. Og så er det gjerne Grafana for å visualisere det, da? Cloud-Grafarne. Den er managet for oss og overraskende billig for hva vi får for det. Det er dashbordløsningen hvor utviklerne kan gå inn og lage sine egne dashbord og jeg ser på de dashbordene som plattformteamet har laget på deres vegne

16:07 --> 16:55

for å få kjappt overblikk og både helheten i clusteren, men også drille ned på applikasjonsspesifikt nivå. Funker den monitoringsdekken også på det som er propritært? Supertært Google-ting som Cloudrun og Firebase, eller må du bruke andre ting der? Jo, altså du kan importere metrikk fra de Google-tingene, men igjen da ender du opp med å betale per API-call til Googles monitoreringsløsning, så da blir det fort veldig dyrt. Hvordan får deg god overvåkning, eller sover Markus godt om natten med å vite at funksjonene snurrer og går? Ja, altså ... Vi har hatt utfordringer med å lage monitoreringsløsninger

16:55 --> 17:36

som vi selv syns er gode. En klok kollega av meg sa det. Grunnen til at dette er vanskelig, er at det er noe som skjer mellom teams. Du har plattformteamet som er ansvarlig for å sette opp en monitoreringsløsning, og så er det utviklerne som er ansvarlig for å bruke den ordentlig til sine applikasjoner. Så mye av det som er vanskelig, oppstår pga. at du får det ... Så får du en utvikler, og så skal du skrive spørringer i et språk du ikke kan, med et monitoreringssystem du aldri har brukt før, for å overvåke din applikasjon. Så føler jeg vi har kommet på et sted hvor det fungerer bra, men det er også et av de stedene hvor det er mest potensial for forbedring.

17:36 --> 18:24

Alle alarmene våre kommer fra Victoria Matrix sine data. De går til Slack, og de går til Via ObsGenie, som er ... Hvis du må bli vekket på natten og du har mutetslekk, så ta opp synet ditt. Det høres for meg at det har kommet veldig langt, for dette med alarmer og ... Det er en vanskelig ting. Jeg tror samtlige organisasjoner sliter med det. Og de som ikke sliter med det, de har ikke begynt på det. Du har helt rett, og det er noe vi har jobbet med siden starten. Vi ønsker å være der at vi kan sove godt om natten og være sikre på at vi blir vekket dersom det er viktig at vi blir vekket.

18:24 --> 19:23

Her er også et skille. Om en pod sliter i Kubernetes på natten, så er det ikke sikkert det har noen kundeimpact i det hele tatt. Det jeg skal jobbe med i 2024, er å få opp virkelig gode alarmer. Virkelig gode alarmer på verdikjeden. Rett og slett kundeimpact. Du nevnte litt om kostnadsbesparelser. Det er kjempeinteressant og i vinden som aldri før. Vil du si litt om hvordan dere gjør kostnadsoversikt? Hvordan har dere innsikt i kosten? Gjør dere noe fordeling ut ifra ulike deler av byldet konsumerer så mye, eller? Vi bruker egentlig bare Googles billingløsning i Google Cloud. Den er faktisk veldig bra. Når du jobber med kostnadsbesparelser, så sorter bare i synkende rekkefølge,

19:23 --> 20:04

og begynner på toppen. Så vi har faktisk satt opp en dataeksport, sånn at rådataene bak den billingløsningen går inn i en database hvor vi kan grave i den som vi vil. Men fram til nå har jeg ... Egentlig ikke hatt behovet for å se på noe som helst annet enn Google Clouds billingoversikt. Det er veldig detaljert og en enkel løsning. Jeg har selv brukt den mye. Det er mye nyttig informasjon man får ut fra den. Eventuelt vil jeg jo type "open cost". Er det noe du har sett på, Didrik? Nei, jeg har ikke hørt om det engang. Nei, det er et sånn CNCF-prosjekt

20:04 --> 20:52

som drar inn fra ulike billing sources. Og gjerne også legge til hva man bruker i Kubernetes og andre steder. Men Bulder er jo litt unik her, sant. Det er ikke så mange. Det er ikke divisjoner og avdelinger og den type, som i større enterpriseorganisasjoner. Så her tror jeg det passer veldig godt at her er dette billingoversikten for Bulder. OK, begynner på toppen. Hva er de største kostdriverne? Virker egentlig som en veldig god strategi. Men jeg lurte på, selv om det er ikke sånn kjempestore ... Men det er fortsatt bra at ting er litt likt på noen områder? Bruker dere plattformen til å styre arkitektur på noe vis?

20:52 --> 21:53

Ja, godt spørsmål. Jeg tenker jo litt som Didrik var inne på, plattformen i seg sjøl. Hvis man da tenker på skiplattformen. Jeg er bygget for å være mest mulig. For å være mest mulig self-service. Det opprettes nye tjenester der når vi har behov for det et eller annet sted i organisasjonen. Så er det litt opp til hvert enkelt applikasjonsplattformteam å bygge sin arkitektur. Der stiller de ganske fritt. Men samtidig så er vi små. Så det er for vår del på Kubernetes, på Google Cloud, så har vi kanskje to arkitekturer nå. Det ene er den som er backen for våre apper, som bygger til Go. Kjøper Kubernetes. De endrer sin arkitektur i sitt team når de ser det er nødvendig. Eller ønskelig. Og det er en kontinuerlig prosess.

21:53 --> 22:58

Og så har vi en dotnet-stack som er litt enklere, som server noen enkle webapplikasjoner hos oss. Og de har sin arkitektur for den type applikasjoner, som de også itererer på. Så skal vi si vi har to arkitekturer i produksjon i dag på applikasjonsplattformene. Og så tenker jeg at det du beskrev tidligere med Firebase og functions som trigger på endringer der, er også et ganske sterkt mønster for hvordan dere gjør ... Absolutt. Men dette er ting som er under en kontinuerlig endring, alt etter hvilke muligheter og kapabiliteter Cooken Cloud tilbyr. Og når vi ser suboptimale patterns f.eks., så tar vi tak i det og forbedrer. Så ja, vi er i utgangspunktet event-dreven og har en event-dreven arkitektur.

22:58 --> 23:46

Men det er på veldig høyt nivå. Hvis jeg skal vise arkitektur, Hvis jeg skal vise arkitekturen vår til noen, så viser jeg det på det nivået, for da slipper jeg å skrive om hele tiden. Men detaljene som ligger under, de endrer seg hele tiden. Bruker dere andre baser også, under f.eks. go backend-tingene? Er det Firebase der, eller har dere andre ting i tillegg? Vi har vært veldig sentrert rundt Firestore lenge. Men vi jobber nå med å innføre Postgress som en mer ... skal vi si ... stabil datastruktur for en del av våre data. Firestore er jo som kanskje kjent en dokumentautorbase.

23:46 --> 24:30

Som ikke egentlig egner seg veldig godt for en del strukturerte data. Som vi etter hvert begynner å få ganske mye av. Postgress er på vei inn hos oss, og det som er tilbydt gjennom Sensores-plattformen til Didrik. Ellers så kan jeg utdype litt med at vi også har Redis, managed i Google, som de kobler seg på fra Kubernetes-applikasjonene. Og når det gjelder analyse, så har vi også en dataplattform hvor det meste går inn i Google Big Query-løsningen. Og så kjører vi opplegg for å lære folk å bruke den dataen. Vi ønsker å unngå å ha en sentralisert datateam

24:30 --> 25:14

som skal gjøre analysen. Det vi ønsker, er at alle de ansatte skal ha anledning til å koble seg på dataene, og lære seg å jobbe med dem etter ønske og behov. Hvordan gjør man previsjonering av en Reddis eller en Postgress når man jobber med en applikasjon og skal koble de sammen? Er det en del av den jammeren man skriver, eller går man et annet sted, da? Det er noen ting som er terraform. Det utviklerne møter, er at 90 % av arbeidet deres gjøres i kumernetisk-hjemmelfilene. Mens når det kommer ting som kanskje er felles for hele cluster, og ikke er en applikasjon, da er de drillet til å finne terraform-repoene.

25:14 --> 26:09

Skulle du hatt en ny Redis-database eller en Postgres-database, da lager du PullerQuest i en hjemmelfil i et terraform. Men er det sånn at disse Reddis-instansene deles på tvers av mange applikasjoner? Og eventuelt òg med Postgress, er det også sånn som deles, eller? Når vi holdt på med kostnadsreduksjon, så oppdaget vi at alle applikasjonene har hver sin Redis, og så spurte vi utviklerne om det er nødvendig, og da sa de nei. Så nå er vi i ferd med å ha en overgang til å dele Rediser der det gir mening, og jeg har ikke peiling. Ja, og i CloudSQL så er det jo forskjell på en instanse, som er det man betaler for, og databaser, så det er gjerne der man kanskje legger isolasjonen, at de får sin egen database, og kanskje også Reddis at det er ulike navnerom

26:09 --> 26:55

eller du har prefikser for de forskjellige applikasjonene. Eller er det meningen at forskjellige applikasjoner skal dele data gjennom Reddis eller Postgres? Det er jeg litt usikker på akkurat nå. Postgress kjører ikke i produksjon, og vi utforsker fortsatt mønstre for hvordan vi har lyst til å løse den oppgaven. Målet vårt er i hvert fall at det er en del data som er i Firestore, en dokumentdatabase som vi mye heller ville hatt i en postgressdatabase, og så itererer vi oss frem til en løsning hvor det ikke lenger er sånn. Ja, det er jo sånn vi finner ut av ting, det er iterativt og det er prøving og feiling og eksperimentering. Det er bare sånn vi lærer. Vi har snakka litt om hvordan man lager apper,

26:55 --> 27:41

men hvordan profesjonerer dere inn fra studert terraform det da, eller? Litt sånn dessverre er det fortsatt terraform. Det er egentlig et mønster som vi ønsker å gå vekk fra. Det er en del skyressurser som lages gjennom noe som heter ConfigConnector, som egentlig er en slags Google Managed Crossplane, men akkurat det mønsteret der, hvor du har et "control plane", som kjører i en evig loop og ser på koden på Github og lager de infrastrukturressursene som defineres der. Det syns vi er bedre enn terraform-mønsteret, hvor terraform-koden må trigges, det er ikke en loop som kjører. Det tror jeg noe er Hashicorp, de som lager terraform.

27:41 --> 28:22

Det er noe de har reservert for Premium og Enterprise-verktøyene sine. Mens vi har, istedenfor å gå den Enterprise-ruten, har vi laget kompliserte CI-løsninger for å kjøre terraform-koden når utviklerne lager pull request. Så i fremtiden har vi planer om å fase ut terraform og gå totalt over på et crossplane-mønster, hvor vi har et eget control plane-Kubernetesk cluster som kjører hele tiden. Og rett og slett bare fase ut terraform. Det er en målsetting. Men samtidig er det ikke veldig mye verdi i å forfølge det sporet sammenlignet med mange andre ting i backloggen.

28:22 --> 29:03

Det er mer sånn: "En gang i fremtiden kommer vi til å gjøre det". Jeg er enig i at ConfiConnector gjør det enklere både med state management og life cycle enn terraform. Det er mer ting du må bry deg om å ordne. Hva med sikkerhet? Hvordan bryr dere dere om sikkerhet i det hele tatt? Ja, det gjør vi. Det er et interessant tema, egentlig. En plattformingeniør har tre hovedmålsettinger som man alltid jobber for å optimalisere mot. Sikkerhet er én av dem, hvis de to andre er brukeropplevelsen til utviklerne. Og så er det kostnader.

29:03 --> 29:49

Og så opplever vi da at når du øker sikkerheten, så er det ganske ofte at det reduserer brukeropplevelsen. Den beste brukeropplevelsen du kan ha, er jo å være admin på absolutt alle overflatene du berører. Så jo mer sikkerhetstiltak vi legger inn, jo dårligere blir brukeropplevelsen. I tillegg er det sånn at på disse tingene som ikke påvirker brukeropplevelsen, så er det ofte sånn at de koster veldig mye penger. Så det er et kontinuerlig optimaliseringsproblem som er vanskelig å løse. Og vi gjør det vi kan uten at det går på bekostning av de to andre målsettingene. Så mikrotjenester får kun lov til å snakke med de mikrotjenestene de skal snakke med. Utviklerne har så lite tilganger som overhodet mulig,

29:49 --> 30:40

og vi prøver å gjøre det sånn at denne "git-ups-workflowen" jeg skisserte tidligere, at den dekker alle mulige behov. Ja. Sikkerhet er veldig viktig hos oss. Det er kanskje litt der hvor Celium Mesh også kommer inn, og hvor i stedet de har vært og sånn. Vil du fortelle litt mer om den biten, Didrik? Så nå, når vi ofrer Istio, så mister vi Mutual TLS i første omgang. Det er fordi vi velger å ikke gå for open source-celium, men en Google managed celium. Jeg hadde mest lyst på open source, men Google Kumanetis Engine er ikke helt samarbeidsvillig på den fronten der ennå. Jeg tror de prøver å styre oss litt over på en Google managed celium,

30:40 --> 31:28

og der kommer antakeligvis Mutual TLS veldig fort. Vi ofrer den akkurat nå fordi vi vurderer at vanlige network policies og begrensning av trafikk og det at det ikke er mange som har tilgang til å lytte på nettverkstrafikken der uansett, i hvert fall ikke i produksjon, den klarer vi oss med. Eventuelt hvis det er andre features man får i Celium Mesh? Ja. Det viktigste feature for oss der er vel egentlig evnen til veldig enkelt å kunne beskytte eksponerte web-endepunkter med e-post. En autentiseringsløsning hvis det er behov for det. Så for eksempel Argo CD. Der inne kan du jo se veldig mye, og jeg spørs hvilken bruker du logger inn med, men du kan potensielt gjøre veldig mye. Så hvis du skal logge inn i Argo CD hos oss,

31:28 --> 32:22

så må du først komme deg gjennom Googles autentisering, som er implementert via Celium. Og da kommer du til landingsiden for Argo CD. Og så må du komme deg gjennom Argo CDs sikkerhetslag, som er en tofaktor-autentisering/innlogging, Det er for ting som er backoffice for utviklerne alene, men hvis det er endepunkter som appene trenger å snakke med direkte, er det noe sikkerhetslag imellom der òg? I hvert fall på TrafikkInn er det det, men kanskje ikke like mye på TrafikkUt. Der er det litt mer manuelt med at vi må begrense hvis en applikasjon skal snakke med noen På internett skriver vi gjerne en regel som sier at det er kun den han får snakke med. Men når det er TrafikkInn, så bruker vi Google Cloud Armor,

32:22 --> 33:07

som er en fin set and forget-løsning, som egentlig bare overvåker all trafikken som kommer inn hvis noen prøver å D-dosse. Eller hvis det er sånn ... Heter det noe Script Child? Folk som skraper og leter etter sårbarheter fra utsiden, de blir automatisk tatt hånd om av en løsning som vi ikke drifter selv. Og det er veldig fint. Mens for utviklernes perspektiv så er det sånn at Cloud Armor, den er bare på. Mindre du aktivt skrur den av. Og hvis du skal ha reversprokser og den slags dype ting, så er det én linje med hjemmelkode. Og så er det viktig å presisere det at Bulla skiller seg veldig fra en hvilken som helst annen nettbank og annen tradisjonell apptjeneste.

33:07 --> 33:50

Med at det er veldig lite som er synkront, stemmer ikke det, Didrik? Det meste går gjennom Fivebase. Appen snakker om Fivebase, og så er det Eventa som skjer der. Det stemmer. Da blir det litt sånn som Markus innledningsvis, this is the back end for front end-applikasjonen. Eller tjenestene som kjører Kubaneskrøystein. Jeg har alltid syntes at det var veldig ... Har dere opplevd noe ... Skaleringsproblemer i løsningen, eller er det liksom all taken care of? Nei, jeg tror ikke vi er i nærheten av det. Eller i hvert fall ikke når vi snakker sånn CPU og ... Det nærmeste vi kan kalle et skaleringsproblem, er vel egentlig ineffektiv bruk av API-er

33:50 --> 34:43

som vi betaler per kall på. Så fra begynnelsen av har det vært utvikla her som har skrevet kode uten å være klar over at hver gang denne loopen itererer, så er det kroner på regningen. Så det er noe vi gjennom kostnadsbesparelsesløpene identifiserer og utbedrer. Men vi oppdaget jo bl.a. at den dyreste tingen vi kjører i stacken vår, er en av de minst brukte funksjonalitetene i appen. Og det er noe som har skjedd fordi vi kanskje ikke har vært flinke nok til å kommunisere at utvikleren var konsekvensen av å gjøre kall mot diverse API-er. Dette er nok litt et resultat av at vi lanserte Bulder, eller bygget Bulder... Jeg tror på Power Pointen står det på ni måneder, men i praksis byggetid snakker vi seks.

34:43 --> 35:43

Så det er klart at i perioder handlet det bare om å få funksjonaliteten til å fungere. Og så har man nå når vi har vokst ganske mye, blitt mye mer obs på hva som driver kostnad. Spesielt, og jeg fikk eventuelt andre flaskehalser vi måtte ha. Både infrastruktur- og applikasjonsplattform. Så det er noe vi jobber kontinuerlig med. Firestore f.eks. er jo et ganske dyrt produkt. Hvis du bruker det mer enn du burde, eller over evne. Og der kjører vi, og Firestore er litt som du er inne på, Hans Kristiansand, event-drevet. Bare Microservices skriver til Firestore. Det som oppdaterer til Firestore, reflekteres umiddelbart i appen.

35:43 --> 36:33

Som gjør jo dette til en veldig dynamisk applikasjon, som har minimalt med loaders. Det er noe av det som gjør Bulda-appen kul å bruke. Men det medfører jo også at vi sender jo noen titalls millioner meldinger gjennom Firestore i løpet av en dag. Det er utrolig. Og her kunne vi dykke. Vi har rukket mye dypere ned i applikasjonsarkitekturen. Det får vi eventuelt komme tilbake igjen og oppfordre lytterne våre til å sende inn masse spørsmål som vi kan ta med oss på eventuelle oppfølgere. Kanskje vi skal lage en sånn søsterpodkast som heter Applikasjonsarkitekturpodden? Ja, Applikasjonsarkitekturpodden. Der. Vi begynner å gå inn for landing, men før vi avslutter har vi et spørsmål som vi spør alle gjestene våre.

36:33 --> 37:17

Det mest prominente eksempelet kommer på å være da vi skulle redusere kostnaden vår i forbindelse med monitorering, og vi dropper Google Manage Prometheus til fordel for Victoria Matrix. Men så hadde vi lyst til å ha alle monitoreringsdata i en og samme plattform, så da begynte vi å importere data fra Google Cloud inn i Victoria Matrix, noe som medførte veldig mange API-kall som vi betaler for, og så gikk det noen uker hvor vi betalte mer enn den gamle løsningen. Men det ble oppdaget, og vi skrudde av den delen, og nå bruker vi Google Cloud til Google-tingene og Victoria Matrix til kubanetis-tingene.

37:17 --> 38:15

Markus, har dere noen prosess for å snakke om noe sånt hvis feil skjer, eller er det noe post mortem? Ja, vi er veldig opptatt av å lære av de feil som skjer. Løper man fort, så snubler man av og til. Det anerkjenner vi. Nå husker jeg ikke akkurat for denne saken her, men generelt sett så skriver vi post mortem for alle incidents som vi har. Der vi både går ganske dypt inn i kartlegging av hvorfor ting skjer, og ikke minst med mål om å lære av de feilene som eventuelt måtte oppstå. Det er noe vi tar alle på post mortem veldig på alvor, og så kjører jeg det i en fellessesjon med alle utviklerne. Så ha alle obs på hva som har skjedd og hvorfor,

38:15 --> 39:10

og hva som kanskje er lurt å unngå neste gang. Det er jo en herlig ironi det at for å spare penger, så må man bruke penger. Eller i hvert fall i dette tilfellet. Men det er veldig gøy eller bra å høre at det endte. At det endte godt, og at man fant ut av det. Vi holder på å runde av her, og er det ellers noe dere vil si før vi avslutter denne episoden? Hvor går veien videre for Bulda f.eks.? Vi kan jo begynne med deg, Markus. 2024, som vi er på veien i nå, blir jo et år der vi går ... på en måte ... Vi kan kanskje si mer over i en driftssituasjon enn det vi kanskje har vært i tidligere. Vi har vært veldig i byggefase. Det betyr også, som jeg har vært inne på tidligere,

39:10 --> 40:08

at vi er 47 ansatte i Bulda. Vi har alle ambisjoner om å vokse mye mer i forhold til kunder og lånevolum. Og for å få det til, så må vi være så effektive som mulig på innsiden. Og det betyr jo at vi må optimalisere for effektiv drift. Bygge de verktøyene vi trenger for å kunne hjelpe kunden best mulig. Eventuelt rydde av veien de små feilene som vi eventuelt bruker tid på i dag, for å rette opp. Så optimalisering er vel kanskje sånn kort oppsummert... Det 2024 kommer til å handle om for vår del. Hvor går veien videre med plattformen til Bulda? For plattformteamet skal vi fortsette med å forbedre utvikleropplevelsen.

40:08 --> 40:55

Vi skal forbedre sikkerheten og redusere kostnadene. Men sånn umiddelbart kort sikt er vi i en prosess hvor vi går fra å ha to utviklingsmiljøer til tre, så nå blir det en DavStagingProd-løsning. I det Dav-miljøet så har vi egentlig trengt til å bare lage en total ny utvikleropplevelse. Koble den fra git-ups-biten og egentlig eksperimentere litt der. Prøve å få feedback fra utviklerne og finne ut hva som funker best for de før de lager pulver-questen sin. Det er enormt spennende å høre og jeg vil bare si tusen, tusen takk til Markus Nordstrønen og Didrik Finnøy fra Bulda for at dere har delt deres kunnskap og erfaringer med hvordan bygge en hel digital og mobil first-bank med alle lytterne våre.

40:55 --> 41:26

Og Audun, nå er jeg veldig spent, hva er ditt høydepunkt fra den episoden? En ting jeg tenkte var veldig gøy å høre om, og som jeg tror er et bra tips å ta med seg videre, er nettopp det at man har en så tydelige prinsipper, en strategi, om hvordan plattformen skal være. Og det at de kunne formulere det så tydelig, tror jeg hjelper når man må lage plattform og gå avtale de små stegene som skal til for å klare å lage noe som funker. Hva med det, Hans Kristian? Det er utrolig spennende å høre på alle de tekniske løftene

41:26 --> 42:07

som er gjort av et så lite plattformteam. Jeg har selv vært inne og jobbet med Bulda tidligere, i den der oppstartsfasen som Markus nevnte. Og det var utrolig hektisk. Og der var det alle kluter til for å få det på luften. Og det er klart at mye Didrik og teamet hans og de andre Bulda har måttet løfte på flere områder etter det. Og faktisk klart å ta de løftene der i fart, mens man da har den økningen i kunder og volum. Så det er et imponerende stykke arbeid. Og med det avslutter vi denne episoden av Plattformpodden.

42:07 --> 42:34

Mitt navn er Hans Kristian Flåtten, og med meg har jeg som vanlig 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. Takk for følget, og ha det bra!