# Molntjänster förklarade: de 11 arkitekturkoncepten du måste känna till (4K Masterclass).

Published: 2026-09-15

De flesta mjukvaruingenjörer försöker lära sig molnarkitektur genom att memorera hundratals leverantörsproduktakronymer från AWS, GCP och Azure. Men verklig molnteknik bygger på elva grundläggande arkitektoniska primitiver. I denna 4K remaster masterclass bryter Niko ner den kompletta företagsritningen: från vertikal kontra horisontell skalning och Layer 7 belastningsutjämning till dynamisk autoskalning, serverlös mikro-VM-exekvering, asynkron händelsestyrd frikoppling, containerorkestrering, den fyrpelariga lagringshierarkin, den kritiska skillnaden mellan hög tillgänglighet och 11 nior av hållbarhet, deklarativ infrastruktur som kod och Virtuell Privat Molnnätverk. Bemästra dessa elva koncept, så kan du arkitektera vilken backend som helst i produktion. Bedömning: SHIP IT.

Canonical: https://thedailydiff.dev/sv/video/2026-09-14-cloud-computing-explained-4k/

## Vad den här videon täcker

- - Arkitekturväggen och Huvudritningen
- - 01. Vertikal vs. Horisontell Skalning
- - 02. Belastningsutjämningsarkitektur (L4 vs. L7 & Hälsokontroller)
- - 03. Autoskalning & Elasticitet
- - 04. Serverlöst (FaaS & Firecracker MicroVMs)

## Kapitel

- 0:00 - Arkitekturväggen & Huvudritningen
- 0:57 - 01. Vertikal vs. Horisontell Skalning
- 2:17 - 02. Belastningsutjämningsarkitektur (L4 vs. L7 & Hälsokontroller)
- 3:45 - 03. Autoskalning & Elasticitet
- 4:50 - 04. Serverlöst (FaaS & Firecracker MicroVMs)
- 6:05 - 05. Händelsestyrd Arkitektur (EDA & Frikoppling)
- 7:13 - 06. Containerorkestrering (Docker & Kubernetes)
- 8:16 - 07. De 4 Molnlagringspelarna (S3, EBS, DBs & Redis)
- 9:44 - 08. Hög Tillgänglighet & Niorna (Multi-AZ Failover)
- 10:53 - 09. Hållbarhet vs. Tillgänglighet (Varför 11 Nior Inte Är Uptime)
- 12:14 - 10. Infrastruktur som Kod (Terraform vs. Konsoldrift)
- 13:20 - 11. Molnnätverk (VPC, Subnets, NAT & Säkerhetsgrupper)
- 14:26 - 12. Den Kompletta Företagsritningen & Bedömning

## Översatt transkription

Översatt från den ursprungliga engelska berättelsen. Tillgängligt ljud och undertexter styrs av YouTube.

### - Arkitekturväggen & Huvudritningen

0:00 Varje mjukvaruingenjör står så småningom inför molnarkitekturväggen. Du bygger en applikation på din laptop, pushar den till produktion, och i det ögonblick riktiga användare anländer, kraschar servrar, databasanslutningar tar slut, och din AWS-räkning ser ut som ett telefonnummer. De flesta utvecklare försöker lösa molnteknik genom att memorera trehundra olika AWS-produktakronymer. Men verklig molnberäkning handlar inte om att memorera leverantörskataloger: det bygger på elva fundamentala arkitektoniska primitiver.

0:34 I denna masterclass kommer vi att gå igenom hela företagsritningen: från skalning och belastningsutjämning till serverlöst, händelsestyrd frikoppling, lagringshierarkier och molnnätverk. Bemästra dessa elva koncept, och du kan designa vilken backend som helst på AWS, GCP eller Azure. Detta är The Daily Diff, under huven.

### - 01. Vertikal vs. Horisontell Skalning

0:57 Koncept nummer ett: Skalning. När din applikation upplever trafikökning har du två fundamentalt olika sätt att hantera belastningen: vertikal skalning, eller horisontell skalning. Vertikal skalning, eller att skala upp, innebär att du tar din befintliga maskin och lägger till fler resurser: uppgraderar från fyra CPU-kärnor till trettiotvå, eller byter trettiotvå gigabyte RAM mot etthundratjugoåtta. åtta. Vertikal skalning kräver noll arkitektoniska förändringar: din kod

1:28 och databas förblir exakt densamma. Men den stöter på ett brutalt hårdvarutak. Ingen enskild maskin i världen har tiotusen CPU-kärnor, och toppklassinstanser medför en exponentiell prispremie. Horisontell skalning, eller att skala ut, innebär att du håller dina servrar små och med billig standardpris, men kör flera instanser parallellt bakom en router. Om en instans kraschar, absorberar de återstående noderna trafiken med noll driftstopp. Den gyllene regeln för horisontell skalning är

