Episoden er transkribert av kunstig intelligens

00:00 --> 00:45

Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og timene som dager dine. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg som vanlig Audun Faukal Strand. Og i sesong to av Plattformpodden løfter vi blikket og utforsker plattformer i privat sektor. Men før vi introduserer dagens gjester, Audun, har du en favorittkonferanse? Det må være Javason. I all hovedsak fordi de har best mat. Eller egentlig best servering av mat, og kontinuerlig leveranse av mat. Nå hørte jeg akkurat at NDC har det samme, og jeg skal dit i juni. Så jeg gleder meg til å finne ut om det også stemmer der. Hva med deg, Hans Kristian?

00:45 --> 01:27

Jeg kan i hvert fall avsløre at det stemmer. Jeg tror det er samme cateringselskapet, samme lokasjon, det er bare å bytte ut bannerne fra NDC til Javason. Nei, for min del er jeg veldig glad i Kubkan. Jeg skal snakke der i år. Jeg har hørt mye bra om GoForkon. Kanskje det blir GoForkon på meg neste år. Men i dag skal vi ikke snakke så mye om konferanser. I dag er vi så heldige å ha med oss Gard Rimestad og Ivar Østhus fra Unleash. Unleash er et åpen kildekodesystem for å styre utrulling av ny funksjonalitet, eller feature toggles, eller funksjonsbrytere på godt norsk, og startet som et internt prosjekt i Finn. Nå er Unleash blitt sitt eget selskap.

01:27 --> 02:15

Et selskap med millioner av nedlastinger over hele verden, og sin egen SAS-løsning hvor de kan kjøre Unleash for deg som en tjeneste. Ivar, kan ikke du begynne å fortelle litt om din bakgrunn, og hva du jobber med i Unleash? Ja, hei. Jeg heter Ivar. I utgangspunktet var jeg utvikla av det. Jeg kjenner veldig på at jeg utvikla det mitt hjerte nært. I Finn fikk jeg da gå reisen og starte som utvikler etter å ha vært tech-lead. Jeg så litt behovene for å kunne bruke et verktøy som Unleash for å hjelpe til med å kontrollere utrullingen. I den reisen så gikk jeg også over til å være arkitekt og lede arkitektgruppen i Finn, og så jo da med et litt større perspektiv hvor nyttig et verktøy som Unleash var

02:15 --> 02:59

for et selskap som Finn. Og i dag så jobber jeg da som CTO og gründer av Unleash, selskapet bak dette Opensource-verktøyet. Kjempekult. Gard, hvorfor begynte du i Unleash, og hva er din rolle? Jeg jobba også i Finn, starta karrieren min i Finn som utvikler, og bevega meg over på driftssiden og så på utviklingsproduktivitetssiden. Og har jobbet mye med plattformer, og Unleash jobba jeg også med i Finn. Og når Ivar hadde starta et firma, og så syns jeg han egentlig bare var kling gæren, som starta et firma for Unleash. Men etter hvert som det kom kunder og sånne ting inn,

02:59 --> 03:49

så syns jeg det var veldig spennende å kunne bli med på den reisen. Så jeg jobber nå i Unleash som plattform-lead. Men før vi dykker ned i mer plattformer, Ivar, kan ikke du dra oss litt igjennom for de som ikke kjenner til Unleash? Hva er det som møter de hvis de begynner å ta i bruk Unleash? Ja, det man typisk gjør, er å laste ned Unleash. Det kan man gjøre på mange måter; den vanligste er å ta i bruk docker-imager. Eller man kan gå via et hell-image. Og så får man da muligheten til å konfigurere opp, definere de forskjellige featurene. Man kaller det gjerne en feature toggle, det som beskytter funksjonaliteten din. Og så får man muligheten til å legge på det vi har valgt å kalle aktiveringsstrategier.

03:50 --> 04:35

Det er det som beskytter denne featuren, det som lar deg bestemme hvem som skal eksponeres for denne funksjonaliteten. Typisk er det at man ønsker å teste det på seg selv først, sitt eget team. Noen som kjenner det man holder på å lage. Og så begynner man etter hvert å ta det mer gradvis ut til flere brukere. Måten man da inkluderer dette i sin kodebase, er at vi har utvikla et sett med SDK-er som konsumerer dette. Som gjør det veldig enkelt å sette opp dette i sin egen applikasjon. Og vi har jo selvfølgelig SDK-er for alle de store programmeringsspråkene og sånn. Ja, så det betyr at dere ... Det er liksom den ene appen, eller applikasjonen Leash, er det dere leverer.

04:36 --> 05:35

