Hvordan fungerer Azure Database for PostgreSQL og Cosmos DB i skyen?

Azure Database for PostgreSQL er en fullt administrert tjeneste som tilbyr høy tilgjengelighet, automatiserte sikkerhetskopier og muligheter for skalering, noe som gjør den til et ideelt valg for kjøring av PostgreSQL-databaser i skyen. PostgreSQL er kjent som et kraftig, åpen kildekode-relasjonsdatabasehåndteringssystem som kjennetegnes ved sin robusthet, utvidbarhet og overholdelse av SQL-standarder. Azure tilbyr primært den fleksible servermodellen for PostgreSQL, som gir mer kontroll over databasekonfigurasjon og vedlikehold. Dette inkluderer muligheten til å definere egne vedlikeholdsvinduer og oppnå høy tilgjengelighet over flere tilgjengelighetssoner. Videre tillater denne modellen dynamisk skalering for å møte varierende arbeidsbelastninger.

Opprettelse av en Azure Database for PostgreSQL kan utføres via flere verktøy som Azure CLI, PowerShell eller Bicep, noe som gir fleksibilitet i hvordan databasen administreres og integreres i ulike infrastrukturløsninger.

Strukturen i Cosmos DB er hierarkisk med konto på toppen, som holder flere databaser. Hver database består av containere, som er skjemauavhengige lagringsenheter for dataobjekter (items). Disse dataobjektene kan være dokumenter, nøkkel-verdi-par eller grafnoder, avhengig av valgt datamodell. En særegen egenskap ved Cosmos DB er støtte for multimodell-API-er som SQL, MongoDB, Cassandra, Gremlin og Table API, hvor man ved opprettelse av en Cosmos DB-konto velger hvilken API som skal benyttes som lagringsmodell. Denne valget kan ikke endres i etterkant, men det er mulig for flere applikasjoner å få tilgang til samme database med samme API.

Global distribusjon er en av Cosmos DBs kjernefunksjoner. Data kan replikeres over flere Azure-regioner for å sikre lav ventetid og høy tilgjengelighet. Brukere kan enkelt legge til eller fjerne regioner og konfigurere lesing/skriving basert på behov. Plattformen støtter automatisk failover og multimaster-replikasjon, noe som gir både robusthet og høy ytelse. Cosmos DB tilbyr også fem forskjellige konsistensnivåer (Strong, Bounded Staleness, Session, Consistent Prefix, og Eventual) som lar utviklere balansere mellom ytelse og datakonsistens, avhengig av applikasjonens krav.

Det er viktig å forstå at mens PostgreSQL i Azure er en relasjonsdatabase med en strukturert datamodell som følger SQL-standarder, er Cosmos DB en NoSQL-plattform som tilbyr flere datamodeller og derfor passer til forskjellige typer applikasjoner. Valget mellom disse tjenestene bør derfor baseres på behov for struktur, skalerbarhet, global tilgjengelighet og type data som skal håndteres.

Hvordan innholdsleveringsnettverk (CDN) forbedrer ytelsen og påliteligheten for globale applikasjoner

CDN (Content Delivery Network) er en teknologi som reduserer latens og forbedrer brukeropplevelsen ved å cache innhold på servere nærmere brukerens fysiske plassering. I en globalisert verden, hvor applikasjoner og nettsteder må betjene brukere fra forskjellige geografiske områder, er CDN en nøkkelfaktor for å sikre at innhold leveres raskt og effektivt, uavhengig av avstand eller nettverksforhold.

En CDN fungerer ved å distribuere kopier av statisk innhold, som bilder, videoer og web-sider, til servere plassert på strategiske steder verden over. Når en bruker i Lagos ønsker å se en video, for eksempel, er det unødvendig å hente data fra en server i USA. I stedet vil CDN finne den nærmeste serveren, kanskje en i Vest-Afrika, og levere innholdet derfra. Dette reduserer ventetiden og forbedrer strømmeopplevelsen, da det er mindre buffering og forsinkelse.

