Architectuurpatronen voor applicaties op AWS

Applicaties implementeren op AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Maak kennis met je docent

Cursusdocent Dunieski Otano, een AWS Solutions Architect met ongeveer tien jaar cloudervaring

Waarom de juiste architectuur telt

Beslisdiagram in lichte stijl waar één architectuurkeuze vertakt naar drie factoren: koppeling, status en communicatie, boven een klein weegschaalpictogram voor afwegingen

Architectuur is een set afwegingen, geen één juist antwoord
- Drie vragen sturen elke keuze:
  - Hoe strak zijn componenten gekoppeld?
  - Waar leeft de status?
  - Is communicatie synchroon of asynchroon?
- Kies het patroon bij de workload, niet bij de mode

De vrijdagavondcascades

Een trage betalings-API bevriest de hele checkout
Elke service wachtte er synchroon op
De oplossing is architectuur, niet een snellere API

Vergelijking naast elkaar: strak gekoppelde services die vastlopen versus services ontkoppeld door een message queue

Waarom architectuurkeuzes de uitrol bepalen

Diagram dat een fragiele strak gekoppelde architectuur toont waar één falende service uitwaaiert naar alle services, versus een veerkrachtig ontwerp waar een queue-buffer de fout isoleert zodat andere services blijven draaien

Het patroon dat je kiest bepaalt hoe de app schaalt en faalt
- Een strak gekoppeld ontwerp breekt onder load
Het juiste patroon maakt uitrol voorspelbaar
- Dezelfde code, heel ander gedrag in productie

De kernarchitectuurpatronen

Monolithisch: één deploybare unit, simpel starten
Microservices: losse services, apart gedeployed
Event-driven: componenten reageren op events, geen directe calls
- Fanout is een subpatroon: één event bereikt veel consumers

Drie applicatie-architectuurpatronen naast elkaar: monolithisch als één gestapeld blok, microservices als losse deploybare services, en event-driven met een eventbus, met fanout als gelabeld subpatroon in het event-driven paneel dat één event naar veel consumers publiceert

Stateful vs stateless

Stateless: geen klantdata tussen requests
- Elke instance kan elk request afhandelen
Stateful: instance onthoudt eerdere interacties
Stateless maakt horizontaal schalen mogelijk
- Zet gedeelde status in DynamoDB of ElastiCache

Links een stateless functie-exemplaar dat elk request kan ontvangen, rechts een stateful exemplaar gekoppeld aan één clientsessie

Strakke vs losse koppeling

Strakke koppeling waarbij de aanroeper blokkeert tot een trage aangeroepene antwoordt, versus losse koppeling met een SQS-queue die berichten buffert zodat de producer doorgaat

Strakke koppeling: aanroeper wacht op antwoord van aangeroepene
Eén trage service doet de hele keten vastlopen
Losse koppeling: een Amazon SQS-queue zit tussen services
De producer gaat door, ook als de consumer down is

Synchroon vs asynchroon

Synchroon: aanroeper blokkeert en wacht op resultaat
Gebruik als de aanroeper nu het antwoord nodig heeft
Asynchroon: aanroeper draagt werk over en keert terug
Gebruik voor traag, piekerig of niet-urgent werk

Links een synchrone call met blokkeren tot de response komt, rechts een asynchrone overdracht met directe terugkeer en achtergrondverwerking

Veerkrachtpatronen voor third-party calls

Retry met exponentiële backoff: wacht langer tussen pogingen
Circuit breaker: bel een falende service tijdelijk niet
Dead-letter queue: parkeer berichten die blijven falen
Combineer ze; blind retrypen verergert storingen

Drie veerkrachtpatronen: exponentiële backoff-retry-curve, circuit breaker die calls naar een falende service stopt, en dead-letter queue die berichten opvangt na uitgeputte retries

Laten we oefenen!

Applicaties implementeren op AWS