Teksten er transkribert av kunstig intelligens.

00:00 --> 00:45

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 Audun Fauchald Strand. I denne sesongen utforsker vi plattformene i offentlig sektor. Audun, hva er ditt favorittprogrammeringsspråk? Det er et veldig godt spørsmål. Jeg programmerte både JA og BPA. Java, Go, Kotlin og Python, i hvert fall. Og jeg tror ... stort sett så er det Go som er favorittprimeringsspråket, for det er lettest å lese og enklest. Og noen ganger når jeg føler meg smart, så syns jeg det er Kotlin,

00:45 --> 01:40

men det går over veldig fort. Hva med deg, Hans Kristian? Nå stjal jo du Go. Jeg har begynt det med utypede språk, og syns jo at det var veldig kjekt. Du kom fort i gang, så kanskje være så freidig å si Ja. Det er såpass, ja. I dag er vi så utrolig heldige å ha med Espen Henriksen og Vegardrd Andersen fra Kartverket. Espen, vil du begynne å fortelle litt om hva du gjør i Kartverket? Ja, Espen heter jeg. Jeg er plattformutvikler og produkteier på Skipteamet i Kartverket. Så vi sitter og bygger plattform, koser oss, prøver å skape orden i kaos for utviklerne i Kartverket. Hva med deg, Vegard? Jeg jobber nå som sjefsarkitekt i Kartverket.

01:40 --> 02:19

Jeg er også teknisk områdeleder for plattform. Vi har både en abplikasjonsplattform og en dataplattform som vi etablerer. Hva var grunnen til at dere begynte å lage plattform? Det er det jo flere grunner til. Jeg har jobba i Kartverket en del år. Jeg har jobba der i litt over åtte år nå, og vi begynte for lenge siden å se at prosjektmodellen førte til at vi fikk veldig mange tekniske siloer. Vi fikk mange initiativer som etablerte sine egen stack, sine egne verktøy, sine egne måter å gjøre ting på. Og vi begynte å tenke på hvordan kan vi klare å få det her til å gå bedre, hvis vi samkjører teknisk plattform.

02:19 --> 03:07

I tillegg var vi veldig inspirert av Nav og Nice. Vi var ivrige deltakere på Javazone. Da så vi Nav sine prater med Audun og Truls, hvor de fortalte om Nice og alle initiative. Initiativene de hadde for å få bedre teknisk retning, for å få et bedre initiativ rundt det her med felles plattform. Og det var da kanskje litt av det som starta arbeidet vårt med skip, da. Vi hadde også i tillegg de offentlige problemene med at prosjektmodellen ofte fører til at vi får veldig silobasert verktøystack basert på prosjektene man jobber i, da. Og det er også noe vi hadde veldig lyst til å gjøre noe med. Kanskje sitter det noen og hører på denne podkasten her og tar inspirasjon fra det nettopp dere skal fortelle om i dag,

03:07 --> 03:52

og lager den neste plattformen. Men hvor mange er det som jobber med plattform? Det går litt opp og ned etter hvert som folk kommer inn og ut, og konsulenter kommer og går. Men i det siste har vi brukt å være rett i underkant av ti personer. Og det syns jeg egentlig er en ganske behagelig størrelse. For altså, det er jo noe med at det ... Det er jo noe med at du har lyst til å prøve å ha litt oversikt over hva folk jobber med. Og når du begynner å nærme deg ti personer, krysser over den magiske grensa der, så begynner det å bli vanskelig. Så vi syns egentlig den teamstørrelsen er veldig fin. Men det er egentlig ett team, da? Vi er ett team på Ship, som altså jobber med Statens kartverks infrastrukturplattform, applikasjonsplattform.

03:52 --> 04:32

Og så er vi et annet team som jobber med dataplattform, og datadeling var alltid der. Og det er DASK-teamet, da. Skip og DASK, så Ship er applikasjonsplattformen. Er det en historie bak det navnet? Det var vel en navnekonkurranse, Vegardrd? Det var litt av at vi var her og snakka med dere, faktisk, med NICE-teamet. Om hvordan vi skulle komme i gang med plattformen på en god måte. Og da kom det her med branding opp veldig fort. Viktig å brande og få et navn. Og viktig å ha en identitet som team. Så da var det Skip skap eller Scoop. For Statens kartverks applikasjonsplattform, infrastrukturplattform

