This feels like a pretty monumental change - my team(s) have historically avoided Lambda specifically because the local dev flow is such a pain and/or open to interpretation, but local dev tooling for building and working with containers is great. At the same time, creating task definitions for one-off tasks in ECS or similar is also kind of a weird workflow if the task is shortlived or event-driven.
Using an actual container orchestration platform when you need it, and a lambda to run the same container image one-off when you don't need orchestration, feels like a best of both worlds.
I like the idea of "serverless" being more "your packaged execution environment, running with no regard for the underlying host" than "your code, running with no regard for the underlying execution environment".
EDIT: Disregard.... see the AWS team's responses in this topic for the full story, its not quite as convenient as anything packaged via standard container being able to run on Lambda
Worth noting this isn't bring any application and publish as AWS Lambda, but rather build from a specific Lambda base image and package your Lambda code into it. Fargate likely closer to what you are describing here
You don't need to build from a Lambda specific base image - you can use (nearly) any base image you choose. Your application just needs to implement the Lambda runtime API, which we provide clients for in multiple languages.
Using an actual container orchestration platform when you need it, and a lambda to run the same container image one-off when you don't need orchestration, feels like a best of both worlds.
I like the idea of "serverless" being more "your packaged execution environment, running with no regard for the underlying host" than "your code, running with no regard for the underlying execution environment".
EDIT: Disregard.... see the AWS team's responses in this topic for the full story, its not quite as convenient as anything packaged via standard container being able to run on Lambda