Ja, så det betyr at dere ... Den ene appen, eller applikasjonen Leash, er det dere leverer. Ja, og så er det jo klart at vi har jo ... Vi har én hovedapp, og så har vi lagd veldig mye annet rundt. Så vi vedlikeholder jo mer enn 25 SDK-er, i forskjellige programmeringsspråk. Vi har lagd noe som heter Ealish Edge, for å hjelpe til med skalering og resilience. Jeg tror vi har over 60 open-sauce-repositoryer som vi maintainer. For dere tilbyr både en SAS og at man kan kjøre selv. Men den SAS-en, hvordan er plattformen der? Vi kjører på Kubernetes og bruker Victoriametrics for med trikker. Og Loki for logger, og Grafana for alerting. Vi kjører på A. Vi kjører på AWS og bruker EKS.

05:35 --> 06:33

Og så setter vi opp ett namespace per kunde, en RDS-database per kunde, og så har vi secrets i parameter store. Så det er ganske enkelt satt opp, veldig standard type plattformskomponenter. Så det er en single tenant, altså selve installasjonen, og så kjører dere opp? Ja, det gjør vi. Og det har jo noen fordeler. En ulempe er at vi har like mange databaser som vi har kunder, men det er også en fordel. For hvis du skal oppgradere over 50 databaser, så gjør du ikke det for hånd. Så vi automatiserer den type ting, og da tilbyr vi faktisk at vi kan oppgradere databaser uten nedetid, f.eks. Og hvis en kunde er veldig annerledes enn andre og trenger større og trenger større database fordi de har mye trafikk,

06:33 --> 07:36

så kan vi flytte de til dedikert større database veldig enkelt uten nedetid. Og det er noe som vi får pga. at vi må være gode på å kjøre veldig mange av én applikasjon. Så applikasjonen vår ... Jeg skulle ønske alle applikasjoner var skrevet sånn. At det fantes "maintenance mode". "Read only mode" av applikasjonen er jo gull. Og en drøm å ha, men det er ikke lett å få overalt. Men vi har det på Unleash vår. Det vi må huske på, hvis man ser det store bildet ... Kjerneproduktet vårt er open sauce. Vi vet om mange tusen selskaper som kjører Unleash aktivt hver eneste dag. Vi kjenner jo ikke plattformen til alle disse selskapene. Så vår jobb er å sørge for at det er så enkelt som mulig. Å kjøre Unleash hvor som helst, i hvilken som helst sky, i hvilken som helst on-pram plattform.

07:36 --> 08:24

Og det betyr at vi må jo forholdes til ulike arkitekturer, f.eks., være trygge på at det funker. Og så må vi være trygge på at vi har færrest mulig avhengigheter, for med en gang vi kommer med: "Nei, du er nødt til å gjøre dette." Så vi har én viktig avhengighet, og det er Postgress. Der har vi valgt å ta et standpunkt. Du må tilby Postgress som en del av oppsettet. Utover det så er det ingen andre krav. Jeg kan selv skrive under på hvor lett det er å kjøre en leash. Vi har kjørt inn leash i Nav i mange år. Hadde først en kjempesvær instans ... Ivar, var du med å sette den opp? Nei. Jeg tror det var noe som var med fra en leash å sette den opp. Men som kjørte frem til ut 2023, og nå har gått over til å kjøre

08:24 --> 09:12

flere instanser, altså én instans per team. Jeg kan skrive under hvor lett det er å få en leash opp å gå. Men tilbake til det du sa om at dere må kjøre på mange plattformer. Hva slags grep tar dere med applikasjonen for at det ikke skal bli mye jobb, når det kommer kunder med veldig rare oppsett som vil gi dere penger for å få en leash? Da må dere jo hoppe, tross alt. Absolutt. Og vi prøver jo å være tydelige på hva som er best practice. Vi følger jo f.eks. vanlig. Sånne ting som Twell Facts Rap er veldig viktig å følge. Så lenge du kan lene deg på de vanlige best practices som de fleste er enig i, så er det iallfall et godt utgangspunkt.

09:12 --> 10:00

Og så er det klart at vi ser jo selskaper som gjør mye rart. Som ikke alltid helt forstår hvorfor de gjør det de gjør. Og vi har noen eksempler på f.eks. at selskaper kommer til å gjøre noe rart. Selskaper kommer til oss og sier: "Hvorfor bruker Ønlich 3 GB minne?" Det er klart at Ønlich ikke bruker 3 GB minne hvis ikke noe er alvorlig galt. Vårt mål er å holde det under 200 MB. Så vi skjønner jo med en gang at her er det noe som skurrer. Og vi har jo ikke noe innsikt inn i kundens plattform i utgangspunktet, hvis de velger å holde det selv. Det som da er viktig, er at vi har gode metrikker. At vi kan be om: Kan du gi oss disse metrikkene?

