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 én av Plattformpodden utforsker vi noen av de beste plattformene som offentlig sektor i Norge har å by på. Men før vi introduserer dagens gjester, Audun, har du noe bakgrunnsmoment? Har du noe bakgrunnsmusikk som du hører på når du programmerer? Ja, jeg har jo det, men jeg har litt det samme forholdet til musikk som Drillo hadde, at jeg tenker på musikk mest som støy. Så jeg har ikke noen spesielle ting jeg hører mye på.

00:43 --> 01:28

Så det er litt tilfeldig. Hva med deg, Hans Kristian? Jeg hører gjerne på litt sånn Low-Fi-musikk. Det må være noe uten vokal, og noen rolige, melodiøse toner, gjerne med noe retro, 8-bit, Zelda, Star Wars. Melodier som jeg kjenner fra min barndom. Da får jeg den gode følelsen i meg. Men i dag skal vi ikke snakke så mye om musikk. I dag er vi så heldige å ha med oss Eirik Eidsaa og Kjetil Espedokken fra Husbanken. Husbanken er kanskje en organisasjon som ikke så mange av lytterne våre har hørt om, men som spiller en svært viktig rolle for samfunnet vårt. Nemlig å sørge for like muligheter til å skaffe seg og beholde egen bolig. Her jobber Husbanken sammen med kommuner, frivillige organisasjoner

01:28 --> 02:14

og byggesektor med å dele sin kunnskap og kompetanse. Og i 2024 forvalter Husbanken en utlånsramme på 29 milliarder kroner. Erik, kan ikke du begynne å fortelle litt om hvordan du begynte i Husbanken, og hva du jobber med? Jo, jeg begynte i Husbanken for noen år siden nå. Fem år, kanskje, eller noe sånt. Søkte egentlig på jobb som utvikler, men endte opp som devops-utvikler på Plattformtime. Det har jeg vært veldig fornøyd med. Så har jeg drevet med byggeplattform siden det. Veldig interessant. Dette skal vi dykke mer i, men først Kjetil, hva med deg? Hvorfor begynte du i Husbanken, og hva er din rolle? Min rolle i dag er som leder for avdeling for IT-arkitektur,

02:14 --> 03:16

som er en avdeling i Husbanken hvor bl.a. plattformen tilhører. Jeg begynte i Husbanken som systemarkitekt. Tilbake i 2017. Da hadde jeg jobba med litt ledelse i en stund, og hadde lyst til å gå tilbake igjen og være litt mer hands on. Fant en jobb i Drammen, visste at Husbanken hadde et godt teknologimiljø. Det var jo ikke så veldig mange av de i Drammen på den tiden. Så jeg begynte da på et spennende tidspunkt. Det var jo da vi var tidlig i plattformreisen vår, som vi skal snakke litt mer om etterpå. Endte etter hvert opp som avdelingsleder for IT-arkitektur. Men er fremdeles hands on og har et overordna arkitekturansvar for alle de løsningene vi lager i Husbanken.

03:16 --> 04:19

For det er ikke så veldig mange i Husbanken. Vil du si litt om omfanget? Husbanken, vi er ikke så veldig store. Vi er totalt ca. 300 stykker. De aller fleste jobber på hovedkontoret her i Drammen. Hvor vi har fire nasjonale kontor. Vi har de som jobber med lån og tilskudd. Vi har kommune og marked som er litt salgsapparatet vårt. Har kunnskap som jobber med å se hvordan virkemidlene våre treffer. Jobber med hvordan vi kan gjøre forbedringer og kanskje bidra til politikkutforming osv. Og så har vi Digitaliseringskontoret, som nå har blitt Husbankens største kontor. Vi er noen og sytti ansatte på IT. Og så har vi 20-25 konsulenter inne.

04:19 --> 05:38

Så vi er et passe stort teknologimiljø her i Husbanken. Erik, du jobber med plattform. Vil du fortelle litt mer om hvordan plattform i Husbanken ser ut? Ja, vi har et openshift-cluster som kjører på huset, og da tilbyr vi jo en del tjenester. Så utviklerne bruker ... eller vi har et eget format som definerer hvordan kjøremiljøene skal være. Og så bruker vi IOCD til å via en egen snurre der for å synkronisere applikasjonene inn i clusteret. Så driver vi også med å bruke ByggIO og pipelines. Vi har standard pipelines som vi bygger applikasjoner med. Så vi prøver egentlig å lage en full pakke, sånn at utviklerne kan ha minst mulig distraksjoner fra å skrive kode. Dere har hatt plattform veldig lenge. Jeg husker jeg møtte noen fra dere i 2018, var det 17?

05:38 --> 06:36

