AWS SNS of Kinesis?

Maar, eerst terug naar events en wat de voordelen zijn van het werken met events. In een cloud-native architectuur ga je ervan uit dat elk onderdeel kapot kan én zal gaan. Je architectuur moet hierop ingericht zijn. Data uitwisselen via events speelt hierop in.

Events zijn natuurlijke gebeurtenissen. Om een voorbeeld te geven van een event, stel dat een klant een bestelling op een website plaatst. Er kan dan een event worden aangemaakt met de gegevens van de klant en wat deze besteld heeft. Dit event wordt gepubliceerd naar een Kinesis-stream of SNS-topic. Vervolgens pikken de componenten (zoals microservices) die naar dit type events ‘luisteren’ of subscriber van een topic zijn op dat er iets gedaan moet worden, zoals bijvoorbeeld het bijwerken van de voorraad of het aanmaken van een factuur. Ook deze componenten produceren events en zo ontstaat een choreografie van events zonder dat de componenten van elkaars bestaan afweten. 

Deze moderne manier van data uitwisselen biedt veel mogelijkheden en voordelen. Stel dat een consumerend component uitvalt, dan blijft het event ‘wachten’. Of beter gezegd ‘bestaan’ tot het component weer beschikbaar is. Ook hoeven componenten niet van elkaars bestaan af te weten (decoupling) en kan je alle events centraal opslaan in een event lake. Dat loggen van events biedt je ook nog eens de mogelijkheid deze events opnieuw ‘af te spelen’. Je kan zelfs zo ver gaan dat je alle events gebruikt om data te berekenen. Bijvoorbeeld de actuele voorraad van een bepaald product op een specifiek moment. Event sourcing heet dat. In een volgend blog gaan we dieper in op deze patronen.

SNS versus Kinesis

AWS biedt meerdere managed services die het communiceren via events ondersteunen. In dit blog richten we ons op de Simple Notification Service (SNS) en Kinesis. Beide diensten kunnen veel meer dan alleen events verzamelen, opslaan en distribueren. Deze  functionaliteiten laten we in dit blog buiten beschouwing.

Met SNS kunnen subscribers zich abonneren op topics. Op die topics kunnen publishers bijvoorbeeld (maar zeker niet alleen maar) events publiceren. Een subscriber kan een e-mailadres zijn, maar ook een Lambda functie, een Simple Queue Service (SQS) queue, een ander SNS-topic, een HTTP(S)-endpoint en zelfs een mobiel nummer voor een SMS-bericht zijn. Kinesis maakt het mogelijk data in streams te verzamelen, analyseren en verwerken. Dat kunnen click streams of logs zijn, maar ook data van IoT sensoren en hetgeen we ons in dit blog op richten: events. Beide diensten zijn volledig managed door AWS.

De relevante verschillen

In veel situaties kan je allebei inzetten. Daarom is het goed te weten wat de belangrijkste relevante verschillen zijn:

• Kinesis bewaart alle events, ongeacht of ze geconsumeerd zijn. Standaard 24 uur en dit kan worden uitgebreid naar 365 dagen. SNS bewaart events slechts tot het moment dat ze door alle consumers bevestigd zijn. Daarna worden ze automatisch verwijderd.
• SNS is laagdrempeliger. Ga je geen gebruik maken van event replays, event lakes, event sourcing en verwacht je dat dit in de toekomst niet gaat gebeuren? Dan valt er veel te zeggen voor de eenvoud van SNS. SNS laat zich goed combineren met de Simple Queue Service (SQS) en met deze combinatie kan je in de meeste architecturen prima uit de voeten.
• Kinesis stelt je in staat het verwerken van alle events in een stream te optimaliseren. Je kan de batch size bepalen, partition keys gebruiken en zelf bepalen hoeveel shards je inzet. Ook kan je met Kinesis Firehose alle events naar S3 wegschrijven en meerdere streams voor verschillende soorten events SNS biedt deze mogelijkheden niet.

Conclusie

Als je voor events in je architectuur kiest, kan je zowel SNS/SQS als Kinesis inzetten. Als je events de basis van je architectuur wilt maken en je van event sourcing, event lakes, event replays en andere patronen gebruik wilt maken, is het aan te raden voor Kinesis te kiezen.

De combinatie van SNS en SQS vormt daarentegen een prima eenvoudiger alternatief als je af en toe met events wilt werken en de eerdergenoemde patronen niet inzet. Het is iets makkelijker op te zetten en daarmee minder arbeidsintensief.

Beide diensten zijn ook prima in combinatie te gebruiken. Zo kan je events van andere AWS-diensten (zoals S3) via SNS en een Lambda functie weer in een Kinesis stream publiceren. Als je hier meer over wil weten, neem contact met ons op. We denken graag met je mee over hoe je deze diensten in jouw architectuur optimaal in kan zetten.

Dit blog is geschreven door Sjoerd Santema.