Subscribe
Share
Share
Embed
Audun og Hans Kristian har hatt entur på besøk for å snakke om dataplattform.
Creators & Guests
What is Plattformpodden?
En podcast om applikasjonsplattformer og teamene som bygger de. Dette er podcasten for deg som bygger plattformer eller som er interessert i lære med om hvordan noen av Norges største om mest fremoverlente organisasjoner legger til rette for sine utviklere.
Episoden er transkribert av kunstig intelligens
Hei, 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 Audun Fauchald Strand. I sesong tre av Plattformpodden ser vi på andre typer plattformer enn de tradisjonelle applikasjonsplattformene vi har sett på så langt. Men før vi introduserer dagens gjester, har du en favorittdatamaskin? Ja, det vil jeg si jeg har. En gang for ... nå var det dette. I 2016 eller noe sånt, 17 var det kanskje, så kjøpte jeg en pixelbook. En selvmotsigelse i seg selv, som jeg syns var veldig fin. Veldig god byggkvalitet og veldig enkel å bruke.
Etter hvert har du til og med godt an å kjøre Linux på den. Det kom noen år etter. Hadde det ikke vært for at den begynte å bli gammel og dårlig, kunne jeg faktisk gjort noe på den Linux-en også, men som en browser-maskin og leketing, så var det veldig bra. Hva med det, Hans Kristian, hva er din favorittdatamaskin? Hjemme har jeg en Apple Macintosh fra 1983. Jeg har ikke så veldig mange minner fra den, for det er lenge, lenge siden. Så jeg må vel egentlig si at Raspberry Pi er min favorittdatamaskin. Den kan brukes til alt.
Du har GPI-pinner hvor du kan styre ledd og motorer og diverse, eller du kan sette den oppe på et teamområde og ha en stor Grafana-skjerm. Veldig fleksibel. Jeg husker jeg sto opp kjempetidlig for å bestille Raspberry Pi da den kom, brukte den aldri til den. Jeg har noen i kjelleren som kjører Kubanesque-laser, det kjører ikke noe oppå det, men det er veldig gøy å ha. Men i dag skal vi kanskje snakke om noe litt større enn Raspberry Pis. Vi er heldige å ha med oss Rejeb Setin og Anders Dalen fra Entur. De fleste har kanskje sett logoen til Entur på en billett eller to,
men uten å helt vite hvem eller hva de gjør. Entur er et statlig selskap som skal gjøre det enklere å velge kollektivt. Entur utvikler og drifter en offentlig nasjonal reiseplanlegger og billettløsninger for kollektivsektoren. Og i 2023 solgte Entur i underkant av 30 millioner billetter til kollektivreiser. Rejep, kan du begynne å fortelle litt om din bakgrunn og hva du jobber med i Entur? Ja, jeg heter Rejep Stein. Jeg jobber som ledende plattformarkitekt for interne plattformer i Entur. Det betyr at jeg har det overordnede ansvaret for den strategiske retningen og teknologivalget for de interne plattformene vi har, som er primært utviklingsplattformen og dataplattformene i Entur. Anders, hva med deg, hva er din rolle i Entur?
Ja, hei. Jeg jobber som tech-lead i data- og innsiktsområdet. Og jobber med videreutvikling av dataplattformen og streamingplattformen vår, som i dag stort sett består av Kafka. Jeg har lyst til å begynne med, siden han er inne i sesong tre, å se på de andre plattformene. Vi kommer sikkert til å snakke litt om applikasjonsplattform også, men vi kan begynne med dataplattform. Og kanskje du, Anders, hva er det? Hva er en dataplattform? Det er et veldig godt spørsmål, egentlig. Det kan være veldig mye, egentlig. Hos oss er det i dag stort sett et big query-datavarehus. Og veldig mange ... Vi skal være litt ærlige med oss selv,
så liker vi vel å kalle oss en dataplattform, men vi er vel egentlig kanskje mer et datavarehus med mange custom pipelines inn. Vi har et ganske standard pattern og en standard filosofi, om at hvis dataen finnes på Kafka, så skal den være lett tilgjengelig i datavarehuset. En konsekvens av den filosofien er jo at man får veldig mye rådata, og skriver mange transformer for å bygge såkalte dataprodukter, som gjør at man kanskje dupliserer en del domenelogikk, og kan få litt vedlikeholdsfriksjon over tid. Men det har fungert veldig bra. Det er en veldig fin måte å komme i gang på, men nå ser vi
at vi kanskje må lage noen litt lurere løsninger. Som lar oss skalere litt bedre, uten å måtte ansette mye mer mennesker. Du sa dataprodukt. Hva mener dere et dataprodukt er? Det er et ... Det er et vanskelig spørsmål. To på rad fra min side! Det kan være et datast... Et datasett som kan bestå av ett eller flere tabeller. Det har et skjema. Og det må være forståelig for en uten inngående domenekunnskap. Noe domenekunnskap vil i mange tilfeller være nødvendig, men at du kan bruke det som et annet team i en tur, f.eks.
Du må ikke være det eiende teamet for å kunne ta i bruk et dataprodukt. Har du noen eksempler på noen som alle kan? Som alle kan skjønne, liksom. Så det er helt tydelig. Ja, jeg kan ta et som ligger åpent tilgjengelig for alle i hele Norge, og det er plandata. Eller altså timetable, som det heter på nettsiden. Det er da rutedatasettene som kommer fra operatørene. Og det er et relativt komplekst datasett, for det kommer på en standard som ikke er bygget for Historisk nøyaktighet er kun bygget for å fortelle om hva den gjeldende ruteplanen er nå. Men dette kan endre seg flere ganger om dagen og har mange komplekse detaljer, som gjør at et historisk datasett er vanskelig å forstå.
Selv om hver rutetabell i isolasjon er veldig lett å forstå, men å se den historiske sammenhengen og utviklingen er ganske kompleks. Da har vi laget et dataprodukt som er ... Som reduserer denne kompleksiteten, sånn at du kan se de grove trekkene på hvordan rutedataen utvikler seg over tid. Som har veldig mye verdi for f.eks. Transportøkonomisk institutt eller SSB, eller operatørene selv. Og så finnes det en del tognerder som også syns dette her er gøy. Nå var jeg inne og klikket her på datainturen. Nå er jo flere fire ... Fire fire. Fire datasett som ligger her umiddelbart. Det ene er nasjonal oversikt over stoppesteder.
Det er veldig greit for de som lager kart, og at det er oppdatert at her er det et stopp, og hva slags kollektivtransport det er som går her. Bruker jo veldig mye hvor er nærmeste T-bane, hvor nærmeste busstopp? Inn i kartappen på telefonen, f.eks. Men dere har jo både dataplattform og applikasjonsplattformer. Hvordan henger de sammen, hvis de henger sammen? Det er et godt spørsmål. De henger vel egentlig godt sammen, i form av at begge kjører i samme skileverandør. Begge er basert på manage-tjenester, og det er egentlig det.
Så har vi Kafka som bindeledd, egentlig. Men fortell litt om teamene, for da er det vel to team som lager dette. Én for dataplattform, én for applikasjonsplattform. Hvordan er de organisert? Vi er organisert etter områder i en tur. Vi representerer da områdene fellestjenester, som leverer den interne utviklerplattformen, og så har vi Datainnsikt, som leverer da ... Som både eier Kafka og dataplattform, så vi eier vel på mange måter to plattformer, egentlig. Rent historisk så var vel utviklingsplattformen EnTour ... Entour er jo et relativt ungt selskap, startet i 2016, født i skyen på mange måter, og arvet litt gammel teknologi fra NSB til Rui, men alt det der er borte nå. Så man bygget jo plattformen på et par prinsipper, som at vi skulle ikke hatt
et operations team, vi skulle hatt et plattformteam, som skal hjelpe til. Utviklingsteamene har ansvaret fra ende til ende på applikasjonen sin. Så skulle vi gå for Managed, som han valgte for GCP. Og Kubernetes, så starta derfra. Etter hvert så kom streamingplattformen også inn i miljøet etter behov. I starten i Kubernetes, men etter hvert så har vi som alle andre funnet ut at det å ha stateful applikasjoner i Kubernetes ikke var ... Det viste seg å være veldig komplisert, spesielt for et domeneteam å vedlikeholde. Det ble jo satt i gang en satsing på data i slutten av 2019, og da fordi man startet allerede fra dag én om at er dataen tilgjengelig på Kafka,
så skal den være tilgjengelig i datavarehuset, så ble de to satt under eierskap av samme team, så fikk man endelig skilt det ut fra domeneteamet, som lagde det fordi de trengte noe streamingtjeneste, og landet litt tilfeldig, tror jeg, på Kafka. Eventuelt så var det kun de som hadde muligheten, støtte for loggstrukturer, på det tidspunktet. Og så er jo det veldig enkelt å få data derfra inn i datavarehuset. Fra jeg kom tilbake til spørsmålet, så består fellestjenester av fire team. Så du har plattformteamet, som har ansvaret for en kompleks, og applikasjonsplattformen, så alle støttetjenester rundt med CICD, logging av observabilitet osv., så har vi et sikkerhetsteam som jobber med
sikkerhetskultur, sikkerhetsstandarder, sikkerhetsinnsikt, og som leverer noen interne og eksterne identitets- og autentisering- og autorisasjonsløsninger, som støtter under vår salgsplattform. Vi har flere plattformer i en tur. Så har vi et kvalitetsteam som er på mange måter et enabling-team, et relativt nytt team som skal jobbe med standard rundt kvalitet og innsikt. Og så har vi et partnerteam som leverer partnerportalen, som egentlig består av et mikrofrontender-rammeverk, pluss noen andre kjernetjenester som støtter under salgsplattformen. Men når dataplattformteamet er dere bruker jo GSP og skal ha Big Query,
går du til Regiops applikasjonsplattformteam og får infrastruktur der, eller håndterer dere det selv? Vi håndterer det i stor grad selv. Noen ting får vi hjelp til. De har laget masse flotte terraform-moduler som lar oss gjøre mye av dette selvbetjent. Så trenger vi en vanlig postgressbase eller slike ting, så bruker vi bare de modulene. Hvis ikke så er vi selvbetjente på å bruke, sette opp f.eks. KafkaConnect og en del sånne støttesystemer som er viktige puslespillbrikker for oss. Det gjør vi i dag selv via Terraform, og ser på et fremtidsbilde hvor vi automatiserer en del av disse prosessene gjennom f.eks. et Kafka Admin-grensesnitt. Vi har et Kafka Admin-grensesnitt i dag
hvor domeneteamene kan opprette og gjøre noen enkle operasjoner på Kafka selv. Så de ikke trenger å gå til oss på Slack eller prate med oss ved kaffemaskinen for å få et Kafka topic, for det skalerer jo ikke. Så vi har lagd et grensesnitt hvor du kan gjøre dette selv. Og der ser vi for oss å bygge inn en del automatiseringer, sånn at du kan tilgjengeliggjøre dataene dine med praktisk talt et klikk for å få det inn i Big Quarry. For du sa at det skulle være enkelt å få data fra Kafka til Big Quarry? Stort sett. Et veldig vanlig pattern er Kafka til Kafka Connect inn i Big Quarry, og så setter man en analytiker og/eller en data engineer på det, og så skriver man transformer for å få det inn i litt mer ...
Ja, i noe som ligner mer på et dataprodukt. Inn i Big Quarry. Da bruker vi dataform. Da er det sikkert et veldig vanlig oppfølgingsspørsmål vi får: Hvorfor bruker dere ikke DBT? DBT er et transformasjonsrammeverk som er veldig vanlig å bruke. Vi så på det, og så fant vi ut at de behovene vi har i dag, vi trenger ikke DBT. Vi klarer oss med dataform, men det er nok naturlig at vi går dit etter hvert. Men hvordan kjører dere Kafka? Nå er vi over på Ivan. Det ble fullført for ca. et halvt år siden. Migrering fra Self-Managed. Det er vi veldig glad for. Det er veldig deilig å slippe å ha det bryet. Men det er ikke helt frittstående heller. Vi må fortsatt gjøre en del ting.
Og vi må følge opp en del. Kjører de Kafka Connect også? Ja. Der kan det hende at vi har noen behov som ikke er støttet av Aivan ennå, så det kan hende at vi går tilbake igjen der. Men per nå så er det riktig. Da bruker vi Kafka Connect i Aivan. Så har vi litt andre tjenester å kjøre hos dem også. Men fortell litt om reisen fra et applikasjonsutviklerperspektiv. Hvis de lager en applikasjon og den har noe behov, enten for å snakke med Kafka, eller ... Eller direkte til Big Quarry eller Elastic Search ... Hva er interfacet de forholder seg til da? For en utviklerteam for å sette ut en ny applikasjon, så må de bestille noe vi har kalt for en landesone. Vi har et DevOps-håndbok, som er interfacet vårt,
som er dokumentasjonen vår, og der får man informasjon fra A til Å om hele livssyklusen til applikasjonen og hvordan man skal bestille dette. Per i dag er ikke dette helt selvbetjent, men vi har en applikasjon. Og minimum der så trenger vi egentlig et applikasjonsnavn og miljøer den skal kjøre i, og om det er et dataprosjekt. For dataprosjektet har noen andre tilgangsstillingsinnstillinger. Så vi har et annet sett med regler for datateamet. Så vanligvis så ber utviklerne om et landesone, og landesone for oss er et kubernetes namespace for applikasjonen. Og et GCP-prosjekt som er knyttet til namespacer via workload identity. Så det er ett cluster, ikke kjempemange cluster i delen av kubernetesverdenen?
På en måte, ja. Vi har prod. og non-prod. Men vi har tre clustre i hver miljø. Det ene er at vi må ha noe i Norge, så vi har et cluster i Azure, AQS. Vi har GKE-cluster, og så har vi noen workload. Som er veldig compute-intensive når de gjør reisesøk-API-et vårt. Så de kjører et annet sett med noder som ikke er tilgjengelig den lokasjonen vi kjører. Men vi gir da et namespace per applikasjon og et prosjekt per miljø. Dette spinnes da opp automatisk i dag. Etter hvert kanskje bygge et mer effektivt interface mot utviklerne. Hvordan det vil se ut i form av CILIAP, eller om det blir en intern utviklerportal. Det kommer vi tilbake til.
Da ser vi for oss kanskje at en dataproduktspekk ikke er så veldig unikt. Den app-spekken man lager, da. Men dere har en applikasjon som lager noe data, som sikkert bor i en postkress. Hvordan kommer den dataen ut på Kafka? Er det noen CDC-løsning? Eller publiserer dere fra applikasjonen, eller? Der oppretter de stort sett et eget topic, og første gang det publiseres, en melding, på det topict så følger det med ... Da har jo de spesifisert et skjema, typisk internt i applikasjonen, altså den produserende applikasjonen, og da populeres skjemaet opp i Schema Registry i Aven, og det er egentlig det.
Og så er det da automatikk i at Connect gjør det til DQ? Nei, da må de her og nå spørre oss, og så gjør vi det i dataplattform. Det er en oppgave som ... Det skjer ikke hver dag, så det eskalerer veldig fint akkurat nå. Men vi ser jo for oss en verden hvor vi ... Vi har egentlig begynt arbeidet akkurat nå på å lage ... Jeg startet med navnet Datakontrakt. I dag går endret jeg navnet til Dataspekk, så det er helt ferskt. Det er fordi det finnes en del verktøy som har coina datakontrakt, for ikke å forveksle det. Som vil være forskjellen på hva som er bare rådata, domenedata,
og hva som er dataprodukt. Så da vil man kunne gjøre en del ... Da er det egentlig bare en enum eller en setting som i den spekken sier: Dette skal være tilgjengelig i datavarehuset, og så blir det tilgjengelig i datavarehuset. Men dette her er et arbeid vi så vidt har begynt, så hvis dere inviterer oss inn om et år, så kan vi kanskje gi en kul oppdatering. Men to ting, egentlig. For det første, hvordan er det dere jobber med å hente inn krav eller behov fra brukerne, enten det er data engineers eller applikasjonsutviklere eller hva det skal være. Og så tror jeg du nevnte en DABOPS-håndbok. Hvor dokumenterer dere hva som er gjeldende? Hva er funksjonalitetene i disse plattformene, og hvordan tar de dem?
Det er ikke hvem som vil begynne å svare. Vi kan begynne med utviklerplattformen. Devopsom-boka er bare en samling av dokumentasjon. I dag så er den dessverre i konfluens, men det er det som er internt tilgjengelig. Og idet en utvikler har bestilt, idet man har fått et landesone, så er det egentlig et sandbox-miljø, et trygt miljø der de kan gjøre alt. Så de kan spinne ut sin applikasjon. Det gjør de via en Golden Path. Og så har vi et CD-verktøy som er standardisert og kan ta det med fra DevTestProd.
Og man kan legge litt mer avansert funksjonalitet som kanskje manuell sjekk eller gjøre noen smoke-tester. Eller Aprol-prosesser, eller what not. Utviklingsteamene har jo ansvaret for vedlikehold av sine egne databaser òg, men vi leverer Terraform-moduler. Der kan du også referere til modulene. CD-verktøyet vårt vil også fange det og gjøre Terraform-plan. I mange tilfeller vil man stoppe utrullingen hvis det er noen endringer i planen, for å dobbeltsjekke, for infrastrukturendringer kan være skummelt. Så går det videre til DevTestProd.
Hva slags CD-verktøy bruker dere? Det er noe som heter Harness. Det var noe vi valgte i 2019 som dekket for behov der. I dag så er det ... Det er Harnes! Så det er et ekteiv som heter Harnes. Før vi går til datablata, hvordan jobber dere med innhenting av behov, og hva er det dere faktisk skal lage, og for hvem? Vi prøver å ha et produkttankegang rundt dette. For det første så har vi årlige spørreundersøkelser, vi har en devOp-skylt. Som tidligere ... jeg lurer på, vi har bicka over 50 episoder der. Det var noen ukentlige greier, nå er det kanskje per måned. Vi har devOp-sementorer plassert i alle team.
Dette er ikke personer som jobber for plattformteamet, men som er en del av en ekspertgruppe, kan du si. I noen tilfeller så er det veldig seniorutviklere, i noen tilfeller juniorutviklere som er interessert i, som hjelper også plattform på feilsøking. Feilsøking og videreformidle behovene. Eller så er det tilbakemelding fra utviklerne, og det vi fanger opp underveis. Hvor melder de tilbake? Ofte Slack. Så har vi jo en to ganger i året med en spørreundersøkelse. Litt sånn walking i hva som skjer i ... Hva folk ønsker og syns om utviklingsplattformen.
Ja, det var den jeg nevnte i starten. Vi spør spesifikt på områder vi begynner å mistenke. Trenger litt oppdatering. Spør spesifikt hva som er viktig for dere innenfor de områdene. Hvordan gjør dere det i dataplattform-biten? Vil du ha lange eller korte? Vi har tid til lange. Vi kan ikke klippe bort det kjedelige. Vi er jo ikke så ... Så vi får ta det litt historisk først, for å sette litt perspektiv på det. Så vi startet som en satsing på at nå må vi gjøre ... Vi har masse data. Vi må bruke dataene til noe gøy og noe verdifullt.
Og så starter man med ambisjonene høyt oppe i skyene, og så finner man ut at nå kanskje vi strakk oss litt langt, og så pivoterer man litt tilbake og tenker at nå må vi få ut verdi før vi trekker videreutviklingen. Vi finner mye hypoteser her dette datasettet tror vi kan gjøre mye morsomt med, og så begynner vi å grave, setter analytikere på det, og hypotesetester egentlig fort. Så er det bra å videreutvikle det, hvis ikke så bare lar vi det ligge. I tillegg så har vi tett samarbeid med Jernbanedirektoratet, og får en del beskjeder. Og får en del bestillinger derifra. Jeg vet ikke helt om jeg kan snakke om nøyaktig hva, så jeg tror jeg hopper over den. Men det kommer en del eksterne bestillinger og undersøkelser og analyser og ting der.
Så er det mye deling av data tilbake igjen til operatørene. Så vi eier jo veldig lite data selv. Og mesteparten av dem verdifulle kommer jo fra bussene som kjører, altså samtidsdata derifra. Salgsdataen. Salgsdataen som kommer mye via Vy, Entur-appen, mange forskjellige plattformer, og stort sett ikke Entur som eier de transaksjonene selv. Så dette må jo deles tilbake igjen til operatørene. Så det er mye arbeid rundt det, og mye kommer på bestilling eksternt. Fra kollektivsektoren for øvrig. Deler du data der, eller mer foredla ting? Begge deler. Både dashbord og ... Både dashbord og rådatasett.
Avhengig av behov og ønsker og hvor mye kapasitet vi har. Kan jeg også si at en tur i starten var relativt nytt selskap, og vi har jo vokst voldsomt, så behovene har endret seg underveis også. Så det er en gradvis forbedring. Det er ikke store endringer som kommer brått, men vi jobber iterativt med dette. Jeg husker tilbake den gangen hvor vi vi feiret at vi hadde 100 000 kall i våre API-er på en uke. I dag har vi nådd 500 millioner kall i uka. Så behovene har også endret seg. Det blir slitsomt om dere skulle feire hver 100 000 på 500 millioner i uka. Det blir mye kaki iallfall. Ja, det hadde vært gøy. Ta noe eksponentiell skala, altså.
Vi har jo ikke snakka så mye om datablåter, så jeg har lyst til å snakke litt mer. Visualisering, hva slags verktøy bruker dere der? Vi bruker i stor grad Looker Studio per nå. Det er et visualiseringsverktøy som Google har kjøpt opp og har tilgjengeliggjort for tett integrasjon med Big Quarey, så det er kjempelett å hente data fra Big Quarey. Så det er kjempelett å hente data fra Big Quare inn og lage gode visualiseringer. Det er nok et verktøy som er mer egnet for adhocanalyser og work in progress-løsninger. Det er ikke spesielt snappy, men det fungerer veldig bra og kan skape mye innsikt for type produkteiere, teamlead, domeneteamene, hvis du vil ha noe. Så mange transaksjoner gikk gjennom,
så kan man hente det fra Datavarehus istedenfor å sette opp f.eks. Grafana med trykker. Eller litt mer kompliserte spørringer som er vanskelig å få løst med. Grafana-lignende verktøy, da? Hva med Discovery-databruker? På API-nivå er det ikke alltid kataloger funker så bra. Men i hvert fall hos oss i Nav ser det ut som om kataloger funker litt bedre på dataprodukter enn på operasjonelle data. Hva gjør det der? Det stemmer veldig bra. Der har vi kommet så langt at vi har laget to egne datakataloger og satt opp en tredje. Har dere en datakatalog-katalog, så det er mulig å se hvem som skal bruke den? Ja, vi trenger det snart. Nei da. Vi har data i entur.no, som er helt åpne data. Og så har vi en microfront-end i partnerportalen, som ble nevnt tidligere.
Hvor operatørene, altså våre tette partnere, vi, SJ osv., kan få tilgang til data delt med dem. I tillegg til det har vi satt opp Datahub som et internt verktøy. Er det et Google-verktøy eller en annen? Det er et open source-verktøy. Vet ikke om det ligger under en organisasjon. Jeg tror det er et open source-produkt. Metadatakatalog, egentlig. Det er en metadatakatalog, og der har vi vært inne og fikset et par småting. En stor fordel med å åpne kildekode er at man kan gå inn og fikse ting selv. Det tar litt tid, men det har vi faktisk prioritert. Har dere integrert noen av de katalogene? Partnerportalen har det. Det er også en av de store linjene vi ser på nå.
Vi har et veldig komplekst delingssystem. Eller, vi har komplekse behov for deling av data. Fordi vi er en offentlig datahub for kollektivdata, som vil si at vi har et ansvar. Vi har et ansvar om å dele data med hvermannsen. Dette gjelder f.eks. Transportøkonomisk institutt, SSB, for journalistiske formål. Der har vi et samfunnsansvar for å dele med dem. Så vi må tilgjengeliggjøre data åpent. I tillegg har vi mange tette samarbeidspartnere, som f.eks. Vy, Go-Ahead osv. Og der er det jo en ordentlig suppe av tilgangskontroll som er strengt nødvendig. For vi vil jo ikke dele Vy-data med SIOD, og motsatt. Da blir de ikke så blide. Så da må vi gjøre ting riktig. Og så har vi data som bare burde eksistere internt, og har enorm nytteverdi internt, men vi vil ha kontroll på at de ikke deles eksternt.
Den dataen dere deler, er det Big Curry direkte, eller er det filer, eller hva ... Stort sett Big Curry direkte. Eller Kafka. Hvis det er Big Crey, hvordan gjør dere med penger? Volumene av dataen er ikke så høye på det som er åpent, så der har vi bare satt på ... Dere spanderer, rett og slett? Ja. Det er bare snakk om noen hundrelapper i måneden. Så lenge det er den skalaen der, så er det ikke noe problem. Per konto kan du ha halv terabyte per bruker. Før det blir rateamet. Det er begrensninger. Og det funker bra per i dag. Så den tar vi bare på vårkappe.
Og de tette operatørene har egne Google-kontoer. Der er det et flagg som heter Request to pace, som løser det problemet veldig elegant. Ja, for vi bruker jo litt Big Curry nå. Og det som er magisk, er at uansett så ser det ut som en database. Så lenge du har tilgang, kan du joine hva som helst. Det er kjempedeilig. Hva med datakvalitet? Bruker dere verktøy for å se på kvaliteten som kanskje er integrert med katalogen, eller noe sånt? Vi har sett på å ta i bruk verktøy for å monitorere datakvalitet. Og én ting vi er helt sikre på, er at datakvaliteten som kommer eksternt, er veldig varierende. Så og ... Det vi har valgt å gjøre istedenfor
å se på et generelt verktøy for det, er å gå mål mer mer. Målrettet inn. For vi vet at dette er grunndata som det er enormt stor kvalitetsvariasjon i. Og har rett og slett bygd en datakvalitetsrapport som burde publiseres snart. Den er ikke helt ferdig. Men den ser på sanntidsdata, og det er egentlig en mer dyptgående, ordentlig tung analyse av kvaliteten i dataene. Da er det ikke bare sånn, er det nullverdier her, er det innenfor threshold-verdiene. Hva betyr disse verdiene operasjonelt, og hva slags operasjonell verdi har dette her for sluttbrukerne.
Klarer vi å måle en sånn kvalitet? Den vil sannsynligvis bli publisert helt offentlig, så alle kan gå inn og se på den. Noe annet som er offentlig med sanntidsdata som jeg ble tipset om av en kollega, det var tavla.entur.no. Den var ny for meg. Vil dere fortelle hva den er? Den er det ikke vi som har jobbet med. Det er et domeneteam. Men ja, de bruker jo disse samtidsdataene, som vi da monitorerer og får inn i datovarhuset. Men de bruker du jo rett fra kilden. Og har laget et slags dataprodukt oppå det. For der kan du gå inn og legge til et avreisestoppested.
Som her er min, på kontoret eller hjemme, når er neste avgang? Fra mitt. Og du kan dele det på artige måter. Alle hjem burde ha det i smartspeilet sitt, tenker jeg. Det har vi hos en tur. Produsenten vår opp med hånden, og han har det. Alle har jo smartspeil, liksom. Jeg har ikke smartspeil. Jeg ser veldig smart i speilet. Det var det du mente, sant? Absolutt. Men jeg ser vi begynner å gå inn for landing. Og før vi avslutter, så har vi spørsmål vi spør alle gjestene våre.
Og det er om dere kan fortelle en gang ting ikke gikk helt etter planen, og hva dere lærte av det. Ja, altså det skjer nok relativt ofte, så det er ikke big deal. Altså at toget ikke gikk etter planen, eller? Nei. Vi har et dynamisk miljø som skalerer opp og ned kraftig to ganger i døgnet. Så vi får jo kjørt oss ofte i løpet av en dag. Men det er ikke sånn veldig katastrofale ting som skjer til vanlig. Men vi har jo slettet Kubernetesk cluster og den type ting som har hendt for lenge siden. Men de er tilbake nå? De er tilbake nå.
Ja ... Så det er ofte de feilene som ... Er det kanskje å ta den med Kafka som er relativt nylig? Ja, den ... Nå har jeg ikke vært så lenge i Dataplattformtima at jeg kan snakke om så store blundere vi har gjort selv der. Men vi hadde en liten hikke i noen sertifikater som ga oss en stress. Vår monitorering var kanskje ikke så bra som den burde vært. Så det tok vel altfor mange minutter før vi fant ut at Kafka-clusteret i praksis var helt nede. Det er litt kjedelig. Men vi har fått rettet opp det og fikset litt bedre monitorering. Og vet om et par painpoints vi skal følge med på som en hauk. Så ... Hvordan monitorerer Kafka Grafana?
Grafana og Prometheus og den standard-stacken der, og en del alarmer som tipser oss. Jeg kan jo tipse om Prometheus Blackbox Exporter, som har innebygget et sertifikatsjekk. Nå har jo dere løst dette her, selvfølgelig. Men for alle de andre som lytter på, som har akkurat de samme problemene ... Vi har hatt nok av sertifikater som har gått ut opp gjennom årene, men det fins gode verktøy for det. Vi bruker faktisk det i Utviklerplattformen, da. Men det var vel interne sertifikater. Synes jeg det er litt intern konkurranse her nå, men vi gjør faktisk det allerede. Mens dere i Dataplattformen har litt å gå på der, ja. Det er skikkelig kult å høre om hvordan dere bygger kollektiv noe.
Selv en kjempefan av kollektivtransport, og bruker både buss og bane enormt mye. Så ... Skal vi ta opp temaet Bane og Bergen, eller skal vi la det ligge? Nei, jeg tror vi lar den ligge. Det er visst noe snøstorm og noe her. Men da lurer jeg på om det er noe vi har glemt å spørre om, eller noe der vi sier før vi runder av. Vi kan jo begynne med deg, Rejeb. Nei, jeg syns det er veldig kult med påtresten her. Veldig flott at vi fikk lov til å snakke om dataplattformen som første ut. Men er det noen store nyvinninger i horisontene for en tur? For oss i Data og Insekt er det å begynne å jobbe mer målrettet
med å plattformisere datavarehuset vårt. Og bygge en plattform som automatiserer mye av painpointene våre når det kommer til deling, komplekse prosjektstrukturer og tilgjengeliggjøring for ... For partnere internt og allmennheten. Der skjer det veldig mye gøy nå. Vi begynner også å se på grensenittet, på hvordan vi kan tilby mer selvbetjening i Utviklerplattformen, og konsolidere mye av de konseptene mot dataplattformen også. Så det er vel det største som engasjerer veldig nå. Eller så er det alltid en ting som beveger seg, en ting som vi er veldig glad over. Det er jo at vi er på vei over til github nå. Så det er jo en ...
Det er masse spennende som skjer her. Hvis vi har lyttere som har spørsmål, så må de sende det inn til oss, og så skal vi sikkert få nye episoder med en tur på et senere tidspunkt. Men nå er jeg interessert. Spent, Audun, har du et høydepunkt fra episoden? Det jeg syns er morsomt med dataplattform, er at det for meg er litt mer uklart hva det er i forhold til applikasjonsplattform, som er deploy-monitorering, og dette har vi løst i mange år allerede. Men selv om det er litt uklart, så er det åpenbart mye å lære, og mye av det spesielt den plattformtankegangen. At man skal automatisere og gjøre det lettere å rette, og lage verktøy.
Den er veldig fin å ha med seg på dataplattformen også, og det tror jeg matcher det. Det matcher også mye av det vi har sett i Nav. Hva med det, Kristian? Hva er ditt høydepunkt? Jeg syns det er veldig gøy med åpen data. Det er en sånn åpen kildekode sin kjære søster eller bror. Åpen kildekode, åpen data, det går hånd i hånd. Og det har et veldig spesielt sted i mitt hjerte, da. Så du plutselig kan finne ut om det er et nytt stoppested som er nærmeste der du går f.eks.? Ja, ja. Jeg har jobbet mye med gisse. Det er kjempespennende. Vi integrerer det vel med en tur på ut.no på et tidspunkt. Få inn nærmeste kollektivstopp når du skal ut og reise.
Det er kjempeviktig for å nå klimamålene og at vi kan få ned biltrafikken. Det er også et veldig viktig sted fra mitt perspektiv. Tusen takk til Regib Setin og Anders Dalen fra Enture for at dere har vært med oss her. Dette har vært en episode av Plattformpodden. Mitt navn er som alltid Hans Kristian Flåtten. Med meg i studio har jeg Audun Fauchaldd Strand. Teknisk produsent har vært Tore Græsdal. Nyeste episoder finner du alltid på plattformpodden.no eller i din lokale podkastapp. Del gjerne episoden med en kollega og få en virtuell klem fra Audun. Takk for oss. Takk til alle sammen! Takk til alle sammen!