04:32 --> 05:14

eller utviklingsplattform. Og av de så var det Skip som var definitivt lettest å lage logo for. Og det ser jo ikke dere som lytter på nå, men Vegardrd har da T-skjorte med Skip-logoen, som er litt sånn Kubernetes-tannhjuleinspirert. Og så er det et skip på toppen. Veldig kult. Jeg lurer på om du tenkte det da du valgte det nautiske temaet for Kubernetes, at det er et helt univers av navn for plattformer som bygger på Kubernetes. Det var heldig at dere valgte den containeren og containerskipet Hvalen. Det gjør ting enkelt når vi har skip som navnet vårt. Det er så mange ting vi kan bygge på toppen av det. Skipper og alle de nautiske tingene.

05:14 --> 06:03

Men da har vi avsluttet at dere bygger på Kubernets. Kan vi ikke si litt mer om hvordan teknisk ser plattformen ut? Ja, vi har jo Kubernetes som du sa, og så bygger vi på Google Cloud, da. Og det vi bygger nå, det er jo en form for hybrid skyplattform. Dvs. at vi har et bein i Google Cloud, hvor vi kjører på Google Kubernetes' engine. Og så har vi OnPrem på kartverket på VMWare, en sånn Antos-installasjon. Og da får du en variant av GKE som kjører på VMWare. Og det funker egentlig ganske greit, den installasjonen der. I denne Antos-pakken er det noen produkter som gjør at de kan prate sammen, for det er en fordel.

06:03 --> 06:53

Så da får du også en sånn service mesh-opplegg som er basert på Istio. Jeg veit jo dere elsker Istio. Det er bloggprogram det før. Men da får vi bundet disse clusterne sammen. Sånn at du kan kjøre noe i sky, du kan kjøre noe om Prem, og så kan de prate sammen, mer eller mindre sømløse. Antos er et kontrollplan som ligger hos Google, som styrer både OnPrem og sky-clusterne. Hvordan funker det? Antos er jo en sånn produktportefølje, på en måte. Og hovedbiten av det er jo GKE OnPrem. Men så er det disse andre tingene også, som er i den porteføljen. Service-mesh osv. Men en av hovedsalgspunktene ...

06:53 --> 07:41

Det er det at du kan administrere alt gjennom Google Cloud. Så du logger deg på Google Cloud, og i sidemenyen din har du et menypunkt som heter Antos, og da kan du gå inn og se alle clusterne dine. Og da kan du se clusterne uavhengig av om de kjører på kartverket i vår til kvelde, i GKE, eller faktisk på Asher eller AVS, og så administrerer du det gjennom et sånn single plane of class. Men hva er det som styrer, da? Hvilke apper som kan kjøre OnPrem og i Sky styrt av Google? Er det sikkerhetsmessige grunner? Det er et litt historisk perspektiv på det, at vi starta med å bygge hele plattformen vår OnPrem.

07:41 --> 08:27

Så Antos-beinet og det vi har etablert til nå, ligger jo OnPrem. Så langt har vi etablert hybridmerse, men vi har ikke begynt å migrere applikasjoner ut. Vi har applikasjoner som har åpne data som er uproblematiske å legge i sky. Og så har vi en del andre typer data som vi jobber aktivt med å vurdere. Som vi må se hvordan lander før vi kan avgjøre i hvilken del av plattformen vi kommer til å kjøre, eller hva slags hensyn vi må ta for å behandle de dataene. Jeg tror det er problemstillinger som de fleste organisasjoner sitter med akkurat de vurderingene der. Men denne plattformen, hvordan er grensen hit til opp mot utviklingstimen? Ja, så vi tilgjengeliggjør en del verktøy som produkttimene bruker.

08:27 --> 09:17

Så blant annet så har vi jo et verktøy som heter shipperator. Dere er jo sikkert kjent med Nicerator og bakgrunnshistorien der. Og den shipperatoren, den er en sånn form for abstraksjon som gjør Kubernetes enkelt å bruke for produkttimene. Så produkttimene setter en del felter, og så blir alltid bakgrunnen hans alt i bakgrunn av service mesh og zero trust networking-oppsett blir satt opp. Og av andre interfacer inn mot skip har vi jo Argo CD, det er måten man deployer. Så når du har dette shipperator application-manifestet, så legger du det inn i et gitter-epo, og så synker det ut på clusteret. Og det har jo vært en kjempesuksess. Folk trives veldig godt med det.

