Put it simply, there's a certain threshold on the ratio of runtime to requests/sec where Lambda & step functions aren't cost optimal compared to a running instance. Of course putting this in a single process in-memory and adding batching will improve performance. This is not a case of Serverless vs Monolith, simply meh vs good design. We had a similar case at work with per sec image processing where we simply used an instance running the same service in parallel for each source devices. Btw, just found your channel, I rarely comment on videos but had to say that I love your content, helped me understand the IGW pretty well!
Cost optimization is a tenant within AWS for its customers. I don't see any problem with AWS using the same cost saving approach with its own services. This doesn't mean serverless is crap, don't use serverless, etc. It means cost savings and only that. AWS analyzed their tech stack and came up with the same performance at less cost. Nothing more to see here... Great explanation!
Great video. I really don't get when people try to force others into trashing completely an approach. I think in the tech world, the right answer is always "it depends". There is always a trade off in every solution. A good architect is the one who find the trade off that is more convenient for that specific customer, in that specific scenario, in that specific use case.
Agreed, but in this case their approach sucked. Like they used the tool wrong and their structure was not good. So yes not the fault of lambda functions
Thank you for doing this video and exposing the reality. A bunch of youtubers needing attention grabbing headlines have completely distorted the message.
Good video, I personally like these architectural deep dives Firstly, the use of S3 as a malformed in-memory cache confused me when I first read the article. Personally, something like EFS seems like itd be better suited for the job but who knows Secondly, it seems like they just re-architected as the problem space changed. They realised the solution they had before couldn't handle large amounts of streams and, thus, they rearchitected. The idea that we have to be "team serverless" or "team monolith" always struck me as a misguided argument when it should be "team best-tech-for-the-problem-at-the-moment"
Great video. Really only the 2nd video I've seen that isn't misrepresenting what the article actually says to support some "monoliths are back" or "amazon went back to monoliths" narrative. It was very disappointing seeing some distinguished/notable software developers misrepresenting what actually happened (at the same time, I was also confused if I missed something).
Many of the issues are caused by CTOs that forces a specific technology on all of their backend systems, when they should in stead use the right technology and implementation for each of the use cases.
Good explanation, Wise analysis of the case study. Totally agree with your opinion (even before watching the video). However, the red color sucks in the black background 😅 (yellowor orange could be better)
Step function is a bad product. Amazon prime team just chose wrong service and it doesn't mean serverless is bad and monolithic is good in terms of cost.
Nevertheless, it is not monolith since it uses separate services for partners’ upload and customer download ;) *nonsense*: it is same as discussing “why Windows is monolith”. Both terms, “monolith” and “serverless”, are not applicable to the platform providing these design patterns out of the box.
Senior engineer at Amazon here. I generally dislike comments that may be perceived as negative, but I do believe we are using the wrong terminology here. This service didn’t switch from “serverless to monolith”. They switched from distributed microservices to monolith which isn’t the same thing. In fact, many of the components of the current infrastructure of this service (S3, SNS, CloudWatch, IAM, etc) are serverless. Others are not. Just like you can have self-hosted microservices, you can also have a monolith built on serverless technologies. E.g: using Fargate on top of ECS. This is a hosted monolith that uses some serverless components. It’s also important to highlight that the tradeoffs for using these technologies internally are somewhat different from using them externally. Side note: the description is linking to the wrong article.
First, title is a huge click bait. Second, they still use serverless for several operations. Third, serverless is not the only way to implement microservices. Fourth, they turned a solution based on distributed serverless functions into a service, which can perfectly be considered as a microservice itself.
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Good to know Amazon is no longer spending so much money on Amazon
Lol
Put it simply, there's a certain threshold on the ratio of runtime to requests/sec where Lambda & step functions aren't cost optimal compared to a running instance. Of course putting this in a single process in-memory and adding batching will improve performance. This is not a case of Serverless vs Monolith, simply meh vs good design. We had a similar case at work with per sec image processing where we simply used an instance running the same service in parallel for each source devices. Btw, just found your channel, I rarely comment on videos but had to say that I love your content, helped me understand the IGW pretty well!
Cost optimization is a tenant within AWS for its customers. I don't see any problem with AWS using the same cost saving approach with its own services. This doesn't mean serverless is crap, don't use serverless, etc. It means cost savings and only that. AWS analyzed their tech stack and came up with the same performance at less cost. Nothing more to see here... Great explanation!
Great video.
I really don't get when people try to force others into trashing completely an approach. I think in the tech world, the right answer is always "it depends". There is always a trade off in every solution. A good architect is the one who find the trade off that is more convenient for that specific customer, in that specific scenario, in that specific use case.
Very well said.
100% spot on
Agreed, but in this case their approach sucked. Like they used the tool wrong and their structure was not good. So yes not the fault of lambda functions
@@krisnrgtrue, it was odd to start with. Would be interesting to know which factors drove them towards the first solution.
Thank you for doing this video and exposing the reality. A bunch of youtubers needing attention grabbing headlines have completely distorted the message.
Good video, I personally like these architectural deep dives
Firstly, the use of S3 as a malformed in-memory cache confused me when I first read the article. Personally, something like EFS seems like itd be better suited for the job but who knows
Secondly, it seems like they just re-architected as the problem space changed. They realised the solution they had before couldn't handle large amounts of streams and, thus, they rearchitected. The idea that we have to be "team serverless" or "team monolith" always struck me as a misguided argument when it should be "team best-tech-for-the-problem-at-the-moment"
Yeah, people forget isn't about being on team X or Y but using the correct tool
Thanks Martin! If others like this type of content please upvote so I know to make more!
Yea this is my approach. The golden rule of cloud architecture. There aren’t solutions only pros and cons to each approach.
Great video. Really only the 2nd video I've seen that isn't misrepresenting what the article actually says to support some "monoliths are back" or "amazon went back to monoliths" narrative. It was very disappointing seeing some distinguished/notable software developers misrepresenting what actually happened (at the same time, I was also confused if I missed something).
I had been waiting for your take and was wondering why it took so long 😁 .Thank you. Excellent
Thanks Gustave and hope you enjoyed!
Thanks a lot!
You might want to improve the colors used to write, red is not that clearly visible.
Thanks Luis! Definitely will fix for next time.
Thank you! I've been waiting for this video 🙌🏼
Hope you enjoyed!
Many of the issues are caused by CTOs that forces a specific technology on all of their backend systems, when they should in stead use the right technology and implementation for each of the use cases.
Good explanation,
Wise analysis of the case study.
Totally agree with your opinion (even before watching the video).
However, the red color sucks in the black background 😅 (yellowor orange could be better)
Thanks Driss! I know the red was so bad! For some reason the pen width was smaller and I didn't realize it until afterwards :( Live and learn.
As always, great video.
Thank you.
BTW, what is the tool that you are using for the handwritten note?
Thanks Pramesh! I'm using OneNote.
@@BeABetterDev OneNote!! Wow !! You have a great handwriting !!
Thank you!
Great breakdown. Thank you. Reminded me of Khan Academy. What do you use to draw on the screen like that?
Hi Alex, I used OneNote and a drawing tablet.
Red colour is not clearly visible
i see it good in a ultrawide screen
Step function is a bad product. Amazon prime team just chose wrong service and it doesn't mean serverless is bad and monolithic is good in terms of cost.
Yeah half of those shiny services and dev tools from all the cloud providers are dog shit except the traditional services
Lol, felt like I’m watching khan academy for Aws. Really like the format!
Thank you for the feedback!
Right on!! Awesome video
Nevertheless, it is not monolith since it uses separate services for partners’ upload and customer download ;) *nonsense*: it is same as discussing “why Windows is monolith”. Both terms, “monolith” and “serverless”, are not applicable to the platform providing these design patterns out of the box.
Senior engineer at Amazon here. I generally dislike comments that may be perceived as negative, but I do believe we are using the wrong terminology here. This service didn’t switch from “serverless to monolith”. They switched from distributed microservices to monolith which isn’t the same thing. In fact, many of the components of the current infrastructure of this service (S3, SNS, CloudWatch, IAM, etc) are serverless. Others are not.
Just like you can have self-hosted microservices, you can also have a monolith built on serverless technologies. E.g: using Fargate on top of ECS. This is a hosted monolith that uses some serverless components.
It’s also important to highlight that the tradeoffs for using these technologies internally are somewhat different from using them externally.
Side note: the description is linking to the wrong article.
Yeah, the redesign is not a monolith. The whole argument is absurd.
First, title is a huge click bait.
Second, they still use serverless for several operations.
Third, serverless is not the only way to implement microservices.
Fourth, they turned a solution based on distributed serverless functions into a service, which can perfectly be considered as a microservice itself.
I hope they lay off whatever's left of the Amplify team and let that trash heap die.