AWS Lambda Reviews

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.

Public Cloud

Amazon Web Services (AWS)

Usually, it is for small transactions. They're very atomic transactions. For example, we built a solution for an ad platform where an electronic ad runs for about 15 seconds a piece. Every time one of the ads runs, we have to record where did it run, how long did it run for, who was in the room, and how many people. There is a bunch of data around that. We typically send that transaction through an Amazon Kinesis pipe into a Lambda function, and then Lambda will take it and store it in S3 or target it to Redshift or put it in some kind of data store. That's one example of what we would use it for. That's a typical model for Lambda. 

It is serverless and scalable. It can scale infinitely. You don't have to worry about the size of the servers that you're pre-allocating. You don't have to build server scale-out models. Auto scale and other similar features are just inherent in Lambda. So, for atomic and fairly non-persistent transactional units of work, Lambda works very well.

My engineers work with it on a daily basis. I just don't have enough depth of knowledge about what kinds of edge cases they may have tried and found lacking. There may be some issues with some language support at one point or another because we couldn't get the underlying libraries in there. A lot of what we do is either in JavaScript, Python, or some of the non-compiled languages. I'm not sure if we've ever tried building a C# solution, for instance, in Lambda or a Java solution in Lambda. It doesn't mean those aren't its capabilities. I would rather refer to my engineers for where the boundaries are.

It has probably been five or six years since we've been migrating functionality from EC2 instances to Lambda.

Its stability is really good, and it is also highly available. The stability is inherent, but it also naturally gives you a high availability model because you don't have to have multiple EC2 instances running in, for instance, different regions. It is baked into the model. So, you can allow for inter-region Lambda functionality. It all becomes very highly available across Amazon's footprint.

It is endlessly scalable. In terms of its users, Lambda is typically baked into the middle of an application somewhere. Our ad platform solution is a fully-automated IoT solution. So, there are no people involved. The whole thing is automated from end to end. So, sometimes people don't even come into the equation.

We probably do or have dealt with their support, but that would be at the end engineer level. It is not something to which I would have much visibility. 

It is straightforward in my understanding. From the engineering perspective, I haven't gotten feedback that it is at all burdensome.

You're not paying for a server if you're not using it, which is another reason I like it. So, you're not paying if you're not using it. It scales, and you're charged based on usage. It all depends on the use case. Some can be extremely inexpensive if you have very low volume transaction rates. That way, you don't have to fire up and absorb the cost of the servers just sitting there waiting for a transaction to come through. You're only paying when you use it. So, depending upon the use model, Lambda could be highly efficient relative to an EC2 solution. You don't have to have things reallocated.

Understanding what your use model looks like is the key. All these cloud providers have so many different ways of implementing a solution that you really have to understand the near-term and long-term picture for that solution. What does it look like? When you're first building it, there might be a more expedited way to get it off the ground, but that may not scale properly, or your cost can get out of control. So, it is very important to align the right set of features within an AWS or Azure environment for not just getting the initial MVP built but also making sure that you're building it in a way that allows scaling and optimization of the cost model over time as the application scales. There's no one answer. The way you build the solution in the cloud is very dependent upon what the use case is.

From my perspective, not being at the engineering level, I would give it a nine out of ten. There is always room for improvement, but it has been a terrific advance over what was previously available just having to build everything in EC2.

I have found this solution very useful. By using Lambda, we can use Python code and the Boto3 solution. 

The triggering feature is also valuable. For example, if we are using Kafka, we need to be aware that the language comes in Kafka when we write in Python, and that we are transforming our data into the meaningful server and dumping that into the S3 bucket.

I would like to see a find and replace function as part of Lambda's future releases. Currently, if we want to replace a code, we copy the code into Notepad, then find and replace it, and then copy that to Lambda. This would improve the editing function of the product.

Lambda would benefit from a debugging feature as well. For example, if you want to debug code running in Python and deployed in Lambda, it would be beneficial to have a debugging feature.

I have been working with AWS Lambda for one year.

The solution is stable. There are times when we do need to refresh when we make changes and deploy them. This seldom occurs.

We have five developers using Lambda. 

Technical support can take a long time to respond. I would rate their service a seven out of 10.

Neutral

The initial setup of AWS Lambda is simple.

I would rate this solution a seven out of ten overall. 

Public Cloud

We have one or two use cases for real-time file processing. We use the event triggers to detect file arrival.

AWS Lambda is serverless. It is quick to deploy. The event-driven execution model has improved the project efficiency because it is quick and easy to deploy. However, it also introduced a set of new problems. It is the industry traction ever since the network went fully API.

Since the tool is serverless and it is hosted in the cloud, we do not need an initial capital investment on servers. We can pay as we use. We have integrated the product with other AWS services. We use SNS and SQL. There is an offering from AWS for integrated solutions.

We face some problems with the event-driven execution model.

The tool is very stable. There are certain things that we have to do to support it, but once we cross the t's and dot the i’s, it works.

The initial setup seems to be very straightforward.

I will recommend the solution to others for serverless computing needs. It’s a quick delivery. We do not have to set up servers before we start deploying. Overall, I rate the product a nine out of ten.

We use it primarily for image resizing in batch and scheduled jobs. Additionally, one of our clients relies on Lambda for running a continuously active custom API, handling their ongoing API requests.