09:17 --> 10:16

Argo sier pull, ikke push. Argo er en pull-basert deployment-strategi. Hvis du sammenligner det med et bynkesteg på GitHub, hvor du kjører terraform for å dytte ting ut på Kubernetes, så er dette motsatt. Du sjekker koden inn i Gitube, og så sitter Argo og overvåker den koden. Og idet det er en endring, så putter den den inn på klosteret. Så puller den den endringen inn. Er det da ett gitter-epo for hele clusteret, eller er det sprudd utover flere? Det er litt interessant, for vi prøvde å finne den beste måten å gjøre dette på. Vi gikk mange runder. Hvordan skal man ha en løsning hvor et team har full tilgang til å opprette nye namespaces, til å spinne opp nye apper on demand for pull requests f.eks.? Hvordan kan man gjøre det på en måte hvor man ikke kan overskrive

10:16 --> 11:06

andre produktteams sine namespaces? Og da kommer vi til slutt fram til det som vi kaller for en sånn apps-repo-arkitektur. Hvor hvert produktteam får et repo, som de kaller for et apps-repo. Der putter de alle appene sine. Og inne i den til repo er det en mappestruktur som sier at hver mappe er et namespace. Som ligger i en mappe som er hvilke clustre det deployes til. Og så får produkteamene et sett med sånne de kaller det for prefikser. Så hvis du er et team som heter NRL, da, så kan du bruke NRL-prefikset. Du kan lage mapper som begynner med NRL. Så da kan du opprette så mange mapper du vil, så mange namespacer du vil, i dette repoet,

11:06 --> 11:45

som starter med NRL, men du får ikke lov til å lage en mappe som begynner med DSA. Da nekter Argo å synke. Så som en arkitektur så har det funka veldig bra. Produktteamene oppretter jo namespacer i hytt og byne. Så hvis du regner det som en suksessfaktor, så har det funka. Men hvordan gjør de så én ting er når du skal konfigurere opp applikasjonen og skal skrive hele manifestet, men hvis du bare har gjort en endring i koden og skal ut en ny tag, hvordan forholder de seg til app-repoet da? Så du har jo separert apps-repoet fra kildekoderepoet ditt. Så du pusher koden din til kildekode-repoet ditt,

11:45 --> 12:28

og så er det en form for github-action som kjører for å bygge en container-image ut av dette her. Og så lastes det opp på container registry. Og så har vi også samtidig en sånn påfølgende jobb som går inn og committer inn i apps-repoet at nå er det en ny tag som skal ligge på dette manifestet, og idet det blir committa inn der, så tar jo Argo og oppdaterer. Det clusteret, da, med den nye taggen. Hvordan vet utviklerne om det har gått bra med applikasjonen og den deployen? Når de bygger en ny og det committes, så vil jo kanskje den jobben bli grønn i github actions? Får de noen tilbakemelding om den kommer hele veien ut i miljøet?

12:28 --> 13:07

Ja, det er jo en av hovedgrunnene til at vi valgte Argo. For det vi ser, er jo at det brukergrensesnittet som produktteamene får gjennom Argo, det er utrolig nyttig for å kunne se om deployen gikk bra. Så produktteamene går jo inn og ser på applikasjonen sin, og der ser de Shipperator application-manifestet. Vi har lagt en litt sånn statusgreie på den, sånn at den blir markert som grønn. Men så ser de også alle de underliggende eide ressursene fra Shipperator application-en, og så ser de at deploymenten er oppe, den har to replicas, whatever. Så ved å kunne gå inn og se på Argo Gui, så får de en innsikt.

13:08 --> 13:56

De kan klikke seg inn og se logger på deploymenten, og hvis du vil, så kan du få en terminal rett inn i poden derfra. Så vi syns jo det er en stor oppgradering, fra å bare kjøre en eller annen jobb i Gitube, som plutselig kan feile med en eller annen weird, quirky feilmelding som man ikke skjønner noe av. Så de bruker rett og slett Argo og Guie til å debugge, og som er en oversikt over applikasjonen og hvilken tilstand den vil finne seg i. Ser de alle applikasjonene sine på tvers av alle miljøene, eller må de da inn i flere Argo-instanser? Så vi har jo gått noen runder på dette her, og vi er ikke helt sikker på at vi er i mål. Men vi har akkurat nå én Argo-instans per cluster.

