Episoden er transkribert av kunstig intelligens, feil vil forekomme.

00:00 --> 01:07

Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er som vanlig Hans Kristian Flåtten, og med meg i studio har jeg Audun Faukal Strand, og i sesong to av Plattformpodden løfter vi blikket og ser på ulike plattformer i bank og forsikring og handel, og kanskje litt ... nettverk òg. Men før vi introduserer dagens gjester, Hva har vært din favoritt-telefon opp gjennom årene? Det syns jeg er et veldig godt spørsmål. Jeg har jo vært tro mot Google og Pixel-brandet lenge. Den første telefonen jeg virkelig likte, det var en Sony Eriksson T68. Kanskje til og med en I, om jeg ikke husker feil. Jeg tror jeg brukte flere timer om dagen på å synke den og pallen på helheten min. For det funka aldri, men det var så gøy å få det til å funke. Favoritt-telefonen min er Pixel Fan. Den var en liten nett og ganske solid. Nå har jeg klart å migrere bort, men sønnen min bruker den gamle fortsatt.

01:07 --> 02:14

Hva med deg, Jan Kristian? Jeg er jo Apple-fan, men jeg tror nok at ... Aldri hatt Apple-telefon. Favoritt-telefonen må nok ha vært Nokia 3210. Det er en sånn indestructable-telefon som bare tålte alt. Det er jo mye ute på tur. De mista bakken og hele pakken. Det var jo noe med at det var en av de første telefonene. Det er nostalgisk på mange måter. Men dette er jo litt lead-up til dagens tema. For i dag er vi så heldige å ha med oss Viberf, Banzal og William Aas Dalen fra plattformteamet i Telenor Norge. Telenor er en organisasjon som de fleste kjenner til, og som har en lang historie helt tilbake til 1800-tallet med Norges første telegraf. I dag har Telenor nesten tre millioner kunder i Norge, og i første kvartal i 2024 blokkerer Telenor 500 millioner forsøk på digitale angrep. Så det er helt klart at Telenor har en kjempeviktig rolle for samfunnet vårt. Viberf, kan ikke du begynne å fortelle litt om hvorfor du begynte i Telenor,

02:14 --> 03:29

og hva du jobber med? Det kan jeg. Jeg har jo stort sett jobba som konsulent, back-end-utvikler og developer-utvikler før jeg begynte i Telenor, for tolv år. Og en dag på jobb fikk jeg en call fra en rekrutter fra Telenor. Telenor har jo alltid vært gjennom transformasjon i sin historie, men det som var litt utmerket de siste fem år, var at YT har vært gjennom enorm transformasjon. Og da jeg fikk en oppringt fra rekrutter, var planen at Telenor skulle begynne å sette opp Cloud-plattformer. Og jeg hadde jo jobba med AVS og Cloud for fem år fordi jeg begynte i Telenor, og dette var jo en ting som jeg hadde skikkelig gleda meg på, et store selskap som Telenor, hvor jeg kan bli med fra startfasen til å etablere en Cloud-plattform. Så da var jeg veldig motivert til å ta den diskusjonen videre, og Telenor var jo veldig godt kjent i markedet for å være en av de største aktørene i Norge. Så var det naturlig for meg å ta opp det valget for å gå og vurdere med, og jeg har godt valg. Jeg har ikke angrepet det i siste seks år, eller fem og et halvt år,

03:29 --> 04:38

nå siden jeg har vært i Telenor. Så kult, Varbav. William, hvorfor begynte du i Telenor, og hva er din rolle? Hei, jeg jobber som en plastmakingeniør på teamet til Varbav. Jeg begynte i Telenor fordi jeg er som deg en Asher-fanboy. Ikke en Asher-fanboy! Og jeg kom over en stillingsannonse de hadde. Jeg kom over en stillingsannonse de hadde som snakka om Asher Governance og Enterprise Scale, som er de store heavy-hitterne i vår bransje. Hvor en link var broken. Så jeg sendte mail og sa: "Linken deres er ødelagt." Så balla det på seg derfra, og så ble jeg i prat med plattformteamet og skjønte at "ok, her gjør de noe kult. Dette har jeg lyst til å være med på". Så jeg starta der i oktober i fjor, og nå jobber jeg med infradelen av spesielt. Det var nesten sånn at du kunne vært med på NRK-episoden? I praksis, ja. Det stemmer. Jeg har også vært innom Telenor som konsulent, og det var jo tilbake da det var open shift on premise.

04:38 --> 05:37

Kjører de fortsatt? Når var det? Jeg var i 2009-2012. Å ja, det er vel mye senere enn det. Så jeg har vært og var der først, på en måte. Årets første open shift-klasse var satt opp i 2016. Så var det andre cluster som var satt opp i 2018. Det var da jeg begynte i Telenor, så jeg var egentlig ansatt for å sette opp den middleware som i den tida kalte vi den avdeling, for å sette opp den open shift-cluster. Heldigvis, den kjører ikke lenger nå. Vi gikk vekk fra den siste open shift-applikasjonen i fjor sommer. Da migrerte vi alt vekk til Ashore, men det har vært en enormt lang reise til å komme vekk fra disse open shift-klastrene våre. Så vi har jo lært massevis, både med å gå over på open shift, og gå vekk fra open shift og over til Ashore.

05:37 --> 06:48

