4 ms·
That's fine, except for all of Lambda's weird limitations: request and response sizes, deployment .zip sizes, max execution time, etc. For anything complicated
by icedchai 1y ago
That's fine, except for all of Lambda's weird limitations: request and response sizes, deployment .zip sizes, max execution time, etc. For anything complicated you'll eventually you run into all this stuff. Plus you'll be locked into AWS.
- themafia 1y ago> request and response sizes If either of these exceed the limitations of the call, which is 6MB or 256kB depending on call type, then you can just use S3. For large distributed task coordination you're going to be doing this anyways. > deployment .zip sizes Overlays exist and are powerful. > max execution time If your workload depends on long uninterrupted runs of time on single CPUs then you have other problems. > Plus you'll be locked into AWS. In the world of serverless your interface to the endpoints and semantics of Lambda are minimal and easily changed.
- icedchai 1y agoOf course, we can generally work around all these things. The point is it is annoying to do so. It adds friction and further couples you to a proprietary platform. You're better off using ECS / Fargate for application logic.