13:56 --> 14:46

Sånn at du må gå inn og se på Argo for Dev eller Argo for Test eller Argo for Devy Cloud ... Men det blir jo veldig mange Argo-er til slutt. Så det vi har kikka litt på akkurat nå, er å se på den nye Cargo-greia til Acuity, for å se om den kan være en overbygg over alle disse Argo-installasjonene. Jeg har hørt navnet, men det er et overbygg? En super-Argo? Ja, det er en form for super-Argo. Så folka som lagde ... Folka som lagde Argo, gikk liksom ett hakk opp i abstraksjonsnivået. Og så sa de at ja, vi deployer applikasjoner, ikke lenger til en server, men vi deployer det til Kubernetes.

14:46 --> 15:27

Og det de har gjort nå med Cargo, er at de har beveget seg enda et hakk lenger opp. Og sagt at vi deployer ikke til Kubernetes, vi deployer til Argo. Så up and up or go. Turtles all the way down. Det holdt jeg på å si i gamle dager. Det som kanskje var foreløpig til Anto, som het Ubernetes. Som var den der "hvordan lage cluster med cluster" eller noe sånt. Men Cluster-API har jo noen skilpadder som står oppe og ... De slutta å kalle det Ubernetes. Men hvordan klarer dere å kommunisere med teamet for å finne ut hva de trenger? Vi jobber veldig aktivt ut mot teamene. Ved kartverket nå har vi en bestemmelse om at vi skal jobbe.

15:28 --> 16:20

En bestemmelse om at vi skal jobbe som produktorganisasjon. Det er at vi har etablert produktområder og produkteam. Og vi jobber aktivt på områdenivå og opp og nede i teamene. Så jeg deltar som produktområdeleder for plattform i kartverket Synne. Vi jobber veldig aktivt mot områdene. Og så jobber Skip og Espen mot teamene. Vi har jo teamene på Slack, og vi jobber veldig tett opp mot dem. Per nå har vi jo ... Sitte sammen, snakke arkitektur, fått opp appene deres mer eller mindre parprogrammert. Og det har jo produktteamene satt veldig pris på, at vi er så tett på dem. Men så må vi jo se nå, etter hvert som Skip blir en suksess, og etter hvert som vi får enda flere team på, hvordan vi skal løse dette i framtida.

16:20 --> 17:04

Du kommer til et punkt hvor det ikke eskalerer å være så tett på, men vi har fortsatt lyst til å jobbe. Men vi har jo fortsatt lyst til å være det. Det er jo en kjempebalansegang. En problemstilling som jeg tror de fleste plattformteam kan kjenne seg igjen i, er at man må ha et godt samarbeid, men samtidig skal du ikke gjøre jobben for teamene. Heller i hvert fall ikke på lang sikt. Å bli driftende og gående og bygge applikasjonene for dem. Jeg tror det handler om å bygge kompetanse i teamene, sørge for at de klarer å gjøre ting selv. Få dem opp, sånn at de kan gå på egen hånd. Og uansett hvilken vei vi går, så har vi fortsatt lyst til å være såpass tett på dem at det er bare å sende oss en melding på Slack.

17:04 --> 17:43

Hvis du lurer på noe, send oss en melding, og så kan hvem som helst svare. Vi har ikke lyst til å få opp noe sånn tikketing-system eller "eat-dill-work-flow" eller noe greier. Det blir bare kål. Det er jo litt av kjernen av det vi gjør, at vi prøver å legge til rette for fart og flyt. At de skal få levert mer forretningsverdi. Og det øyeblikket du begynner å implementere samme systemer, . Kommer du for langt unna igjen, da. Så det er noe vi jobber aktivt med. Når et nytt team oppstår, eller skal lage ny app, gjør det noe spesielt mot dem? Eller kommer det nye folk, eller? Når det kommer et nytt team på skip, så har vi først en liten prosess.

17:43 --> 18:42