Var det til AKS, da, eller? Ja, nå kjører vi alt på AKS. Hva var det som var mest jobb? Å gå fra open shift til AKS? Det var mange ting som var krevende. Det første var å få prioritært hus alle timene, for de timene har altfor mye å levere på business-worthy. Når vi fra et plattformteam går til dem og setter opp et krav om at dere må komme ut av den plattformen, og så gå over til ny plattform, det er ikke bare bare å migrere i en container fra et sted til et annet sted. For det innebærer masse brannmyrer. Vi har en spagati av applikasjoner og systemer. Vi har ikke applikasjoner som kan leve isolært sett, så de integrerer med mange andre applikasjoner. Brannmur var et av helvetene som vi måtte gjennom. Vi var i en peak-periode på migrasjonsfasen, så vi hadde en fast innleide som jobba bare, bare med brannmur. Bestillingshåndtering både med Ashore og med våre onprem-datasentra. Det høres ut som en drømmejobb, vi jobber bare med brannmur-bestillinger!

06:48 --> 08:05

Det var jo ikke så lett, for å si det sånn. Og så var det sikkerhet som var en veldig stor ... Jeg skal ikke si problemet, men poenget var jo at den måten vi satte opp applikasjonene på on prem. open shift clusters, vi kunne rett og slett ikke ha det akkurat likt på Ashore. Kybernetes forventning var jo at vi skal tilpasse oss litt bedre på secret management. Litt bedre på encryption, som vi ikke hadde så mye på onprem. Så disse tingene balla på seg og gjorde det litt ekstra vanskelig. Så det var det at dere dytta mer kvalitet inn i plattformen samtidig som dere migrerte, det var ikke bare en sånn ren ... Det var ikke litt frind shift. Vi må sikre på at det er ikke bare bare containers som skulle migrere vekk, vi må samtidig se på hvilken database, f.eks. Hvis de kan flytte samtidig ut på Ashore, Slik at vi har mindre latensive mellom Ashore-pods og database på onprem. Så alt var håndtert med en moderniseringstankegang. Da jeg var der inne, var det ikke noe team som het Utvikleropplevelse. Og jeg tror ikke vi snakket veldig mye med utviklerne. Hvordan er det i dag?

08:05 --> 09:07

I dag har vi etablert en ganske god rutine for samarbeid. Vi har en slagkanal. Vi har en Slack-kanal vi kaller for DX Support, som er hjertet til vår avdeling. Hvor det har utvikla seg en kultur hvor man stiller et spørsmål, og så er det ofte utviklerne som hjelper andre utviklere, istedenfor at vi bruker av vår tid på å drive support. Men samtidig så får vi anledning til å bruke den kanalen til å se på hvilke behov som oppstår, og hvilke forbedringer i dokumentasjonen vi trenger å gjøre. For en Community Day, som skjer ganske ofte med en viss regelmessighet, jeg tror det er hver andre uke, hvor vi møtes, legger ut temaer på forhånd som de kan stemme på, hva har lyst til å snakke om, er det Secret Management, er det ny deploy-løp, er det whatever ... Utviklerne stemmer, og så tar vi det opp som temaer. Og det er en veldig interaktiv sak. Det er noen som har ansvaret for å fortelle, og så, når presentasjonen er ferdig, så er det åpent for spørsmål. Det tar ofte en god drøy time.

09:08 --> 10:30

Ja, det er et veldig bra engasjement. Men en annen ting som er litt annerledes enn den tida da du har vært gjennom Telenor ... Tidligere var vi ikke sånn ... Vi i Plattformteam var veldig opptatt av å lage worktrip på egen hånd mellom 2016 fram til 2021. Det vi gjorde, var at første gang i IT-avdeling fikk vi i sommerprosjektet fantastiske tre studenter fra NTN. Hele poenget med sommeroppdraget var at de skulle komme inn og teste ut noen open source worktrip, f.eks. ArgoCD, Helmcharge, Customize, Flux, som vi var langt unna fra. Vi hadde egenutvikla et oppkam-worktrip, som vi pleide å kalle det på den tida. Dette var et stort lykkemoment for oss, når de testa ArgoCD og Helmcharge, og så testa vi pilot med et par timer for å se på om om de vil foretrekke oppkam eller de nye worktripene. Naturlig valg var å gå for den. Så hadde vi kjørt gjennom migresjonsfasen fra OpenShift til Archer Kybernetes. Det var jo også hele tooling, migresjon, som vi håndterte samtidig. Så alle teamene gikk vekk fra egne utviklings worktriper til mer og mer open source worktriper.

10:30 --> 11:35

Så veldig mange ting har forandra seg i siste tre-fire år, Hans Kristian. Det er gøy. Det er gøy å høre. Hvordan er utvikleropplevelsen i dag? Hvordan er det utviklerne går fra å ha kode som de har kjørende på sin maskin, til noe som kjører i produksjon? Veien ut er ganske straightforward. Vi har en veldig god dokumentasjonsside som alle utviklerne har tilgang på. Og der inne står det beskrevet hvordan du kommer deg ut. Og første steg er å etablere et rep å ha kode i, og det er issue up som styrer i Geetub. Og du trenger også et operations repost. Et operations repost story, som vi kaller det, hvor infrastrukturkoden, manifestene dine og alt det ligger. Derfra skjer det en del automatikk: Du lager en puller quest på et repost story hvor du identifiserer systemet ditt, og så er det ArgoCD som plukker opp: Hei, her er det en applikasjon som skal ut. Så skjer resten selv: Du blir dytta ut på det clusteret som passer til din applikasjon, eller som du har spesifisert den type tjeneste du ligger inne hos om.

11:35 --> 12:40

Og så er du ute på et av kubernetsklusterne våre. Derfra ut finnes det guider som forteller deg om hvordan du legger til tilleggstjenester, tracing og observability og MTLS. Da skjønner jeg at dere i det religiøse bildet av ett element i kubernetsclusteret, så sa du clustere, så dere går for mange, ikke sant? Vi går for mange. Vi har et veldig tydelig skille på miljø og sone. Soneklasser. De tradisjonelle soneklassene. Men det har gitt oss en stor fordel, og vi har gruppert litt videre utover inn i det. Vi har noen web-facing clustere og noen API-facing clustere, og vi har noen som er kun for statiske workloads med stateful sets, og vi har prøvd å segregere inn i de logiske, eller for oss logiske, inndelingene som fins. I tillegg til en del sandbox og dev. Hvordan håndterer dere da oppsettet av clustere og oppgradering og migrering i den type butikk? Vi har et eget utvikla verktøy som genererer terraform, basert på en input som er standardisert for oss.