10:00 --> 10:50

Og så kan vi si: Ja, men det er ikke Ønlich som bruker 3 GB minne her? Hvor har du sett at Ønlich bruker så mye? Jo, det har de sett i sin APN. Hvilken APN bruker du? Hvordan instrumenterer du? Hva annet har du i din plattform? Da viser det seg ofte at det er noe annet rundt det. F.eks. at man har en sidecar. F.eks. man har en service mesh som er litt rart konfigurert. Eller man har en APN-agent som man har installert på den noden, som gjør noe litt rart. Og gjerne ha en minnelekkasje. Men det er ting som vi da må, spesielt i kundeforholdene, vi må forholde oss til dette. Det er ikke nok å si at "nei, Ønlich er ikke et problem". Vi må komme opp igjen. Kundene må finne problemene før man er enige om det. Helt til det motsatte er bevist, i hvert fall.

10:50 --> 11:40

Vi møter jo litt spennende kunder sånn sett òg, som ikke vet hvorfor ting ikke virker. Bare det virker ikke. Det er spennende med en Edge-løsning som er skrevet i Røst. Den starter instantant, nesten. Og det er første gang jeg har sett i et cluster at nettverk ikke er tilgjengelig. Så vi måtte ... Jeg testa med kunden og legger på en slip før applikasjonen starter. Ta et godt tegn når du må innom og legge på en slip. Jeg lærte et triks om Kubernetes. Hvis du snakker med noen og de kanskje ikke kan alt om Kubernetes, og så tar du en kube-Ztl, get-Crd, wc minus l, og hvis den er over 50, så vet du at de antakeligvis ikke vet

11:40 --> 12:29

hva som skjer der, og da må du følge ordentlig nøye med, og prøve å tenke på alle muligheter. Det var sånn vi fant dette nettverksproblemet. Så det var ganske spennende. Var det en service match, sidecar, et eller annet som ikke var på plass? Jeg vet ikke hva som forårsaka det, men den Edge kunne ikke snakke med Unleash, og feilmeldingen ... Vi klarte ikke å reprodusere den lokalt. Jeg konkluderte bare med at nettverket ikke var der, da. Men det fikk vi ordna. Det er spennende. For raskt å starte opp på SV? Ja. Men den kjører EKS, sant? Så dere har jo Kubernetes. Har dere laget en operator for å kjøre Unleash?

12:29 --> 13:13

Det er mer rundt hvordan dere hoster det selv? Ja, vi har flere operators. Vi har én operator som tar liksom ... Det å kjøre en leash er veldig enkelt, men vi har jo oncall også. Vi går vaktordning. Og noen kunder er veldig store. Og noen kunder er veldig store, noen kunder er veldig små. Og vi har f.eks. istedenfor at vi skal forholde oss til CPU og minne, så har vi lagd T-shirt-sizing i operatoren. Så du sier size small, large eller ekstra large for å gi ressurser, istedenfor å forholde deg til hvor mange megabyte minne skal det være. Og så har vi en del andre attributter også, som vi styrer der.

13:13 --> 13:57

F.eks. så kan vi legge på, hvis det er noen som vil ha ... Allow-listing av IP-er, så legger vi det inn i CRD-en vår. Så tar operatoren og skriver om det til Traffic Middleware f.eks. Det er sånn vi har veldig liten kjent det selv for Unleash. Og så får vi alle kubernetsobjektene på andre sida. Den andre operatoren vår er egentlig litt mer unik. Vi har forskjellige release channels av Unleash, som er at brokunder skal ha ... Bro-kunder skal få det, demo-kunder skal få det, Enterprise-kunder skal kanskje få en litt mer testa versjon, osv. Da har vi release channels som vi noterer på objektene,

13:57 --> 14:46

og så har vi en operator som synkroniserer imaget med hva som er desired state for den release channelen. Det bruker vi på Unleash, vi bruker det på kronjobber, vi bruker det på andre deployments og sånne ting. Så der har vi på en måte en liten plattform, med også et eget deployment-verktøy. Som vi har utvikla for det å styre release channels og tracke ting. For når dere får en ny kunde, hva er det dere må gjøre da? Sånn teknisk ...? I dag så har vi automatisert det. Vi har alltid en alert som sier at vi har mindre enn fem ledige kundeinstanser. Og hvis vi har det, så legger vi til nye. Vi legger typisk til 25 om gangen.

14:47 --> 15:29