Hvor vi prater med dem og prøver å få oversikt over hva de har lyst til å deploye. For det hender at det kommer et team som vil ta noe software fra 1970 for å putte det på spissen. Lyst til å bare putte det på skip og klappe i henda og si "ja, det er ferdig". Men det er jo ikke sånn Cloud funker. Så vi tar en liten gjennomgang av arkitekturen og ser: Har dere tenkt Cloud Native? Har dere vurdert om det er den beste løsningen for dere å gå på skip? Og så etter man har gjort det, så kan vi begynne å ta det praktiske. Så da er det jo å få på skipet, få de inn i de rette gruppene, så de får tilganger. Spinne opp litt Terraform-greier, så de blir satt opp i Google Cloud og alt det der. Så det er jo en bitte liten jobb, men det er jo stort sett automatisert, da. Men i framtida håper vi at mesteparten av det der blir self-service.

18:42 --> 19:33

For i dag så må noe av infrastrukturen fra teamenes side lages med Terraform, mens noe får det gjennom skip? Ja. Så vi har liksom en sånn sentral Terraform-workflow. Vi har registrert at det er andre plattformteam der ute som lager terraform-moduler og sånn. Og det er jo en veldig kul måte å gjøre det på. Men vi har ikke gått den veien, da. Jeg tror hvis vi skal gjøre noen tilpasninger på workflow-en vår i framtida, så blir det mer i form av det å tilby en self-service-portal, mer enn terraform. Og da kikker vi jo på litt forskjellige alternativer. Vi tenker jo på backstage, som er et fint alternativ. Skal vi skrive noe helt fra bunnen av? Dere i Nav har jo skrevet noe fra bunnen av.

19:33 --> 20:20

Ja, det er det fasitverktøyet. Da snakker du om bootstrapping av team. Da er det litt infrastruktur, konfigurasjon, få teamene opp, at de får sitt prosjekt i Google f.eks. Men mer sånn gjennom skip i det daglige, når de først er oppe og går. Hvilke andre tjenester får de gjennom skip? Vi har snakket om Argo og Deploy. Men det er andre tjenester de får gjennom skipet også. De får Grafana. Så vi har en ring for observability, hvor vi har satt opp hele LGTM-stacken. Pluss at vi bruker Grafana Agent for å hente inn med trikker og tracer og alt det der. Så det er jo ganske kult. Produktteamen er veldig fan av det. Grafana Agent er inn i dokkekonteineren som liksom skipper ting tilbake?

20:20 --> 21:04

Slipper ting tilbake, blir jeg overrasket. Grafana Agenten kjører jo da per node som en container, og den sitter og overvåker alle containerne og slurper opp logger og henter inn tracere og alt mulig sånt. Se for deg at den gjør jobben som Promtail gjør for logger, og Prometheus for med trikker, og Grafana Agent for tracer. Den samler alltid én boks. Er det Antos eller noe de har valgt selv? Dette er open source, det er Grafana. Men det er ikke Antos som har valgt det verktøyet? Så av observability-biten så gikk vi for LGTM-stacken fordi vi hadde lyst på litt mer kontroll.

21:04 --> 21:55

Men bruker dere da Open Telemetry Agenten for å instrumentere applikasjonene, eller er det noe applikasjonene gjør selv og drar inn i bibliotekene? Per akkurat nå, så er det noe de gjør selv. Vi har vurdert autoinstrumentering. Men akkurat nå så ser det ut som å være et litt komplekst setup, kan man si. Litt intrusive. Kanskje vi bare lar produkttimene gjøre det selv. For det er snakk om et par linjer med Konfig for å få det trikkensamlingsoppsettet. Hvilket språk er stort sett applikasjonene skrevet i? Vi har veldig mye Java-applikasjoner. Vi jobber også mye med Python. Det fins en god del andre språk også i kartverket, men det er nok hovedspråkene på den nye plattformen i hvert fall.

21:55 --> 22:36

Så vi prøver å fokusere mest der, men i utgangspunktet så er vi ganske språkagnostiske på det vi setter opp. Prøver å legge opp til å ha noen ting vi anbefaler. God teknisk retning, men samtidig la team få velge mye selv. Er Python mest brukt rundt data? Mye brukt rundt dataløyper. Vi har mange applikasjoner som forholder seg til geodata, og der er det mye Python. Både i land og sjø og sånne områder. Java har hovedsakelig vært i eiendomsregistrene og det miljøet rundt der, men så ser vi at de her begynner å flyte bra sammen