12:40 --> 13:56

Og så blir det automatisk generert pipelines også, som står og kjører Terraform Apply når det trigges, rett og slett. Da sprer det litt ut? Hvis du ikke oppgraderer kubernetsksempler, gjør du ikke det akkurat samtidig i alle clustere? Men sånn helt rent konkret, for at ting snurrer og går i Kubernetes, disse manifestene, er det noe som utviklerne skriver selv, eller er det noe verktøy ... De bruker handcharts, så de har anledning til å putte på de variablene som vi har gjort tilgjengelig for dem, og derfra så kommer applikasjonen ut og spinner. Vi kan egentlig støtte både Helm-charts, og så kan utviklerne bruke rent Kubernetes-manifest også. Men det er jo nesten ingen som gjør det, for å si det sånn. Så alle bruker et Helm-chart, Value-state-amoult, som de pleier å override. Det er ganske enkelt for dem å bruke. Vi i Plattformteam har utvikla noe parent Helm-charts. Vi har stort sett tre Helm-charts, én for batch-applikasjon

13:56 --> 15:13

og én for only-applikasjon, som alle utviklerne og teamene bruker. I tillegg til standardiserte gitter-batches for bygging av dokkekonteinere og det som ellers må til. Hva slags tjenester er det dere ... Har dere også ansvar for basedelen, eller er det andre? Og eventuelt hvilke andre ting er det man spesifiserer Helm-chart til, hva tilbyr det? I Helm-chart i seg selv har jeg ikke alle detaljene. Der er det app-team hos oss som vedlikeholder og utvikler det. Men sånn jeg har forstått det, så får du en del gratis. Vi prøver å ikke eksponere altfor mange variabler. Vi får se inn Defaults inni clusteret, og så kan man heller velge å opp-the-out på en del av de. Men hvis de skal ha databaser, så er det teamene som selv provisjonerer det i sin subscription? Det gjør vi som et plattformteam. Så i dag, på en måte, vi har jo disse kybernetis-klustere og application-gateway, som vi bruker stort sett for å eksponere våre UPI på internett. Det har de som har plattformtjenester som vi eier på våre egne landingssoner. Men alle andre ting, f.eks. databaser, har de satt opp på hvert teams landingssone.

15:13 --> 16:21

Men greia er jo at de teamene har ikke nok kompetanse. Vi har jo en fase hvor de moderniserer seg med kompetansemessig på ski òg. Men slik de er i dag, så er det et plattformteam som lager landingsone for dem. Og så provisjonerer de en database eller reddisk eller hva det er behov for. Så vi har jo noe standard dessert-tjenestekatalog på Ashore. Litt sånn vanlig MongoDB-databasen, AshurSequel, Reddis og Postgres. Så hvis behovene er nok for disse tjenestene, så kan de bare levere et hjemmel manifest til oss, og så provisjonerer vi databasen for dem. Men på slutten av dagen, forventning har vi fortsatt, selv om vi provisjonerer ressurser for teamene ... Er det de som må stå opp om natta? Ja, så de skal forholde seg til dette, vi har provisjonært. De må jo logge inn på Ashore portal, eller gå litt inn på Grofana for å se hvordan de kan monitorere SQL-monstre og forbruk på databaser.

16:21 --> 17:30

Så vi prøver å kjøre hele "you build it, you run it"-mekanisme. Det er en modningsreise, for å gå fra at vi setter opp databasen og utstyret, og det er deres ansvar, til at de står opp om natta. Det er jo en reise som tar litt tid. En fin del av reisen. Litt sånn nattog. Men har dere i planene deres at dere skal gjøre self-service på den type profesjonering òg? Vårt mantra er jo "vi skal lage den beste utvikleropplevelsen". I det inngår det self-service av de standardiserte tjenestene. I dag er det en del som blir automatisk provisjonert, Kafka-ting blir automatisk provisjonert. Basert på manifester. Og så er det noe som vi gjør manuelt, men som for brukeren oppleves som ganske sømløst. Det er et steg for å trigge en self-service-reise og en identitet hos brukeren som kan gjenoppleve det. Men akkurat i disse dager er vi i ferd med å modernisere selvbetjeningsløsningen,

17:30 --> 18:41

så vi skriver litt kode selv for å gjøre automatisk provisjonering basert på de samme, eller litt enklere, jammel manifester. Gjennom migrasjonsfasen fra open shift til Ashore, vi satte opp rundt 50 Postgres-databaser på Ashore. I den tida hadde vi en person som satt fast og bare profesjonelt hadde disse Postgres-databasene hele tiden. Fordi vi hadde ikke det automatiserte self-service-framworket på plass. Men deretter har vi fått mye bra, vi jobber aktivt med ... Dette var et tema vi hadde dekka på den KCD-dagen i Oslo. Hvordan hele selvbetjening har vært gjennom Italynor. Det er en veldig bra ... Vi lærer masse fra disse selvbetjeningsreisene våre. Og så bruker vi Terraform Controller. Tofo-kontroller som man nå heter. Viktig å påpeke. Det greia med det var at for to år siden selvbetjening har Selvomboen vært på agendaen, men det har gått litt tregt. Vi begynte først med cross-plane, vi kjørte noe POC-er med cross-plane,

18:41 --> 20:00