Og så har vi det som klare instanser, og så har vi automasjonen på at når du signer opp, så får du en frist. Selvservice hele signup-prosessen. Ja. Og det er en av de tingene nå. Nå mentener vi over 500 instanser, og da er det på tide at vi automatiserer denne biten òg, og lager de 25 nye. Og det er et av de målene vi har for 2024. For vi skal doble, vi skal over 1000. Da er det kjedelig å gjøre noe manuelt. Den ene siden er å automatisere tildeling, men så er det også opprydning. Vi tildeler også trial-instanser og sånn, og med den veksten vi ser nå, så ønsker vi å begynne å se på det mer som data.

15:29 --> 16:14

Så det er en av de tingene som står på lista for å forbedre i år. Det er også en annen viktig faktor i vårt oppsett, og det er at vi har flere produksjonsklustre. Og det er mest for å supportere at vi har noe ... Europeiske kunder foretrekker at data er lagret i Europa. Men det vi også har lært, er at amerikanske kunder er opptatt av at deres data skal lages i USA. Så det går begge veier. Da er det fint at vi enkelt kan tilby det. De vil slippe hele gdp-tinget? Det begynner jo å komme tilsvarende regulative ting i USA, som gjør at store selskaper foretrekker at data lages.

16:14 --> 17:03

Det er en større prosess hvis vi skal selge at det skal være i Europa, selv om vi er på et amerikansk selskaps datasenter. Så vi syns det er litt interessant. Men fordelen vår er at når vi har denne single tenant-modelen, så er det ganske grei skuring for oss å ha flere clusters. Utenom det juridisk kommersielle, er det noen tekniske grunner? Hvor mye må det spres bare for ...? For dere har kunder over hele verden. Hvor mange lokasjoner er dere på, hva er de tekniske bakgrunnene? Hvis man skal skalere i forhold til performance, har vi noen globale kunder som har behov for å ha tilstedeværelse i større deler av verden. Da er det dette Unleash Edge-produktet, som vi bruker til å skalere.

17:03 --> 17:49

Så at du har tilgjengelighet der du måtte trenge tilgjengelighet. Og den kan også være persistent. Men poenget er at det er persistent storage av dine konfigurasjoner, hvor det ender opp, som er det legale. Men det er kanskje litt latency òg, at det kan være en fordel å ha instansen litt nærmere der hvor du har applikasjoner? Ja, dette har vi testa mye, da. Og det viser seg jo at nå er det først og fremst Europa og USA som vi fokuserer på. Og det er klart at alt av front-end assets og sånn, det har vi selvfølgelig. Så er det jo klart ... Responstiden til USA er faktisk ikke så ille. Så det er ikke egentlig et stort problem at applikasjonen hostes i USA,

17:49 --> 18:40

hvis du skal konsumere den fra Norge, så lenge alt av Javascript og bilder hostes lokalt. Så performancemessig og i forhold til hvordan du kobler på din applikasjon, så har vi en SDK som catcher dette i bakkant. Du vil jo aldri gå ut og spørre én og én feature-tog eller on the fly. Det ville jo aldri vært fort nok. Så vår erfaring er at det er jo bedre å ha det nært nå, men det er mange andre ting man også kan optimalisere, som kanskje er viktigere. Sånn som med segmenter og utrullingsstrategi evalueres, det er også lokalt i SDK-en? Riktig. Så du slipper å sende all den dataen og få et svar om ...? Ja, og det er der vi har valgt å ta et tydelig standpunkt.

18:40 --> 19:28

Vi skal ikke se kundenes data. Det evalueres lokalt. Så klart det har noen utfordringer. Det er f.eks. hvis du ønsker å bruke feature-toggles i en frontend-applikasjon. For da betyr det jo at det er inni din browser som sluttbruker. Og det er igjen der vi har utvikla dette age-produktet, som kunden kan hoste selv. Som da vil evaluere server-side, men da igjen innenfor en server som er kontrollert av kunden. Riktig. Det er veldig interessant. Hvordan er det i forhold til andre konkurrenter eller andre alternativer? Har de lagt seg på samme modell der, eller? De begynner å ta etter.

19:28 --> 20:24

Så vi har to hovedkonkurrenter, så trenger vi ikke gå inn på navn i bøkene, men folk er gode. Vi ser at vi har to hovedkonkurrenter. Opprinnelig ønska de å samle så mye data som mulig, for å eie data har en stor egenverdi. Men det er jo en kjempeutfordring privacy-messig. Så vi har valgt å gå den motsatte vei fra dag én, og være tydelige på at vi eier konfigurasjonen, men det er din applikasjon som skal vurdere om det er på eller av. Det er litt mer komplisert å bygge et bra brukergrensesnitt på den måten. Det betyr at vi ikke har tilgang til dine end users, vi ser ikke sluttbrukeren. Og vi må da lage gode gooie rundt dette for å gjøre det forutsigbart hvem du ruller ut til. Og hvor vi ser at konkurrentene har starta med et motsatt utgangspunkt,

