AWS Lambda Reviews

We use AWS Lambda for various tasks, such as triggering reports, queueing calls for displays on our dashboard, and integrating with environmental variables for different outputs.

AWS Lambda saves a lot of time in our project deployments by allowing us to create users, establish user policies, handle voice mail set-ups, and develop dashboards with live views of agent status and queue additions, thus enhancing overall efficiency and cost-effectiveness.

One of the really handy features is keeping the environment variables in the Lambda for our outputs. It makes configurations more convenient as changes can be made through the environmental variables without altering the main code.

One area of improvement is Lambda's runtime version management. It currently requires manual user maintenance to upgrade and evaluate, and an automated provision for this would be beneficial.

We have been using AWS Lambda for more than two years, starting from the deployment of Amazon Connect.

AWS Lambda is quite stable. However, any changes in versions may require small code adjustments, which we must manage.

AWS Lambda offers a high level of scalability. It can handle multiple calls automatically when busy and reduce to one when free. I rate it a nine for scalability.

AWS offers excellent technical support. They have been very helpful, especially when one of our Lambdas was not functioning due to a minor code discrepancy that required a simple fix.

Positive

The setup for AWS Lambda is quite easy. The challenge lies mostly in ensuring our code is error-free for successful execution.

AWS Lambda is very cost-effective. It allows for one hundred thousand requests for free per month, and subsequent requests incur a very low cost per trigger.

Ensure that you have foundational knowledge of cloud formations or other AWS services for an optimal experience with AWS Lambda.

I'll rate the solution ten out of ten.

Lambda is basically a serverless computation service. We are partners with AWS and I'm a consultant. 

Because Lambda is serverless, it has optimized our resources. There's no need to worry about capacity. 

Lambda is very handy because it gives us the parallelism of computation. If you want to launch thousands of instances simultaneously, it can be done on one site. The solution has a 15-minute computation limit but you can create a chain with the same code so that the output automatically switches to another functionality after 15 minutes. 

The only issue is that if you have Lambda in one AWS account and want to utilize it in another account, it can't be done. It's a limitation of the solution. S3 bucket provides that option with its resource access management. If you have a Python library and want to package it, you have to create the package of those libraries. It requires changing the conflict file and the patent library to create the package because the configuration is a little difficult for beginners. They should simplify package creation and configuration. Writing test cases is a little difficult because of the memory and short duration. Your computation has to be finished within that time limit. 

I've been using this solution for five years. 

We haven't had any performance issues because Lambda automatically gauges the kind of computation required.

The scalability is excellent and there is no capacity limit. 

Provided the person deploying the solution knows the format of the input, the setup is relatively simple for experienced users. Deployment doesn't take long because of the integrated machine services. Our implementation was carried out in-house. It doesn't require any maintenance once it has run for a month.

Licensing costs are reasonable even though you have to pay for the computation and for the volume of data. Once the work is done, the storage is freed up so you only get charged for the instance. 

If an organization wants to go serverless, Lambda offers a truly serverless service. Even though there are some areas that could be improved, I rate this solution 10 out of 10. 

AWS Lambda is a serverless computing service provided by AWS. It is allowed to run the course without the provisioning or managing server and paying only for the compute time consumed during execution.

The most valuable features of AWS Lambda are a serverless and event-driven architecture. The solution provides automatic scaling and supports languages like Node.js, Python, and Java.

AWS Lambda should support additional languages.

I have been using AWS Lambda for two years.

AWS Lambda is a stable solution.

More than five people are using the solution in our organization.

The solution’s technical support is good.

The solution’s initial setup is easy.

AWS Lambda is a cheap solution. The solution has a generic pricing before being triggered. After triggering, we need to pay the bill based on how much time the server runs.

Our company decided to use AWS Lambda because it is integrated with AWS services. The solution enables the building of serverless applications and provides automatic scaling and event-driven execution. AWS Lambda can be triggered by various AWS services like AWS S3, DynamoDB, AWS API gateway, and AWS CloudWatch.

I would recommend the solution to other users. It is easy for someone to learn to use Lambda for the first time.

Overall, I rate the solution ten out of ten.

I have to send daily reports. We have many child accounts in AWS Organizations. We need reports on the cost of the accounts. I use AWS Lambda because we have to run the code without provisioning the servers. AWS Lambda is a serverless computing service.

The tool scales automatically based on the number of incoming requests. It supports multiple languages. We can use Python, Java, and Ruby. We can use the solution to stop and start the instances.

We must at least know the basics of languages like Python or Java to implement automatic processes and daily schedules. We must learn the Lambda function and the languages to use the tool.