2:01 tillståndslöshet: dina applikationsservrar får inte lagra användarsessioner, uppladdade filer eller tillstånd på sina lokala diskar. Tillstånd måste finnas i en extern databas eller cache, vilket tillåter vilken nod som helst att hantera vilken användarförfrågan som helst.

### - 02. Belastningsutjämningsarkitektur (L4 vs. L7 & Hälsokontroller)

2:17 Koncept nummer två: Belastningsutjämning. Horisontell skalning låter bra på papperet, men det introducerar ett omedelbart problem: när tiotusen användare besöker ditt domännamn, vilken specifik server tar emot deras trafik? En belastningsutjämnare fungerar som en omvänd proxy som sitter mellan det offentliga internet och ditt privata backend-kluster. Den accepterar inkommande TCP- eller HTTP-anslutningar och distribuerar förfrågningar över dina friska instanser.

2:47 Belastningsutjämnare arbetar på två primära nätverkslager. Layer 4 Network Load Balancers fungerar på transportlagret, dirigerar råa TCP- och UDP-paket baserat på IP-adress och port med mikrosekundlatency och miljontals förfrågningar per sekund. Layer 7 Application Load Balancers inspekterar HTTP-protokollet självt: läser URL-sökvägar, förfrågningshuvuden, cookies och HTTP-metoder. metoder. Detta möjliggör sökvägsbaserad dirigering: skickar slash-api-förfrågningar till ditt backend-kluster och slash-static-förfrågningar till ett

3:25 objektlager. Avgörande är att belastningsutjämnare utför aktiva hälsokontroller. Varannan sekund pingar balanseraren en hälsoslutpunkt på varje instans. Om en instans kastar tre på varandra följande femhundra fel eller misslyckas med att svara, tas den automatiskt bort från poolen med noll tappade förfrågningar.

### - 03. Autoskalning & Elasticitet

3:45 Koncept nummer tre: Autoskalning. Om din webbapp behöver två servrar klockan tre på morgonen, men tjugo servrar under en lansering mitt på dagen, är manuell klickning på knappar i molnkonsolen en garanterad väg till driftstopp och konkurs. Autoskalning ger dynamisk elasticitet till horisontella serverpooler. En autoskalningsgrupp övervakar prestandamått som genomsnittlig CPU-utnyttjande, nätverks-I/O eller köbackloggsdjup. När genomsnittlig CPU överskrider en definierad tröskel – säg,

4:19 sjuttio procent i tre minuter i följd – startar autoskalaren automatiskt nya virtuella maskiner, registrerar dem med din belastningsutjämnare, och börjar dirigera trafik. Lika viktigt är att skala in: när trafikvågen avtar, terminerar autoskalaren överskottsinstanser så att du slutar betala för inaktiv beräkningskapacitet. För att förhindra flappning – där servrar snabbt skapas och förstörs i en oändlig kastningsslinga – konfigurerar molnarkitekter nedkylningsperioder. Koncept nummer fyra: Serverlöst.

### - 04. Serverlöst (FaaS & Firecracker MicroVMs)

4:53 Under åratal marknadsförde marknadsteam serverlöst som magisk kod som körs i molnet. I verkligheten använder serverlöst fortfarande servrar – men du äger, patchar eller betalar inte för dem när ingen kod körs. Med Function-as-a-Service som AWS Lambda eller Google Cloud Functions, skriver du en fristående hanteringsfunktion. När en HTTP-förfrågan, S3-filuppladdning eller databasändring inträffar, startar molnkörtiden en efemär

5:23 mikrovirtuell maskin som Firecracker på mindre än fem millisekunder. Din kod körs, returnerar ett svar och stängs av. Om ingen besöker din webbplats på tre månader är din beräkningsräkning exakt noll dollar och noll cent. Om en miljon användare besöker den samtidigt, snurrar leverantören upp en miljon samtidiga mikro-VM:ar. De tekniska kompromisserna är verkliga: kallstartsfördröjning vid uppstart av nya körtider, en hård femton minuters exekveringsgräns på Lambda, och strikt tillståndslöshet.

5:55 Serverlöst är oslagbart för händelsepipelines och sporadiska API:er, men dåligt för ihållande WebSockets eller träningskörningar som pågår i flera timmar.

### - 05. Händelsestyrd Arkitektur (EDA & Frikoppling)

6:05 Koncept nummer fem: Händelsestyrd Arkitektur, eller EDA. I traditionella arkitekturer kommunicerar tjänster synkront. Din kassa-tjänst anropar betalning, betalning anropar lager, lager anropar bedrägeri, och bedrägeri anropar e-post. Detta skapar den synkrona kaskaden av undergång. Om den tredjeparts e-postleverantören upplever en nätverkshicka och tar tio sekunder att svara, timeoutar kundens hela kassa-förfrågan med ett fel. I en händelsestyrd arkitektur är tjänster helt frikopplade.