men cross-plane var jo litt ... ikke der hvor vi hadde ønsket oss å ta den videre i produksjon. Så da oppdaga vi Tofo-kontroller, som heter det nå. Vi hadde jo allerede Terraform-moduler på plass. Med Torro-Tofo-kontroller kunne vi ha gjenbrukt disse modulene for å sette opp samme ressurser fra et annet kybernettperspektiv. Det er naturlig for oss å ta den valgen vi gjør. Det var noen databaseressurser dere snakket om i KCD talken. Vi snakket i all hovedsak om Kafka. Men ambisjonen nå er alle de Golden Path-ressursene som vi har i dag, men som skal bli en del av Self-Service, skal gjennom en slik automatisk pipeline. Gjerne basert på Terraform med Tofo-kontroller og AOCD til å plukke opp sånne fester. Utviklerne får et Helm-chart-utgangspunkt. I tillegg til Kafka kan de ha Postkas og gi noe input til det, så blir det profesjonelt. Det blir egne manifester for det. Vi har laget egne oppgir, litt fordi vi da kan lage front-ender og gjøre det vi har lyst til på utsiden.

20:00 --> 21:02

Men i essens blir det det. Det er jo en workflow som har fungert veldig bra for ganske mange, inkludert Nav. Så det blir veldig spennende å høre videre om. Jeg fikk lyst på å ta en ting til, for jeg tror første gangen jeg hadde en diskusjon om man skulle bruke Helm eller Jammel Operators, var i 2015, kanskje, da vi satt og lagde fjas, altså Finn sin applikasjonsplattform. Og da, samme som vi gjorde i Nav, så gikk vi bort fra Helm, da brukte vi Helm bare til støttetjenester. Så hvis jeg en god del bruker Helm også til applikasjonene, så lurte jeg på: Har dere gjort den vurdering undergang, og hva tenker dere om det? Jeg kan si litt om det, for jeg tror før vi gikk til Helm, så hadde vi en ikke-Jammel-operator, vi hadde den gamle worktopen, hvor vi lagde Jason-feel istedenfor Jammel-feel, så vi hadde ikke støtte for Jammel-feel fram til 2019. Så vi vurderte Helm gjennom to år, 2019-2021.

21:02 --> 22:08

Det som var litt grunnen til at vi gikk for Helm, var jo Helm3. Med en gang vi gikk vekk, eller Open Source, gikk vekk fra Helm2 til Helm3, og så, hva heter den, til Helm2 av det eller annet. Chiller. Det var noe vi ikke hadde lyst til å vurdere, men med en gang Helm3 var borte, så begynte vi å bruke Helm. Argo hadde veldig god støtte for HelmCharts i tillegg, så tilpassa begge to walkta veldig godt sammen for oss. Det var en grunn til at vi gikk for Helm. En annen ting, med en annen fordel, det vi tenkte på, var jo ... Vi er kanskje ikke de beste for å lage dokumentasjon for alle utviklere, selv om vi jobber i Plattformdien. Vår ambisjon har alltid vært at om vi kan finne et worktøy hvor det finnes masse god dokumentasjon allerede fra før, det er en fordel for utviklerne. Da slipper de å være et mellom.

22:08 --> 23:27

Lag mellom utviklerklærne og disse valgtøyene. Så det var også en ting som påvirka oss. Helm var veldig godt kjent, masse god dokumentasjon, Argo side i tillegg, så de bare ... var et naturlig svar. Det er en ekstrem gevinst spesielt med AI, som har kommet med alle disse chattjenestene, hvor du i praksis kan spørre om hva som helst, og så får du et svar som ansakeligvis vil fungere på vår plattform også, fordi det bruker open sores-verktøy. Dokumentasjonen er allerede absorbert. Det er et godt poeng. For pro-open source òg, som jeg ikke har brukt så mye, dette med at ChatGPT kjenner til enormt mye av de verktøyene ... Jeg hadde anledning til å snakke med en av hermentinnene på Oddkubkan. De snakket om at Helm 4 er under oppseiling, og dette med mer templating i values ​​filer gjør det enda enklere å ha predefinerte helm charts, men å kunne gi litt mer custom input. Jeg tror ikke det er en dårlig måte å strukturere. Og har jo selv laget plattformer basert på herm fra applikasjonenes side tidligere. Men applikasjonene i Telenors plattform, hva er de skrevet i?

23:27 --> 24:52

Java er vel en stor del hos oss? Ja, java.net. Vi har det på Dotnet også. Og DODS. Og så har vi ViewDS. Det er det mest brukte språket. Litt Python, våre data scientists som har begynt å komme på disse plattformene nå. Men ellers har vi på plattformteam stort sett ... GoLang. Vi har kanskje litt Kotlin her og der, gammelt moro, som vi kommer nok til å gå vekk fra. Det er bra å kalle Kotlin gammel moro, da plasserer du det rett i tidslinja! Det er liksom båd som begynner å være litt mer jubby, kuttes i plattformteamet, da. Men ellers utviklerne bruker de stort sett i andre språk. Når jeg jobba i Telenor, i sen steinalder, så jobba jeg i KOS. Før det jobba jeg i Origo. Svære monolitter. Jeg husker i Kos ... Nei, I Origo! Ordredelen, den ble kalt Mordor. Det var helt umulig å komme inn dit og komme ut igjen levende. Og det var millioner av kodelinjer ... Lever det fortsatt, eller er det skrevet om mer tilpassa ...? KOS lever fortsatt, så vidt jeg husker. Solardelen av KOS også? Den som håndterer tilgangskontroll og sånn?

24:52 --> 26:03