I have been using the solution for three months.

I rate the tool’s stability a nine out of ten.

I rate the scalability an eight out of ten. We have more than 100 users.

The support team does not know how to implement and build the solution.

Neutral

We must know Python or Java to implement the product. It is not easy, but it is not difficult. We need some experience.

We only need to pay for the compute time our code consumes. The solution does not cost much.

I will recommend the product to others. We can automate the processes and integrate the solution with other services. The product provides elasticity and automatic scaling features. Overall, I rate the product a nine out of ten.

My prior company used the solution to perform event-based actions and notifications, process data in an S3 bucket, and send messages in the SQS queue. 

Our development team worked with 300 users across different departments to integrate the solution. 

The serverless format is a benefit because on-demand computing can be performed without having to run machines.

The solution integrates well with API gateways and S3 events via its AWS ecosystem. 

The solution works with various programming languages including .NET and Java. 

The solution should continue to streamline integrations with AWS services. 

At one point, there was an issue receiving support for a new version. Support was behind by two versions and this presented challenges, but they caught up over time. 

I have been using the solution for three years. 

The solution is very stable. 

The solution is scalable for users because it is serverless. You can provision IAM users and easily give them access.

We scaled a core from one million to ten millions runs with no issues.  

I never needed to contact support. 

The setup is very easy and onboarding happens quickly. 

We implemented the solution in-house.

Implementation includes determining which APS you need, writing code, and packaging it all for upload. There is no real deployment other than adding the package to your CI/CD pipeline and pushing it. We do not consider this work to be substantial. 

The operational push takes a matter of minutes. 

The ROI is definitely worthwhile because pricing is based on use. 

The pricing is on-demand and based on runs or times that are billed out monthly. 

For example, one million requests might cost 20 cents. 

Our company wanted to compute in an ad-hoc manner. The solution allowed us to schedule cron jobs which made things easier. 

The solution also integrates well with the AWS suite of products so can be used with an API gateway and S3 functions. 

The solution can be used for many scenarios encountered by IT developers. There is a general push to create serverless systems that have on-demand use and price models. For most use cases, there is a 50% chance the solution will be a good fit.  

I rate the solution a nine out of ten. 

We are building microservices in Lambda and exposing them via an API Gateway for the end consumer. These microservices talk to DynamoDB, or third-party APIs but can also be event-driven. These microservices carry out specific business functionalities.

We have plans to increase usage in the future. We have been modernizing our usage of SOA technology and rewriting those SOA services on the cloud using AWS Lambda. We are transitioning to a serverless environment using Lambda. 

Lambda is the preferred compute option because of on-demand cost. We don't have to provision any hardware beforehand. We don't have to provision the capacity required for the services because it is serverless. 

AWS takes care of things behind the scenes and we pay only for usage. We don't have to incur uptime or the upfront cost to procure a EC2 instance or create any ECS service.

You can trigger Lambda in various ways including API Gateway events or a S3 object event. You can create a file in SP and it can trigger a Lambda function. You can process the file based on the event and complete asynchronous programming. It supports both synchronous as well as asynchronous programming. It is integrated with variety of AWS services like the S3, SQS or SNS.

You can use Lambda for a variety of use cases. You just have to write a Lambda which can be in various languages including Python, Node.js or Java. There is no limit on what you can do with Lambda because it is integrated with a variety of AWS services. 

The first time Lambda is started up, it takes some time to spin up an instance for serving the consumer requests. AWS has been trying to solve this in a variety of ways but have not yet managed to do so. 

Lambda can only run for a maximum for 15 minutes. If you have a job which requires running for more than 15 minutes, you cannot use Lambda for that use case. 

I have been using this solution for five years. 

I would rate Lambda an eight out of ten for stability. 

This is a scalable solution. I would rate it an eight or nine. You can have 999 Lambda instances running at a particular second at one time. That is the default. It you need to scale above this, you can request for AWS to increase your capacity.

I would rate the technical support an eight out of ten. We do contact the AWS support team if we are stuck or something is not working. They provide their input and we set up a call with them to explain our issues and reach a resolution.

Positive

The initial setup is straightforward. They have variety of ways to set it up via the console, ETK or CFT. You can easily configure Lambda via variety of ways based on your experience. Usually, newcomers will use console which is a UI and makes your task easier. Experienced people will go with CLIs, SDPF or CFTs to create Lambda resources.

We are not just deploying Lambda. We have a variety of AWS services which we combine into one script and we do it via an AWS code pipeline.