CDNs er ikke bare begrenset til video. De forbedrer også leveransen av andre typer innhold, som CSS-filer, JavaScript og fonter, ved å cache og servere disse elementene fra en server nær brukeren. Dette reduserer belastningen på opprinnelsesserverne og bidrar til raskere lastetider for nettsteder og applikasjoner. I tillegg optimerer CDNs leveringen av dynamisk innhold som API-responser og tilpassede nettsider, og sikrer at også disse dataene når brukeren raskt.

Når det gjelder applikasjoner som krever store filnedlastinger, som oppdateringer for apper eller spill, spiller CDN en avgjørende rolle i å distribuere disse filene raskt til brukere på tvers av verden. For live-streaming er CDN avgjørende for å støtte tusenvis eller millioner av samtidige seere, uten å overbelaste opprinnelsesserveren. Dette skjer ved at CDN balanserer trafikken på tvers av flere edge-lokasjoner, som forhindrer at trafikken kollapser på en enkelt server.

Når det gjelder Azure, er det to hovedløsninger som kan brukes til å optimalisere innholdslevering globalt: Azure CDN og Azure Front Door. Begge fungerer som CDNs, men de har forskjellige bruksområder og optimaliseringsstrategier. Azure CDN er primært designet for statisk innhold, mens Azure Front Door er laget for å håndtere både statisk og dynamisk innhold, og tilbyr mer avanserte funksjoner som intelligent trafikkstyring og lastbalansering.

Azure CDN er perfekt for å cache statisk innhold som bilder og videoer, og reduserer behovet for å hente data fra den opprinnelige serveren hver gang en bruker ber om et bestemt fil. Når en bruker for eksempel ber om et bilde fra et nettsted, sjekker Azure CDN om filen allerede er lagret på en nær server. Hvis filen finnes der, blir den levert umiddelbart. Hvis ikke, henter CDN filen fra opprinnelsesserveren og lagrer den for fremtidig bruk. Denne prosessen kalles cache-opplading, og skjer gradvis etter hvert som innhold etterspørres.

Azure Front Door, på den annen side, er et globalt applikasjonsleveringsnettverk som kombinerer innholds-caching med intelligent trafikkstyring, sikkerhet og lastbalansering. Dette er spesielt nyttig når en applikasjon har brukere på flere geografiske steder og trenger en rask og pålitelig opplevelse på tvers av alle regioner. Front Door kan også omdirigere trafikk til den beste tilgjengelige backend-tjenesten, basert på helse-sjekker og lastbalansering.

Når brukeren sender en forespørsel, bestemmer Azure Front Door hvilken backend som skal håndtere forespørselen, basert på nærhet, ytelse og tilgjengelighet. Hvis innholdet kan caches, leverer Front Door det fra nærmeste edge-server. Hvis forespørselen krever sanntidsbehandling, blir brukeren automatisk omdirigert til en backend-server som er mest egnet til å håndtere forespørselen.

For en komplett implementering av Azure Front Door, er det nødvendig å sette opp et Front Door-profil, endepunkt og origin-grupper. Dette kan gjøres enten via kommandolinjeverktøyet eller ved hjelp av Bicep-skript, som beskriver infrastrukturen og hvordan ulike tjenester skal kommunisere.

Når det gjelder distribuering av innhold og applikasjoner på global skala, er det viktig å forstå at både Azure CDN og Azure Front Door er essensielle verktøy for å sikre rask og pålitelig leveranse, uavhengig av hvor brukeren befinner seg. Valg av riktig løsning avhenger av innholdet som skal leveres, og hvor dynamisk applikasjonen er. CDN gir fordeler for statisk innhold, mens Azure Front Door gir en mer omfattende løsning for applikasjoner som krever sanntidsbehandling og intelligent trafikkstyring.

Endtext

Hvordan oppretter og konfigurerer man en App Service i Azure ved hjelp av PowerShell?

Opprettelsen av en App Service i Azure er en grunnleggende del av moderne skybasert applikasjonsinfrastruktur. Det starter med å navigere til "App Services" i Azure-portalen. Her får man en oversikt over allerede eksisterende tjenester i gjeldende katalog. Ved å klikke på "Create" åpnes et veivisersystem hvor man spesifiserer alle nødvendige detaljer for å opprette tjenesten. Etter gjennomgang og validering opprettes tjenesten, forutsatt at ingen feil oppstår. Men i mange situasjoner – spesielt i profesjonelle miljøer – vil man ha behov for å automatisere prosessen. Her kommer PowerShell inn som et kraftig alternativ.