Ja, i det tilgangskontrollet. Solard kjenner jeg ikke til, men KOS lever fortsatt. Da jeg begynte i Telenor for fem år siden, så var det ... KOS var et av de systemene som hadde fire årlige releases. Og så var det jo alltid under diskusjon, for dette var jo hjertet av mobil hvor de kjenner til Telenor. Hvis KOS går ned, så vil i praksis hele Telenor-mobil hvor de kjenner, gå ned. Men KOS har også vært gjennom masse modernisering. Hvordan det skjer, er at enkelte komponenter fra KOS har begynt å bli splitta opp, og så migrert over til Kybernetes eller gamle dager med åpen skift. Men i helheten, KOS lever fortsatt, da. Men ikke som fire årlige releases. I 2019 kicket vi allerede over til ukentlige releases. Ukentlig release på KOS, så hadde vi masse CICD som var implementert på KOS, selv om det ikke var på en containerplattform. Det kjører jeg fortsatt på ved Blogic.

26:03 --> 27:09

I hvert fall dere gjør det da, det husker jeg. Du er allerede innpå, Telenor mobil, og så har man sikkert Telenor nett eller fiber. Hvilke domener er det som kjører på plattformen hos dere? Hvilke typer produkter? Det er vel i all hovedsak nettdelen av det, altså mye nettdel. Bestillingssystemene og alt det som er ansvarlig for at når du skal ha et SIM-kort og du skal ha en telefon, så kikker den opp. Telenor.no og mine sider og den slags ting. Ja, Telenoride og alle de tingene der er essensielle på vår plattform. Men vi er jo en stor organisasjon, og vi har jo fortsatt en del kritiske systemer som står på bakkenivå, for det er vi jo strengt tatt nødt til. Men vi har jo en slags up to in-plattform, så vi ønsker å lage den beste utvikleropplevelsen, og det håper vi jo tiltrekker andre deler av organisasjonen til vår plattform. Så vi er liksom i en evig ekspansjonsreise, hvor vi rigger en plattform som er klar for ett sett med applikasjoner i dag,

27:09 --> 28:15

og så må den utvikles for å kunne støtte andre former for applikasjoner i fremtiden. For jeg tror jeg leste en årsrapport fra Telenor Group, og da har det jo gått litt i vei... Det var research. Går inn i alle selskaper i Norge, årsrapport, sinkende ... Jeg gikk gjennom alle årsrapporter til offentlig sek... nesten alle! Det forventer intet mindre. Da har man gått litt vekk til Norge, og nå har man til Nordic, til Asia ... Kan ikke dere fortelle litt om ekspansjonen, eller hva er veien videre her for plattformen? Det kan vi jo godt, som Sakte er en Optin-plattform, og Nordic-samarbeidet er i all hovedsak en mulighet for oss å kunne lage en plattform som også appellerer til de andre nordiske delene av Telenor. Hvis vi klarer å gjøre den såpass attraktiv, så får vi jo muligheten til å kanskje ta vekk overhead som fins andre steder, minimere ompremise-infrastruktur.

28:15 --> 29:36

Kanskje konsoliere både kunnskap og ressursbruk, som kan være en veldig stor gevinst for oss. I tillegg til at vi blir eksperter i enda større grad enn det vi er. Både på open source, public cloud, whatever, men også på våre egne systemer og tjenester. Her er det en trend, for vi snakket med Vipps, eller Vipps Mobile Pace som de heter nå. Når de skulle fusjonere der, så var det den norske plattformen som skulle brukes videre. Norge er trendy, er det det? I hvert fall i Norden, så er det Norge, altså. Foregangsaktør som de ga opp. På plattformingeniering er Norge uten tvil en av de veldig fremme med alle ender. Det kommer med både fordeler og ulemper, for greia er jo at vi må samarbeide med våre ... Kollegaer? Kolleger i Sverige og Danmark, og vi kan ikke tvinge dem til å bruke vår plattform, så vi må samarbeide og ekstende den plattformen på slik måte at de kan ta eierskap. Så vi er i dialog med Cloud Engineers både i Danmark og Sverige, hvordan skal vi samarbeide best,

29:36 --> 31:00

for å anse denne plattformen som et Telenor nordisk plattform, og ikke som et Telenor Norge. Med Telenor Nordics strategi er det jo at vi må "build once", deploy four times. Det gjelder ikke bare plattform, men alle produktene som vi leverer i markedet. Det er strategi der vi skal bygge et bredbåndprodukt eller et TV-produkt, og så selge den til alle fire landene. For plattformen var det et naturlig valg, det hjelper ikke med å sette opp 80 plattformer i fire land, enn å bare sette opp 18-20 på ett sted og ekstende den på Nordics. For oss som plattform ingeniør, tror jeg det som passer best for oss, er det fra 400 utviklere i Nord-Norge som bruker denne plattformen i dag. Vi kommer til å ha 1000 utviklere som skal bruke den plattformen i framtida. Cloud kommer i ambisjon her, fordi alle landene er ikke på Ashore. Det er naturlig for Sverige å være litt på AWS, for AWS har en region i Sverige. Vi må støtte både Ashore, Google Cloud og AWS en gang i framtida,

31:00 --> 32:04

for disse 1000 utviklerne til å ha en seamless experience på torsdag. Og dette i seg selv er jo en veldig ... Kompleks oppgave. Kompleks oppgave som vi har veldig lyst til å ... Så blir det litt spennende mennesket kulturmessig òg, både andre kulturer, selv om Norden har mye lik kultur, for så vidt. Men nå er jo dere kun på Fornebu, stort sett alle sammen, nå blir det flere geografiske regioner. Har du noen tanker rundt den biten òg, eller? Norden er ganske gode på kryssregionalt samarbeid, siden det er så mange bedriftsenheter rundt i verden. Så vi har en del frihet i dag. Jeg jobber f.eks. fire dager i uka utenfor Fornebu, og andre team har andre løsninger for det. Så jeg tror det skal gå greit. Det er jo veldig mye engelskspråklig også hos oss, så kommunikasjonen foregår på et sånt nivå som de aller fleste forstår.

32:04 --> 33:20

