Cloud computing forklaret: de 11 arkitekturkoncepter du skal kende (4K Masterclass).

Hvad denne video dækker

• - Arkitekturvæggen & Masterplanen
• - 01. Vertikal vs. Horisontal Skalering
• - 02. Load Balancing Arkitektur (L4 vs. L7 & Health Checks)
• - 03. Autoskalering & Elasticitet
• - 04. Serverløs (FaaS & Firecracker MicroVMs)

Oversat udskrift

Oversat fra den originale engelske fortælling. Tilgængelig lyd og undertekster styres af YouTube.

- Arkitekturvæggen & Masterplanen

0:00 Hver softwareingeniør står til sidst over for cloud-arkitekturvæggen. Du bygger en applikation på din bærbare computer, skubber den ud i produktion, og i det øjeblik rigtige brugere ankommer, går serverne ned, databaseforbindelser løber tør, og din AWS-regning ligner et telefonnummer. De fleste udviklere forsøger at løse cloud engineering ved at memorere tre hundrede forskellige AWS produktakronymer. Men ægte cloud computing handler ikke om at memorere leverandørkataloger: det er bygget på elleve fundamentale arkitektoniske primitiver.

0:34 I denne masterclass vil vi gennemgå hele virksomhedsplanen: fra skalering og loadbalancering til serverløs, begivenhedsdrevet afkobling, lagerhierarkier og cloud-netværk. Mestrer disse elleve koncepter, og du kan designe enhver backend på AWS, GCP eller Azure. Dette er The Daily Diff, under overfladen.

- 01. Vertikal vs. Horisontal Skalering

0:57 Koncept nummer et: Skalering. Når din applikation oplever trafikvækst, har du to fundamentalt forskellige måder at håndtere belastningen på: vertikal skalering eller horisontal skalering. Vertikal skalering, eller opskalering, betyder at tage din eksisterende maskine og tilføje flere ressourcer: opgradere fra fire CPU-kerner til toogtredive, eller udskifte toogtredive gigabyte RAM med et hundrede otteogtyve. Vertikal skalering kræver ingen arkitektoniske ændringer: din kode

1:28 og database forbliver nøjagtig den samme. Men den rammer et brutalt hardwareloft. Ingen enkelt maskine i verden har ti tusind CPU-kerner, og top-tier instanser bærer en eksponentiel prispræmie. Horisontal skalering, eller udskalering, betyder at holde dine servere små og prisvenlige, men køre flere instanser parallelt bag en router. Hvis en instans går ned, absorberer de resterende noder trafikken med nul nedetid. Den gyldne regel for horisontal skalering er

2:01 statelessness: dine applikationsservere kan ikke gemme brugersessioner, uploadede filer eller tilstand på deres lokale diske. Tilstand skal leve i en ekstern database eller cache, hvilket tillader enhver node at håndtere enhver brugeranmodning.

- 02. Load Balancing Arkitektur (L4 vs. L7 & Health Checks)

2:17 Koncept nummer to: Load Balancing. Horisontal skalering lyder fantastisk på papiret, men det introducerer et øjeblikkeligt problem: når ti tusind brugere rammer dit domænenavn, hvilken specifik server modtager deres trafik? En loadbalancer fungerer som en reverse proxy, der sidder mellem det offentlige internet og din private backend-klynge. Den accepterer indgående TCP- eller HTTP-forbindelser og fordeler anmodninger på tværs af dine sunde instanser.

2:47 Loadbalancere opererer på to primære netværkslag. Layer 4 Network Load Balancers opererer på transportlaget, dirigerer rå TCP- og UDP-pakker baseret på IP-adresse og port med mikrosekunds latenstid og millioner af anmodninger per sekund. Layer 7 Application Load Balancers inspicerer HTTP-protokollen selv: læser URL-stier, anmodningsheadere, cookies og HTTP- metoder. Dette muliggør sti-baseret routing: sender skråstreg-api anmodninger til din backend-klynge og skråstreg-statisk anmodninger til en

3:25 objektlager. Afgørende er, at loadbalancere udfører aktive sundheds- checks. Hvert par sekunder pinger loadbalanceren et sundhedsendepunkt på hver instans. Hvis en instans kaster tre på hinanden følgende femhundrede fejl eller ikke reagerer, fjernes den automatisk fra puljen med nul tabte anmodninger.