6:37 När en kund klickar på köp, anropar kassa-tjänsten inte nedströms tjänster. Den publicerar helt enkelt en händelse kallad OrderPlaced till en central Event Bus som Amazon EventBridge eller ett SNS-ämne. Kassan slutförs på femtio millisekunder. Nedströmsarbetare för betalning, lagerminskning och e-postkvitton hämtar meddelanden oberoende från sina egna dedikerade SQS-köer. Om e-posttjänsten går ner i en timme, väntar meddelandena säkert buffrade i kön utan en enda tappad order.

### - 06. Containerorkestrering (Docker & Kubernetes)

7:13 Koncept nummer sex: Containerorkestrering. Docker löste paketering: det kapslar in din applikationskod, systembibliotek, konfiguration och körtid i en oföränderlig avbildning som körs identiskt på din MacBook och i molnet. Men att paketera en container är enkelt. Att köra femhundra containrar över femtio fysiska virtuella maskiner är där ingenjörsarbetet går sönder. Därför finns containerorkestratorer som Kubernetes och AWS ECS.

7:41 En orkestrator tillhandahåller ett kontrollplan: en API-server, en etcd-tillståndsdatabas och en intelligent schemaläggare. Du deklarerar ditt önskade tillstånd: Jag vill ha tio repliker av min autentiseringstjänst med två gigabyte RAM vardera. Schemaläggaren inspekterar klustret, placerar poddar på noder med ledigt minne, konfigurerar internt nätverk och förenar kontinuerligt verkligheten. Om en nod drabbas av ett maskinvarufel, upptäcker Kubernetes förlusten och schemalägger omedelbart om alla förflyttade poddar till

### - 07. De 4 Molnlagringspelarna (S3, EBS, DBs & Redis)

8:16 friska noder. Koncept nummer sju: Molnlagringshierarkin. Nykomlingar behandlar ofta molnlagring som en enda hink där du dumpar filer. I produktionsarkitektur är lagring uppdelad i fyra distinkta pelare baserade på åtkomstmönster och latens. Först är Objektlagring, som Amazon S3 eller Google Cloud Storage. Du får åtkomst till filer över HTTP REST API:er med enkla PUT- och GET-anrop. Det erbjuder oändlig horisontell kapacitet till två cent per gigabyte per månad,

8:49 vilket gör det idealiskt för video, användaruppladdningar, loggar och säkerhetskopior. För det andra är Blocklagring, som Amazon EBS. Dessa är virtuella hårddiskar monterade direkt till en specifik virtuell maskin över höghastighetsförbindelser. De formateras till standardfilsystem som ext4, stöder snabb slumpmässig läs- och skrivåtkomst som krävs av databasmotorer. Tredje är Hanterade Databaser: relationella motorer som PostgreSQL på RDS som tillhandahåller ACID-transaktioner och komplexa join-operationer,

9:21 och NoSQL-motorer som DynamoDB som levererar enciffrig millisekundlatency i massiv skala. Och fjärde är in-memory-cachar som Redis. Att läsa data från RAM tar mikrosekunder snarare än millisekunder. Cachar sitter framför din databas, skyddar den från upprepad lästrafik och hanterar volatila användarsessionstokens.

### - 08. Hög Tillgänglighet & Niorna (Multi-AZ Failover)

9:44 Koncept nummer åtta: Hög Tillgänglighet, eller HA. Tillgänglighet besvarar en fråga: hur stor procentandel av tiden är din applikation operativ och nåbar för användare? I företagsavtal mäts tillgänglighet i nior. Två nior, eller nittionio procent tillgänglighet, tillåter över tre och en halv halv dagars driftstopp varje år. Fyra nior sänker tillåten driftstopp till femtiotvå minuter, och fem nior tillåter knappt fem minuters totalt driftstopp per

10:15 år. För att uppnå hög tillgänglighet måste du eliminera enskilda felpunkter över feldomäner. I molnet innebär det att distribuera över flera tillgänglighetszoner. En tillgänglighetszon är inte ett enda rack: det är ett eller flera distinkta fysiska datacenter med mil emellan med oberoende ström och kylning. Genom att köra aktiva instanser i Zon A och Zon B med synkron databasreplikering, resulterar ett blixtnedslag eller fiberbrott som slår ut en hel fysisk anläggning i en automatisk failover.

10:50 på trettio sekunder utan mänsklig inblandning.

### - 09. Hållbarhet vs. Tillgänglighet (Varför 11 Nior Inte Är Uptime)