Kan du fortelle litt om hvordan ting har utvikla seg siden starten? Husbanken, vi har jo hatt en ganske lang reise som du er inne på. Vi begynte tidlig. Vi begynte med Java-baserte applikasjoner tilbake i 2004. Og i starten så hadde vi jo som alle andre dedikerte applikasjonsservere og dedikerte holster. Etter hvert som vi bestemte ... Etter hvert som vi bestemte oss for å modernisere alle applikasjonene våre, tilbake i 2012, så fant vi ut at dette skalerte dårlig. Vi gikk over til Jboss-cluster i starten. Hadde det på plass fra 2013 ca. Det gjorde jo ting litt bedre. Gjorde at det skalerte bedre, men det var jo en del utfordringer også med det.

06:37 --> 07:34

Så når vi hørte om dokker ... Dokker kom vel en gang i 2013. Da var det plukka opp veldig raskt i Husbanken. Vi diskuterte det på ... Jeg var ikke der da, men det ble diskutert allerede i 2014 på avdelingssamling om man begynte å legge planer for hvordan man kunne ta i bruk dokker. Det ga jo mange fordeler for både utviklere og drift. Og da begynte man, da vi begynte å lage nye ... Vi har mange ulike applikasjoner, men da vi kom til e-søknad for startlån, så begynte man å lage sin egen containerplattform i Husbanken. Sånn i 2015 ca. Det var litt strikk og binders.

07:34 --> 08:30

Det skjedde jo også endringer i både måten å jobbe på og i arkitekturen. Vi gikk over ... Fra 2012-2013 så begynte man med litt mer tjenester på starten. Vi gikk over ... Fra 2012-2013 begynte man med litt mer tjenestebasert arkitektur, introduserte stadig flere tjenester. I 2015 da begynte vi å tenke mikrotjenester. Begynte å lage saksbehandlingsløsning for startlån. Hvor applikasjonen besto av den gang ca. 13 tjenester. Og man fant ut at det var en del begrensninger i den egenutvikla tjenesteplattformen vår.

08:30 --> 09:21

Men da hadde vi gjort ganske mye rundt det å automatisere. Det å få opp hele plattformen, det var automatisert ved hjelp av ARG og CD. Vi hadde gjort mye rundt standardisering på applikasjoner og tjenester. Vi hadde ganske mye på plass. Men vi hadde en del utfordringer, særlig med det å håndtere sikkerhet, tilgangsstyring, den type ting. Så da begynte vi å kikke litt rundt og se hva som finnes av mer standard produkter. Vi valgte tidlig å se mot Kubernetes. Vi ønska å finne noe som var basert på Kubernetes. Hadde samtaler med ulike leverandører.

09:21 --> 10:15

Etter en prosess endte vi opp med OperShift fra Red Hat som vår tjenesteplattform eller containerplattform. Den ble ... Ja, nå er vi kommet til ca. 2016. Og da hadde vi jo en periode hvor vi hadde fremdeles noe kjørende på Jibos. Vi hadde vår egen containerplattform som noe kjørte på, og vi begynte å bygge OperShift-plattform og begynte å migrere over til applikasjonene våre. Vi begynte med de som kjørte på vår containerplattform. Fikk det over først på OperShift, og så hadde vi også laget vårt eget tjenesterammeverk som ble brukt av applikasjonene våre i Husbanken.

10:15 --> 11:02

Vi fant ut at det var en del utfordringer med det, så da vi starta et nytt prosjekt i 2018, valgte vi også å gå for Spring og Spring Boot, som er litt av den stacken vi har i dag. Og da har vi vel siden jobba litt med å migrere over de ulike løsningene våre fra clustre og gamle rammeverk over til den nye, moderne tjeneste... Altså stacken vi har for tjenesterammeverk. Tjenesterammeverk og OperShift-plattformen vår. Så det var litt sånn ... litt lang, men det var litt reisen vår inn til den plattformen vi har i dag. For det første må jeg bare si at det er veldig kult at dere var så tidlig på.

11:02 --> 11:54

Dokker i 2014 er heftige greier, altså. Vi har hatt dedigerte mennesker, og det er litt av Husbanken. Vi liker å prøve ting tidlig. Veldig god kultur for det. Veldig god kultur for det i Husbanken, det er noe jeg liker aller best. Med Husbanken er den viljen til å ta tak i noe som ser spennende ut, prøve det ut og se om det kan være noe for oss. Det er veldig, veldig bra. Men det kom jo ikke gratis. Det var jo mye prøving og feiling. Er det noen av de valgene dere har tatt på veien som har vært spesielt bra eller spesielt dårlig? Jeg tenker ... Jeg syns vi har tatt gode valg i Husbanken. Vi har på en måte hatt en god utvikling både i ...

11:54 --> 12:47