- 03. Autoskalering & Elasticitet

3:45 Koncept nummer tre: Autoskalering. Hvis din webapp har brug for to servere klokken tre om morgenen, men tyve servere under en middagslancering, er manuelt at klikke på knapper i cloudkonsollen en garanteret vej til nedetid og konkurs. Autoskalering bringer dynamisk elasticitet til horisontale serverpools. En Auto Scaling Group overvåger ydeevnemålinger som gennemsnitlig CPU-udnyttelse, netværks-I/O eller kø-restance-dybde. Når gennemsnitlig CPU overskrider en defineret tærskel – f.eks.

4:19 halvfjerds procent i tre på hinanden følgende minutter – lancerer autoskaleren automatisk nye virtuelle maskiner, registrerer dem hos din loadbalancer, og begynder at dirigere trafik. Lige så vigtigt er indskalering: når trafikbølgen aftager, autoskaleren terminerer overskydende instanser, så du stopper med at betale for ubrugt beregningskraft. For at forhindre flappen – hvor servere hurtigt oprettes og ødelægges i en endeløs sløjfe – konfigurerer cloudarkitekter nedkølingsperioder. Koncept nummer fire: Serverløs.

- 04. Serverløs (FaaS & Firecracker MicroVMs)

4:53 I årevis har marketingteams præsenteret serverløs som magisk kode der kører i skyen. I virkeligheden bruger serverløs stadig servere – men du ejer, patcher eller betaler ikke for dem, når ingen kode kører. Med Function-as-a-Service som AWS Lambda eller Google Cloud Functions, skriver du en selvstændig handler-funktion. Når en HTTP-anmodning, S3-filupload eller databaseændring indtræffer, booter cloud-runtimeen en flygtig

5:23 mikro-virtuel-maskine som Firecracker på under fem millisekunder. Din kode udføres, returnerer et svar og lukker ned. Hvis ingen besøger din hjemmeside i tre måneder, er din beregningsregning præcis nul dollars og nul cents. Hvis en million brugere rammer den samtidigt, starter udbyderen en million samtidige mikro-VM'er. De tekniske kompromiser er reelle: koldstart latenstid ved opstart af nye runtimes, en hård femten minutters udførelsesgrænse på Lambda og streng statsløshed.

5:55 Serverløs er uovertruffen til begivenhedspipelines og sporadiske API'er, men dårlig til vedvarende WebSockets eller flere timers træningskørsler.

- 05. Begivenhedsdrevet Arkitektur (EDA & Dekobling)

6:05 Koncept nummer fem: Begivenhedsdrevet Arkitektur, eller EDA. I traditionelle arkitekturer kommunikerer tjenester synkront. Din checkout-tjeneste kalder betaling, betaling kalder lager, lager kalder svindel, og svindel kalder e-mail. Dette skaber den synkrone kaskade af undergang. Hvis den tredjeparts e-mail-udbyder oplever en netværkssnak og tager ti sekunder at svare, udløber kundens hele checkout-anmodning med en fejl. I en begivenhedsdrevet arkitektur er tjenester fuldstændig afkoblet.

6:37 Når en kunde klikker køb, kalder checkout-tjenesten ikke downstream tjenester. Den publicerer blot en begivenhed kaldet OrderPlaced til en central Event Bus som Amazon EventBridge eller et SNS-emne. Checkout gennemføres på halvtreds millisekunder. Downstream-arbejdere for betaling, lagerfradrag og e-mail-kvitteringer trækker beskeder uafhængigt fra deres egne dedikerede SQS-køer. Hvis e-mail-tjenesten går ned i en time, venter beskeder sikkert bufferet i køen uden en eneste tabt ordre.

- 06. Container Orkestrering (Docker & Kubernetes)

7:13 Koncept nummer seks: Container Orkestrering. Docker løste pakning: den pakker din applikationskode, systembiblioteker, konfiguration og runtime ind i et uforanderligt billede, der kører identisk på din MacBook og i skyen. Men at pakke en container er nemt. At køre fem hundrede containere på tværs af halvtreds fysiske virtuelle maskiner er der, hvor ingeniørarbejdet bryder sammen. Det er derfor, containerorkestratorer som Kubernetes og AWS ECS

