AWS Lambda Reviews

My primary use cases for AWS Lambda is collecting data from other systems through API, pre-calculations, and ETL.

The feature I found most valuable about Lambda is the fact that it's serverless.

I would like the layers to have a bigger volume. I would like to be able to add more. I don't want to be limited by the layer. 

In addition, writing temporary data to Lambda is not straightforward. Sometimes I use the S3 for that. I found it a little bit challenging. 

I have been using AWS Lambda for a couple of years.

My impression is that it is a stable solution.

I would rate the scalability of this solution a 10, on a scale of one to 10, with one being not scalable and 10 being very scalable.

I have never used Amazon's tech support.

I would say the initial setup was straightforward.

We required two technical staff to do the deployment and maintenance.

We have about 15 to 20 users of Lambda in our company and plan to expand.

There a variety of use cases for this solution but it is mostly used for data processing type transformations from one source to a target. In instances when Lambda works well, we are planning to increase usage. 

Deployment and maintenance of Lambda requires two people but this may increase depending on the size of the deployment.

Lambda has improved our organization by making it possible to transform data.

Lambda has limitations on the amount of memory you can use and is not a good solution for long running processes. If the amount of data is reasonably small, it will run and transform successfully. If you have tons of data coming in, it stops working and you have to restart it.

The orchestration and coordination between different Lambdas could also be improved.

I have used this solution or a couple of years.

This is a fairly stable solution. 

This solution has some limitations on scalability due to the problem with coordination between the different Lambdas. Is it not very straightforward and you have to do a lot of testing.

The initial setup was fairly straightforward.

I would advise others to use it in those circumstances where it works well and to be aware of the problems with coordination and orchestration. Make sure that it doesn't have to process tons of data.

I would rate this solution a seven out of ten.

AWS Lambda is mainly used for automation. To simplify, in AWS Lambda, I define a function, and I can invoke that function or feature whenever I want and on schedule.

For example, if I have data to collect daily from different services, I schedule the AWS Lambda function to do that, and it does the job. That's one of the use cases of the tool.

Another use case for AWS Lambda is when you have multiple servers running and need to shut down the servers at night. You can configure an AWS Lambda function that would shut down the servers every night on schedule. You can also use it as a backend and invoke it through API, so you deploy your backend from an AWS Lambda function, then link it with the API gateway, then you can invoke your function through the API.

What I like best about AWS Lambda is that it's feature-rich, and I appreciate that. I also like that it's stable and supports many languages.

What could be improved in AWS Lambda is a tricky question because I base the area for improvement on a specific matrix, for example, latency, so I'm still determining if I can be the judge on that. However, room for improvement could be when you're using AWS Lambda as a backend, it can be challenging to use it for monitoring. Monitoring is critical in development, and I don't have much expertise in the area, but you can use other services such as Xray. I found that monitoring on AWS Lambda is a challenge. The tool needs better monitoring.

Another area for improvement in AWS Lambda is the cold start, where it takes some time to invoke a function the first time, but after that, invoking it becomes swift. Still, there's room for improvement in that AWS Lambda process.

In the next release of AWS Lambda, I'd like AWS to improve monitoring so that I can monitor codes better.

I've been using AWS Lambda for one year and a half.

AWS Lambda is a stable product.

I have yet to contact the AWS Lambda technical support team because I haven't experienced any difficulty with the tool.

One of the reasons my company went with AWS Lambda is that it's serverless, so you don't need to manage any server because AWS will handle it. This means that a lot of responsibilities will be taken care of by AWS, which helps you avoid many problems.

Another reason for choosing AWS Lambda is its stability. Latency is also not a problem on AWS Lambda, allowing you to use different services in your AWS account securely. For example, when you want to reach the AWS billing service, you can do it within the environment of your AWS account without an external tool, which makes it very secure. AWS Lambda also helps you reach other AWS accounts securely because it depends on roles rather than search keys or passwords.

The initial setup for AWS Lambda is straightforward. It's effortless to start using AWS Lambda.

Price-wise, AWS Lambda is very cheap. It's not free, but it's not that expensive.

I'm using the latest version of AWS Lambda because when a framework or tool is deployed on a public cloud, it's always the newest version, and you don't get to choose the version.

I'd tell first-time users of AWS Lambda, or anyone looking into using the tool, that you can deploy every application within AWS Lambda, and it's very easy to set up and deploy. You can also use it with any application regardless of language because AWS Lambda supports many languages such as Go, Bison, Node, GS, and .NET. The tool is very code-agnostic, and not coded with programming languages, so you can still use Docker images to start your AWS Lambda function, for example.

My rating for AWS Lambda is nine out of ten because of how hard AWS worked on having good latency, security, and an intuitive start. The tool supports different languages and is stable, so I gave it a high rating.

I'm a customer of AWS Lambda.

AWS Lambda is used only by the DevOps team. I can use the solution to configure and set up all the requirements for testing the application and test code.

AWS Lambda should improve its compatibility with the language used to write the code. I would like to be able to choose a different language to code in AWS Lambda.

I have been using AWS Lambda for six months.

Around 15 to 20 users work with AWS Lambda in our organization. The solution is used by different teams, including the DevOps, testing, and development teams.

I faced some challenges when we worked on the migration. I raised tickets to the support team, and they helped me.

