AWS Lambda is a great place to run some microservices, but due to some of Lambda's limitations, we found that ECS was a better place for some critical workloads.

Fettblog is a blog by Stefan Judis, offering articles, tutorials, and insights on web development, JavaScript, and performance optimization. Developers can learn about web development best practices, modern JavaScript features, and web performance optimization techniques to create fast and accessible web experiences.

DZone

 Prismatic is an integration platform for B2B software companies. The first incarnation of Prismatic used LocalStack to simulate AWS Lambda. We moved Prismatic to an actual production environment, with real Lambdas, queues, databases, etc. Our integration runners ran on real Lambda, and were triggered via SQS.

Why We Moved From Lambda to ECS

<p>Really interesting to know: “Process Isolation. This was the issue that surprised me the most. At first, AWS Lambda seems appealing as a stateless compute engine - run a job, exit, run another job, etc - scale horizontally as needed. We naively assumed that Lambda invocations were isolated from one another, but that turned out to only be half true. Concurrent invocations are isolated (they run in distinct containers within Lambda). However, subsequent invocations reuse previous “warm” environments, so an integration runner might inherit a “dirty” environment from a previous integration run. That’s especially a problem if you let customers write their own code, like we do for our customers’ integrations”</p>
