Don't confuse Kinesis with a Queue system.
Rating: 1 out of 10
IncentivizedUse Cases and Deployment Scope
We currently use Kinesis as a trigger for Amazon Lambda functions, however we're working at switching back to SQS since Lambda now works with SQS directly. We simply used Kinesis as a temporary method of plumbing requests from one Lambda function to another.
We also use it as a byproduct of using DynamoDB Streams, but only in so far as that's used under-the-hood to link changes from DynamoDB to a Lambda trigger.
We also use it as a byproduct of using DynamoDB Streams, but only in so far as that's used under-the-hood to link changes from DynamoDB to a Lambda trigger.
Pros
- Link DynamoDB change events directly to Lambda
- Fast streaming of events
- Easy to "tail" changes/latest events
Cons
- Not a queue system, so little visibility into "backlog" if there is any
- Confusing terminology to make sure events aren't missed
- Sometimes didn't seem to trigger Lambda functions, or dropped events when a lot came in
Likelihood to Recommend
It's great for big data applications, where it's not as important to make sure each event is processed, but you're more looking for overall analytics and speed is more important than absolute detail. It's added quite a few features like analytics and other tools specifically designed around big data, but it's not the same thing as a queue system.
Originally we were forced into using Kinesis since Lambda didn't support SQS directly, but now that there is native SQS support for Lambda, we'll be switching almost all of our implementation over to use that instead. Kinesis has its strengths, but monitoring and error retry logic is not one of those.
Originally we were forced into using Kinesis since Lambda didn't support SQS directly, but now that there is native SQS support for Lambda, we'll be switching almost all of our implementation over to use that instead. Kinesis has its strengths, but monitoring and error retry logic is not one of those.
Vetted Review
1 year of experience