Services coördineren en state beheren

Toepassingen ontwikkelen op AWS

Ricardo Sueiras

Principal Technologist

Servicecoördinatie

 

• Meerdere services werken samen om een workflow te voltooien.
• Ze hebben een coördinatiestrategie nodig.
• Twee aanpakken: orkestratie en choreografie.

Orkestratie

 

• Een centrale orkestrator coördineert de workflow.
• De orkestrator bepaalt de volgorde en welke service daarna draait.
• Handig voor retries, conditionele logica en foutafhandeling.
• Op AWS: met Step Functions over Lambda, ECS, DynamoDB.

Orkestratie

 

• Workflowlogica staat op één plek, dus debuggen en monitoren is makkelijker.
• Afweging: introduceert een centrale afhankelijkheid.

Choreografie

• Geen centrale controller.
• Services reageren zelfstandig op events.
• Elke service luistert naar relevante events en doet zijn werk.
• Geen enkele service hoeft de hele workflow te kennen.
• Verbetert losse koppeling en schaalbaarheid.

 

Choreografie

• Op AWS: EventBridge, SNS, SQS.
• Zeer schaalbaar.
• Afweging: wordt lastiger te begrijpen en debuggen naarmate workflows groeien.

 

Event-driven architecture

• Services communiceren door events te produceren en te consumeren.
• Stimuleert losse koppeling tussen services.
• Stimuleert hoge schaalbaarheid.
• Maakt parallelle verwerking van events mogelijk.
• Nieuwe services kunnen abonneren zonder bestaande te wijzigen.

 

Event-driven architecture

 

• Afwegingen bij EDA:
• Ontwerp voor eventual consistency.
• Implementeer idempotentie.
• Fouthandling is complexer.

Idempotentie

 

• Dezelfde bewerking meerdere keren uitvoeren geeft hetzelfde resultaat.
• Cruciaal ontwerpbeginsel in asynchrone en event-driven systemen.
• Gedistribueerde systemen kunnen dubbele events leveren (retries, netwerkfouten, reprocessing).
• Bewaart correctheid en betrouwbaarheid van het systeem.

Dead-letter queues

 

• Beheert fouten in asynchrone communicatie.
• Isoleert problematische "poison"-berichten.
• Na herhaalde retry-fouten gaat het bericht naar de DLQ.
• De hoofdverwerkingsstroom blijft draaien.

Dead-letter queues

• Gebruik als berichtvolgorde niet kritisch is.
• Sla over voor niet-kritische systemen waar af en toe dataverlies oké is.
• Vermijd als berichtvolgorde behouden moet blijven.

 

State beheren

• State beheren is essentieel voor cloud-native apps.
• State is alle data die bewaard blijft tussen interacties.
• State lokaal op de server opslaan beperkt schaalbaarheid en veerkracht.

 

State beheren

• Statebeheer kent afwegingen afhankelijk van wat je bouwt.
• Externe state verbetert schaalbaarheid en veerkracht.
• Kosten: extra latentie en complexiteit.
• Let op: consistentie, caching en data-toegangs­patronen.

 

Stateful

 

• Sessiegegevens blijven op de server staan.
• Requests moeten naar dezelfde instance (sticky sessions).
• Beperkt schaalflexibiliteit.
• Valt de instance uit, dan is de sessie weg.

Stateless

 

• Elke request wordt onafhankelijk behandeld.
• Geen state op de server.
• State zit in externe systemen.
• Voorkeursaanpak voor cloud-native apps.
• Elke instance kan elke request afhandelen, dus horizontaal schalen is eenvoudig.

Laten we oefenen!

Toepassingen ontwikkelen op AWS