Det vi ikke snakker om, er måten å jobbe på. Det har også endra seg betydelig i den perioden. Vi har hele tiden utvikla måten vi jobber på. Jobbe smidig, mer agilt. Vi har utvikla arkitekturen vår i tråd med ... Med beste praksis den veien trendene har gått. Vi har vært relativt tidlig ute, men ikke sånn veldig tidlig ute. Vi har gjort ganske trygge valg, gode valg. Men det er klart når vi gikk over til å prøve ut mikrotjenester, som så mange andre, så er jo det en ... Det er jo ikke alltid du trenger å strekke strikken og se hvor langt. Den strikken kan strekkes, for å si det sånn.

12:47 --> 13:41

Men vi har litt av kulturen. Jeg syns vi evner å ta oss inn igjen fort. Hvis vi gjør feil valg, så er vi ikke redd for å gjøre noe nytt, prøve noe nytt, endre. Så har vi gjort noen veldig sånn store feil. Det å bygge sin egen plattform var jo ambisiøst, da. Kan jo si det. Men vi lærte utrolig mye av det. Husbanken lærte veldig, veldig mye. Den fikk veldig god forståelse. Så jeg tror det var et godt valg. Fremfor å kanskje prøve å finne noe annet. Så tror jeg akkurat den fasen gjorde at vi har skapt en veldig god kompetanse rundt plattform. Så vi så jo at det ikke var veien, men ...

13:42 --> 14:37

Det var veldig lærekt. Hva vil du si er de største forskjellene mellom Husbanken og andre private banker når det kommer til det å ta litt risiko på ny teknologi, endringsvilje? Er det store forskjeller der? Vi har ikke snakka så mye om Husbanken utover din introduksjon, men Husbanken ... vi er jo i ... Vi er jo ikke helt som andre banker. Vi er jo en boligsosial aktør. Vår fokus er at alle skal bo godt og trygt. Det er det vi jobber for hver dag, og det er det våre løsninger skal hjelpe til å oppnå. I forhold til andre banker ... Vi er jo offentlige. Jeg tenker at vi har en ... Vi er ganske ... Skal vi si ...

14:37 --> 15:56

Trygge på, i valg av prosjektet, hva vi lager for å oppnå våre mål i Husbanken. På teknologisiden så vil jeg si vi er relativt ... risikovillige. Men vi er ikke rede for å prøve og feile på teknologi. Vi tester ut ting, og det har vi hatt rom til i Husbanken. Det er vi opptatt av å gjøre. Vi prøver ut ting. Vi får ting til å ... Vi ser om det er noe for oss som gir verdi, og så prøver vi å rulle det ut så fort vi kan på tvers av timene. Men løsningene vi lager, der er vi opptatt av å gi verdi til brukerne våre, om det er innbyggere, om det er kommunale saksbehandlere, eller om det er Husbankens egne ansatte. Så er vi opptatt av å velge den funksjonaliteten som gir størst verdi for brukerne våre. Der kommer jo plattformen inn, som gjør det mulig for utviklingsteamene å levere raskt.

15:56 --> 16:56

Og levere disse nye applikasjonene. Enten det er til brukere, fulktbehandlere eller interne. Hvordan jobber ditt team med å finne ut hva dere skal lage i plattformen? Hvilken funksjonalitet trenger dere, og hvordan samarbeider dere med utviklingsteamene? Vi jobber mye med å ha litt stråer ute, og se hva som skjer i markedet. Lære nye ting, følge med. Så har vi også en veldig tett dialog med de teamene som er ute i prosjektet, lytter til dem. Vi har jo veldig mye trafikk borti plattform. Når de kommer med et problem, så er vi ganske kjappe med å prøve å finne en løsning og implementere funksjonalitet som de etterspør. Eller vi ser at de gjør ting veldig tungvint, så prøver vi å automatisere ting osv.

16:56 --> 17:57

Hvis jeg kan legge til, jeg syns jo veldig lave skott mellom de ulike teamene i Husbanken. God informasjonsflyt, og man er flinke til å dele og hjelpe hverandre. Plattformteamet har vært helt sentralt i å få det til å fungere også i Husbanken. Jeg kan kanskje si at en stor del av vår suksess også tror jeg at vi har bundet ... På plattformen har vi ikke bare Oppershift-plattformen, men vi har også bytta inn rammeverk. Så selv om vi har et veldig ... Det er godt samarbeid, og mange i teamene bidrar til f.eks. springbytte eller rammeverket som vi har, men det holdes i av meg på plattform. Samtidig har vi designsystemet og fronten-komponentene. Det er også en som sitter hos oss og holder i det.

17:57 --> 18:47