20:24 --> 21:12

hvor de ønsker å samle så mye data som mulig for å kunne vise deg hvem du ruller ut til, og må ha begynt å ta grep for å være mer forsiktig med hvilke data. Og gjøre det mer valgfritt om du skal samle en data. Vi håper jo at det er fordi vi gjør det annerledes, da. Jeg syns det er litt spennende å tenke på hvor Unleash kommer fra, Oda. For Unleash kommer fra Finn, skulle dekke utrulling i Finn av features. Da trengte man ikke å vite alt om sluttbrukerne der. Det er ikke en kommersiell avgjørelse som har gjort at man har denne arkitekturen. Det er det som var mest effektivt da vi jobba i Finn. Det gjør at det er ikke et valg som er der bare for GDPR.

21:12 --> 22:06

GDPR fantes ikke på den tida der. Det er sånn en effektiv feature toggle-løsning burde evaluere toggles, rett og slett. Tilbake til det tekniske. Hvordan gjør dere overvåkning når dere har 500 instanser? Hvordan passer dere på? Har dere også overvåkning av det som kjører i der det ikke er SAS? Ja. Jeg vil svare på del 1 først, da. Det er greit. Herved akseptert. Tusen takk. Victoria Metrics er konge, syns jeg. Da får du Prometheus som skalerer horisontalt. Vi har mye med trikker, som Ivar var inne på tidligere, og vi lagrer det i Victoria Metrics. Og vi gir Victoria Metrics litt minne og sånne ting.

22:06 --> 22:54

Og kjører dashboards, så når utviklerer ruller ut ... Hvis du skal passe på at du har fått ut til 300 deployments i release-channelen din, så er det slitsomt å lese, ikke sant? EU, BB48, ok, grønn der, osv., nedover. Da er det bedre å ... Å se på med trikker. Så vi har dashboards man følger med på når man ruller ut, og de inneholder da hvilken versjon kjører, hvor mange av den versjonen, hvor mange feillogger er det, hvordan HTP-statuser er det, og litt beskrivelse per graf på hva man skal forvente under en utrulling. Så det er kult å følge deployments med trikker.

22:54 --> 24:09

Og det samme har vi på alerting, ikke sant? Fordi kundene våre bruker en liten tid. Kundene våre bruker en leash veldig forskjellig. Noen har veldig mange toggles, noen bruker mye front-end-evaluering, noen kjører lastebiler med tjeneste på som dumper inn masse med trikker når de først får nett og den type ting. Så det er veldig forskjellige patterns. Så vi trenger mange alurter som er proaktive. Så vi får sånn: Denne kunden bruker ganske mye minner nå, kan vi få på dagtid. På dagtid-alurter på. Så begynner vi å se på den og bruksmønstere der. Og så har vi en annen ting som er 24/7-alurter, og det er sånn: Her restarter faktisk en pod, her har vi 500, den type ting. Så det er kult å kunne jobbe ordentlig med alerting i applikasjonen, siden vi kjører så mange av samme applikasjon. Så vi kjenner den rimelig greit nå. Det er et viktig poeng, for det er utviklerne selv som er med på denne. On-call-rotasjonen. Så vi har jo en egeninteresse alle sammen. Å både ha riktige med trikker, gode med trikker, og ikke feile med trikker.

24:09 --> 25:00

Så at de blir ringt midt på natta for noe som egentlig ikke er noe man trenger å ta midt på natta. For det er jo ikke så mange, verken i hele selskapet eller som jobber med plattform? Nei, absolutt. Vi er rundt 35 ansatte i selskapet, og så er vi tolv utvikla. Og så er vi tolv utviklere. Og så har vi ikke et eget plattformteam per se, det er en del av produktet og produktutviklingen. Så kommer det litt an på hvilke ting vi gjør. Når ... Sette opp Victoria Metrics, f.eks., er noe jeg kan gjøre ganske greit alene. Mens når vi skal lage en operator, f.eks., så samarbeider vi veldig med å ha flere utviklere med i den. Så det spørs hva som er spesielt for oss. Og hva er "read the docks on the internet"? Det er to forskjellige ting for oss.

25:00 --> 25:49