22:36 --> 23:21

og dra litt nytte av hverandre etter hvert. Hvor stopper ansvaret til plattformingen, og hvor begynner ansvaret til applikasjonstimene? Så per akkurat nå så har vi sagt det at vi på plattformteamet, vi styrer alt opp til og med namespace-grensa på Kubernetes. Og innenfor namespacene så kan jo produktteamene gjøre mer eller mindre enn hva de vil. Så det er jo en veldig fin sånn logisk grense for oss. Namespacet er managet av skip gjennom Argo. Men alt innenfor namespaces eier produktteamene, og så kan produktteamene spinne opp flere namespaces gjennom disse apps.

23:21 --> 24:18

Utanfor kubernetes databaser og sånn, hvordan funker det? Så vi har fortsatt en liten vei igjen å gå, tror jeg, på databaser og lagring og sånn. Men du toucher på et litt sånn interessant punkt, og det er det her med lagring i kubernetes og ellers. Jeg skal svare på spørsmålet om databaser, men du bare pirra meg et øyeblikk der. En liten digresjon, og det er det at vi har tatt et litt sånn interessant standpunkt på skip. Og det standpunktet er det at alle clusterne våre, de skal være stateless. Så hvis noen kommer og sier det at vi ønsker å kjøre en database på skip, eller vi ønsker å sette opp en PWC som lagrer data til disk på skip, så kommer vi til å si nei. Og det er mange gode grunner til det.

24:18 --> 25:03

Bare for å ta et eksempel: Så hadde vi en katastrofeøvelse for noen dager siden. Og da var scenarioet at nå har det landa en meteoritt i clusteret. Vi må få opp et nytt cluster. Infrastrukturgjengen har jobba dag og natt med å få opp ny hardware. Så nå er vi i et helt plain cluster. Få opp hele verktøystacken, få opp alle. Appene, så fort som mulig. Og da satte vi i gang og begynte å jobbe med dette her. Vi gikk inn på et møterom og låste døra. Og da var jo egentlig bare jobben å få opp Argo så fort som mulig. Og så få Argo til å synke alle manifestene inn i clusteret.

25:03 --> 25:52

Og så er du ferdig. Det er ikke verre enn det. Du trenger ikke backup restore i det hele tatt. Vi har ikke backup restore. Fryktelig uflaks om du møter litt akkurat rett i clusteret. Det skulle vi tenkt på. Men det betyr altså at i den katastrofeøvelsen så brukte vi en halvtime fra et helt plain cluster til alle appene og alle verktøykjedene, alt mulig, var oppe å kjøre. Det syns jeg er ganske bra. Men hvor ligger persistent data der? Hvor ligger kartdataen lagret der? Vi har jo mye intern infrastruktur i Kartverket, vi har jo flere datasenter. Så mye lagring foregår på intern infrastruktur. Og så kobles det til skip.

25:52 --> 26:48

Så både databaser og lagring i stor grad provisjoneres der nå. Og så jobber vi med å etablere nye evner og kunne bruke skyen bedre. Men i en del tilfeller er det snakk om så store datamengder at det ikke har vært hensiktsmessig. Og så må vi se hvordan den nye infrastrukturen blir når vi begynner å få applikasjoner som kjører inne og ute med Egress og alt det her. Hvor er det ting kommer til å ligge etter hvert. Men sånn som det er nå, så er det oppsettet vi har. Kartverket har fly som flyr over Norge og tar bilde av hele landet flere ganger hvert år. Og de flyene har også sensorer som måler høydedata over hele landet. Og det blir nye data. Så resultatet av dette her er at vi har databaser som er på petabyte-scale, som håndterer alle disse detaljene.

26:48 --> 27:35

Og det koster noen kroner å flytte ut i Sju. Så de kjører på kartverket, da. Riktig. For det jeg også skulle spørre om, var jo da hvilke typer applikasjoner er det som kjører på skip, og hvilke er fortsatt på litt mer tradisjonell infrastruktur? Vi har egentlig sagt at alle nye applikasjoner i kartverket skal etableres på skip. Og så skal skip serve de behovene vi har der. Og så har vi en god del applikasjoner som har levd i mange år, som ikke nødvendigvis egner seg til å kjøre på sky, eller som kanskje har utfordringer i forhold til datamengde eller sikkerhetsproblematikk som vi må ta litt over tid. Og det er en modningsreise på mange områder. Espen, du nevnte litt at dere kjører....

