Prime Video's Prime Video team had followed the path that I refer to as Serverless First, where the initial attempt at creating things is built using Step Functions and Lambda calls. The blog post states that it was easy to construct and that's the reason. If you're trying to figure out how to make something, making the prototype within days or even weeks is an ideal strategy. After that, they attempted to scale the service to handle large volumes of traffic. They discovered that certain states in their step function were often too frequent and there were some busy calls that were made between AWS lambda function and S3. The team was able to reuse the majority of their code in one long-running microservice which is scaled horizontally using ECS and is executed using a lambda. It's only one of numerous microservices which make up this Prime Video program. However, they referred to this as changing a microservice into a monolith, but this is clearly a microservice-based Refactoring process, and it's exactly what I advise people to take in my presentations on Serverless first. We don't support "Serverless Only", and I advised that if your needs require continuous high-traffic, efficient and low latency it is best to implement your prototype in an autoscaled, continuously running container that is part of a bigger serverless-based event-driven architecture as they have done. If you had it built in a microservice form to begin with, it will be slower (especially since you will have to make many decision-making decisions regarding how to create and manage it) as well as be more difficult to modify as you work out what you intend to achieve.

amazon.com/code