Men det blir spennende å se spesielt på kompetansedeling, og det å ikke måtte nødvendigvis ansette for kompetanse, men heller å få opp en delingskultur som gjør at vi kan bygge det sammen, og bli bedre på hverandres områder. Du jobber fire dager remote. Hvordan er arbeidsformen innad i teamet deres i dag? Du får ansvar for å bygge din egen måte å jobbe på. Mitt team, som er in-fra, vi bruker GitHub Cambans projects for oppgavedeling, og vi har timeføring i et eget system. Vi har funnet en løsning som fungerer for oss. I andre team kan de velge å gjøre det på en annen måte, men det er ganske likt hos oss. Vi har stort fokus på par-programmering, selv om vi ikke sitter i et zoom-call fra klokka ni til fem. Men vi prøver fortsatt å unngå veldig mange pull-requester. Det tar tid, og ofte markerer vi ... Hvis du ikke gjør par-programmering, og så leverer et PR, så du får tilbakemelding som "looks good to me". Stort sett 90 % av ganger. Vi prøver å gjøre masse par-programmering.

33:20 --> 34:35

Så begynte vi litt med mob-programmering for en periode. Men det både fungerte og ikke fungerte. Vi kan ikke la utvikling i klærne vente for små ting her og der. Så innimellom, vi jobber litt med mob-programmering, med tre-fire personer som jobber på ett oppgave. Litt med par-programmering, og enkelte ting vi bare låser selv også. Hva slags team er det egentlig, hvordan er dere delt, og hvordan er dere organisert? Da vi begynte med Developer experience-avdeling, hadde vi fem team på Developer experience. To team jobbet på plattform, ett app-team og ett datetegnet fra teamet. Da jobbet vi sammen. Så var det ni stykker på hvert av disse teamene. De 300 teamene var penetration testing team og API integration team, som var ikke direkte med ski-plattform, men mer med utvikling. Men i det siste korte året har vi eksperimentert det litt. Ni og ni personer er kanskje ikke det beste.

34:35 --> 35:39

Får ikke metta med to pizzaer da. Det vi har testa i siste korte år, er at et app-team lever fortsatt. Men data- og infrateam har splittet opp i tre team. Ett har infrateam, hvor William jobber nå, med tre stykker. Jeg tar data-delen av teamet, hvor jeg jobber med to andre plattformer. Og så har vi satt opp et eget GCP-team. Nå går vi også litt over på GCP fra ... vi ikke går vekk fra sure, men en del data-plattformer som vi begynner å sette opp nå i Telenor Norge, de går over på GCP også, da. Så da har vi også satt opp et GCP-infrateam med tre stykker. Dette teamet med ni stykker er splitta opp i tre team, med tre personer. Om disse oppsettene funker ikke, så må vi finne en annen måte å sette dem opp på. Det er ikke veldig tette skodd heller. Det er åpne slack-kanaler. Dere vil snakke om en annenhver tirsdag fra 11 til 12, da er det bare Night Sandal.

35:39 --> 36:54

Booka! På Fornum! Conway's Law kommer litt i "top of my mind" her. At du har tre team som lager en compiler, så får du en trefase-compiler. Hvordan jobber dere da aktivt for å unngå at "nå skal jeg løse en oppgave"? Da må jeg selvfølgelig løse det innenfor mitt domene her, og ikke nødvendigvis på naboen. Vi har fortsatt felles Slack-kanalen, hvor vi diskuterer. Men bortsett fra det, så har vi et felles arkitekturmøte. To ganger i uka, eller én gang i uka, hvert uke. Hvor vi diskuterer hvilke styreendringer hvert team har tenkt å jobbe med i nærmeste tid. Hvis dette påvirker de andre teamene, så for å sikre at vi har et helhetlig perspektiv på store endringer, i hvert fall da. Det har ikke vært så lenge nå at vi har splitta opp disse timene til tre-fire timer. Vi fortsatt lærer, og vi må bare finne en måte å unngå silo. Arkitekturmøte hver uke har vi bare ett av tiltakene vi har på plass. Men hvis vi trenger flere tiltak, så må vi bare få dem på plass.

36:54 --> 38:16

Så vi har det jo veldig agilt. Vi har ikke noen fasit, at dette må vi jobbe sånn, dette må vi jobbe sånn. Vi må bare unngå å være veldig tradisjonelt silo-basert time. Oppgaver og product roadmap, hvordan styrer dere hva dere skal jobbe med fremover? Vi har to øvrevisjonærer, med Thorbjørn og Mats, som setter kursen og staker ut de store linjene. Og så har man et veldig ålreit lederkore-team, som Varberg er en del av, som staker ut hvilke kvartalsvise områder vi skal satse på. Og så er det all about. Designe en last som funker for teamet, at vi har nok burn på de ulike områdene. Det skjer siden vi er såpass få, så skjer det ganske naturlig. Det er jo en fordel, for oss i hvert fall. Utviklerne våre har veldig stor maks til å påvirke våre råd med prioritering hele tiden. Mange ganger må vi også balansere utviklernes behov mye, et eller annet. F.eks. vi ofte jobber med noe det har masse liggesid. Vi er et 160-80 år gammelt telegoselskap, så det er uten tvil masse leggesid.

38:16 --> 39:34

