41–50 of 526 posts
I love how some of developers jumped on the serverless bandwagon with some of the least "serverless" workloads first "Let's make our entire website serverless now" erm, no? It's cargo culting of the worse kind
Understanding this behavioralism will get you through many situations in life.
I'd be surprised if this doesn't get taken down as it casts AWS lambda in an unfavorable light (and rightly so). That's the impression I have of Amazon's leadership but maybe I'm wrong.
> We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly. The message seems more that they outgrew AWS lambda but that lambda was a good choice at first.
I'm pretty convinced that microservices are one of those things that make sense 5% of the time and the other 95% is cargo culting.
If you ask me, if the time and focus is invested properly, it would be much more efficient to run a monolith instead. That's what some small number of great teams end up doing.
Sending video frames between services is expensive, also doing per state transition hosting on things doing state transitions multiple times per second in a single stream is also expensive... Like, did they even think about cost when designing this the first time?
Considering they don't actually pay the bill for this and it is internal accounting, probably not. Belt tightening has probably pushed cloud providers to figure out if they're wasting stuff they could put to better use, and I assume when it launched and nobody was watching Prime Video, inefficiencies were both smaller and less noticeable.
I'm pretty convinced that microservices are one of those things that make sense 5% of the time and the other 95% is cargo culting.
A lot of people here say...one service per team. But to me that is, or can be, a monolith. Often a team is a product line, so you have one service for that product. Is that a monolith? I don't know either, I guess.
I -do- know most people who go around promoting that sweet microservice life end up being the worst. They seem to want every db table to be its own service, introduce tons of message passing and queues, etc, for absolutely no reason. I think we can probably all agree that is about the worst way to go about it.
Next they will transition to on premises hardware from the cloud to save another 90%.... oh wait...
I'd be surprised if this doesn't get taken down as it casts AWS lambda in an unfavorable light (and rightly so). That's the impression I have of Amazon's leadership but maybe I'm wrong.
> We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly. The message seems more that they outgrew AWS lambda but that lambda was a good choice at first.
I love how some of developers jumped on the serverless bandwagon with some of the least "serverless" workloads first "Let's make our entire website serverless now" erm, no? It's cargo culting of the worse kind
It's the same story as NoSQL. "Let's migrate our transactional data that requires strict referential integrity to CouchDB... Oh, wait..."
It’s something they use to check for defects in the video stream - hence the storing of individual frames in S3.
Original title: Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%