AWS re:Invent 2022 - Building Serverlesspresso: Creating event-driven architectures (SVS312)
Вставка
- Опубліковано 5 гру 2022
- Serverlesspresso is an event-driven, serverless workload that uses Amazon EventBridge and AWS Step Functions to coordinate events across microservices and support thousands of orders per day. This session explores the design decisions made in building this application, how new features influenced the development process, and lessons learned in creating a production-ready application using this approach. Explore useful patterns and options for extensibility that helped the team design a robust, scalable solution that costs about 1 dollar a day to operate. This session includes examples you can apply to your serverless applications and teaches you how to combine EventBridge and Step Functions to solve complex architectural challenges in larger applications.
Learn more about AWS re:Invent at go.aws/3ikK4dD.
Subscribe:
More AWS videos bit.ly/2O3zS75
More AWS events videos bit.ly/316g9t4
ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.
AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers-including the fastest-growing startups, largest enterprises, and leading government agencies-are using AWS to lower costs, become more agile, and innovate faster.
#reInvent2022 #AWSreInvent2022 #AWSEvents - Наука та технологія
Awesome presentation. In less than an hour a summary of what I teach students in three months! Makes me🙂
We're happy to hear that you liked the presentation, Arjen! 😀 ^AK
Thanks Arjen! That's great to hear!
amazing presentation. 👏🏿👏🏿. 👏🏿
Great presentation. Thanks James.
Thank you!
Like a pro
Wow... awesome!
Thank you so much!
Classic legacy integration challenge: scalable front-end and limited legacy system capacity :-)
One question, did you normalize the events for your workflow to consume? What I mean by this question is were the events having a common "event" Json which was then sent to the workflow?
Hi Deepa! No, each service followed its own event format. After building the prototype, we then found it's better to produce event schema, definitions, and naming conventions ahead of time so all services produce similar-looking events.
@@JamesBeswickD Thanks for your response. I think normalizing events helps make sense of data better. I have always struggled with this concept of disparate events, because it is going to be harder to make sense of data with disparate event formats.
What were the total hours taken to develop?
What was the main reason to use IOT Core? If you needed messaging system for microservices to communicate, could you be using SNS/SQS? What was the main reason you went with IOT Core? Thank you.
SNS/SQS are not built for websockets from what I understand. They are primarily meant to decouple two systems and fan out.
Hello! SNS can deliver messages to other backend services, HTTP and SMS endpoints. But in our case we need to communicate back to a SPA-style application, so we needed a WebSocket delivery. IoT Core provides a very elegant and cost-effectively way to implement messages over MQTT so that's how it was chosen. HTH!
Thank you for this wonderful content. James is an amazing choice when it comes to presentations. It is easier to learn once he is the one who explains it. Thanks James!!!! 🩷
Thank you - you are too kind!