Så vi får helheten på hele plattformen samla hos oss, som tror jeg har vært en stor del. Rammeverket snakker godt med plattformen. Vi får inn overvåking og vi har felles måter å drive artifisering på. Kommunikasjonen mellom tjenester blir gjort på en standarden måte. Alle de tingene gjør at plattformen snakker bra rundt i teamene og tjenestene snakker sammen bra inn i clustera. Det er egentlig lagd en ganske høy plattform som gjør ganske mye applikasjon. Ja, du kan si det, men selv om det holdes i hos oss på plattform, så er det veldig mye bidrag som kommer ut fra teamene selv. Det er bare at vi på plattform har en slags koordinator-rolle,

18:47 --> 19:39

eller vi passer på at ting blir kommunisert rundt og at det blir en helhet rundt det. Sånn at hele plattformen blir et slags samarbeidsprosjekt i hele Husbanken. Så vi er jo veldig få på plattform, vi er bare sju-åtte stykker. Men likevel har vi et såpass stort ansvar, da. Er det utfordrende å få alle utviklerne til å gå med på det, eller tenker de at det er greit at det egentlig bare er hjelp å slippe å løse alle de tingene sjøl? Jeg har inntrykk av at de aller fleste er veldig glad for at vi har en såpass altoppfyllende plattform. Men det er vel også mye at de bidrar mye. Hvis et team driver med et eller annet som de ser, hvis et team driver med et eller annet som de ser kunne ha veldig god effekt eller positive innvirkninger, så bidrar de det selgeren å implementere det

19:39 --> 20:31

inn i sin egen applikasjon og bare gjør det tilgjengelig for seg selv. Så begynner de å lage en pull request inn i et felles rammeverk. Og i og med at de er såpass flinke til å oppgradere også, så er de aller fleste med på hele reisen, så vi har jo allerede oppgradert veldig mye til Java21. Vi er på nesten siste springroots-starter. Vi har ikke mye sånn ligger bak hele tiden. Vi passer hele tiden på å få med halen. Så det ... ja. Det var det jeg skulle spørre om. Hvordan klarer dere å holde ting oppgradert? Ofte kan det være utfordrende fordi det blir så spredt, og du har vanskelig å holde oversikten. Det er så mange som må velge å oppgradere for å levere på et eller annet de har lovet. Men hvis man får det inn i kulturen, så er det jo masse fordeler med det også.

20:31 --> 21:23

Vi har implementert et verktøy som heter Renovate, som hjelper veldig med å holde oppdatert. Så vi bruker Renovate kun på husbanken Defendancies. Og så lager den Automatic Procrast, så veldig mye av oppgraderingsjobben skjer egentlig helt av seg selv, uten at vi trenger å gjøre så veldig mye. Github tror jeg har lignende verktøy som Dependerbot. Så det er jo tilsvarende, bare at vi kjører det selv, da. Bruker dere Github forresten? Nei, vi hosta Atlassianstacken sjøl inntil nå. Men det er jo ikke så veldig fint. Hva gjør dere når den lisensen går ut, holdt jeg på å si? Vi har valgt å gå foreløpig ut i skyen med de, fordi vi ikke har beholdende rett til å ...

21:23 --> 22:14

Ikke har beholdende rett til å tenke så mye på alternativer akkurat nå. Men vi har vel ikke låst oss til de for uendelig, så vi får se. Men du sier at Renovate bare var på de interne avhengighetene. Hva gjør dere med det eksterne? Springboot-rammeverket vårt, den får jo inn av alt, ikke sant. Men for å slippe støyen videre ut i prosjektene, har vi sagt at ... Vi har Springboot-rammeverket, det håndterer alle eksterne avhengigheter. Så lenge du holder deg oppdatert på Springboot, så er du oppdatert ellers også. Så har vi i tillegg Snikk som går rundt og sjekker hvis det er ting som må kreveres. Det hender jo at team drar inn egne avhengigheter utenfra.

22:14 --> 23:07

Men da plukker vi opp de sikkerhetsissuene via Snykk isteden. Hvis jeg skal lage en ny applikasjon hos dere og skal ha et API og en database, hva er det egentlig jeg må gjøre da? Da har vi en Maven archetype som du kjører, som spytter ut et ferdig prosjekt. Med ferdig byggepipeline, ferdig alt, egentlig. Du må velge hvilken systemgruppe du skal være i. Om det er bostøttestartlån, KOBO eller hva som helst. Og et navn på tjenesten. Så dytter du det inn. Så dytter du det inn i Bitbucket, og da bygger du automatisk, og du har et image som du kan kjøre så det vil ta deg ... Ja, jeg vil bruke to minutter ca. for å få en applikasjon fra scrapfolding til ut i åpenskift.

23:07 --> 23:57