Så f.eks. vi må kvitte oss med noe av systemet, som har begynt med et lisensiert worktar. Så må vi utvikle nye kapabiliteter på Ski plattform, som kan erstatte disse leggesy-komponentene med 10-20-tall, millioner kroner. Så vi må hele tiden balansere hva et team ønsker seg, ut fra. Hvordan skal vi utvikle Ski plattformvidere for å håndtere disse leggesid-moderniseringene? Her er det masse kods-applikasjoner som vi også bruker i Telenor. Så vi må balansere hvordan disse kods-applikasjonene, som kanskje ikke alltid tilpasser seg et kybernettets rammevalg, som vi har satt opp for disse 400 utviklerne, hvordan skal de jobbe på våre ski-plattformer? Så disse tingene prøver vi å balansere hele tiden. Men som William sa, vi har et korp-møte hvor alle i Lead Platform Genius med Mats sitter sammen og tegner hva som er viktigste prioritering i framtida. Sikkerhet er jo veldig stort fokus for Telenor hele tida, på en måte. Telenor er jo en av de mest ... Utsatte plattformene?

39:34 --> 40:35

Og leverer jo sikkerhetstjenester til mange andre organisasjoner, inkludert Nav? Ja, inkludert Nav. Jeg syntes det var gøy å starte i Telenor og jobbe med den plattformen, da jeg så hvor seriøst sikkerhetsdelen av det er. Det er typisk med cloud-løsninger, at man kan klikke seg fram til en løsning som fungerer, og så sier man litt sånn: "Ok, det var gøy." Nå er det lav leadtime, så da gjør vi bare det samme på nytt. Mens i Telenor har man faktisk fått mandat og tid, og tid til å danne et grunnlag som er veldig representativt for den sikkerheten vi skal imøtekomme. Og den blir opprettholdt hver eneste dag, det er ekstremt bra fokus på det. Selvsagt kan jo det ha en bekostning på hvor raskt man kan vitrere over noe, men med vårt eget bentestingteam, og med de menneskene som har sikkerhet hos oss, så føler jeg ikke at det er til hinder i det hele tatt. Det er veldig deilig. For jeg husker jo gjerne fra min tid i Telenor, så skulle ting innom Telenor sikkerhet for godkjenning.

40:35 --> 41:44

Hvordan er den prosessen, hvordan jobber dere med de ... Du nevner jo William at dere har egne pensester. Det må jo fortsatt innom ulike sikkerhetsinstanser, men jeg har ikke inntrykk av at det nødvendigvis går sakte. Ting har jo forandra seg litt. Sikkerhetsavdelingen i Telenor Norge har jo mer som rådgiver, og ikke en godkjenningstampel. Vi får ofte råd fra dem. Men til slutt, siden vi jobber mer og mer autonomt, så er det jo greit at teamene må selv ta ansvar for hva de putter ut i produksjonen, om det er på skiplattform eller på håndbrem. Så timene står ansvarlig. Forventningene i Telenor Norge nå er jo at timene må følge på prosessene, men timene seg selv godkjenner hva de skal legge ut. Og hva de skal ikke legge ut. De tar den risikoen seg selv, så de må gjøre risikovurdering. For å putte ting ut i produksjonen. Når vi lager nye plattformkapabiliteter, vi tar råd fra både Penetration Testing Team og Sikkerhetsavdelingen i Telenor,

41:44 --> 42:51

men i begynnelsen er det vi som tar risikoen for å ... F.eks. med den GCP-plattformen vi bygger opp, så vi tar den risikoen i seg selv. Det er en veldig sunn og god tilnærming til nettopp det med risikoansvar og sånn. Ja, her er det kommet langt stygt på vei. Dette med sikkerhet kan vi ikke dekke nok, og det er jo så viktig. Enda viktigere i den tiden vi lever i akkurat nå. Hva slags kapabiliteter har dere i plattformene rundt sikkerhet? Hva leverer dere til utviklerne som særbetjenter tjenester osv.? Skiplattformen i seg selv, siden det er Asher, har jo en del innebygd funksjonalitet. Det har vi lagt oss veldig tungt på. Alle logger og activity-deler blir shippa inn sentralt, og vi har analyser der som varsler oss på de kanalene som vi er tilgjengelige på. Det samme gjelder vel for utviklerne. Deres applikasjonslogger blir jo shippa inn et sentralt sted, og så kan man behandle det der.

42:51 --> 43:59

Og så er jeg helt sikker på at det fins andre sikkerhetsprodukter i Telenor som sikkert ikke jeg veit om engang. Har dere verktøy rundt det? Vi har jo Sneak som vi har brukt ganske mye i det siste, for å sikre en skanning på dependencies. Men nå skal vi egentlig ut fra Sneak også, vi går over til Github. Fullstendig Github, så bruker vi Github 1s security capabilitator i tillegg. Og så bruker vi Sentinel veldig mye. Blant annet vi har NoeEilers. Vi har egentlig ikke noen container image-skanning. Vi bruker Asher Defender for cloud. Der er det vel aktiveringer som også går på det. Men vi har jo også en sentral brannmur gjennom alt, som tar seg av IDS-en og all den flyten der. Men sånn type network policies, er det i bruk fra teamene og appene sin side?

43:59 --> 45:10

I Kubernetes-kløssen, ja. Nei, det veit jeg ikke om er i bruk hos oss. Vi bruker sentral brannmur akkurat nå, i tillegg til At Service Mesh, ISTO, som gir oss grei dekning, egentlig. Men det er jo alltid en diskusjon oppe om hva som er lettest og lurest for vår del. Hva som er mest brukervennlig, om det er en sentral brannmur, eller om man skal gjøre filtreringen ved origin og gi casterne selv. Så en kontinuerlig analyse av det. Istio har jo også en del sikkerhetsmessige funksjoner, så jeg antar det er noen sikkerhetshensyn som har gjort at man har valgt det oppsettet der. Er det appteamet som har mer med Istio å gjøre? Det stemmer. Gå inn for landing. Det er det hemmelige kodeordet her. Ja. Nei, men vi begynner å gå inn for landing. Før vi avslutter, har vi et spørsmål som vi stiller alle gjestene våre. Det er om dere kan fortelle om en gang ting ikke gikk helt etter planen.

45:10 --> 46:34