Så vi investerer sammen i de tingene som er core for businessen. F.eks. Release-channel-operatoren, det var en utvikler som for første gang skrev en operator. Og han gjorde det annerledes enn det jeg ville gjøre. Han skrev det i typescript. Oi, oi, oi! Den var spenstig. Men bruker da de SDK-ene fra Kubernetes for å snakke med Kubernetes API? Eller er det ikke en egen operator-SDK for det? Vi bruker vel API-en direkte, ja. Vi leser notasjoner, og så oppdaterer vi image på de forskjellige typene. Det var jo noen som laget plattform i typescript. Hver sin lyst. Hva med kostnader?

25:49 --> 26:42

Hvordan har dere koll på det, og hvordan optimaliserer dere for det? Med så mange like skulle man se for seg at det går an å bli mer effektiv ganske heftig. Absolutt. Bare for å være tydelig på det. Hvis vi skulle gjort dette ekstremt kostnadseffektivt, så ville vi ikke kjørt single tennet, altså én instans per kunde. Vårt mål er å selge til større selskaper hvor privacy ... Sikkerhet og skalerbarhet per kunde er viktigere. En skalerbarhet på tvers. Hvis vi skulle hatt millioner av kunder på denne plattformen ... Når er det planen at dere skal få millioner av gennomgang? I 2026? Da vil vi skrive om til multitenent applikasjon. Absolutt. Når det er sagt, så er det helt riktig

26:42 --> 27:28

at det er veldig mulig å optimalisere kostnader veldig mye. Vi har gjort mange grep. Vi har testa mye også på veien. Vi har kommet frem til at f.eks. det å kjøre om-demand-instanser for normal-last er lurt. For det er en del ekstra kompleksitet ved å ha alt på spot. Vi kjørte alt på spot en periode. Alle kubanetesnodene på spot. Det er krevende når du har to minutter på spot. Det er krevende når du har to minutter på å flytte all last til noe annet, når du plutselig får beskjed om at den noden skal dø! Vi har jo også Carpenter, som skalerer opp on demand, og det er kult. Men når vi har kjørt alt på spot før, så er vi jo ganske kule der.

27:28 --> 28:30

Men vi kjører også alt på arm. Og det har vært en reise med kull. Du har fått unlish til å kjøre på arm, men du har ikke fått unlish til å kjøre på arm. Men når du går på internett og henter Victoria Metrics, støtter arm ut av boksen. Alt støtter arm ut av boksen, så å si! Det er veldig overraskende, og det fungerer veldig bra. Det alene gir deg fort enn 20 % performance boost, bare ved å bruke arm. Men vi har ikke hatt så mange som har snakket om kubanetes på AWS. Hvordan har den opplevelsen vært ellers? Det er som før. Man tror jo at man skal få alt ut av skyleverandøren av ferdige løsninger, og så er det bare å skru på, og så kan du kjøre appen din. Det er jo ikke sånn ennå. Så vi har jo inngress i Traffic. En av utfordringene er at vi bruker NLB,

28:30 --> 29:19

og har måttet jobbe mye med det å registrere instanser inn der. Man kan ikke bruke det innebygde verktøyene egentlig for å håndtere inngress. Man må. Finne opp hjulet på nytt selv, lage strenge regler og sørge for at NLB-en aldri har unhealthy noder inni registrert, og at den tar ut ting ordentlig før du fjerner traffic fra en node, f.eks. Så det er vel det som skuffer meg mest med sky. At ingrace ... Det er fortsatt jobb å gjøre, liksom? Ja. I den forrige jobben hadde jeg noen veldig flinke folk. Jeg hadde bare hørt om alt de gjorde på det, og stolte fullt og holdent på dem. Og nå har jeg måttet investere i det.

29:19 --> 30:15

Du trenger mer undersåtter der du er nå? Ja, men det er mer imponerende hvor vanskelig det skal være med last i 2024. Så ellers så syns jeg ting er veldig greit i AWS. Sånn persistent volum. Har ikke hatt noe trøbbel med det. Det er veldig fint å kunne bruke. Veldig fint å kunne bruke Parameter Store for Secrets, fordi vi monter de inn i namespacene og har IEM-roller som gir tilgang til de. Og vi er jo et lite firma, vi kjører ikke upgrade i kubernetsklusterne, vi bytter de ut. Og da har jeg ingen state i et kubernetskluster som jeg injekter på noen rar måte. Og da er det kjempelett å kjøre to i parallell og så flytte over trafikken. Den infrastrukturen jeg ellers har på AWS, er den automatisert med TerraFarm?

30:15 --> 31:09