Leveraging it to run containers directly from Amazon Elastic Container Registry has proven to be highly valuable. The utilization of containers is particularly beneficial in overcoming the size limitations imposed on Lambda functions which not only allows us to work around these constraints but also contributes to the improvement and maintenance of our code.

There's room for improvement in the testing setup. Attempting to test it through the AWS CLI also posed issues, and when trying to test the Lambda function on my local machine, I encountered difficulties in obtaining comprehensive logs or error messages to diagnose what might be going wrong.

I have been working with it for one year.

It provides a high level of stability, and I have not encountered any issues so far. The system demonstrated stability whenever we attempted to update the function or perform any operations. Responses consistently aligned with the timeframes specified on the AWS website, remaining within the service level agreement. I would rate it nine out of ten.

The scalability is notably high, I would rate it nine out of ten. Approximately sixty percent of my clients are utilizing this approach. While I serve two major organizations, the majority of my clientele consists of small and medium-sized businesses.

The technical support from Amazon has been excellent, and I've consistently had positive experiences. During a customer migration from another cloud provider to AWS, the entire technical team provided valuable insights and enhanced the architecture. Their assistance not only improved the overall design but also ensured smooth transition and support. Even for minor issues, the response times have consistently exceeded the expectations stated on the website. For instance, if a 24-hour response time is indicated, they typically respond within twelve hours. I would rate it nine out of ten.

Positive

I would rate the initial setup around seven out of ten. While it wasn't overly challenging, it did demand a certain level of technical proficiency. Someone without substantial technical knowledge might find it less straightforward to set up.

In our container-based approach, we initiated by constructing containers on the local developer machine, then we pushed these containers to AWS Elastic Container Repository. Following this, we established a Lambda function that utilized the uploaded ECR image, allowing it to execute the associated container. Additionally, we incrementally built services to utilize those containers at Lambda functions. The deployment took less than three hours.

The pricing varies based on the specific solution you're implementing, and in comparison to the value it provides, the overall cost is reasonable. When used appropriately for its intended purpose, the price is relatively low. However, if Lambda is employed outside its intended scope, the cost can escalate exponentially. I would rate it four out of ten.

I recommend thoroughly reading the documentation to determine if it is a suitable solution for your specific use case. It's essential to understand the nuances of your use case before proceeding with the implementation. Overall, I would rate it eight out of ten.

Public Cloud

Amazon Web Services (AWS)

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. 

Private Cloud

Amazon Web Services (AWS)

We primarily use the solution for integration purposes. We use it very closely with Jira, for example. 

The workflow is the best thing about the product. When the integration happened and from where to where is something we can see automatically and navigate the workflow. 

From Jira to AWS Lambda, we're sending data. When we go from Jira to AWS, through webhooks, we are sending data to the Lambda function. From Lambda, they're navigating Jira. Whenever the manual rework is done, they need to perform some job bundles from the AWS to the Jira only. They can operate from Jira to AWS and AWS to Jira, which is great.

The initial setup is pretty easy. 

I don't have much experience after six months. I can't speak to the pros and cons. 

I have seen some drawbacks with certain integrations. 

I started using the solution six months ago. 

I'm not aware of any issues with stability. It's been issue-free so far. 

The solution can scale. We can add more users to it. We have ten to 15 people on the product right now. They are developers. 

I've never needed to reach out to technical support. I haven't had any issues. I can't, therefore, speak to how helpful or responsive they are. 

We found the setup to be straightforward. It's not complicated at all. 

It took me one day to get everything up and running.

I'm not aware of the exact pricing. I don't handle any licensing. 

Our company is looking into ServiceNow to see how it handles integrations. 

We are a customer and end-user. We use the cloud for integration purposes. 

I'm not completely into AWS Lambda just yet. What I can say, integration-wise, Lambda does not require any username or password from the Jira once they start talking to each other. It's integrated very well. 

I'd recommend the solution to others. 

I'd rate the solution seven out of ten. It is a very new tool for me; I need to do some more research on it to really understand it fully.

Public Cloud

I use AWS Lambda for serverless computing, and I am charged only for the AWS Lambda instances I use. I value its cost efficiency because it activates instances based on load and tasks initiated.

I appreciate AWS Lambda for its serverless computing, with charges incurred only for the used instances. This serverless architecture enables the activation of instances based on task load, contributing significantly to cost efficiency.

Currently, I don't have any specific suggestions for improvements. However, enhancements could be introduced to better satisfy customer requirements.

I have used AWS Lambda for around two years.

The initial setup of AWS Lambda is quite straightforward and easy.

I rate the stability of AWS Lambda as a ten out of ten, suggesting that it is highly stable.

I rate the scalability of AWS Lambda as eight out of ten. Although it is stable and scalable, the number of instances can be optimized for other workloads when needed.

I rate AWS Lambda's technical support an eight out of ten. The support can be improved by increasing the number of support personnel.

Positive

The initial setup of AWS Lambda is quite easy.

The pricing of AWS Lambda is reasonable. It's beneficial and cost-effective for users regardless of the number of instances used.

I recommend Amazon Web Services Lambda to other users. I rate AWS Lambda as one of the best solutions, giving it a ten out of ten overall.

Public Cloud

Amazon Web Services (AWS)