Hej og velkommen til den her ugegave af Allmors Aschere. Hej Nicolaj, og Michael. Godt at se dig. Goddag. Goddag. I denne her uge er det en speciel uge for Microsoft -gutterfans som os. Der er Ignite. Der er Ignite. Og jeg tror, det var din søns fødselsdag, men det er jo sådan noget andet. Ja. Tillykke til ham også. Han ser sikkert med derude. Det er bare han, der har at gøre. Ja, præcis. Ignite. Vi er lige midt i det nu. Hvad har været det fedeste indtil videre? Har der været nogle fede? Det er jo AI, all of our. Det er en stor omgang AI, du. Og vi står tilbage som cloud-infrastrukturpersoner. Der er ikke meget læggeri til os, er det der? Det du selvfølgelig skal huske på, omvendt alt det andet, det er jo noget, de bygger ovenpå det Azure, som vi elsker. Det er selvfølgelig rigtigt. De hælder database ind, der kommer mere sikkerhed. Det hele er jo Azure funderet. Ingen Azure AI service, uden noget data, der skal behandles og laves træning på, som ligger i noget. Ja. Der er altid mere... Og jeg synes jo også, at alle vores kolleger, der arbejder med udviklingen med database, og par om jeg, alle de der gutter og drenger og piger, vi har, de har jo lavet masser og masser af ting i Azure. Og så plejer de at ringe og sige, hvordan er det nu de der ressourcer der, og hvordan binder vi dem sammen, og hvordan... Ja, og det peger jo lidt ind, at vi skal snakke om i dag. Vi snakker app-modernisering. Ja. Og egentlig, så skal vi jo snakke modernisering, fordi det er det, alle vores kunder snakker om. Altså, når vi laver analyse omkring Azure, så starter vi i, ved at godt Microsoft, de kan gerne prøve at migrere hele skiddet, og det er også godt. Men alle gevinsterne, de ligger jo ved at modernisere det. Lige præcis. Der er mange, der har sådan lidt, uh, modernisering, det er en stor base. Så, men inden vi lige hopper over på den, så vil vi lige give et lille Ignite-fif. Ja. For vi skal nok snakke app-modernisering, vi snakker virkelig meget app-modernisering. Det vi snakker om før, vi har også vist, hvordan man kunne modernisere en app direkte via Azure Micrate, og vi lader en masse andre snakke, når vi snakker modernisering. Vi kommer til at snakke rigtig meget om modernisering i dag også. Meget på sådan et organisatorisk niveau. Ja. Men lad os lige tage og forestået Ignite'en først. Ja. Og det vil vi jo overstå ekstremt hurtigt, fordi vi stiller ikke om til Chicago eller noget fancy. Det må vi lade nogle andre om. Hvert år til alle Microsofts konferencer efterhånden udgiver de den her Book of News website. Det er som Microsoft Snack 2024. Der er også en for 2322. Der er også en for Build. Her kan vi gå ind og se, hvad de har frigivet af nyheder. nyheder, og den kommer egentlig på dag 1, tror jeg den her. Ja. Så den kom i går. Faktisk, der var det allerede mandag. Nå, der vil du bare se, ikke? Der er allerede bagud. Ja. Men her kan vi se alle de nyheder, der måtte være inden for de her forskellige kategorier. Og der er jo et rigtig stort slag på AI. Ja. Både på Co-Pilot og på Azure Open AI Services. Ja. En lille smule infrastruktur, ikke? Det er lidt småt med infrastrukturen, men en lille smule får vi. Men ellers så kan man bare gå ind i sin yndlingssøgemaskine og så skrive Azure, eller hvad hedder det, Microsoft Ignite Book of News. Ja. Og du får nogle fede links der. Man får nogle... Der er en masse links, ikke? Ja. Og så kan man dykke ned i det, man selv synes er interessant, og inden for de arbejdsområder, man sidder med. Ja. Så går jeg ind og kigger det ind. Nå. Modernisering. Ja. Hvorfor skal vi overhovedet snakke om modernisering? Der er jo nogle forskellige bevæggrunde, hvorfor det er interessant at modernisere sin applikation. Hvorfor var det interessant at gå fra pen og papir til at bruge en computer? Det var fordi, vi kunne pludselig gøre tingene hurtigere, ikke? Mhm. Hvorfor er det interessant at gå fra den ene software -arkitektur til den anden software-arkitektur? Hvorfor er det interessant at gå fra sine OS-services på Windows-server eller Linux-server til nogle services i Azure? Det er jo lidt de samme bevæggrunde stadigvæk. Men problemet er jo, at der er jo mange af dem. Fordi der er mange, der snakker. Egalitæt. Det er sådan noget flot nåde, de snakker om på direktionsgangene også. Så er der flere, der snakker om penge, fordi det er jo sådan noget, hvor vi ikke kan klare om at bruge det. Det er også noget flot nåde, nogen snakker om. Ja, men altså, de ved ikke, hvad det koster nu i hvert fald. Men vi kan regne ud, hvad det koster i Azure. Ja. Så er der nogen, der gerne vil snakke sådan noget cloud nature. Vi kan gøre en hel masse smarte ting. Ja, og hvorfor skal vi det ikke? Ligesom er det, vi så skal snakke om nu i dag. Så man kan sige, at bevæggrunde for at lave de her moderniseringer er jo tit noget med noget time to market. Noget allergivitet. Hvor hurtigt kan jeg ændre på noget af det, jeg har kørende for at opfylde nogens krav. Min egen organisations krav. Mine kunders krav. Borgerne i kommunens krav. Hvem det nu måtte være. Det er jo en ting, ikke? En anden ting er jo skalerebarhed. Hvordan skalere det her? Hvor skal jeg have høj skalerbarhed? Har jeg nogle peak perioder, hvor jeg skal have meget skalerbarhed? Det er også en anden faktor, der spiller ind i forhold til det her. Ja. Så er der noget i forhold til sikkerhed og sådan noget reliability. Altså oppe i tid på mine systemer. der er jo ingen tvivl om, at vi har jo også hørt til at tale om platformen. Ja, det er vi snakker om. Men den fylder meget for mange, at de forventer egentlig noget bedre godt med. Der er vi noget til. Ja. Forventer og forventer noget bedre godt med. Ja. Bedre styper sikkerheden. Bedre styper sikkerheden. Og faktisk også bedre reliability. Altså at tingene kører, de er oppe og de virker. Ja. Jeg havde et møde i går med en kunde, som sad i nogle områder i Tyskland, som kunne være ramt af noget overfømmelse. Og der snakkede vi netop om det her reliability og disaster recovery og hvordan kan vi bruge det her. Det er så ikke så meget om app-modernisering snakken, men det er jo igen, hvis vi har vores app bygget et sted, hvor de har taget højde for de her ting. Ja. Så er det jo plus. Altså så er der også noget i forhold til, det bliver jo lidt noget fluffer, ikke? Sådan noget effektivitet og hvordan måler vi effektivitet. Men det er jo noget i forhold til, du som udvikler, hvilke værktøjer har du til rådighed, hvordan er du mest effektiv i dit arbejde, ikke? Og din deployment, din releases, din testing og alle de værktøjer, du bruger. Men der jo indfylder mig, at egentlig dem vi møder mest derude, det er jo den med, at vi mangler hænder. Der er simpelthen for få IT-folk. Der er alt for få, ja. Og det vil sige, at dem, der har passet server, der er jo nogen, der har bare sat deres service til host, og så har de sparet noget tid. Men der bruges stadig masser af tid på at drive infrastrukturer. Så det er jo meget det, de kom med, at vi vil gerne have frigidt nogle hænder. Vi vil gerne have skabt nogle udviklere, uden nogle folk, der ikke udvikler i dag. Ja, helt klart. Og vi vil jo gerne prøve, altså der er jo et vis overhead i al den her infrastruktur, selvom vi elsker infrastruktur. Så er der stadig noget overhead i den her infrastruktur, hvor vi gerne vil prøve at have et større fokus på vores leverance, den service, vi nu til veje bringer. Vi har jo for vores kunder, vores partner, vores borgere, hvad end det er, ikke? Det er den, vi skal have sat i fokus. Så lad os prøve at barbere alt det over flødet i fedt fra, og lader nogle andre håndtere det. Og så sætte vores udviklere fri til at have fokus på at levere nogle services. Det kan den her app monisering, og det er jo noget, det cloud kan. Det er at skære alt det rundt om, for nu er det nogle andre, der varetager det. Og det kan vi prøve at komme med nogle tekniske eksempler på. Ja, så det handler meget om det der med, at den lidt skjult effekt er, at alt det, der får jeg ikke, for det meste er jo leveret som service. Det vil sige, at der er en masse ting, du ikke skal tage dig i. Yes. Så hvis vi har styr på governance gennem en platform og nogle policies og nogle ting, og det er helt en service, jamen så kan du netop det der med enabler nogen, sætte nogen fri i. Vi håber vi i gang med at bygge den her egen business-applikation. Bygge den forretningslur, som skal understøtte forretningen i at sælge flere frosne ærter. Ja, lave en lækker kundeportal. Lave en lækker, hvor man kan købe noget andet end frosne ærter måske. Det er bedre eksempel. Det kan jeg ikke. Det er også lige meget. Men så er der hele den her hurdle, når vi skal snakke om app-modernisering. Fordi det er fint, at vi siger, at vi skal modernisere vores app. Vi har en client-server-app i kælderen, måske med noget data et eller andet sted i noget SQL, og den vil vi gerne modernisere. hvordan kommer man i gang? Hvad skal man gøre? Hvilke værktøjer har vi? Hvilke sprog bruger vi? Hvilke frameworks inden for de forskellige sprog er rigtige for os? Så er der et vildt af spørgsmål, der pludselig dukker op. Jeg har lidt på fornemmelsen, når vi dukker ned i det. Det ville jo være nemt, hvis det bare var et svar. Men jeg synes, hver gang vi dykker ned med nye kunder, så er der nye forhængninger eller nye muligheder. Ja, så det handler virkeligheden rigtig meget om at finde ud af, hvordan vi gerne vil arbejde med det her som virksomhed. Hvordan vil vi gerne som udviklere arbejde med den teknologi, som vi kan vælge nogle teknologier, der kan understøtte de krav, man har. Om det så er fullstack, C-sharp, eller om vi har noget React frontend, eller om vi er et jævahus, og det vil vi fortsætte med at være. Fordi de valg, du så træffer, det er jo så med til at vælge også, hvad for nogle services, og så de rigtige services i Azure. Jamen jeg synes bare tit, at jeg får modstander ud. Jeg er med på, at vi tit bliver bedt om det der med, at vi skal have defineret arkitektur. Og med det mener man jo tit, hvad er det for nogle værktøjer, vi bruger, hvad er det for nogle frameworks, vi bruger, hvad er det, vi bygger, hvordan bygger vi. Men jeg kan også lige sit mærke, så er der nogen, der synes, okay, vi er ikke så vilde med at bruge container, eller vi er ikke så vilde med at bruge C-sharp, eller så får vi sådan en. Så er der nogen, der støder sig på det, ikke også? Jo, og det er jo så en eller anden kultur, som man skal arbejde med, ikke? Fordi, hvor er det, vi gerne vil hen, ikke? Og man kan godt sidde sådan her, ikke? Ja, ja. Og jeg ved simpelthen ikke, det kommer man jo ikke nogen vegne af, vel? Nej. Men igen, hvis man nu er glad for det, man har, så skal man jo ind og arbejde med hele det her, den her snak omkring, hvad er det, vi får ud af det, ikke? What's in it for me? Hvad er det, og hvad er det, hvad er ligesom fordelen for forretningen ved, at vi laver de her indringer, ikke? Og der skal være nogle helt klare målepunkter for, hvad er det, vi håber på at opnå med den her modernisering? Ja. Så man kan se noget værdi i det, fordi vi skal ikke bare ændre vores clientserver til en microservicearkitektur og så hurra. Nej. Hvad er det, vi vil opnå med det her? Ja. For så har vi bare spillet en masse penge, og så har vi bare en anden arkitektur. Ja. Men hvis vi så arbejder med den på samme måde, så har vi jo ikke vundet noget. Så dem, der sidder sådan her, dem skal vi have... De plejer også at være fornuftige mennesker, der lytter til gode argumenter. Og fornuftige, så er de pludselig gør sådan her. Ja, men det er jo helt rigtigt. Det er jo faktisk nogle mennesker, der ved noget, og de er passionerede omkring noget. Så de bare vil gerne vide, hvorfor vi vil have det ene eller andet. Ja. Og måske er der heller ikke et svar på det. Fordi det er jo også det lidt, du siger. Ophængig af, hvad du vil, så er der måske nok forskellige svar på det. Yes. Fordi jeg synes jo også, at uden at foregribe, at der er nogen, der siger med, der skal vi ikke bare putte den her is over med det der ind i en container, og det er så det. Er det så moderniseret? Nej, men det kan køre i cloud. Nej. Ja, vi kan være, at vi er nogen skridt på vejen. Fordi nu undergraver måske også noget af vores eget arbejde i den her udtalelse. Men nogle gange, så er det jo dårlig praksis at have en VM i cloud. Så bruger du cloud forkert. Men vi laver også rigtig meget lift-and-shift-migræng, og vi flytter rigtig mange VM'er til Asia. Fordi der kan være en bevæggrund, hvorfor man vil have de VM'er væk fra der, hvor man er. Det er en helt anden snak. Det har vi taget i nogle migreringssnak. Så se med i det andet afsnit. Fordi vi skal jo bruge de services, der er i Asia. Vi skal jo ikke bruge VM'er. Vi skal bruge de services rigtigt. Det kommer vi lidt ind på lige om lidt. Men hvad er applikationsmoneteringen og hvorfor? Det har Microsoft et bud på igennem cloud adoption framework og nogle andre ting. Lad os lige scrolle igennem en hjemmeside, for lige at se, hvad deres tag er på det. Her er et lille link. Det kan vi godt sende ud. Hvad er det, vi skal til højde for i nogle overskrifter? Hvad betyder den her app-modernisering i forhold til cloud computing og modernisering af nye værktøjer? Målet er ligesom at forbedre vores firma igennem teknologien. Altså vi skal være mere effektive. Vi skal kunne spare ressourcer. Vi skal kunne tilbyde en bedre service, så vores kunder køber flere frostende ærter og hele den her snak. Forstå, hvad det er for noget, hvad vi kommer fra og hvor det er, vi gerne vil hen. Og hvad det er for nogle applikationstyper, vi oftest moderniserer. Det kunne være .NET-applikationer, Linux, Web Apps, Java Apps eller andet. Og noget SQL. Det, vi har lidt været inde på i forhold til, hvad er fordelene ved den her app-modernisering. Og så lidt omkring at bygge den her applikations-moderniseringsstrategi. Hvad er det, vi skal tage højde for, når vi begynder? Og hvad er det, der er faldgrupperne, når vi begynder at modernisere? Og det er jo lidt forskelligt i de her kasser i forhold til det her well-architected framework, det vi snakkede om før. Hvad er vigtigt for nogen, kan være vigtigt for nogen andre. hvor alle de, jeg snakker om rigtig mange softwarefirmaer, ISV-firmaer. Og der er noget af det, der er allervigtigst, det er at komme over stæberne og det pris. Og så kan det være, når jeg snakker med en uge, at så er det noget som operational excellence og security og real life. Så er det nogle andre ting, der er en vigtigere faktor. Koster altså en faktor. Men igen, hvis du ikke har så mange penge, så er det endnu større faktor. Men det er klart, hvis du har sagt, at der for at være en mere digital virksomhed, vil have en meget bedre digital oplevelse for vores kunder, og har en til 10 udviklere, så er det kostet måske ikke det vigtigste selv. Så vil vi bare have noget, der spiller. Så skal vi have et miljø, hvor de bare kan slås løs. Vi kan få lavet nogle fede løsninger. Og du behøver ikke stå af i på alt, men hvis du så vil putte den af i, så er det fedt, hvis du også kan det. Ja, det behøver bestemt ikke stå. Det kan man altså også blive lidt trædt. Men Microsoft har også nogle rigtig gode links i forhold til at tage den her snak om, hvilke steps skal jeg igennem i min app-modernisering i forhold til det her cloud adoption framework, hvilke strategier er der, jeg kan arbejde med, og det linker også videre til det her cloud adoption framework. Og så er I jo et væld af forskellige virksomheder derude. Nogen er i manufacturing-forretning, nogen er i health, nogen er governmental og kommuner, og vi har retail og andre forretninger. Og I arbejder med IT forskelligt. Nogen har store udviklingsafdelinger og gør ting selv, fordi de har et produkt. De er en... Vi snakkede om det her, inden vi gik på det her med, er du en supermarkedskæde, eller er du en softwarevirksomhed? Du er i virkeligheden begge dele, ikke? Jo, altså der er ingen tvivl, men de fleste begynder at sige, at vi er også en IT-virksomhed. Selv dem, der bare kører lastbiler, det er også en IT-virksomhed, fordi de er mere effektivt og bedre til at køre lastbiler, ikke også? Ja, og så har vi de her kunder, hvor vi ser, når man snakker på kommuner eller andre statslige organer, men de er også i virksomheder, ja, det er de, men de er måske også mere afhængige af at købe nogle services ud i byen. Og det kommer tilbage til de her 6 A'er, vi også har snakket om med Rehost Replatform, fordi nogen har styr på alt selv, fordi de er dem, der har bygget løsningerne, og nogen er nødt til at udfordre nogle leverandører til at modernisere deres løsninger. Ja, og så er vi igen ude i det der, nu er det kan altså godt tage noget tid, og så er det nødt til at finde, hvor du vil fokusere henne. Ja, lige præcis. Gør det hele på en gang, vel? Så. Check. Check vi den, ikke? Check vi den. Så hvis vi nu forestiller os, at vi har prøvet diskuteret, nu vil vi gerne modernisere, hvorfor vil vi modernisere? Hvad er det, vi gerne modernisere? Hvor starter vi henne? Okay. Hvad så? Ja, hvad så? Hvad så? Altså, vi skal jo finde ud af, hvordan vi gerne vil modernisere her. Det kræver, at vi kan klæde vores udviklere, vores infrastrukturfolk, der måske skal lære at bygge infrastruktur på Azure, hvor vores udviklere også skal lære at bygge infrastruktur på Azure, men også kan begynde at arbejde med deres source code, så den kan deploys på Azure. Og det kræver jo virkelig en indsigt i, hvordan Azure fungerer, hvilke værktøjer er det til rådighed, hvilke services er det til rådighed. Det kunne være, at det her var noget certificering ind på løn, Microsoft, og begynde at lære noget om alle de ting, vi snakker om her også, om BICEP, om de forskellige services, hvordan containerization på Azure, hvad betyder det, og hvilke services finder der, hvilken service skal jeg bruge for at bygge min navigation? Så der er ingen fylde om, at det gælder egentlig både for udviklere, og de driftfolk, der nu skal være med til at drifte på en anden måde, du er altså nødt til at sætte dig ind i nogle af de her nye teknologier. Ja. Og du er nødt til at sige til din chef, at du skal have lidt tid til at lege med nogle ting, og du er nødt til at øve dig på dem, hvor du kan lære på kænden. Lige præcis, og det er jo det der med, altså jo, hvis du ved, hvilke værktøjer der er til rådighed, så har du en bredere palette af muligheder, og kan ligesom stå bedre stille, måske en enkelt arkitekt, men jeg fornemmer tit, at der er ikke arkitektresurser nok, der er udviklerne. Så udviklerne er også nødt til at være lidt arkitekt, og de er nødt til at vide noget om, hvilke værktøjer de skal bruge. Ja, og lidt nødt til at vide, hvordan tingene hænger sammen, og det gør de fleste udviklere, jeg har snakket med jo også i stor stil, inden for det område, de ligesom arbejder i. Så skal man bare ligesom prøve igen, at delegne sig ny viden, et nyt område, men med den store ballast, man har som udvikler, i det man allerede ved i forvejen. Fordi det er en anden måde, at lave development på, og release. Nå, altså hvis du har lavet versionsstyring engang, med noget Teams her, nu skal du gøre med DevOps, det fandt ud af, jamen altså, de fleste kan jo tage nogle små skridt fremad, at putte nye teknologier på, det er jo ikke sådan set det, der er problemet. Problemet er bare, at for mange af Azure er sådan lidt en stor, og grå voks af de her søgerbind. Ja, ja, helt bestemt. Og alle udviklere er vant til at bruge, sådan noget som Git Source Controlling, alle udviklere er vant til at bruge rigtig mange af de her værktøjer, men så hvordan får vi det så op i Azure og flyve? Vi kender også til Container Association, jeg kan godt bygge en container, jeg kan godt køre den lokalt, jeg kan også godt køre den et andet sted, måske har jeg et Kubernetes cluster on-prem, men hvad er så smart, og det skal vi lige prøve at dykke lidt ned i, for nu har vi, det er vi nu tilbage, så nu går vi i gang. Okay, så lad os lige prøve at tage den her. Microsoft har en lille flow, også inde på deres kaffe, det er faktisk inde på deres arkitekturcenter, man kan finde den her. Det er valg af Compute Stack, hvad skal jeg? Lad os tage den nemlig, skal jeg migrere noget? Og on-prem, det var det, jeg nævnte, det laver vi rigtig meget af. Er det en lift-and-shift migrering? Ja, det laver vi rigtig meget af. Kan den blive containerized? Nej, det kan den ikke. Nå, er det en købt applikation ude i byen, det her? Ja, det er det. Men så skal den nok ned på en VM, fordi det er det, vi nu kan. Og så ved vi, det virker. Så kan det være, det er det ikke, så kan det være, vi kan gøre enkelte ting, hvor vi så måske kan smide den på en app-service eller noget Spring-app, som er så Java Spring Boot. Som også kan være containerized. Er den allerede cloud-optimized, der vi gerne migrere? Ja, det er den. Så kan vi begynde at kigge på nogle af de her services. Men hvis vi skal bygge noget nyt, skal du have fuld kontrol over alt, så skal du have adgang til hele OS-stacken. Ja, indslører det bare en 725, og så bare, ja. Så ruller du den, så arkenaber du den, og så kører du bare 10 tommelfingere op. Men lad os så stille runde, som vi kommer ned i stacken her, så begynder vi mere og mere at kunne svare på, om det er et high-compute workload, er det event-driven, skal det være managed webhosting, og så stiller det ned, så til sidst rammer vi, noget mere af sådan nogle microservice-drevet ting, skal det være familiar with service fabric, ikke? Ej, det er der snart ingen mennesker i verden, der er efterhånden længere. Og beklager til dem, der sidder derude og bruger Azure Service Fabric, men altså, det hedder jo Kubernetes-hånden det, ikke? og så kommer vi ned, når man, skal du bruge, skal du bruge Red Hat OpenShift, ikke? Skal du bruge Kubernetes-app-hid, skal du have adgang til klosteret? Ja. Ja eller nej? Og nej, så ender vi ned i den her relativt nye service, Azure Container Apps. Ja. Og det er den, vi lige skal kigge lidt på. Lige om lidt. Så det er ligesom sådan en rimelig simpel guide til at tage et valg igen, men man skal jo vide, hvad de forskellige kasser sådan betyder, som man siger. Så når jeg stiller spørgsmålet Managed Web Hosting Platform and Features, så skal jeg jo kunne svare ja eller nej på det, og det kræver, jeg ved, hvad den her Azure Apps Service, den indeholder, ikke? Ja. Og hvad den kan, og hvad er kravene fra min forretning og mine bruger. Men så må jeg så sige igen, altså, vi har jo også tidligere vist, at der findes jo faktisk nogle vedheder, der kan prøve at hælde noget. Hvis du har en nye service, prøve at hælde tingene over, virker det, gør det, jamen så, okay, det kunne vi så godt. Ja. Og hvis du skal bygge nyt, og vil gerne tilegne dig noget viden og have noget inspiration, så er der den her Azure Architecture Center, hvor man kan gå ind og få nogle referencer, arkitektur og design, så man har noget længe så opad. Ja, og håndsvist, jeg kom godt i gang over tutorials og quickstart og så tænker jeg, altså, du kan bare kaste noget i kodet. Bare give den fuld skrald, ikke? Nå, men snu webapps, det er svaret på alt. Eller containerapps. Vi gider slet ikke snakke webapps. Nej, containerapps. Så lad med det. Ja. Nu vil vi gerne snakke, altså webapps kan faktisk også køre containerization. Du kan også køre containerized webapps. Både Linux og Windows container. Nu snakker vi Azure Kubernetes Service og Azure Container Apps. Så er der nogen, der kan købe, altså der kan vi, der er vi på Linux container, i hvert fald på container apps. Så her har vi sådan, igen tilsvarende, at vi har valgt, at vi skal være noget microservice-orienteret. aktiviteter. Og så kan man sige, hvad er det bedre end en monolith, og er monolith bedst, og det bliver sådan en regionslåskamp, fordi der er fordel og ulemper ved det hele. Så lad os lade være, at master det. Det hele skal vi lige holdes, og det kan være lige kompleks i virkeligheden. Du er dygtig, kan vi måske have flere, der arbejder siddelygtende med flere ting måske. Ja. Ja. Så her, der snakker vi lidt om, er der behov for noget dedikeret compute, eller skal vi køre serverless, eller skal vi have noget containerized microservice. hvis vi ikke er containerized, så hedder det svaret Azure Function. Er vi serverless og containerized, så hedder det svaret Azure Container Apps. Og igen, skal vi begynde at arbejde med det her, er der behov for GPU? Der er faktisk lige kommet noget, jeg mener, det er lige kommet noget GPU til Azure Container Apps også. Så det er også det, den skriver her. Så igen, vi kommer til at have et lille fokus på Azure Container Apps i den her lille modernization demo. Azure Container Apps er en pæs service, som er på år gammel, og hoster en Azure Kubernetes Service. Okay. Igen, masser af lag væk. Masser af lag væk, og så har vi en masse interfaces ind i vores container apps, som vi er vant til, når vi snakker Kubernetes. Om det så er on-prem, eller det er Azure Kubernetes, eller en anden cloud provider. Yes. Det er sammen. Yes. Det er sammen. Godt. så lad os prøve at tage et kig på den løsning, vi har lavet, fordi det, jeg har gjort, det er, at jeg har forket et repository for Azure samples. .NET frontend to backend on Azure Container Apps. Så det er sådan en rimelig simpel frontend med backend services. Hvis vi kigger på arkitekturen her, så har jeg en store. Vi kan åbne den og gøre den lidt større. Så har jeg en store frontend, og jeg har to. Jeg har et product API og et inventory API i backenden. Ja. Når vi arbejder med container apps, så har vi det her container app environment. Og et container app environment beskriver det kloster, vi har vores apps i. Så det skal forbindes et v-net og have nogle IP-adresser og nogle forskellige ting og grupper og sådan nogle ting. Men vi kan faktisk automatisk her vælge, om det skal være container app environment, der styrer vores ingress, eller om den er publicly available. så det er faktisk at klikke på en knap, at jeg kan gå ind og sætte de her products og inventories i. Dem må du kun kommunikere med internt. Til gengæld den her store, dem må du gerne have noget ingress trafik fra internet. Så det vil sige, at jeg kan kalde storefronten, og storefronten kan kalde vores backend, men jeg kan aldrig kalde backenden, hvis jeg ikke er i det her app environment. Ja. Tjek. Så det er en ret hurtig lavpraktisk måde at lave noget segmentering, noget netværkssegmentering af mine services. Og så har du ikke en container ind i den. Så er det bare derude af. Så har jeg deployet nogle container ind i den her løsning. Og det er jo så den, vi kigger ind i. Her. Supermoden. Ja. Og inde i Supermoden appen, der er nogle supportive ressourcer, vi har her, med noget mannest identity til at lave adgangen, primært til vores container-regi, hvor vores images ligger. Og så har jeg for eksempel min store container-app. Så det man vil se her, at meget af terminologien er den samme, når vi arbejder med vores Kubernetes-cluster on-prem. Vi har, vi referencer et eller andet image, vi har nogle environment-variabler, vi har de samme health-probe-typer, startup, readiness og liveness-probe, som vi kender fra Kubernetes. Så her har vi bare et interface ind imod klusteret. Så det er ikke alt, vi kan. Vi er meget begrænset på fx netværksdelen og hvordan vi ruter ting og får adgang til nogle. hvis vi skal have adgang til noget OS i Linux eller Windows, så er vi jo også begrænset i det. Jo, jo. Vi kan skalere den her til rigtig mange replikærer, men den kan faktisk også skalere ned til 0 og koster så ikke noget jo. Så den ikke kører. Det gør jo så, hvis vi begynder at have noget, der kun er tilgængelig en gang imellem eller noget, der kun kræver en kørsel i gang imellem, så kan vi skalere den ned til 0. Vi kan også skalere den ned til 0 og så snart jeg får en HTTP-request, som er den måde, jeg skal skalere på, så starter den op. Men det gør jo så, at den første kunde får måske en dårligere oplevelse inden de næste, fordi den lige skal varme op. Hvis det nu er en skalærvej, hvis du havde to, altså de i Svindighederhus, så koste de 30 kroner om måneden, de små af dem, så det er ikke nogen store ting. Nej. Altså en kører, der lige holder i lidt øje. Nej. En minimum, det lærer man jo at kende, når man laver load-testing og sådan nogle forskellige ting på en system. Asher. Load-testing kunne være et godt produkt til det. Så finder vi jo af, hvor mange replikas skal vi have i forhold til vores minimum load her. Det kunne man også sætte en alarm op, hvis du mangler den. Det kunne man også. Og vi kan lave en masse forskellige måder at lave de her skalering på. Det kunne være antallet af requests, der kommer ind. Det kunne være en AsherQ eller noget helt andet, vi vil så gerne skalere på. Fit. Men jeg synes, det smarte i den her service, kontra meget andet, det er jo, og det smarte ved clusteret, eller den her container app, det er, at vi skal ikke hoste det her cluster. Jeg skal stadig vide lidt om, hvordan et cluster fungerer, fordi det er jo det, jeg interagerer med, når jeg laver min skalering her og mine prober, så jeg skal stadig vide lidt om det, men jeg skal ikke mandes det her cluster. Nej, fordi dybest set så har du bare ikke sådan en container, der kan se hinanden og fungere som enhed. Mig som udvikler, er det her jo super nemt at komme i gang med. Og det er nemt, og fordi vi arbejder med replikager, så laver den hele tiden, så skalerer den de replikager, vi har. i stedet for, hvor det er for eksempel en web app for container, så er det en ny instans hver gang, så vi får sådan et lidt for stort computer, end vi måske har behov af. Og så vil jeg lige vise det her ingress trafik, som gør det super nemt, og altså det er vidderligt at sige, den her, den må tilgås alle steder fra. Det kan jeg så yderligere IP-restricted, hvis jeg vil det. Yes. eller den er limited i det her miljøgrunde. Og nu hørte jeg jo noget i radioen lidt tidligere i dag, så gammelig af, jeg lytter til radioen, om at der er en bank, som er fuldstændig lagt ned af det også. Kunne det jo være, at man skal lige have noget frontdoor, eller noget foran? Det her, det er jo ikke nok i sig selv. Når vi går i produktion, så skal vi lave nogle sikkerhedsforstigninger. Det er også protection, måske med frontdoor, af nogle andre ting. Måske vil vi gerne have noget geolocation, blocking og sådan nogle ting på det her. Ikke, at det løser problemet nødvendigvis, men sammen har vi haft nogle foranstaltninger. Nu skal man jo ikke close sig på for meget på det, der sker derude. Det er en anden broadcast. Ja, det er et helt andet medie. Så det her er for at sige, at her er der faktisk noget, der er super nemt at komme i gang med for en udvikler. Og jeg har en frontend her, der viser nogle produkter, og de produkter har den hentet i mit product-API, og mit inventory har den så hentet i mit inventory-API, hvor mange har jeg af dem. Så det er super simpelt, og det var super simpelt for mig at lave noget bicep, fordi det kunne jeg. Ja. Og så var det super simpelt for mig at have min abduktion og pakke den som en dockerfil og puste den her ud. Man kan også bare ligge i portalen. Man kan også finde den sample her, og så begynde at lære noget på den sample. Så bare lege. Og så bare lege. Bugner til i juleferie. Og så bare lege. Container.