Ja, vi bruker Polumi. Det fungerer egentlig veldig fint. Veldig fornøyd. Så da er det bare å opp med nytt EKS-cluster i Polumi, og så er det rute om lastebilen? Eller få ting på applikasjonene opp og gå der? Det er jo litt morsomt av akkurat det du sier der, for måten vi oppgraderer. Kuberneteskluster. Det hender vi må oppgradere i Kubernetesk? Da har vi gjort oss noen erfaringer med hvordan det er lurt å gjøre. I Polumi har vi forskjellige lag. Vi har ett som er core-laget, som er nettverk og sånne ting. Og der laget over er EKS-clusteret. Og så har vi plattform og apps som ligger oppå der igjen. Og de lagene som ligger oppå EKS, de har støtte for ...

31:09 --> 32:01

For å ha to clustre, alled on new, samtidig. Sånn at vi bare enabler new. Og da vil den deploye plattformen til begge, i EU Central f.eks., og alle applikasjonene til begge. Da dobler vi antall ressurser i Polumi for en liten periode. Men da kan man se på det og flytte over trafikken gradvis og rulle tilbake. Da kan vi ha begge produksjonsclusterne kjørende i en uke, f.eks. Kjører du last mot begge samtidig, eller er det bare én av de som får ...? Vi kan, vi prøver å kjøre. Forrige gang bytta vi nettverk også samtidig, og da kjørte vi to NLB-er. Da hadde vi den kjørende ganske lenge, fordi det er DNS-lag og sånne ting i verden.

32:01 --> 32:53

Mens denne gangen kommer vi til å kjøre mye raskere, fordi vi kommer til å bruke samme NLB-en. Vi må være ute om hvor den peker til. Men da er alle unleashene også definert inn i Polumi-koden? I dag er det en av de tingene som vi har lyst til å forbedre i år. Vi ser jo at det blir litt mye. Og litt lite håndterbart, med tanke på også den veksten som vi har. Så vi tenker at nå er det på tide. Litt sånn som historien vår har vært òg. Vi starta ikke med Kubernetes, men vi endte opp der når vi kom på et visst nivå. Da vi var rundt 100 kunder, valgte vi å gå over på Kubernetes. Og nå føler vi at tiden er moden for å flytte kunder

32:53 --> 33:50

fra statisk konfigurasjon til mer dynamisk konfigurasjon. Vi har starta arbeidet allerede. Før definerte vi hele kunden i Polumi. Nå har vi kun navnet. Og hvilken T-skjorte-size det skal være, og eventuelle allow-listings. Så det er CRD-en som blir styrt av Polumi nå. Og planen vår er da å kunne ha et slags backoffice-verktøy. Hvor den CRD-en kommer fra det, istedenfor fra Polumi. Men vi har refakturert ut alt som var logikk som styrtes der, det er bare en CRD-en genererer nå. Når du skal opp et nytt cluster, hvordan ville du gjort det med å få ut selve CRD-ene på det nye clusteret? Jeg tror det kommer til å være en egen operator der,

33:50 --> 34:45

som egentlig bare poller fra etappe I, og så setter ut alle disse CRD-ene. Istedenfor å ha push, så flytter vi til pull. Cluster puller staten. Tenker jeg. Det er en kjent måte, jeg har jobbet med banker hvor de har hatt green-blue på clusteret og har en operator, gjerne flux, altså mer githubs-approach. Så når den starter opp, kobler den seg på et RPI eller et git og henter inn det som skal være. "Dette skal kjøre i dette clusteret." Så det er en veldig velkjent approach for å styre det. Ans Kristian er proose, rett og slett. Har vi sånn approve soundtrack? Men vi begynner å gå inn for landing, og da har vi jo et fast spørsmål som vi spør alle gjestene, og det er jo om de kan fortelle noe

34:45 --> 35:40

når ting ikke gikk helt etter planen, når noe feilet, og kanskje enda viktigere: Hva de har lært av det? Ja, det er jo tilbake til logging, da. Jeg husker en gang hvor vi dreit oss skikkelig ut på logging. Vår historie er at vi ikke flytter ting til plattform før vi må. Og jeg husker den gangen ... Du kan jo ikke fortelle det konkrete rundt hva vi gjorde. Ørn-Niesh er en applikasjon som logger svært lite på worn og error-nivå. Og så hadde vi en bug som gjorde at man logga mye på error. Og så logga Ørn-Nish direkte til Cloudwatch. Og Cloudwatch har noe som heter rate limit. Og hvis du ikke har håndtert den rate limitingen, så fyller du jo minnen din,

35:40 --> 36:33

