Een serverless microservice ontwerpen

Welkom bij het ontwerpen van een serverloze microservice uit de praktijk! Laten we eerst begrijpen wat een microservice in deze context is.

• Een microservice is een kleine, zelfstandige service die één bedrijfsmogelijkheid uitvoert.
• De service wordt onafhankelijk geïmplementeerd en beheerd en communiceert via API's met andere microservices.
• Met een serverloze microservice bedoelen we services die zijn gebouwd met serverloze technologieën zoals AWS Lambda en API Gateway.

Deze aanpak helpt je schaalbare, onderhoudbare en veerkrachtige applicaties te bouwen.

Een serverloze architectuur past uitstekend bij microservices. Dit is waarom:

• Automatisch schalen: Serverloze functies, zoals Lambda, schalen automatisch op of af op basis van de vraag en verwerken verkeerspieken moeiteloos.
• Betalen naar gebruik: Je betaalt alleen voor de rekentijd en resources die je functies daadwerkelijk gebruiken, wat aanzienlijke kostenbesparingen oplevert.
• Minder operationele overhead: AWS beheert de onderliggende infrastructuur, patches en schaalbaarheid, zodat jij je kunt richten op de logica van je applicatie.
• Snellere ontwikkeling: Kleinere, gerichte services zijn eenvoudiger onafhankelijk te ontwikkelen, testen en implementeren.

Bij het ontwerpen van een serverloze microservice zijn vaak enkele belangrijke AWS-services betrokken:

• AWS API Gateway: Deze service fungeert als de 'voordeur' van je microservice, verwerkt alle binnenkomende HTTP-verzoeken en stuurt ze door naar de juiste backend.
• AWS Lambda: Je rekendienst. Lambda-functies bevatten de daadwerkelijke bedrijfslogica van je microservice.
• Amazon DynamoDB: Een snelle, flexibele NoSQL-databaseservice die ideaal is voor serverloze applicaties dankzij de schaalbaarheid en het model waarbij je naar gebruik betaalt.
• Amazon SQS/SNS: Voor asynchrone communicatie tussen microservices, waardoor de koppeling wordt verminderd en de fouttolerantie verbetert.

De eerste stap bij het ontwerpen van je microservice is het definiëren van de openbare interface: de API-eindpunten.

• Resources identificeren: Welke ‘dingen’ beheert je service? (bijvoorbeeld producten, bestellingen en gebruikers).
• Acties definiëren: Welke bewerkingen kunnen op deze resources worden uitgevoerd? (bijvoorbeeld maken, lezen, bijwerken en verwijderen).
• HTTP-methoden gebruiken: Koppel acties aan standaard-HTTP-methoden (GET voor lezen, POST voor maken, PUT/PATCH voor bijwerken en DELETE voor verwijderen).
• Duidelijke paden ontwerpen: Gebruik beschrijvende, hiërarchische URL’s voor je resources (bijvoorbeeld /products/{id}).

Een goed ontworpen API is intuïtief en gemakkelijk te gebruiken.

Laten we de API voor een eenvoudige microservice voor ‘producten’ ontwerpen:

• GET /products: Een lijst met alle producten ophalen.
• POST /products: Een nieuw product maken.
• GET /products/{id}: De details van een specifiek product ophalen.
• PUT /products/{id}: Een bestaand product bijwerken.
• DELETE /products/{id}: Een product verwijderen.

Elk van deze eindpunten wordt doorgaans afgehandeld door een specifieke Lambda-functie die door API Gateway wordt geactiveerd.

Nadat je je API hebt gedefinieerd, moet je ontwerpen hoe de gegevens van je microservice worden opgeslagen. Voor DynamoDB betekent dit dat je nadenkt over je toegangspatronen.

• Entiteiten identificeren: Wat zijn de belangrijkste gegevensobjecten? (bijvoorbeeld een product of een gebruiker).
• Toegangspatronen bepalen: Hoe ga je deze gegevens opvragen? (bijvoorbeeld ‘product ophalen op ID’ of ‘producten per categorie weergeven’).
• Primaire sleutels kiezen: Selecteer een Partition Key en eventueel een Sort Key die je meest gebruikte toegangspatronen ondersteunen. Dit is cruciaal voor de prestaties van DynamoDB.
• Normaliseren wanneer dat nodig is: DynamoDB profiteert vaak van denormalisatie, omdat dit joins vermindert en de leesprestaties verbetert.

Voor onze microservice voor ‘producten’ kan een eenvoudig gegevensmodel in DynamoDB er als volgt uitzien:

Tabel: Products

• Partition Key: productId (bijvoorbeeld 'P123')
• Attributen:
• name (tekenreeks)
• description (tekenreeks)
• price (getal)
• category (tekenreeks)
• stock (getal)
• createdAt (tekenreeks/tijdstempel)

Met dit ontwerp kunnen producten efficiënt op basis van hun unieke ID worden opgehaald.

Microservices bestaan zelden op zichzelf. Ze moeten met elkaar communiceren. Er zijn twee hoofdpatronen:

• Synchrone communicatie: Eén service roept rechtstreeks een andere aan en wacht op een antwoord.
• Voorbeeld: Service A roept het API Gateway-eindpunt van Service B aan.
• Voordelen: Directe feedback.
• Nadelen: Sterke koppeling; Service A moet wachten en dit kan leiden tot kettingfouten.
• Asynchrone communicatie: Services communiceren via berichten zonder op een direct antwoord te wachten.
• Voorbeeld: Service A publiceert een bericht naar SNS/SQS en Service B verwerkt het later.
• Voordelen: Losjes gekoppeld, bestand tegen fouten en beter schaalbaar.
• Nadelen: Moeilijker te traceren en eventual consistency.

Voor serverloze microservices hebben asynchrone patronen over het algemeen de voorkeur.

Houd bij het ontwerpen altijd rekening met de manier waarop je microservice omgaat met omstandigheden uit de praktijk:

• Fouttolerantie: Ontwerp voor storingen. Wat gebeurt er als een downstreamservice niet beschikbaar is? Implementeer nieuwe pogingen met een exponentiële wachttijd.
• Idempotentie: Zorg ervoor dat het meerdere keren herhalen van een aanvraag hetzelfde effect heeft als deze één keer uitvoeren. Dit is cruciaal voor gedistribueerde systemen.
• Bewaking en logging: Plan hoe je de gezondheid en prestaties van je service observeert (bijvoorbeeld met AWS CloudWatch).
• Beveiliging: Definieer IAM-rollen volgens het principe van minimale bevoegdheden. Overweeg authorizers voor API Gateway.

Deze overwegingen leiden tot veerkrachtigere en beter onderhoudbare systemen.

Gefeliciteerd! Je hebt de belangrijkste stappen voor het ontwerpen van een serverloze microservice doorlopen.

• We hebben gedefinieerd wat een serverloze microservice is en welke voordelen deze biedt.
• We hebben de belangrijkste betrokken AWS-services verkend.
• Je hebt geleerd hoe je duidelijke API-eindpunten en efficiënte gegevensmodellen ontwerpt.
• Je begrijpt nu het belang van asynchrone communicatie en robuuste architectuurprincipes.

Dit fundamentele ontwerpwerk is cruciaal voordat je ook maar één regel code schrijft. Vervolgens ga je deze ontwerpen implementeren!