Men hva er det med eksterne avhenger? Jeg trodde du skulle spørre om akkurat det samme. Hvis jeg vil ha en ny database til den applikasjonen, hvordan går jeg frem da? Da må det spørres litt om du skal i test. Så kan du sette opp en egen database. Men i produksjonen bruker de i all hovedsak Microsoft SQL, som kjører ikke i clusteret. Da blir det litt mer styr. Så det kommer litt an på hva slags krav du har til database. Så tror jeg dere bruker Tekton Pipelines og ikke Bitbucket Pipelines, stemmer det? Ja, det stemmer. Så vi har jo hatt ... Da jeg kom inn ved Husmarked, brukte vi Jenkins. Da hadde vi lagd et rammeverk som var skrevet i skala

23:57 --> 24:48

eller et eller annet sånt greier som jeg aldri ble helt venn med. Og etter hvert så ... Det var veldig keitete å drive på med. Så testa vi ut Tekton og skrev egentlig alt over til en ... Rammeverket som vi hadde skrevet der, hadde vi skrevet over til en IAW-applikasjon som basically lagde Tekton Pipelines. Så vi flytta alle over, egentlig, veldig kjapt. Fordi vi gjenbrukte de samme manifestfilene som vi hadde fra før. Så det ... Vi har hatt en tradisjon i Husbanken så lenge jeg har vært her, å prøve å abstrahere vekk mest mulig. Sånn at i alle repene så har vi en fil som vi kaller for HBbild.

24:48 --> 25:35

Som vi har noe ... ja, definerer, da. Er det helt standard spring route eller standard frontend-bygg, så trenger du egentlig ikke definere noe annet enn hvilken systemgrep på system og navn. Og så finner den "tensible defaults". Hvis det er en POM-fil der, så vet den at den skal bygge det. Er det en package av Jason, vet den at det er node. Er det en dokke-fil, så vet den at den skal bygge dokker. Og tilsvarende, i deploy-konfig har vi også definert våre egne skjemaer. Litt sånn Nav og Drateru har deres eget manifest. Så vi har også det, men vi har ikke ... Eller vi har egentlig hatt de samme filene hele tiden. Hvor vi definerer bare image-versjon,

25:35 --> 26:17

og så er det standard spring route, så trenger du ikke definere noe særlig mer, egentlig. Annet enn hvis du trenger litt mer minne enn defaults eller sånn. Og så har vi en Java-applikasjon som snurrer gjennom med "fablicates" for å definere opp alle definisjonene. Så det har jo også gjort at flytting fra oppskift 3 til oppskift 4, f.eks., da vi gjorde det, var også rimelig enkelt. Fordi vi måtte bare skrive om den ene applikasjonen som drev med skrappfolde og alt det greiene. Så fikk vi Indistio og fikk flytta over alt som skulle gjennom det. Og måtte skrive om alle definisjonene. Men dra litt gjennom den Java-applikasjonen.

26:17 --> 27:02

Du sier at du har et deploy-manifest som du sender til en Java-applikasjon, og så spytter den ut Kubernetesk-manifester i andre enden? Da vi var i OperShift 3-verden, var det sånn. Og da vi migrerte, fant vi ut at Argo CD var en greie. Og da tenkte vi at det var jo veldig kult. Så det vi gjorde da, var egentlig å lage ... Vi fortsatte med de samme filene, men istedenfor at Java-applikasjonen skulle applie det direkte på clusteret, så fikk vi til å spytte det tilbake til Argo CD. Så det er nå Argo CD som gjør jobben, men vi har fremdeles den samme Applikationen med Fablicate som skrappholder alt av hvordan det skal bli.

27:03 --> 28:02

Kom midt av den detaljen, et github-repo, og så tar Argo det videre derfra? Nei, så vi har laget det sånn at vi har et konfigrepo per system. Og så for hvert miljø du vil ha, så lager du en egen branch for det. Og så the branch-navnet, det prefikses med hvilket cluster du skal ha det på. Så inni de repoene så har vi våre egne Jason filer som definerer ... Vi definerer versjon, image og andre greier hvis vi ikke har en annen port eller motforbodning eller må ha litt minne eller sånn. Så da er det en webbook til Argo CD som lytter på endringer dere er på. Og da har vi laget en liten extension på Argo CD som faktisk går og kaller den applikasjonen for å få tilbake hjemmelen.

28:02 --> 28:55

Da pleier den å ende rett på clusteret. Vi har ikke noe sånn mellom-komitt eller noe sånt som gjør det. Så det er bare det ene repo, liksom. Det er jo veldig likt som operator patternet, bare at den kjører litt på utsiden, men likevel kaller inn og gjør de operasjonene. Vi kommer nok til å vandre mer i retning av en operator variant. Ja. Jeg har bare endt opp der for historiske vandring, liksom. Si at du har et nytt team mellom nyutviklere. Hvor går den personen for å finne informasjon om plattformene og plattformtjenestene og konfigurasjoner? Det kommer litt an på hvor dypt han skal. Men hvis det er sånn overfladisk