27:35 --> 28:29

Som en del av annet har dere Istio som service-mesh. Bruker dere en del av den funksjonaliteten som dere får i service-mesh, eller er det først og fremst for kryptert MTLS-kommunikasjon? Det er jo kryptert også, selvfølgelig. Det er jo en av hovedfeaturene her. Men vi bruker også Istio som en del av den derre broa mellom sky og omtrem. Så hver applikasjon som er på skip, blir jo lagt inn i service discovery-algoritmen til Istio. Og på den måten så veit Istio at en applikasjon ligger enten onprem eller i sky. Så si da du spinner opp frontenden din i sky, for du ønsker å skalere den masse. Men av en eller annen grunn så trenger du en back-end som lever på kartverket.

28:29 --> 29:15

Kanskje du skal snakke med noen omprem-databaser, så må den leve på kartverket. Vel, da får du en request inn på frontenden din i skyen, og så skal den requesten videre til back-enden. Da veit Istio at den lever på back-end, og så rutes den inn der automatisk, uten at frontenden trenger å gjøre noe spesielt med tanke på å åpne firewalls eller hva det skal være. Det bare skjer automatisk i service-merchet. Kan du utvide også til leggesystemer? At du kan kalle applikasjoner utenfor Kubernetes som om de var på innsiden? Jeg tror det. Men det er ikke noe de gjør i dag, kanskje? Nei, altså det er noe funksjonalitet i Istio, noen service entries og greier,

29:15 --> 30:01

hvor du kan spesifisere ting som er utenfor Kubernetes. Men det vi bruker det mest til, stort sett, det er dette her med zero trust networking. Fordi en applikasjon på skip kan ikke i utgangspunktet prate med noen andre applikasjoner. Alt er deny first, default deny. Og hvis du skal snakke med en annen applikasjon, så må du skrive i skipperator-manifestet ditt at de skal kunne prate sammen. Dette er kjennstoff for dere. Men det som skjer i bakgrunnen, er at det settes opp network policies for trafikk innenfor Kubernetes. Men trafikk som går ut fra Kubernetes, der er det litt spesielt.

30:01 --> 30:43

Fordi trafikk ut fra Kubernetes er jo layer 7. Og network policies funker ikke på layer 7, dessverre. Det hadde vært veldig kult om det gjorde det, men det gjør det ikke. Så der så har vi et triks, og det er det at vi tømmer routingtabellen til Istio for alle URL-er. Så vi sier at ingen URL-er på internett kan routes. Og så legger vi inn service entries for hver ting som applikasjonen sier at den skal kunne prate med. Sånn at de kan routes. Og da har du zero trust. Så i utgangspunktet så kan ikke den finne de eksterne hostene,

30:43 --> 31:27

men så legger dere dem inn som service entries? Kult. Det høres ut som dere er ganske gode koll på pingen mellom Helsinki og Hønefoss. Dere har liksom sidestilt "omprøm og sky", og at dere deployer begge steder, ytelsesmessig og sånn. Vi har ikke merka så store ytelsesproblemer der, egentlig. Helsinki er jo relativt nære Norge, så det har jo gått greit. Vi tenker mest på databasene, egentlig. Hvis du har noe loops med noen som spør om databasene, så blir 12-15 ms fort mye. Nei, vi prøver jo å kjøre backen der hvor databasen ligger, da. Det er i hvert fall det som har vært kutymen så langt.

31:27 --> 32:10

Og det er jo litt av det hensynet som du sier der, at hvis du skal gjøre masse spørringer over internett til databasene, så kan det fort ta litt tid. Jeg tror vi begynner å gå inn for landing. Vi pleier å spørre om en gang ting ikke gikk helt etter planen. Det er jo veldig mye vi lærer når ting går feil. Har dere en historie å dele med oss? Vi har jo den gangen, før vi etablerte Antos, da ... Så kjørte vi på en bever-teknologi som het Tansu. Da hadde vi en rekke uheldige ting som fikk en konvergens av tekniske problemer

32:10 --> 33:04

