Reviews (1-25 of 35)
- AWS Lambda is a welcoming platform, supporting several languages, including Java, Go, PowerShell, Node.js, C#, Python, and Ruby. And if you need to deploy a Lambda function in another language, AWS offers a Runtime API for integration.
- We really appreciate how AWS Lambda is always-on for our functions, with only a brief "cold-start" waiting period the first time a function is called after being dormant.
- In addition to only generating costs when it's actually being used, AWS Lambda really puts the "serverless" in serverless architecture, offering turnkey scaleability and high availability for our code with zero effort on our part.
- Putting a significant portion of your codebase into AWS Lambda and taking advantage of the high level of integration with other AWS services comes with the risk of vendor lock-in.
- While the AWS Lambda environment is "not your problem," it's also not at your disposal to extend or modify, nor does it preserve state between function executions.
- AWS Lambda functions are subject to strict time limitations, and will be aborted if they exceed five minutes of execution time. This can be a problem for some longer-running tasks that are otherwise well-suited to serverless delivery.
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.
In the organization, we have got a need to increase the monitoring and availability of the systems, because of which we have created several scripts that run on a server for every 15 mins to extract data from one system and store it in a database. It was working fine when we have a few scripts and less number of CRON jobs. We have a complex environment, we interact with multiple systems most of the time and there are several logs that are captured in different systems, so our number of scripts increased, eventually jobs increased to run. We started to see a bottleneck on the server, so we started to think Cloud alternative and analyzed about the usage of AWS Lambda functions.
- Lambda functions are best in our use case because they are serverless and you could schedule AWS Cloud watch events to run periodically.
- Less expensive.
- Fast execution.
- Learning curve, it was a little bit challenging to start with, especially NodeJS runtime functions.
- Easy alerting mechanism upon failed invocations.
- Troubleshooting errors. We can write logs inside the function, however, if we have the ability inside the Lambda function where you raise a type of error, it can create an alert automatically, it would be great.
- AWS Lambda is a great compute engine that allows you to run and execute your computation code without the need of maintaining servers and the overhead that comes with that.
- We all can use our favorite programming language to develop the functions.
- AWS Lambda is the fastest server setup on the market.
- The relationship with S3 Triggers leaves a lot of room for improvement.
- The solution community forums leave a lot to be desired.
- The AWS Lambda UI experience could aid an overhaul. It's not unusable but not a great reflection of how great the service product is.
- I have used the AWS Lambda for moving the RDS snapshots from cross-region like East to West and West to East. We used it as part of our DR solution. AWS Lambda is the service provided by AWS, and it makes it easy to manage the AWS resources.
- I have used AWS Lambda for running a cleanup code against the database at scheduled times. I use Python as the coding language. AWS Lambda is the service provided by AWS, which makes easy to manage the AWS resources.
- We can use AWS lambda function for serverless architecture.
- We can use AWS Lambda for managing Micro-service architecture.
- AWS Lambda has not worked in an efficient way for running long-lived applications, especially on serverless architecture.
- AWS Lambda provides a zip deployment method, but there is a limit on size, like 500MB.
- AWS Lambda has a significant issue with "Cold Start." It takes some time for it to handle the first request -- there, we see a real problem.
- Runs "functions" in the cloud. Pretty simple really
- Always having the latest version available
- Not having to worry about infrastructure
- Anything too complex is not a great solution
- Can take a little while to spin up if inactive for a while
- Can be easy to misuse or abuse.
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.
- It is an excellent tool for continuous integration.
- It allows for executing code triggered by other services of AWS.
- Ideal for serverless applications.
- Cross-platform support.
- A great tool for scalable projects, which allows us to configure the resources and time necessary to execute a function.
- It constantly changes from one instance to another, so there is no control over the execution environment.
- It is not ideal to run functions that take a long time to run. For example, the upload of heavy files, videos, etc.
- The learning curve is steep. It requires a lot of knowledge to be able to take advantage of it, since you have to know the average time of execution of a function to be able to configure it correctly, besides having the most optimized code possible.
- Simple implementation and deployment.
- Quickly scale up and down on demand.
- High performance and high availability.
- Well integrated with other AWS services like S3, SQS, IAM, and SNS.
- Save costs as we only pay for our Lambda function when it is triggered.
- Have a limit on accessing underline VM.
- Lack of name and documentation for Lambda function.
- Not well integrated with VPC, which will face an issue when Lambda function needs to access the resource both inside and outside VPC.
This allows us to keep throughput for messages in our app low, and scaling is nearly automatic and instantaneous. We needed a way for our app and data to be presented to a multitude of 3rd party applications and services and didn't want to make all these points of contact happen inside our main app. Therefore we chose a queue-based approach where our main app delivers messages to a queue and the Lambdas pick those messages up and process them until the queue is empty or more Lambdas are needed.
Lambdas have proven to be very cost-effective and prevents us from needing to incur uptime for other servers.
- Reliability - Lambdas just work. They do their job and quite well. I've never had any hiccups with them as a unit of hardware.
- Scalability - This automatic scaling and availability are amazing. It's like having a fleet of servers at the ready but only when needed. And at a fraction of the cost.
- Price - AWS gives you a generous helping of free invocations every month, and even after that, it's still cheap compared to an always-on solution.
- The UI and Developer experience is not so great. IF you use an abstraction like Serverless Application Model (SAM), things get pretty easy, but it's still AWS UI/DX you're working with after that (which is to say, not their strength).
- Documentation is always a mixed bag. Sometimes it's just easier to google your specific problem and see how others have solved it. This can be much faster than trying to find an example that may or may not be there in the documentation (which oftentimes has multiple versions and revisions).
- Cost Savings
- AWS integration
- Python and Go support
- Need to rely on 3rd party tools for complex deployments
- Precompiled Python dependencies sometimes won't work
- Inability to share test events with other users
- Reliable for low workloads.
- It's an easy entry point for development.
- Quick speed to market.
- It would be good to have more distribution about upgrades or changes to the platform.
- A little more documentation on the nuances of the offered supported languages.
- A little more portability of some of the code once you've developed it from other cloud platforms.
- It automatically scales up your functions when demand is high.
- It allows developers to focus only on business logic,
- It is very cost-effective, since you're not paying for idle server time.
- There is a lot to configure, as is the case with most of AWS's offerings. I wish it were easier to set up API Gateway with Lambda responders.
- The default logging destination (CloudWatch) leaves much to be desired, and we opted for an external logging tool (Splunk) instead.
- Cold starts are a persistent problem which can be mitigated with a simple cron job but would ideally be handled by the platform.
- Easy to set up.
- Support different programming languages.
- Events-based trigger.
- Continuous deployment integration with GitHub.
- Would like to easily toggle between environments.
- An interface to map out/organize different functions.
- No need to maintain architecture.
- Easier operational management with AWS console.
- Scaling benefits of FaaS beyond costs. You pay only for what you used.
- Vendor lock-in, dependency on AWS ecosystem.
- It's a bit difficult to get started. AWS needs to provide more getting started examples.
- UI is a bit dull and messy. They should make it cleaner.
- Scalability - No worries for load balancing.
- Flexibility- Easy to integrate with Python/ Java/ C#/ Node.js, etc
- API - APIs are easy to integrate.
- Microservices - Best option is to be able to use microservices with serverless architecture.
- UI - The UI part can be groomed for beginners to easily take on the tasks.
- Debugging - Again it becomes tougher for naive users to onboard and use the tool at its full capacity.
- Lag- The tool lags on slow networks which can be improved.
- Alexa skills.
- Serverless architectures.
- Ability to create RESTful APIs.
It is also very easy to integrate it with other AWS services, like consuming AWS SQS or SNS messages, and you can write your own API in minutes while integrating your Lambda with AWS API gateway.
- No need to worry about the maintenance of your lambda.
- It is scalable and you can always change the memory allocation and timeout.
- Integration with other AWS Services is great!
- Pricing is reasonable.
- I think the cold start of AWS Lambda may be improved. The termination period of a lambda is 15 minutes. If the lambda service being called each time for less than 15 minutes there would be no cold start problem at all. The cold start problem could be solved like triggering a dummy request every 15 minutes, but that would cause some cost for the company.
- Short computational code - For those that need scalability without maintaining servers, AWS lambda basically achieves all of this as one service.
- Scalability - For most lambda services, you are charged by run amount, as long as run-time remains low.
- Non-hosted websites/serverless code - Services like Netlify implement similar lambda functionality that is completely free. There may be services hosted on Amazon that achieve the same.
- UI could use some improvement - Like the rest of the Amazon Web Services UI, much of the interface is complex and hard to understand at the beginning.
- Hard to troubleshoot/debug - Lambda, in itself, is set up in an environment that makes it difficult to troubleshoot in the product. The use of staging production code is absolutely necessary.
- The pricing is a bit more expensive when compared to other services that provide lambda function execution services.
- It scales endlessly. We chose AWS's serverless architecture specifically for its ability to start small and scale as needed.
- Its always available. AWS's geographic redundancy and serverless architecture mean there's no server downtime. Ever.
- From a PM's perspective, there's a learning curve. We've had to either hire out experience engineers, or absorb the not-insignificant orientation of not-yet-initiated engineers. But I suppose the same is true of anything.
- Your organization is fairly well established (see: runway)
- You're married to AWS Infrastructure
- You hate servers
- You aren't utilizing AWS's manages services
- Your organization is still in the boot-strapped stage (trying to run as lean as possible)
- AWS Lambda is fully-managed. It is easy to build and manage functions and related resources with the Serverless framework.
- AWS Lambda integrates well with other AWS products. It is easy to use S3, SNS or DynamoDB events to invoke functions.
- For some use-cases, AWS Lambda is very inexpensive. Sub-second metering is great. Lambda is great for infrequently-used or bursty services.
- Managing development, staging, and production environments with Lambda is an open question. Some organizations use separate AWS accounts for different environments, but that is not feasible for teams that use ephemeral, per-feature or per-team development environments.
- AWS Lambda integrates well with other AWS products, and it is natural to build distributed systems from them. It can be difficult to test features that use Lambda functions end-to-end. LocalStack and moto can help.
- Lambda functions have very limited access to disk space.
- Container cold-starts can be problematic and difficult to foresee.
AWS Lambda Scorecard Summary
Feature Scorecard Summary
About AWS Lambda
AWS Lambda is a serverless computing platform that lets developers run code without provisioning or managing servers. With Lambda, users can run code for virtually any type of app or backend service—all with zero administration. It takes care of requirements to run and scale code with high availability. Users pay only for the compute time they consume—there is no charge when their code is not running.
Developers uploading to Lambda don’t have to deal with their code’s environment. It’s a “serverless” service which lets outside code or events invoke functions. Lambda doesn’t store data, but it allows access to other services which do. Users can set up their code to automatically trigger from other AWS services or call it directly from any web or mobile app.
AWS Lambda Technical Details