28:55 --> 29:46

som jeg trenger å deploye en ny versjon av i dette miljøet, så har vi laget et eget utvikla ... Vi kaller det for systemoversikt. Det er basically en skanner gjennom alle konfigurerpene og lage sånn at du enkelt kan finne miljø, velge hvilken versjon som skal kjøre osv. Så har du samla alle linker til overalt hvor du skulle trenge å gå. Inn til Open Shift og inn i pipelines og gitt repos og overalt. Spotfide har et verktøy som jeg har glemt navnet på nå. Backstage, takk. Så det er på en måte vår egen backstage. Som jeg har utvikla siden jeg kom inn i Husbanken. Vi har planer nå om å flytte over til backstage, faktisk.

29:46 --> 30:29

Men backstage fyller ikke helt denne rollen, så vi kommer til å utvikle våre egne, flytte systemoversikt over i backstage. Og samtidig få en del gratis fulltidalitet som backstage. Har som vi ikke har i systemoversikt. Det er litt av det vi skal jobbe med framover. Hva med overvåkning og monitorering, hvordan gjør dere det? Vi har Grafana og Prometius til overvåking. Og da har vi ... trodde vi vi hadde lagt godt til rette for at teamene skulle kunne lage alert og greier, men fremdeles kommer brukerstyrker og isløpere og sier at nå feiler det her.

30:29 --> 31:26

Fordi folk har ringt, så fant vi ut at det var litt for ... Vi måtte gjøre et eller annet, så da endte vi opp med å lage standard-alert som vi pusha ut i alle namespace med en standard Grafana-dashboard. Som nå har gjort at vi hører ikke så veldig mye at ting feiler lenger. Så det er jo bra. Samtidig som teamene kan lage flere alert eller dashboard om de trenger det. Men vi har prøvd å dekke basisbehovet for å si at ting feiler. Typisk type 500-feil. Er det kanskje noe latency-alarmer òg? Eller hva slags alarmer snakker vi om? Vi har hatt standard som latency, lytte på HDTPR-koder. Det er hovedsakelig indikatornumrene som vi har, om tjenesten kjører eller ikke, eller om det er

31:26 --> 32:21

færre replikas enn det skulle vært, eller ... Se litt på status på pod feilstatus og jobber som kjører og sånne ting. Men har utviklerne også muligheter til å bygge inn custom matrics i applikasjonene sine? Og få det inn i Prometheus og Grafana? De kan gjøre det. Det er jo egentlig standard spring-bloot- eller mikrometerrammeverk. Så det er det noen som har gjort, å hente det ut i egne dashbord. Hva gjør dere med logging og eventuelt om dere har sett noe på tracing? På logging har vi flere muligheter. Skal vi se logging på tvers av massetjenester, har vi splunk av historiske årsaker. Så har vi elgstacken liggende som ikke brukes så mye,

32:21 --> 33:09

bare fordi den kom med åpent skift. Spurte om en ting til, husker ikke. Tracing. Ja, vi bruker Istio. Så Istio i kombinasjon med Spring sine tracing-greier, gjør jo at vi får veldig god innsikt i ... I trafikk og hvem snakker med hvem, og hvor feiler det, osv. Så vi har jo Kiali, som er veldig ålreit å bruke til å sikte på sånne ting. Jeg ville bare si fort hva Kiali er for de som ikke kjenner til det. Du får et grafisk bilde, og du kan se hvem kaller hvem nedover, og du kan se timingen, sånn at du ser hvor det feiler og hvor lang tid ting tar.

33:09 --> 34:05

Du kan få ganske god oversikt over hvor det går galt. Bruker utviklerne det òg, eller er det mest plattformer eller de som er mer driftsteknisk som bruker det? Godt spørsmål. Vi har prøvd å gjøre det godt tilgjengelig med å linke direkte i systemoversiktpartiet vårt, så du kommer lett inn. Men vi har vært litt uheldig med migrering av de ... Vi opererte Spring sist, og det ble litt ødelagt, de tracing-nøklene og sånn. Så det har ikke vært sånn helt 100 % siste tida. Det er jo et verktøy som i hvert fall vil prøve å promotere mer utviklerne. Det er veldig nyttig. Så det korte svaret er vel at i hovedsak vi på Blattform som har brukt det, sikkert.

34:05 --> 34:54