I would rate the setup a nine out of ten.

Deployment was done in-house by our own team. The patching of underlying hardware and other maintenance is done by AWS. 

We have experienced a ROI using this solution. I would rate it an eight out of ten. 

Lambda is an affordable solution. They offer free requests every month and charge per the compute time. If you are working in a big organization, usually AWS offer a savings plan where you get approximately 70% discount on pricing.

If one is very affordable and ten is expensive, I would rate this solution a two out of ten. Costing is per account. Production will involve a higher cost. 

If you are planning to implement the solution using scripting language like Node.js or Python, it's better to rather use traditional programming language like Java, or .NET, because Lambda runs faster and more efficiently. We implement it using these scripting languages as the first choice.  

It is important to understand your use case properly and if Lambda is a good fit. Solutions such as Docker, Kubernetes, OpenShift or normal EC2 instances may be a better fit for your business.

I would rate this solution a nine out of ten. It integrates well with variety of AWS services which makes the event-based programming easy. Lambda is well suited to a variety of use cases or applications.

AWS Lambda has serverless programming, like Logic Apps from Azure. You just configure the run-time and then they start coding. It is event-driven. It started with my obtaining Salesforce. Salesforce is a low-code and non-code program and totally SAS. Everything starts from the event, from the trigger. You get the trigger and you work at the program. You have some other models, maybe faster or fancier models. But in my opinion, this kind of program is started by locating the system and identifying where the trigger and entry point of the program are. Then you get the full advantage of the program. You don't need to worry about any infrastructure.

I think this is the future. Compared with the EC2, you don't have to pay anything if you don't run it. Otherwise, with EC2 when our client provisions the system and the instances, you always have to pay. There are other tremendous advantages, like flexibility. After you provision EC2 you can write something that does not totally follow the cloud convention. You use it to provision the container. With the program you need to have those 10 principles of cloud computing. Especially recently, within the past four or five years, I have gotten away from DevOps, or the software development life cycle. Even though I researched the product portfolio from DevOps and then the life cycle for DevOps, I try to position myself as an architect with hands-on experience.

In my opinion, Lambda is very similar to Salesforce, which is the original for the SaaS platform and is an extremely low-code environment. With Microsoft and AWS you can say, "Okay. You can choose whatever language you need to make it even more flexible." 

Everything is the cloud. Lambda is a fully managed service. If you want to do it either as a private cloud or on-premise, I'm sure you can do that, too. But I don't know how to manage the pricing structure. But then you've lost the point of Lambda because if you do not use it, you do not pay. Again, I just want to emphasize, I'm not a Lambda expert. But, logically thinking, the big advantage of serverless programming for the customer is that you just use it and pay. Pay and go. You don't need to provision anything.

All my experience with AWS Azure is on the public cloud. We do not get too deep. In IBM we do. When we do sales training we always get the private cloud on-premise. There are many reasons for this. One reason is that IBM lost the battle for the public cloud so we get into it much deeper. We go to the enterprise and we can deploy programs to your data center and offices. But for the tech data for AWS and Azure, we are all using the public cloud as a showcase when we talk to the customer and to the retailer.

The number one feature with AWS Lambda is that it is fully managed. From the developer's perspective, you get the coding much more easily. Now many situations are not using code. You plug in, assemble it, and configure it. Lambda makes it low-code. I come from being a Java certified developer for 15 years. You configure the environment for deployment just like in DevOps. That was always the most challenging part as a developer. You identified when to trigger it. If the program can't facilitate it, then 80% is gone. With 20% you just Lose Syntax. You can use Lose Syntax with any programming language as a reference finding out the variables, the statements, the loop, and what other kinds of things you can do. Just follow that to where you can plot it into your business system. 

They might think to have the business benefits say, "Hey, if you don't like it, no need to pay." So, potentially, you can save. If the future is going to be serverless, that's what I think the future of something like Salesforce will be. Programming is getting much easier and does not need a lot of configuration because step-by-step abstraction starts from the infrastructure service. You can replace your hardware, but you still need to do a lot of things in the abstract. The environment now is totally fully managed. I'm not sure if we're totally aligned there. I always talk against those aspects in the Salesforce situation. But I believe Lambda is a comparable peer, apples to apples.

I can only speak from the user experience. Salesforce integrates SharesPost efficiently. How? They say, "Okay, I invented another language called Apex. Forget about anything else. This is my language." The benefit of this language is that everything is simplified. Your system is super easy to maintain. But AWS then assures you that they are flexible, that they have a collection of 10 or 20 languages, and you just choose your environment and range. That's the reason I appreciate Salesforce. They always make things easier. They have their loop reasoning because they are a different kind of company. Microsoft and AWS really get the full spec. They want to own the business. But Salesforce data wants the simplest way.

