AWS Lambda Reviews

For over a year, I worked in an IoT company, where we had some web applications. I used AWS Lambda in all of our devices for connection. During this time, I also taught AWS, using Lambda to help my students learn how the code of infrastructure works.

What I like most about AWS Lambda is that it's very easy to deploy. You basically have to click a couple of buttons, and suddenly you have a Lambda function that works. Obviously, then you have to write all the code, however, that it's a good service for beginners. 

Additionally, encapsulating code in Lambda functions makes applications easier to maintain and scale better than having one EC2 instance hosting everything. I think scalability and maintenance are major advantages. 

Also, the ability to work with different versions of Python is useful; sometimes I want to use different libraries unavailable in some versions.

The way Lambda works with HTTP headers is a bit odd. It needs some change as the configuration is somewhat hidden, so I don't really know what I'm changing. Managing the HTTP headers should be modified for clarity since, at least in my case, I found it challenging to configure and manage them initially. I would suggest that this is an area for improvement.

I have used Lambda for over a year.

I have never had issues with Lambda's stability. The first executions may have a bit of latency due to the cold start, however, once the Lambda is up, everything is much faster. It's a fast service, yet, in cases where the Lambda has been idle for a long time and has to restart, it's a bit slower. However, I think it's still something manageable.

I have found that Lambda has no problem with scalability. I can have many Lambdas working simultaneously. In case there is a traffic peak, AWS manages the scalability itself. I don't need to configure anything. It's all done by AWS, and for me, it has always worked perfectly. I have never seen any problem with that.

If I want a Lambda ready to go with no configurations, it's easy. I just click a few times, and it works. I don't need to know how it works underneath. However, if I want something more complex, for example, working with HTTP headers, it gets complex.

In the same way I used Lambda, I would say that no, I did not. It's a very unique service.

I would give it a nine out of ten.

The best thing to do is to pick a programming language you already know. Instead of starting with GitHub actions or workflows, it's better to make the Lambda public, start coding directly into the Lambda editor, and see how everything works. Try to understand how executions are logged into CloudTrail. 

When you gain more experience, obviously, Lambda should not be public, and you can make more complex things, like working with headers and authentication and connections to other AWS services.

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.

Public Cloud

Amazon Web Services (AWS)

We primarily use AWS Lambda for our APIs. Most of our transactions flow through the API, which is managed using API Gateway and AWS Lambda. Our development team works on the API.

We use AWS Lambda because it provides a solution for our needs without requiring us to manage our infrastructure. With the tool, we only pay for the resources we use. Additionally, it is straightforward to implement and integrates with other services like API Gateway.

The tool's serverless nature has had the most significant impact on our workflow. I find it particularly attractive because it eliminates the need for managing servers. In my previous experience, managing upgrades and updates was quite challenging. 

The solution's integration process with other AWS services was relatively easy. We primarily use AWS services such as EventBridge for scheduling processes and log management. 

We need to invest time in learning the tool's language variant. We have encountered instances of downtime as well. 

I have been using the product for a year. 

I rate the tool's stability an eight out of ten. 

The tool is scalable. 

The solution's technical support is good. 

Positive

AWS Lambda's deployment is very easy. 

The solution follows a pay-as-you-go licensing model, which results in cost savings. 

I rate the overall solution a nine out of ten. 

AWS Lambda is primarily used for serverless architecture. I have used it for web applications, particularly during my time at a company where we developed an image processing tool. It helps to trigger events on a runtime basis. AWS Lambda also has various other use cases such as machine learning processes and handling big data tasks.

AWS Lambda's serverless architecture and event-driven programming are highly valuable. You pay only for the events triggered, optimizing costs. It is beneficial for deployment CI/CD tooling and for triggering pipelines for data processing. The cost model is pay-as-you-go, with a tier for free requests and computational time. Scalability and stability are also very efficient.

AWS Lambda could offer support for more programming languages beyond Python and Node.js. The process for creating Lambdas could be simplified for beginners with less expertise in AWS.

I have been working with AWS Lambda for almost eight years.

Deploying AWS Lambda is pretty quick if the process is known. It takes between 30 minutes to one hour to deploy once the code is ready.

AWS Lambda is very stable. Issues are typically related to the user’s code and can be debugged through logs such as CloudWatch.

AWS Lambda's auto-scaling features are crucial for operations and provide great scalability. I rate the scalability of AWS Lambda at eight out of ten.

The documentation for AWS Lambda is comprehensive and thorough, eliminating the need for frequent technical support. A 2000-page guide covers all aspects, from setup to advanced use.

Positive