Det at dere har en sånn veldig opinionated plattform, da, hvordan påvirker det applikasjonsarkitekturen og arkitekturneret generelt? Tenker dere at det er en styrke? Jeg tenker at det er en styrke, fordi du må se det i sammenheng med størrelsen på organisasjonen. Hvis hvert team skulle måtte sitte og gjøre veldig mye valg og velge sin egen greie, så ville det blitt mer utfordrende. Hvis vi måtte flytte på folk, som vi gjør av og til, så måtte man lære seg helt nye ting hele tiden. For Husbanken så har det vært veldig positivt, med tanke på størrelse. Og at vi får et litt større miljø rundt det vi har.

34:54 --> 35:45

Og at flere bidrar og drar sammen, gjør at vi har fått en veldig bra plattform. Som har kommet ganske langt. Så må vi kanskje legge til, selv om vi har en opinionatet plattform, så er det jo stor grad av mulighet til å påvirke fra de ulike teamene hva de ønsker. De har veldig tett kontakt med plattformteamet og de som utvikler rammeverkene, sånn at man greier ofte å finne løsninger på de utfordringene som kommer. Men det har vært en bevisst strategi å prøve å standardisere og få ting over til ... Å harmonisere, få ting så likt som mulig. Nettopp fordi vi ser det som en styrke som Eirik beskrev godt.

35:45 --> 36:36

Hva med sikkerhetsutfordringer, hvordan løser dere de? Vi har vært litt inne på det, men er det andre ting rundt det som er nyttig å snakke om? Tenker du på hvordan vi autentiserer, hvordan det fungerer, eller tenker du mer på sik... For eksempel. Vi kan jo si at vi bruker Red Hat SSO, som er jo en litt eldre versjon av Kick Clock, med support. Og så har vi laget våre egne moduler inni der som håndterer Husbanken-ting og integrerer ID-porten osv. Og for Test så har vi laget en egen versjon av Kick Clock som vi faker inn loggingen, som vi får ... Så i Test og i produksjon så kan vi gjennomføre full sikkerhets...

36:37 --> 37:34

Sikkerhetsoversikt, eller sikkerhetsmekanismer, hele veien ved at vi ... Rammeverket og Kick Clock kjenner hverandre ... Eller det er vi som har lagd begge deler, så vi har begge ender og kan lage sikkerhetsregimer som henger sammen. Sånn type nettverkssikkerhet, Network Policies, Istio har en del funksjonalitet rundt trafikkstyring og sånt? Ja, vi bruker Istio til Mutual TLS. Så langt så har vi ikke så veldig mye restriksjoner med mindre vi ser det er behov for det. Så så lenge du er inne i meshet så kan du stort sett snakke med det du vil. Så lenge du ... Kick clock og issuer og sånn og stemmer, da. Så vi har på en måte flere lag med sikkerhet.

37:34 --> 38:18

Alle tjenester i rusbanken skal jo være sikret som en resource server. Altså at de tar inn en eller annen claim eller token? Ja, de tar inn en token, og så vet du ut fra tokenet hvem det er snakk om om det er en service agent eller om den brukeren har rettighet til å gjøre noe med den ressursen eller ikke. Og så sender man kanskje det med videre innover hvis du trenger å kalle andre tjenester i systemet. Det er helt klart at her er det veldig mye vi kunne ha dygget dypt. Kanskje kan vi ta en oppfølgingsepisode ved en senere anledning som anbefaler alle lytterne å sende inn spørsmål hvis dere har det.

38:18 --> 39:03

Kan vi ta det med videre. Vi begynner å gå inn for landing, men før vi avslutter, så har vi et spørsmål vi spør alle gjestene våre. Det er om dere kan fortelle om en gang ting ikke gikk helt etter planen, og hva dere lærte av det. Ja, vi har vel stort sett en ganske stabil plattform. Det er sjelden vi går ned. Vanligvis så finner vi ut av det. Men det kan kanskje komme et eksempel av noe som feila som var utenfor plattformen. For vi hadde en ... Vi har hatt dårlig samvittighet lenge for en antivirustjeneste som gikk og snurra på en eldre Windows-maskin.

39:03 --> 39:55

Som gikk ned hver helg i en periode. Og det var litt spennende, for feilmeldingene hos utviklerne pekte i litt andre retninger. Så det var vanskelig for de å forstå at det var det som skjedde. Mens infrastruktur visste jo at den gikk ned hver helg og fikk noe opp i klokka åtte. Men de utdelte som kom klokka seks, satt og spredte seg i håret og skjønte ingenting. Så til slutt fikk vi jo samla oss og finne ut hva de var. Fikk jo flytta det over på en nyere Linux-maskin og fikk overvåking på den så den var litt mer synlig i plattformene osv. Lærdommen er vel å ikke ha så mange svin på skogen. Når du har dårlig samvittighet for noe, så burde du gjøre noe med det.