som gjorde at vi droppa det som plattformteknologi i sin helhet. Det var på en måte utløsende faktor i at vi gikk over til Antos og en annen. Det var ganske heftig. Det var en kombinasjon av det at ... Vi kunne ikke spinne opp nye noder pga. en bug i systemet. Og det var en fiks som var lansert på en nyere versjon, som vi ikke kunne oppgradere til fordi vi ikke kunne spinne opp nye noder. I tillegg til det så hadde poddene utfordringer med at de var tomme for ressurser, så de begynte å evikte podder pga. memory pressure og sånn. Og så kunne vi ikke spinne opp nye noder for å få mer ressurser.

33:04 --> 33:58

Vi måtte rett og slett bare sette opp hele miljøet på nytt. Og det var ganske omfattende, da. Å migrere alle appene over. Men helt til slutt, da. Hva er det neste? Jeg personlig har jo veldig lyst til å fremhende ting. Det er jo det at vi i offentlig sektor, og generelt sett i privat næringsliv, alle vi som driver med data, vi må begynne å tenke litt mer som på miljø. Prøve å få oversikt over det utslippet vi faktisk står for. Og da handler det jo om å samle inn disse metrikkene om hva koster det egentlig å kjøre ting i omprem og sky? Jeg syns det var en interessant ting som kom opp for en stund tilbake.

33:58 --> 34:44

Og det er det at når du kjører ting i sky, så kjører du på et hyperscale datasenter. Du kjører på datamaskiner som er kjøla med vannkjøling og ... Det er masse ting som gjør at det datasenteret er ... Er mye bedre for miljøet enn å kjøre ting omprem. Og det er en ting som jeg syns ikke kommer fram så veldig mye i diskusjonen av sky og omprem. Miljøaspektet av å kjøre ... Altså ting overalt, distribuert rundt om i ganske land. Så jeg har lyst til at en eller annen gang i framtida, at vi får opp med trikker på skip over hva det koster. Ikke bare i kroner og øre, det også, men i CO2.

34:44 --> 35:27

Og så prøve å bygge løsninger som optimaliserer for det. Har ikke Google det i konsoll? Google har det i konsoll, ja. Ikke VM-greiene. Nei, ikke omprem. Men å begynne å bruke det mer aktivt. I tillegg så har vi jo veldig fokus for plattformen og på internal developer portals, eller IDP-er. Altså backstage eller sånne typer produkter. Vi har jo veldig fokus på det å gjøre ... Gjøre plattformen enda mer gøyal å bruke for teamene våre. Og sørge for at de enklere kan følge en teknisk retning. At vi får litt mer fokus på det her med golden pass i en mer konkret form enn det vi har til nå.

35:27 --> 36:15

Det er også sånne ting som vi kommer til å jobbe mye med nå framover, da. Og så lanserte dere en tack-blogg i dag. Espen, hvor finner de som har lyttet på i dag, den? Så hvis dere har lyst til å høre mer om skip og alle de spennende tingene vi driver med, så kan dere gå til skip.kartverket.no. Der finner dere en link til tech-bloggen vår. Klikk innom. Vi setter veldig pris på at dere leser. Lenke til den finner dere også i beskrivelsen for episoden. Tusen takk til Vegardr Andersen og Espen Henriksen fra Kartverket for at dere tok turen fra Hønefoss for å snakke med oss i dag. Audun, hva har vi lært i dag? I dag, jeg husker ... I Finn, for åtte år ... For et år siden hadde jeg min første diskusjon med de andre

36:15 --> 36:56

som skulle lage Plattformfind, om det var å lures med pull eller push. Og da valgte vi push, og så har jeg stort sett lagd ting som er push siden. Så det er veldig gøy å høre om noen som faktisk har gjort det andre, og fått mer innsikt i de åpenbare fordelene med en pull-basert rapport. Hva med det, Sisan? Helt siden jeg jobbet med ut.no, så har jeg digget de tingene som kartverket har gjort, og utrolig gøy å få høre mer om hva dere gjør. Og ikke minst å ha fått lov til å følge dere fra sidelinjen på denne reisen. Kjempegøy at dere deler her hos oss i dag. Med det runder vi av denne episoden av Plattformpodden med Hans Kristian Flåtten og Audun Fauchald Strand,

36:56 --> 37:13

teknisk produsent er vår eminente Tore Gresdal. Takk for oss. Ha det bra!