AWS Summit ANZ 2021 - Design patterns for success in serverless microservices
HTML-код
- Опубликовано: 8 янв 2022
- Developers love patterns - proven approaches to well-known problems that make our jobs easier and set our projects up for success. In complex, distributed systems such as microservices, patterns like CQRS and Event Sourcing help decouple and scale your systems, and unlock hidden context that is valuable to the business. In this session, we take a look at some typical patterns for building robust and performant serverless microservices, and how data access patterns drive polyglot persistence.
To see what’s coming up from Amazon Web Services in Australia and New Zealand, visit
go.aws/3FTtDM6
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.
#AWS #AmazonWebServices #CloudComputing 
Наука
A comprehensive yet compact presentation on design patterns in server-less micro-services architecture utilizing available lambda integration services for further utilization of AWS managed Kubernetes service that is Fargate. All of this makes the most efficient and cost effective utilization of cloud resources and further makes the lives of developers and architects much easier. Two thumbs up! 👍 👍
Very nice presentation. Easy to understand. just the right amount of detail. Thanks
Very much useful .
That's great to hear! 🙌
Awesome presentation skills
Awesome presentation thank you
Thanks for the compliment, Mohamed! 😍 🤝 ☁️
Hello, I learned a lot from this presentation. I have a question regarding SNS: if multiple users are simultaneously using the application, will the SNS messages get lost or sent to the wrong user? Or will the correct user (subscriber) receive the correct response? I'm just curious if SNS automatically directs the response message to the correct caller.
Hi, there. This resource includes helpful information about SNS and may address your questions: go.aws/3VKlsfJ. 🔎 For any further questions, please reach out to our free community of helpful engineers at re:Post: go.aws/aws-repost. 🤝 ^ZP
In the demo the API transaction Order ID 3 is overwritten with second request using the same order id 3, I assume in a real world implementation this would normally be an invalid transaction, would you record this as an error event or discard it ?
I'm sorry to hear that your having difficulties, Myles. I've forwarded your question to our Support team for further review. In the meantime, please feel free to ask our community of experts in re:Post for further guidance: go.aws/aws-repost. ^KR
I don't understand how this helps database contention. You've separated reads from writes at the service level, but the RDS database still gets written to, just in a roundabout way. So if too many writes were causing degradation in service, those writes are still being done, maybe with a 500ms delay, but for example 1000 "place order" calls per second still ends up creating about 1000 writes per second on the RDS database, so you'd still get the same performance degradation. Unless you for example limit the RDS write throughput via something like setting a low reserved concurrency on the lambda which writes to RDS, but that isn't mentioned.
Search service now pulls from the elasticache, not the Aurora/RDS, so the contention for resources on RDS is alleviated, although reporting is still reading from RDS, I suppose the assumption is that search is more frequent/impactful than reporting, as is usually the case.
If you are giving demo it should be from scratch