Og hva dere lærte av det. Du kan vel ta det som har gjort at vi har brukt såpass lang tid på å anvende kontrollere, kybernetiskontrollere for self-service, og fortelle litt om den reisen dit. Du mente lært av podkast eller plattform? Av deres egne erfaringer, hva du har lært i Telenor med at ting har gått litt galt. Ja, jeg har jo egentlig lært masse, for dette er min første jobb som ikke-konsulent. Så jeg har jo på en måte holdt dette cap ex og opp ex, det var jo veldig nytt for meg. Det fikk jeg et veldig godt forhold til, men ut fra det tekniske, jeg har lært masse om marsher. Self-service har vært en enorm reise for oss. Det var en erfaring vi delte på KCD i dag. Vi har vært gjennom mange kriser. En av krisene jeg husker veldig godt, var da hele OpenShift-klusterne var vekke fredag kveld. Vi brukte seks timer på å få alle systemene oppå og kjørende på den cluster. Årsaken var en Namespace operator? Årsaken var jo den controller som vi egenutviklet.

46:34 --> 47:59

Å ha den continuous feedback fra klærne våre, det er også en veldig viktig ting. Det er lett å bygge plattform og produkt, men hvis du har ikke kunder på disse plattformene, så gir det lite av verdi. Å lage produktet med kundefast, fokus, er ikke så lett. Det er min læring. Men når ting går galt, har dere en prosess for å ta tak i det på en god måte? Det har vi nok, men jeg kan med glede si at av den perioden jeg har vært der, så har det ikke vært en reell hendelse. Og nå er det da 18. april. Det stemmer. Men det har vi jo. Vi har prosesser som tar tak i det. Men jeg har ikke vært igjennom den ennå, for vi har ikke hatt en reell hendelse. Som er veldig deilig. At vi kan stole på den skyplattformen som vi har bygd. Får håpe det blir noe snart, da. 17. mai er jo dagen. En gang det var Melodi Grand Prix i Telenor allerede. Og da hadde vi Grand Prix-frys. Man var redd det skulle komme endringer som skapte blest akkurat da det var Grand Prix.

47:59 --> 49:22

Så vi hadde kodefrys en helg eller noe sånt. Det har jeg aldri hatt, verken før eller siden. Det tror jeg ikke vi har i dag heller. Jeg håper ikke det, når ikke NRK har det. Vi har den på papir, men ikke på den plattformen som vi jobber med. Her er det teamene selv som tar risiko, om de skal ta en release rett før jul eller 17. mai. Ellers har vi en krisestab i Telenor som vi alene møter. Det er en standard praksis i Telenor. Og vi har et oncall-team som vi har i Developer Experience i tillegg. Første kontaktpunkt hvis det skjer noe galt med plattformen. Så oncall-team aktiverer seg i vårrom-typen hvis det er en eller annen krise. Men heldigvis har vi ikke hatt noen store kriser. Vi har alltid vært litt små problemer her og der, men vi har ikke hatt noen krise i det siste. Den siste krisen jeg husker var i det åpne skiftet, som var en event. Hvor hele klassen var borte. Heldigvis hadde ikke Namespace Operator tilgang til disse plattform-namespaces.

49:22 --> 50:36

Så din Red Hats sine namespaces hadde den ikke tilgang til. Så plattform var oppe og kjører, men det var bare applikasjonene som var borte. Men hadde Namespace Operator også vært brukt for plattform-namespaces, så hadde vi det. Et kubesystem er hellig. Det røres ikke. Det er en god ting, og det syns jeg kan være et godt ord å ta med seg videre. Tusen takk til Veiber F. Bansal og William Aasdalen fra Telenor for at dere har delt så mye kunnskap, og at vi kunne mimre oss tilbake igjen i tiden i Telenor. Audun, hva har vært ditt høydepunkt i den episoden? For det første må jeg få hilse to stykker i Telenor som jeg har lyst til å si hei til, som sikkert hører med. Som tok meg imot i KOS i 2009 og brukte seks måneder på å lære meg og noen andre opp i verdens største applikasjon, tror jeg. Og som fortsatt jobber der, og sikkert kommer til å jobbe i Telenor til evig tid. Og Torbjørn, som er den mest visjonære personen jeg noen gang jobba med, og som jeg fortsatt er evig takknemlig for at han kom til Nav og satte i gang det han gjorde der. Men høydepunktet, det var en liten ting, men det er noe som mange ikke får til.

50:36 --> 51:48

Det var at dere så at ni mennesker i team er litt mye, og delte opp. Å prøve det tror jeg veldig mange kan lære, for jeg ser mange team som stopper opp og beklager at vi er så mange, og som ikke helt skjønner det. Det er egentlig enkle grepet, men fortsatt vanskelig å finne ut hvordan vi skal dele opp, og hvordan vi kan bli mer smidige. Det tenker jeg mange kan bli inspirert av. Jeg vil også ha en shoutout til Martin Tverråen. Han er ikke i Telenor, men han jobbet med det oppsettet, og lurer på om håret forsvant etterpå. Høydepunktet har vært å se den autonomiteten som har kommet, og dette med at teamene også i større grad kan eie risiko. For det er jo en del av det å ta ansvar. Så det her syns jeg Telenor er virkelig på god reise. Og at det blir spennende å høre mer. Oppfordring til lytterne våre: Hvis dere har spørsmål, så send det gjerne inn, og så kan vi ta det ved neste korsvei vi skal invitere til i studio. Med det avslutter vi denne episoden av Plattformpodden med Hans Christian Flåtten og Audun Faukal Strand.

51:48 --> 52:08

Teknisk produsent har som alltid vært Tore Græsdal. Nyeste episode finner du alltid på plattformpodden.no, eller i din lokale podkastapp. Følg oss gjerne på LinkedIn. Ha det!