7:41 eksisterer. En orkestrator leverer et kontrolplan: en API-server, en etcd-tilstandslager og en intelligent scheduler. Du erklærer din ønskede tilstand: Jeg ønsker ti replikaer af min autentificeringstjeneste med to gigabyte RAM hver. Scheduleren inspicerer klyngen, placerer pods på noder med ledig hukommelse, konfigurerer internt netværk og afstemmer kontinuerligt virkeligheden. Hvis en node lider under en hardwarefejl, opdager Kubernetes tabet og omlægger øjeblikkeligt alle forskudte pods til

- 07. De 4 Cloud Storage Søjler (S3, EBS, DB'er & Redis)

8:16 sunde noder. Koncept nummer syv: Cloud Storage Hierarkiet. Begyndere behandler ofte cloud-storage som en enkelt spand, hvor du dumper filer. I produktionsarkitektur er lagring opdelt i fire forskellige søjler baseret på adgangsmønstre og latenstid. Først er Objektopbevaring, som Amazon S3 eller Google Cloud Storage. Du tilgår filer via HTTP REST API'er ved hjælp af simple PUT- og GET-kald. Den tilbyder uendelig horisontal kapacitet til to cents pr. gigabyte pr. måned,

8:49 hvilket gør den ideel til video, brugeruploads, logs og backups. Andet er Blokopbevaring, som Amazon EBS. Dette er virtuelle harddiske monteret direkte på en specifik virtuel maskine over højhastighedsforbindelser. De formateres til standardfilsystemer som ext4, understøtter hurtig tilfældig læse- og skriveadgang, der kræves af database- motorer. Tredje er Administrerede Databaser: relationelle motorer som PostgreSQL på RDS, der leverer ACID-transaktioner og komplekse joins,

9:21 og NoSQL-motorer som DynamoDB, der leverer encifret millisekunds latenstid i massiv skala. Og fjerde er In-Memory Caches som Redis. Læsning af data fra RAM tager mikrosekunder snarere end millisekunder. Caches sidder foran din database og beskytter den mod gentagen læsetrafik og administrerer flygtige brugersessionstokens.

- 08. Høj Tilgængelighed & Nines (Multi-AZ Failover)

9:44 Koncept nummer otte: Høj Tilgængelighed, eller HA. Tilgængelighed besvarer et spørgsmål: hvor mange procent af tiden er din applikation operationel og tilgængelig for brugere? I virksomhedskontrakter måles tilgængelighed i 'nines'. To 'nines', eller nioghalvfems procent tilgængelighed, tillader over tre og en halv dag nedetid hvert år. Fire 'nines' reducerer tilladt nedetid til tooghalvtreds minutter, og fem 'nines' tillader knap fem minutters total nedetid pr.

10:15 år. For at opnå høj tilgængelighed skal du eliminere enkeltpunkter for fejl på tværs af fejldomæner. I skyen betyder det at implementere på tværs af flere Tilgængelighedszoner. En Tilgængelighedszone er ikke et enkelt rack: det er et eller flere separate fysiske datacentre adskillige kilometer fra hinanden med uafhængig strøm og køling. Ved at køre aktive instanser i Zone A og Zone B med synkron databasereplikering, resulterer et lynnedslag eller fiberbrud, der tager en hel fysisk facilitet ned, i et automatisk failover.

10:50 på tredive sekunder med nul menneskelig indgriben.

- 09. Holdbarhed vs. Tilgængelighed (Hvorfor 11 Nines Ikke Er Oppetid)

10:53 Koncept nummer ni: Holdbarhed versus tilgængelighed. Dette er den mest almindelige konceptuelle fælde i skyarkitektur interviews. Ingeniører bruger ofte ordene i flæng, men de måler helt forskellige egenskaber. Tilgængelighed måler oppetid: kan jeg foretage et API-kald for at læse eller skrive mine data lige nu? Holdbarhed måler bevaring: vil mine data overleve uden permanent bitrot, korruption eller ødelæggelse over ti år?

11:24 Se på Amazon S3 Standard. Dets Service Level Agreement tilbyder nioghalvfems komma ni procent tilgængelighed, hvilket tillader cirka treogfyrre minutters nedetid hver måned hvor en API-anmodning kan returnere en femhundrede-fejl. Men S3 lover elleve niere i holdbarhed: nioghalvfems komma ni ni ni ni ni ni ni ni ni procent. Hvis du lagrer ti millioner filer i S3, kan du statistisk forvente at miste en

11:56 gennemsnitligt én fil hver ti tusinde år. S3 opnår dette ved erasure-coding af objekter og replikering af datablokke på tværs af mindst tre geografisk adskilte datafaciliteter. Under et større regionalt netværksudfald kan S3 midlertidigt være utilgængeligt, men dine data ødelægges aldrig.

- 10. Infrastructure as Code (Terraform vs. Konsoldrift)

12:14 Koncept nummer ti: Infrastruktur som Kode, eller IaC. I de tidlige dage af cloud computing loggede ingeniører ind på AWS web management konsollen og klikkede manuelt rundt for at oprette virtuelle maskiner, konfigurere subnets og tilknytte sikkerhedsgrupper. Industrien kalder dette ClickOps, og i produktion er det en absolut katastrofe. Manuelle konsolændringer har ingen revisionsspor, ingen rollback mekanisme, og forårsager uundgåeligt konfigurationsafvigelse mellem staging- og produktionsmiljøer. Med Infrastruktur

12:48 som Kode værktøjer som Terraform, OpenTofu, Pulumi eller AWS CDK, definerer du din hele skyarkitekturen i deklarative konfigurationsfiler gemt i Git. Hver ændring af en åben port eller database-replika går gennem en pull request og peer review. At køre terraform plan forhåndsviser den præcise API-diff før noget røres, og at starte en identisk replika af din produktion stack tager fire minutter i stedet for fire uger.

- 11. Cloud Netværk (VPC, Subnets, NAT & Sikkerhedsgrupper)

13:20 Koncept nummer elleve: Cloudnetværk og virtuelle private skyer. Når du implementerer servere til skyen, sidder de ikke blot eksponeret på det rå offentlige internet. De lever inden for en softwaredefineret isoleret grænse kaldet en VPC. Inde i din VPC tildeler du et privat IP-adresseområde som ti-punktum-nul-punktum-nul-punktum-nul skråstreg seksten, og opdeler det i offentlige og private subnets. Et offentligt subnet har en direkte rute til en Internet Gateway.

13:51 Det rummer offentligt tilgængelige aktiver som dine Application Load Balancers og NAT Gateways. Det er den eneste del af dit netværk, der besidder offentlige IP- adresser. Dine applikationsservere og produktionsdatabaser lever strengt i private subnets uden offentlige IP'er og nul indgående ruter fra internettet. Når dine backend-servere skal downloade sikkerhedsopdateringer, dirigeres deres udgående trafik gennem NAT Gateway'en i det offentlige subnet. Omkring hver instans er der Sikkerhedsgrupper: stateful virtuelle firewalls, der håndhæver princippet om mindste privilegium.

- 12. Den Komplette Virksomhedsplan & Dom

14:28 Din databasesikkerhedsgruppe accepterer kun forbindelser på port 5432 strengt fra sikkerhedsgruppen for dine applikationsservere, hvilket gør ekstern indtrængen matematisk umulig. Når du zoomer ud, forbinder disse elleve primitiver sig til ét sammenhængende system. Din DNS ruter til en Load Balancer i et offentligt subnet, autoskaleringgrupper håndterer trafikspidser på tværs af flere tilgængelighedszoner, event buses afkobler backend-workers, og hele din stack er implementeret fra Git ved hjælp af Infrastructure as Code.

15:02 Dagens masterclass-dom: SHIP IT. Stop med at huske hundredvis af cloud-marketingakronymer. Mestrer disse elleve arkitekturmønstre, afkobl din tilstand, og byg systemer, der ikke kan fejle. Fortæl mig hvilket cloud-koncept der gav dig den største hovedpine, da du først begyndte at bygge i kommentarerne. Og for at få det komplette arkitektur-snydeark, abonner på nyhedsbrevet på the daily diff dot dev,

15:28 link nedenfor. Og det var The Daily Diff for i dag. Jeg er Niko fra Axrisi. Flet ansvarligt.

Kilder

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io