39:55 --> 40:47

Men sånn i etterkant av sånne hendelser ... For det er jo ... Dette er jo sånt som skjer oss alle. Men har dere noen prosess for hvordan dere lærer av sånne denne og lignende feil, og jobber for å forbedre organisasjonen og prosessen? Vi prøver jo alltid å lære av feil. Sånne hendelser ... Vi har ikke en ... Hvis det ikke blir logga av oss med Davik, så er det ikke en sånn veldig formell prosess. Men teamet er veldig flinke til å lære av feil og finne ut hvordan skal vi løse det. Og så har vi gode kommunikasjonskanaler ut til alle teamene våre som bruker plattformen hvis det er ting de må gjøre og ta tak i.

40:47 --> 41:53

Så det er mer kulturen, vil jeg si, som sikrer at vi fanger opp og forbedrer oss over tid enn akkurat de formelle beskrevne rutinene. Kulturen i Husbanken er ... ja. Det er kjempeviktig å ha den kulturen der. Vi kan alltid bli bedre, og vi skal gjøre det sammen uten å måtte peke for mye fingre. Er det ellers noe du vil si, Kjetil? Hvor er veien videre for Husbanken? Ja, hvor er veien videre? Vi fortsetter med å bygge plattform og bygge team. Som Eirik var innom, så er vi ikke så veldig mange i plattformteamet. Syv stykker. Vi prøver å styrke teamet litt, og vi driver og ansetter nå nye driftsteknikere på Kubernetes. Ny arkitekt, og så tenker vi også å styrke teamet med litt ... kanskje en del.

41:53 --> 42:47

Kanskje en devops-ressurs som har som mål å jobbe ut mot teamene og få dem enda bedre i stand til å gjøre devops. Altså få ting til å kunne jobbe mot plattformen på en effektiv måte. Ellers har vi andre spennende ting som vi driver med ... Vi var jo pilotbruker på Ansattporten, så nå ruller vi ut Ansattporten. Vi ser på ansatteplikasjoner for alle applikasjoner, altså fagapplikasjoner som brukes av kommunene. Vi sa jo ikke det, vi snakker om Husbanken, men vi har ca. 5000 kommunale saksbehandlere som også bruker applikasjoner vi lager. Så det å få på Ansattporten og få selvbetjening via alltid en autorisasjon for kommunene,

42:47 --> 43:33

er en viktig oppgave fremover. Backstage var jo Eirik innom. Hvordan vi kan ta i bruk advanse, cluster security på en bedre måte. Ja, vi har en ganske lang liste. Ellers er det jo ofte de små tingene, de små inkrementelle forbedringene, som skjer hele tiden. Og som ikke alltid er på backloggen som er planlagt. Som også gjør at plattformen hele tiden lever. Og tar store steg hvert år. Hva med deg, Eirik, noen siste ord før vi avslutter? Nei, jeg har jo vært gjennom ganske mye spennende.

43:33 --> 44:12

Men det er jo bare å fortsette å lese og bli smart, og prøve ut nye ting. Jeg tror det kan være lærdommer for oss alle. Tusen takk til Eirik Eidsaa og Kjetil Espedokken fra Husbanken for at dere har delt så mye kunnskap og innsikt om Husbanken til alle lytterne våre. Øydun, nå er jeg spent. Hva var ditt høydepunkt fra denne episoden? Det jeg syntes var gøy å høre, var at de hadde lagd en plattform som gikk ganske mye høyere opp i stakken enn mange andre plattformer. Det tenker jeg noen ganger kan være utfordrende. Men det at de har klart å få til så god deltakelse av de som lager applikasjonene,

44:12 --> 44:45

veier opp for mange av de potensielle ulempene. Da slipper du å få et plattformteam som bestemmer alt med limitten, men du klarer å løse problemer som utviklerne har, og som gjør at det blir nyttig for teamene. Og det ser man jo på hva de sier. Hva med deg, Hans Kristian? Jeg syns det var veldig gøy å få mer innsikt i hvordan Husbanken jobber, og hva som er deres oppdrag, og ikke minst hvordan de jobber for å løse det oppdraget. Det var et navn jeg har sett i noen forbindelser, men ikke egentlig visst om hva de jobber med. Det var egentlig mitt generelle høydepunkt her.

44:45 --> 45:15

Og med det så avslutter vi denne episoden av Plattformpodden. Mitt navn er Hans Kristian Flåtten. Med meg i studio har jeg som vanlig Audun Fauchald Strand. Teknisk produsent har vært Tore Gresdal. Nyeste episode finner du alltid på plattformpodden.no, eller i din lokale podkast. Følg oss gjerne på LinkedIn. Takk for følget, og ha det bra! Ha det bra!