Here is a blog post that goes through how you can build a streaming data backend by using a serverless approach. The blog provides a complete example application that you can deploy to your AWS account: aws.amazon.com/blogs/compute/building-serverless-applications-with-streaming-data-part-1/
@RaGePr00fs3 жыл бұрын
I would like to ask you, what online certified courses would you recommend for becoming a cloud engineer?
@WinTheCloud3 жыл бұрын
@@RaGePr00fs I have dedicated a video for this specific question ;) kzbin.info/www/bejne/Y5a1l6mhm6iMZrs
@RaGePr00fs3 жыл бұрын
@@WinTheCloud Ohh :DDD thank you. I watched after I wrote the comment back then ) . Thank you for your hard -work and following up.
@oleksandroliinyk41463 жыл бұрын
Man, thank you! I've been watching your videos for 5 days and gonna watch all of them!
@WinTheCloud3 жыл бұрын
Awesome, thank you! I'm really glad you like them. I was starting to get worried people didn't find them useful..
@lousydropout3 жыл бұрын
At 11:36, you have an SQS queue between your consumer and producer lambdas. Why not just have a single lambda that reads from one kinesis data stream to the other? I'd imagine that the SQS queue would largely bring disadvantages. For example, if you use a regular (non-FIFO) sqs queue, then you lose the ordering you had within each kinesis data stream shard. If, instead, you use a FIFO queue, then you potentially create a bottleneck due to its lower throughput per message group (even if you, say, set the message group id to equal the shard id and, especially, if batching is enabled for kinesis data stream). Also, SQS has a smaller message size limit (256kb vs 1MB I wanna say?), so, it might be a no-go to begin with.
@WinTheCloud3 жыл бұрын
The SQS queue is mainly there to act like a buffer while the producer reads the messages from SQS in a batch manner. The idea is to leverage Lambda concurrency model + Lambda batch processing capabilities to save on calls cost: For example, we can configure Lambda to wait until 10 messages are in the queue (or once every 30 sec) before doing one round trip to SQS. This doesn't only save on cost, but also scales better since you most likely won't go over the Lambda invocation limit your account have. As for the message size limit, of course a bigger size message would be a new constraint that will most likely require a design change, for example: Consumer B puts object to S3, then Producer reads that object...
@lousydropout3 жыл бұрын
@@WinTheCloud Even though kinesis data stream works just fine as a buffer? My thoughts: Just have the kinesis data stream / lambda event source be configured with a batch size of, say, 200 records and a maximum wait time of 60 seconds. Your lambda would then poll for either 200 records or until 60 seconds has passed (whichever occurs first) before processing them all (and pushing the processed records to that other fraud detection kinesis data stream) at once. Far as I can tell, this would provide the same buffering effect you're going for. If you further keep the ParallelizationFactor at 1 (i think this is the default value), then you'd keep the within-shard ordering that you'd lose w/ a non-FIFO SQS queue. You'd end up with far fewer lambda invocations (as lambda can poll up to 1,000 records from kinesis vs 10 from SQS), fewer components (1 sqs queue and 1 lambda fewer), and fewer added constraints (kinesis data stream record size limit).
@lousydropout2 жыл бұрын
@Robin Chan Yes, but you get the same benefits (and more) by removing the SQS queue there. I like the architecture design (with the SQS queue removed) and agree with your comment that the main focus was on the separation of ownership. It's just that the SQS queue there doesn't help anything and yet adds size & ordering limitations. So, I'm saying remove the SQS queue and keep the rest.
@michaelgentry75342 жыл бұрын
@@lousydropout The benefit of the queue is that any number of other subscribers can subscribe to the queue as the application grows.
@vamsiakhumukhi95823 жыл бұрын
Amazing Video... excited about upcoming videos !!!
@WinTheCloud3 жыл бұрын
More to come!
@MichelCarroll3 жыл бұрын
Thanks! Really interesting pattern. Been looking at event sourcing patterns for awhile, and this is one of the most immediately practical videos I've seen on the topic. Looking forward to part 2.
@jackakif3 жыл бұрын
keep posting educative videos like this man
@WinTheCloud3 жыл бұрын
As long as you keep giving them likes haha ! Jokes aside, I'll definitely do my best!
@luislla3142 Жыл бұрын
Amazing content!!! Thanks for your work. Please We need more use cases, like examples of scenarios and your proposed architectures and patterns applied. Thanks in advance.
@WinTheCloud Жыл бұрын
Thank you, Luis! I have more patterns in store, next I'm going to be talking about the GateKeeper pattern and more in the same style.
@luislla3142 Жыл бұрын
@@WinTheCloud 😊👍
@mrnobody57632 жыл бұрын
Really I don't understand how a person who produce such a great quality content can have only 10k subs. Let's keep up this way, you're doing a great job.
@WinTheCloud2 жыл бұрын
Thank you brother! My content is very niched, and I like it this way. I can produce videos that go over the top to get more views, but it's not my focus right now, maybe one day
@folashocky27353 жыл бұрын
Great video! I'm surprised that you don't have more subscribers.
@WinTheCloud3 жыл бұрын
Thank you my friend! if you like the video, please give it a like, apparently it helps the channel to be more suggested to other people
@marianocalandranotonlyclou15793 жыл бұрын
Nice solution. Just to be safe: at 9:12 that DynamoDB table is just a denormalized view of the events?
@WinTheCloud3 жыл бұрын
It is. This DynamoDB table can be your main DB that your app reads from, so you can use whatever schema your app requires
@anthonygrear62263 жыл бұрын
I've been getting confused with the different Amazon Kinesis products- so I'm glad they were used in this architectural design pattern. I have a feeling this channel will get much bigger. Keep up the good work.
@WinTheCloud3 жыл бұрын
Glad it was helpful!
@alexisnarvaez2 жыл бұрын
Interesting video. How does Kinesis help you handling optimistic concurrency exceptions? That is a must to validate commands before emitting events
@WinTheCloud2 жыл бұрын
I haven't seen many cases where optimistic locking is handled on the data stream itself. Some AWS services like DynamoDB and ElasticSearch are pretty good at this: docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html
@saifeddinebouazizi56542 жыл бұрын
i'm currently studying to get my solutions architect certificate (associate level). your videos are really great. thanks
@WinTheCloud2 жыл бұрын
Super happy to hear it! Good luck for your certificate
@saifeddinebouazizi56542 жыл бұрын
@@WinTheCloudThanks
@shadidhaque10092 жыл бұрын
Exactly what I was looking for
@WinTheCloud2 жыл бұрын
Glad it was helpful Shadid ;)
@saurabh36143 жыл бұрын
alot to learn from you thanks, buddy!!
@djfriiky3 жыл бұрын
IMO the most important part of serverless is, that you do not need to select any size, server model etc. when provisioning a service. Therefore Kinesis is managed, but not serverless as you need to select the shard count.
@WinTheCloud3 жыл бұрын
I see your point. I use the same definition for Serverless as well (no size, mode... are required)
@kanonochina3 жыл бұрын
Very informative! Can you please do a architectural design for serverless AWS that can communicate to other APIs like Stripe? Thanks for the awesome videos.
@WinTheCloud3 жыл бұрын
How about this one? kzbin.info/www/bejne/r3OqfaqVmq6HnLs Let me know if you have questions!
@laxmisuresh2 жыл бұрын
Nice video. Can we push messages directly from lambda to kinesis to avoid sqs in this solution?.
@WinTheCloud2 жыл бұрын
Yes, definitely, the SQS is there to add a buffer in case the load spikes, but also to avoid tight coupling: If you decide to use Kafka, later rather than Kinesis, you won't have to change your Lambda function code ;)
@mexicanmax2273 жыл бұрын
Audio sounds great! Amazing video too!
@WinTheCloud3 жыл бұрын
Much appreciated!
@mexicanmax2273 жыл бұрын
I can’t thank you enough for your vids! They help me prepare for everything from coding to cloud certifications and best practices from all over the cloud industry. Plus your approach to teaching it is so well presented and easy to understand!!
@pauldarwin51113 жыл бұрын
Audio quality is great.
@WinTheCloud3 жыл бұрын
Thank you for the feedback! I appreciate it
@bogdanvaduva644 Жыл бұрын
What happens if as an example, from one domain to the other, I want to send some information that is under GDPR protection, so it needs to be deleted at some point. Can I set up a lambda between Data streams and Firehose such that I strip that data from the event and only use it to produce a report (let's say) but not have it permanently stored in the S3 bucket?
@chatchaikomrangded9603 жыл бұрын
Great!
@WinTheCloud3 жыл бұрын
Thank you. I'm happy you enjoyed it
@tusharanand40593 жыл бұрын
Good One.
@WinTheCloud3 жыл бұрын
Thank you! Cheers!
@nithinkirthick86363 жыл бұрын
lol can u guide road map to solution architect
@nicositio543 жыл бұрын
Why not eventbridge?
@WinTheCloud3 жыл бұрын
EventBridge works for this as well - You can also use SQS to sort of "stream" data rather than Kinesis Data Stream... Many variations are possible