AWS Lambda Reviews

[AWS Lambda] is very well suited for the projects that doesn't have any infra but needs it where short running processes are required. But if your application need to run continuously than this might not be the very apt tool for you.

Process large datasets where bigger files are broken into smaller ones. Executing step functions. Submitting requests for Sagemaker pipeline. Submitting queries to Redshift data API. Managing dynamodb records (read-write).

I believe the main concern is about costs. If your function calls generates profit, no problem with the amount, as more [is] better. But if this is not the case and your user case trends to grow without associate profit, maybe by provisioning dedicated resources (EC2 instances for example) to run your functions will hurt less in your wallet.

AWS Lambda is most suited as a Serverless methodology. When you do not want to handle the software and only want to work on logic and code development, AWS Lambda is the best option. You can also trigger AWS Lambda from many AWS services like when a new row is added into DynamoDB or when a new file is uploaded to S3 or also when you want to execute Lambda once a day or at a specific intervals(cron jobs).

AWS Lambda works very well when you want to execute some code without our server interaction.
It provides sample code also, so you can quick start building our own functions.

AWS Lambda has very much pre-defined expression structure which can fit almost all our scheduler job requirements.
It also provides test functionality to test function before go to live.

AWS Lambda is useful to use as an additional business service, as part of some bigger tasks like store images, by example, although the system limited by bandwidth when sending big files.
AWS Lambda should not be used in case of long asynchronous requests to another cloud, by example. It saves time and money to deploy average project logic anyway.

Working with Web and mobile apps well suited for Lambda. It provides a clear support path and improvement. Also it helps to reduce cost and accelerate speed of reaction on changes.

A sess appropriate scenario would be when CIO push to implement new technology and services without clear understanding of the results and project needs.

A great example of using AWS Lambda is when your application needs to be able to render images for the user and have those images be resized and optimized on load. Using AWS Lambda you can create endpoints with a minimal amount of code that allows your applications to request the images and use query parameters to declare the height and width etc.

I would recommend using AWS Lambda when you have one-off tasks that can be accomplished with a single function and do not require a persistent, constantly running compute resource. Some example use cases include file or image processing, data analytics (you might have DynamoDB stream updates to AWS Lambda for processing), in conjunction with API Gateway as a backend.
I would not recommend using AWS Lambda when your Lambda function has potentially long-running, asynchronous calls involved (e.g., calling out to a service hosted in another cloud platform). This can drive up execution time and, in turn, cost. While Lambda layers allow you to share code between Lambda functions, I would not recommend AWS Lambda for cases where there are high degrees of interdependence between the Lambdas. I think that Lambdas work better when considered isolated.

Well suited:
1. when we need to worry about time to market and we don’t have infra defined.

Not suited:
1. Not suited for Business Client transactions as its server are located out of Switzerland and hence country laws are different

Easy to manage and integrate backend when sending request either via API or web interface. However, limited by bandwidth when sending large request with big files.

I would definitely recommend using Lambda for short-running, event-triggered processes that are dedicated to a single function. This could be for one-off processing or intermediate tasks between other resources like objects stored in buckets and queues for processing those objects. Also, since Lambda executions can be scheduled, processes that need to happen on regular intervals can be implemented with Lambda as well.
I would not recommend using Lambda for anything that needs to run longer than a few seconds. Long running processes like ETL jobs or intensive computations may be better suited for step functions, batch jobs, or even a server based approach.

The main area in my point of view is the automation reduction of costs. You can program and use Lambda to execute several tasks based in several types of events like logs, schedules, and output from other AWS tools. With the AWS API, you can do almost anything you want and your function will use only the needed resource (memory, cpu) so it is optimized.

I think it works really well for managing workloads without the need to manage the underneath infrastructure.

AWS Lambda is a great way to deploy smaller-scale data synchronization jobs and other "housekeeping" routines that don't require preservation of state. We use it to build API gateway tools used by our larger applications (many of which are hosted on AWS EC2 instances) and it's a perfect fit.

If you have complicated workflows that run a long time, or require state to be saved between function calls, AWS Lambda is probably not the right choice for a serverless solution.

AWS Lambda is very well suited to the scenario in which I use it; namely, Alexa skills. To respond to an Alexa skill request, it would be inefficient to spin up a server. For applications that run continuously and are not event-driven, AWS Lambda is not well-suited.

I know a lot of our developers use this personally to develop Alexa skills. The best use case for us is building simple rest API's with minimal effort and overhead. It is easy to use and scalable. You can also through a lot of load against it very quickly with little to no performance issues that I have seen. Also, it is very well suited in environments where developers have language freedoms.

AWS Lambda is best for short-lived applications/codes. Configure AWS Lambda to act based on the events that are produced on certain services. It works. We used it to move the RDS snapshot from WEST to EAST and EAST to WEST whenever the RDS automatic backups are done. It helps in other scenarios, like when application teams don't have a server or don't have a place to run a job on a regular basis. Then we can leverage this AWS Lambda to run the code against the database. As I mentioned, this is not suited for long-lived applications.

Anywhere you have an isolated responsibility of your code, AWS Lambdas are well suited for. If you have something that has to perform an intensive calculation - it makes sense to offload that to something like an AWS Lambda. Or something that needs to send data and integrate with another service, it can be a good place for that interface/job to live.

It can be possible to build a larger architecture using a series of AWS Lambdas, but it could become hard to maintain and be hard to understand very quickly.

AWS Lambda is best for new, small applications. With frameworks like serverless.io, the deployment issue is completely negated. Managing large serverless applications becomes easy. With the technology, a significant amount of the scaling and other performance related issues are handled. Programmers are left to deal with RAM and processor issues on a per execution basis.

AWS Lambda is suitable when we need to process data on demand and require a large number of instances. AWS Lambda is not too complex, and it will fit well in case we need an authentication function to verify user login information, process input data in S3, retrieve and execute message SQS or triggered on demand by the user. AWS Lambda would not fit if we needed to constantly receive user requests, run background processes or needed to access VM underline.

If you're not afraid to get your hands dirty in wiring things up yourselves or you can use AWS' own abstractions like Amplify or SAM, then Lambdas and their surrounding platform pairings (Like SQS, API gateway) are great tools that can help you create a backend or infrastructure for a relatively low cost. If you don't find yourself in that camp, but you know your way around full-stack JavaScript frameworks and tooling, you may be better served with a higher level abstraction like what Zeit Now or Netlify offers.

AWS Lambda is best used in environments where you need to perform specific actions in response to an event happening. This reduces cost and will only be billed for the CPU time it takes to run the function. For long-running tasks, AWS Lambda is not good because of the timeouts set by the function.

AWS Lambda is well suited for batch scripts, and API development.

AWS Lambda is great for atomic micro services and being leveraged as a conduit for other Amazon services. It's great for a quick way to innovate other resources that you already have on the platform. It marries well with the ecosystem and allows for easy deployments and updates to the program based on the tools.