The initial setup of AWS Lambda can be somewhat challenging for first-time users, primarily due to the learning curve involved. I would rate it a six on the ease scale.

AWS Lambda has a cost model that aligns with usage. There is an initial free tier, after which charges apply based on requests and compute time. Different architectures have distinct pricing models. Despite being a bit expensive initially, the overall cost effectiveness is notable.

AWS Lambda should be used when there is a need for event-driven programming on an as-needed basis. It might become expensive if used for continuous processes. In terms of the overall solution, I rate AWS Lambda at nine out of ten.

Public Cloud

Amazon Web Services (AWS)

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.

Hybrid Cloud

Amazon Web Services (AWS)

I primarily use AWS Lambda for building serverless applications. I integrate it with services such as S3 and DynamoDB.

The capability of AWS Lambda to automatically scale thousands of requests simultaneously without requiring manual intervention is invaluable. 

Additionally, its integration with other AWS services such as Amazon S3 and DynamoDB has been very beneficial. The pay-as-you-go pricing model ensures that I only pay for the resources used, providing cost-effectiveness. 

The serverless computing feature eliminates the need to manage servers, provision, or scale.

AWS Lambda has a limitation where the execution time is capped at 15 minutes per task. Increasing this time would allow for handling heavier tasks more efficiently. 

While the documentation is satisfactory, beginners might encounter some challenges, so any improvements could be helpful.

I have been working with AWS Lambda for about six months.

AWS Lambda is quite stable, with a high level of availability and the ability to distribute functions across multiple availability zones. I'd rate it at nine out of ten in terms of stability.

AWS Lambda can automatically scale to handle increasing requests. For example, I used it in a personal project to integrate with a Simple Notification Service, which ensured I received real-time notifications during peak times without manual scaling.

I did not use a different solution before AWS Lambda.

The initial setup was moderately challenging, especially for beginners. Although the documentation is adequate, new users might find it not entirely straightforward and may face some challenges. It took me around five to ten minutes to deploy Lambda for the first time.

I deployed AWS Lambda by myself while learning about it and sought help from friends when necessary.

Lambda provides a cost-saving advantage because of its serverless design and automatic scaling without manual infrastructure needs. Its pay-as-you-go model means I only pay for what I use, which is financially beneficial for handling applications with fluctuating traffic levels.

AWS Lambda is cost-effective and flexible, particularly suitable for small applications. I am using the service within a free tier account, which influences the pricing experience.

I rate AWS Lambda overall at ten out of ten. New users should thoroughly read the documentation and start with small projects to understand the platform. It's important to be aware of AWS Lambda's limitations, take advantage of monitoring and debugging tools, and stay updated with new releases. Joining a community for learning and sharing is also recommended.

Public Cloud

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)

There's a lot of use cases. The solution is used for immediate processing, so it's used everywhere. When data comes in, you process a Lambda function to tag it and categorize it. I've used Lambda functions to process inbound videos to make them smaller. I've used a Lambda function as a serverless backend for a customer-facing app, so I didn't have servers running.

With a highly variable load, our idle cost is pretty much zero, and we haven't had any scale barriers, so we've scaled smoothly.

I think the most valuable features are event-based triggers. Basically, a Lambda function doesn't get called because you say, "I'm going to call it." It gets called because something happens: a file arrives, a message arrives, or a database gets written. It's really good for a reactive style when you want things to happen as soon as something else happens. That's the best pattern.

There's room for improvement in the solution's warm start, which refers to the minimum time it takes to start up a Lambda function if you haven't been running it. 

I have been using Lambda since 2014, so about eight years. 

This is a stable solution. 

This solution is scalable. We have hundreds of thousands of users, so everything in Lambda gets used a little bit at a time in different parts of the process. We have plans to increase our usage in the future. 

I would rate the technical support as a ten out of ten. You are able to pick a language, pick an environment, and deploy it. 

Positive

It is pretty straightforward to set up this solution. 

We've run some scenarios. For example, say you have three million requests per month, and 120 milliseconds each time someone requests. The total cost ends up being $2.73 a month, which is very cheap for what you get.

There's two charges for this solution. There's the charge for how many times you call a Lambda function, which is 20 cents for every million function calls. Then there's also the size and amount of time that the Lambda function runs, which is measured as 0.0000166667 dollars. It's a fraction of a penny for every gigabyte second. A gigabyte, if you ran it for like a million seconds, would cost one dollar. It computes by the cycle, and it's very cheap.

My advice is to think about the architecture first and don’t just throw your code into Lambda. Think about how your application is designed because using serverless is different.

I would rate this solution as a ten out of ten. It's a very critical service. 

Public Cloud

Amazon Web Services (AWS)