Et første skritt i PowerShell er autentisering mot Azure. Dette gjøres ved å bruke Connect-AzAccount, som lar deg logge inn i terminalen. Etter autentisering kan man opprette en ressursgruppe, for eksempel med følgende kommando:

powershell
Copy code
New-AzResourceGroup -Name SampleRg -Location EastUS

Dette oppretter en ressursgruppe kalt SampleRg i regionen EastUS. I praksis bør regionen velges med omhu basert på applikasjonens behov, juridiske krav og brukerens geografiske plassering.

Deretter opprettes en App Service-plan, som definerer prisnivå, ytelse og kapasitet. Eksempelvis:

powershell
Copy code
New-AzAppServicePlan -Name SamplePlan -ResourceGroupName SampleRg -Tier Premium

Denne planen ligger til grunn for selve applikasjonstjenesten. Når planen er etablert, kan man opprette applikasjonen:

powershell
Copy code
New-AzWebApp -Name sampleApp -ResourceGroupName SampleRg -AppServicePlan SamplePlan

Opprettelsen kan verifiseres gjennom portalen, eller med kommandoen:

powershell
Copy code
Get-AzWebApp -ResourceGroupName SampleRg -Name sampleApp

Disse trinnene representerer det minimale grunnlaget for infrastruktur i Azure, og viser samtidig hvordan man med få kommandoer kan automatisere en ellers grafisk prosess.

Skalering skjer på to nivåer: vertikalt og horisontalt. Vertikal skalering innebærer å oppgradere tjenesteplanen til en høyere tier, som gir mer CPU, minne og tilleggsfunksjoner. For eksempel vil en overgang fra Standard til Premium gi bedre ytelse og støtte for avanserte behov som tilpassede domener og SSL.

Horisontal skalering – det å legge til flere instanser – adresserer behovet for distribusjon av trafikk og last. Dette er spesielt relevant for applikasjoner som må være tilgjengelige uten avbrudd, også under plutselige økninger i brukermengde.

bash
Copy code
az webapp config appsettings set --resource-group SampleRg --name sampleApp --settings Environment=Production

Tilsvarende i PowerShell:

powershell
Copy code
$settings = @{"Environment" = "Production"}

Set-AzWebApp -ResourceGroupName SampleRg -Name sampleApp -AppSettings $settings

En av fordelene ved denne tilnærmingen er fleksibilitet. Endringer i miljøet krever ikke endringer i applikasjonskoden, noe som reduserer risiko og forbedrer vedlikeholdbarhet.

Et annet viktig aspekt er deployment slots – isolerte miljøer som lar deg teste nye versjoner av applikasjonen uten å påvirke produksjonen. For eksempel kan du ha en staging slot hvor du kjører ny funksjonalitet, før du "swapper" denne inn i produksjon. Dette gir en trygg og kontrollert rulleprosess.

Tilkoblingsstrenger representerer en annen sentral konfigurasjonstype. Disse brukes for å koble applikasjonen til eksterne databaser og tjenester. Et eksempel på å legge til en tilkoblingsstreng i CLI:

bash
Copy code
az webapp config connection-string set --resource-group SampleRg --name sampleApp --settings MyConnectionString="Server=myServer;Database=myDB;User Id=myUser;Password=myPassword;" --connection-string-type SQLAzure

Eller i PowerShell:

powershell
Copy code
$connectionStrings = @{"MyConnectionString" = @{Value="Server=myServer;Database=myDB;User Id=myUser;Password=myPassword;"; Type="SQLAzure"}}
Set-AzWebApp -ResourceGroupName SampleRg -Name sampleApp -ConnectionStrings $connectionStrings

Azure tillater kun bestemte verdier for connection-string-type, og det er viktig å merke seg at mange API-nøkler og tredjepartstjenester heller bør legges inn som vanlige applikasjonsinnstillinger fremfor tilkoblingsstrenger.