So, this is my understanding and unique experience.

I think that perhaps Lambda could explore its functionality more.

I have been using AWS Lambda for a few months.

I didn't explore enough information to evaluate that.

I didn't experience the scalability personally, only from my reading. Amazon takes care of the scalability. That's the right way. It's automatic and it's fully managed. That's one benefit of Lambda.

We have all kinds and sizes of resellers. There are large enterprises and small businesses. It's different. And some of them are product based, they are creating their own products. Some of them are consultant based. It's really different. Tech data is different vs. a business model.

I contacted support many times. My experience was very little and I just saw how Lambda was working, to try to understand if it is okay.

I don't actually use AWS Lambda. I'm a distributor. I try to explain solutions to the vendor. I previously used Salesforce Apex. I use the Azure Logic App service.

Salesforce does not have so many options to choose from, such as Java or C++. Salesforce said, lets invent a language. They call it "invent" but actually they just made a simplified edition of Java and eliminated a lot of complex features. Now all the syntax is the same. Salesforce is a business company. They focus on business solutions development and they make the customer's lifecycle development simple. AWS really does not stick to any business because they are a technology company.

Let me explain the similar things that Lambda has to Salesforce. When you get the event you have to see our form. With the sales approval process, if you have the 50% to get to the half million and above, you need the vice president to get the approval. You can use this trigger based serverless program. All you want to do is to write down the logic and then put it under the trigger of whenever a certain number changes in the half billion, and then you need to do the multiple steps.

This kind of programming is easily defined in the business. All you need to do is get the logic done, get it tested, see the steps you are doing, and then fix up the errors. As for Lambda, as I said, I've just experienced two very simple examples in the AWS, but they were the same thing.

Logic App and Lambda should be doing the same thing - fully managed coding. You focus on the logic triggered by the certain events. And there are other additions within the Lambda family. It can be scheduled as a batch job. I don't think it's originally lack of motivation from the serverless. The serverless is from the trigger.

The initial setup is straightforward. If you follow a 30 or 45 minute lab, it seems pretty clear.

Everybody should check out AWS Lambda. That's why I didn't explore much and it was at the top of my list. This is a fully managed model. The number one. This is for the future. In the future, many of the EC2 applications may be replaced by Lambda. If I started something from scratch, I would try to use Lambda. It's much simpler. It can simplify a lot. If you add the scalability into the picture, it could have 80% or 90% of the complexity. They are very important. All the servlets are very important from a cloud computing perspective.

On a scale of one to ten, I would rate AWS Lambda an eight.

I am a fan of the no-code, low-code if you consistently improve to make it even simpler. Maybe they could do something to simplify the language. I'm not sure if Lambda has the code for the Microsoft Logic App, which means they can eliminate most of the code and everything becomes drag and a drop. Because they eliminated those "if errors." They have those kinds of functions. I think mostly because I have not explored the whole portfolio of AWS. I believe there is a full suite of them.

I believe their full suite of the service is complemented with Lambda. But I do believe the competition is going to make it simple with low-code, no-code. There is no-code, low-code and also no infrastructure. That is going to be the key. Also, maybe you can have the Lambda ecosystem and have some component of the module built above the Lambda so that people can make graphing and plotting even easier. This is not just any software, you get the module there which is much better. But AWS is big enough to neutralize the ecosystem. I believe it will come but the people don't have the patience to start from scratch these days.

I have used AWS Lambda for simple messaging for SQS, creating a cron job, and delay messaging. Creating a cron job ensures emails are automatically sent to users at a specific time we set. For example, a mail would be sent automatically instead of manually to a user whose subscription is about to expire.

AWS Lambda functions have many versions. Sometimes, it takes a little time to load and run the commands in AWS Lambda. We can write anything as code, but the solution will not give proper error information. It is a little time-consuming to understand where the error came from.

I have been using AWS Lambda for one and a half years.

The solution's initial setup is easy. You can easily code in AWS Lambda if you have good coding experience in any coding language.

The solution is free of cost for the first year, and after that, it becomes expensive.

If you are using AWS Lambda for the first time, you need to know about AWS. You need good coding knowledge to work with AWS Lambda. If you want to code a node, you must know about node and node syntax. If we are using AWS Lambda with Python, you have to know about Python. It is easy to learn AWS Lambda if you have good coding knowledge.

Overall, I rate the solution a seven out of ten.