The solution's initial setup can be done with the help of documents.

AWS Lambda is not expensive for micro testing but is expensive if used for long deployment or long services.

It is not difficult for a beginner to learn to use AWS Lambda for the first time because it has good documentation.

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

Our primary use case for the solution is automation. There was a scenario where we tried to reduce cost in our environment using Instance Scheduler, where the AWS Lambda function was also used during that process. So we use it for automation and tagging.

The solution has helped our organization with cost optimization. So we have used AWS Lambda for consolidated billing.

The automation feature is valuable.

The runtime for the solution can be improved.

We have been using the solution for approximately two years.

The solution is stable. I rate it a nine out of ten.

The solution is scalable, and I rate it a ten out of ten.

The initial setup was straightforward.

The solution is very expensive.

I rate the solution a nine out of ten.

We have some services deployed that we need to consume in Lambda because it's a faster and better implementation. We have a model that microservice in the product, which we implement in AWS. For that reason, we use Lambda.

The solution has improved our organization by providing us with better communication with the different services, dependencies, and implementations our clients require. The solution is faster and the consumption is really good.

There are some restrictions. For example, we have some services that if you have more than 60 seconds in consumption of this service, we don't use it, because they have that restriction with the gateway. Those services we implement with Fargate and with Docker.

The most valuable feature is that there is no need to implement it in a server because it is a service.

The 60 seconds limitation with the consumption of the service is really restrictive for a service and the solution can be improved by eliminating that.

I have been using the solution for one year.

The solution is stable.

The solution is scalable.

The initial setup is easy but you do need some experience.

The implementation was completed in-house.

The return on investment is good because it is a Cloud-based solution that doesn't require maintenance or a server on-premises saving you money.

I give the solution a seven out of ten.

One person with AWS knowledge is sufficient for deploying and maintaining the solution.

We currently have around 160 people using the solution.

All of the products we implement are in AWS so we do have plans to increase the usage of Lambda, Fargate, and all of the services in AWS to help speed up the implementations.

For anyone thinking about using the solution, you must make sure you have some experience in AWS or another cloud, maybe Azure, and have some experience with software development. If you don't have software development skills, maybe you have experience in deploying services on IIS or something like that.

We are primarily using AWS Lambda for real-time API services. We use AWS Redshift to support our Lambda code functions. 

This solution is cloud-based. 

One of the most valuable features of AWS Lambda is the performance. Lambda is very technical and has very high performance, as well as good real-time performance. 

AWS Lambda could be improved with better stability. 

I have been using AWS Lambda for more than two years. 

This solution is very, very stable. 

In our organization, there are around 300 users of AWS Lambda. We have plans to increase our usage. 

I have contacted Amazon's technical support, and they were very excellent. 

The installation is straightforward. The process took us under three hours, and we did it ourselves. For deployment and maintenance, we have a team of 10 engineers and developers. 

We implemented this solution through an in-house team. 

For licensing, we pay a yearly subscription. 

I rate AWS Lambda a nine out of ten. To those looking to implement AWS Lambda, I would recommend this solution, and say that Lambda has a learning curve in order to enhance the service when using it for the first time. I would advise the user to study hard to use Lambda as a tool.

We are a startup, and we are doing faster and cheaper storage for IT. We are going to offer our storage services in about two months, and we are starting with AWS. We do lossless compression using microservices. We do the compute in a lossless compression way similar to gzip, WinZip, or PKZIP, except that we are giving a discount to customers.

The product that we are developing is not yet in the market. We are doing alpha testing for select customers who are using AWS. The biggest advantage is that you get faster storage without doing a forklift upgrade, and you get 35% cheaper storage. So, you get 2X faster storage with a 35% to 50% lower monthly bill.

We use AWS Lambda to encode and decode data. I work on the encode and decode software. I am working with a cloud developer. He works on the Lambda deliverable and wraps my C code with his C++ wrappers. They get bundled together with no JS stuff.

The cool thing about AWS Lambda is that AWS does all the management. For compression, it is all about making the data small and then making it regular size again. We have an encode function and a decode function. AWS Lambda schedules each of those for us. It has a load balancer and all the fancy stuff, depending on the demand.

The most valuable part of AWS Lambda is that I only need to write the software. I need to write two functions, and my cloud developer turns them into two AWS Lambda instances. That's it.

One area of improvement is to include support for more programming languages. AWS Lambda does not support a lot of programming languages. You have to write the Lambda functions in a certain programming language. We are using C++. My developer knows a couple of other languages. Python is his favorite language, but Python is not supported in AWS Lambda.

I have been using AWS Lambda since it came out in 2016.

It is very stable.

Its scalability is great. We write an encode function, and my cloud developer turns that into an AWS Lambda instance. We then write a decode function, and he turns it into another AWS Lambda instance. We just hook it up and use an API gateway for doing the security check, encryption, and other things.

We did not require any support. Most of the stuff in the cloud is anyways self-serve.

The initial setup was straightforward.

They have a program for AWS customers called Activate. With the Activate program, you can get compute and storage credits. They gave us like $10,000 worth of credit over 18 months.

I would recommend using this solution. It was the first microservice. It doesn't have much overhead, and it does what it claims to do. 

I would rate AWS Lambda an eight out of ten. It is a good solution.