10:53 Koncept nummer nio: Varaktighet kontra Tillgänglighet. Detta är den enskilt vanligaste konceptuella fällan i molnarkitektur- intervjuer. Ingenjörer använder ofta orden omväxlande, men de mäter helt olika egenskaper. Tillgänglighet mäter drifttid: kan jag göra ett API-anrop för att läsa eller skriva min data just nu? Varaktighet mäter bevarande: kommer min data att överleva utan permanent bit-röta, korruption eller förstörelse under tio år?

11:24 Titta på Amazon S3 Standard. Dess Service Level Agreement erbjuder nittionio komma nio procent tillgänglighet, vilket tillåter ungefär fyrtiotre minuters nedtid varje månad där en API-förfrågan kan returnera ett femhundra-fel. Men S3 lovar elva nior av varaktighet: nittionio komma nio nio nio nio nio nio nio nio nio procent. Om du lagrar tio miljoner filer i S3 kan du statistiskt förvänta dig att förlora i snitt en

11:56 fil var tio tusen år. S3 uppnår detta genom att radera-koda objekt och replikera segment över minst tre geografiskt åtskilda dataanläggningar. Under ett större regionalt nätverksavbrott kan S3 tillfälligt vara otillgängligt, men din data förstörs aldrig.

### - 10. Infrastruktur som Kod (Terraform vs. Konsoldrift)

12:14 Koncept nummer tio: Infrastruktur som Kod, eller IaC. I molntjänsternas barndom loggade ingenjörer in på AWS webbhanteringskonsolen och klickade sig manuellt runt för att skapa virtuella maskiner, konfigurera subnät och koppla säkerhetsgrupper. Branschen kallar detta ClickOps, och i produktion är det en absolut katastrof. Manuella konsoländringar har ingen revisionsspår, ingen återställnings- mekanism, och orsakar oundvikligen konfigurationsavvikelser mellan staging- och produktionsmiljöer. Med Infrastruktur

12:48 som Kod-verktyg som Terraform, OpenTofu, Pulumi eller AWS CDK, definierar du din hela molnarkitektur i deklarativa konfigurationsfiler lagrade i Git. Varje ändring till en öppen port eller databasreplik går igenom en pull request och peer review. Att köra terraform plan förhandsgranskar den exakta API-diffen innan något rörs, och att starta en identisk replika av din produktions- stack tar fyra minuter istället för fyra veckor.

### - 11. Molnnätverk (VPC, Subnets, NAT & Säkerhetsgrupper)

13:20 Koncept nummer elva: Molnnätverk och Virtuella Privata Moln. När du distribuerar servrar till molnet, sitter de inte exponerade på det råa publika internet. De lever inom en mjukvarudefinierad isolerad gräns kallad en VPC. Inne i din VPC tilldelar du ett privat IP-adressutrymme som tio-punkt-noll-punkt-noll-punkt-noll slash sexton, och delar upp det i publika och privata subnät. Ett publikt subnät har en direkt väg till en Internet Gateway.

13:51 Det rymmer publika tillgångar som dina Application Load Balancers och NAT Gateways. Det är den enda delen av ditt nätverk som besitter publika IP- adresser. Dina applikationsservrar och produktionsdatabaser lever strikt i privata subnät utan publika IP-adresser och noll inkommande rutter från internet. När dina backend-servrar behöver ladda ner säkerhetsuppdateringar, dirigeras deras utgående trafik via NAT Gateway i det publika subnätet. Runt varje instans finns säkerhetsgrupper: tillståndskänsliga virtuella brandväggar som upprätthåller principen om minsta behörighet.

### - 12. Den Kompletta Företagsritningen & Bedömning

14:28 Din databas säkerhetsgrupp accepterar endast anslutningar på port 5432 strikt från säkerhetsgruppen för dina applikationsservrar, vilket gör extern intrång matematiskt omöjligt. När du zoomar ut kopplas dessa elva primitiva element samman till ett sammanhängande system. Din DNS dirigerar till en lastbalanserare i ett publikt subnät, autoskalningsgrupper hanterar trafikökningar över flera tillgänglighetszoner, händelsebussar frikopplar backend-arbetare, och hela din stack är distribuerad från Git med Infrastruktur som Kod.

15:02 Dagens mästarklassdom: SHIP IT. Sluta memorera hundratals akronymer för molnmarknadsföring. Bemästra dessa elva arkitekturmönster, frikoppla ditt tillstånd, och bygg system som inte kan misslyckas. Berätta vilket molnkoncept som gav dig mest huvudvärk när du först började bygga i kommentarerna. Och för att hämta det kompletta arkitektur-fusket, prenumerera på nyhetsbrevet på the daily diff dot dev,

15:28 länk nedan. Och det var diffen för idag. Jag är Niko från Axrisi. Sammanfoga ansvarsfullt.

## Källor

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io