og så dør poden til slutt. Så vi fikk masse poder som begynte å dø. Og fant ut at de døde fordi de prøvde å logge, og at vi ikke fikk logga pga. rate limiting i Cloudwatch. Så det var jo en incident vi hadde. Vi mitigata den veldig fort på å skru av logging. Og det gjorde at vi flytta fra at applikasjonen skulle ha ansvaret for å logge, til at den bare logger til standard out, og at vi da innførte fluent bit, som istedenfor Cloudwatch så brukte vi bare S3 direkte, og introduserte Loki. Så da har vi nå sentralisert logging i Loki, syv dager retention, og hvis du må ha noe lenger, så er det i S3. Det er veldig kjekt.

36:33 --> 37:28

Og da flytta vi den logikken fra applikasjonslaget ned i plattformen, som er bedre. Det er twelve factor app å logge standard out. Ikke sant? Det er utrolig gøy å høre. Dette er en teknologisuksess fra norsk teknologisuksess med Unleash. Egentlig har jeg lyst til å spørre om det er noe dere vil legge til, eller noe å fortelle om. Som kom veien videre, før vi avslutter. Vi kan jo begynne med det, Ivar. Ja, vi har jo kommet til en fase nå i produktet hvor vi begynner å se på en del spennende muligheter fremover. Og det vi jobber med nå, er å se på hele den livssyklusen fra ... Definere en feature toggel til den har på en måte gjort jobben, og få den både tydeligere, men også at vi kan hjelpe utviklerne i større grad med å forstå hvor de er på den reisen.

37:28 --> 38:22

Men også hjelpe dem opp med selve oppryddingen. Og det ser vi på, vi jobber med en del store selskaper. Når du har flere tusen utviklere som bruker en plattform som Unleash over mange år, så ser vi at det er ikke alle som er like flinke til å rydde opp dette her. Og det er jo klart at én ting er at du får veldig mange feature tog inni vårt verktøy, som fører til at vi må bygge noe kompleks funksjonalitet for å hjelpe deg å navigere inni Unleash. Men min store bekymring er alle disse kodebasene der ute, som har masse døde kodepater som aldri eksekveres i produksjon. Det er waste, det er stor risiko, og vi kan bidra masse til å hjelpe til med å rydde opp dette. Og det er noe som vi kommer til å investere ganske tungt i resten av året.

38:22 --> 39:18

Utrolig spennende, jeg har absolutt snakket til det å ha mye feature toggivninger! Hva med deg, Gard? På plattformsida så syns jeg jo at det blir veldig interessant å lage bedre backoffice. Vi har backofficen der nå, det er den som sørger for automatisering av databaseoppgraderinger og sånne ting. Men jeg gleder meg til vi virkelig får kontroll på det, og det kommer til å gi en del muligheter. Det er noen produkter som man kan legge på på plattformsiden. Jeg har snakka om allow-listing tidligere, men antakeligvis det å spinne opp edge-instanser rundt om i verden. Kanskje det kan være et oppsalgsprodukt som er inne i backofficen, som kundene kan ha tilgang til å kjøpe og spinne det opp.

39:18 --> 40:05

Den type ting syns jeg er veldig spennende òg. Så vi kan få til ganske spenstige ting i plattformen fremover. Det er veldig gøy å høre om. Her må vi bare benytte anledningen til å si at det er hjertelig velkommen tilbake igjen. Hvis noen av dere som lytter på har oppfølgingsspørsmål, så send de inn til oss, og så kan vi invitere tilbake igjen for oppfølging. Så tusen takk til Gard Rimestad og Ivar Østhus fra Unleash for at dere har vært med i studio i dag og delt med oss. Audun, har du noe høydepunkt fra denne episoden? For det første var det morsomt å høre om noen som hadde et litt annet plattformproblem enn det vi har hørt om før. Men jeg syns det er spesielt imponerende hvordan de klarer å vente

40:05 --> 40:43

med å lage plattform til det trengs. For det er kanskje enda viktigere i en vekstfase, som man er der. Men det å utsette det, og bare gjøre det når det er nødvendig, og da slipper du mye jobb, ser jeg for meg. Hva med deg, Jan Kristian? Å høre om low level Kubernetes-ting og med operators, og folk som lager operator for første gang, og hvor mye gutter og folk fra Unleash har klart å få til. Med å være så lite selskap og så få personer. Det er utrolig gøy å høre på. Det blir veldig spennende å følge med på videre.

40:43 --> 41:10

Dette har vært nok en episode av Plattformpodden. Mitt navn er som vanlig Hans Kristian Flåtten, og med meg har jeg Audun Fauka. Hva er Audun Faukas Tann, teknisk produsent er vår eminente 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 Plattformpodden-klistremerke fra Audun neste gang du treffer ham. Ha det! Ha det bra!