AWS Lambda Provides Function-based Compute On Demand
Updated May 12, 2020

AWS Lambda Provides Function-based Compute On Demand

Michael Jenkins | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with AWS Lambda

My team uses AWS Lambda in two primary ways: as a back end service and as middle-ware for log processing. As a backend, Lambda provides the compute for APIs fronted by AWS API Gateway or one-off tasks that can be handled in the cloud by a small piece of code. As a middle-ware for log processing, Lambda processes logs ingested by AWS Kenesis by feeding them into AWS Cloudwatch and third-party logging services.

Lambda provides an interface to managed compute resources without the overhead of the team having to mange servers or other resources.
  • Lambda provides multiple methods for triggering functions, this includes AWS resources and services and external triggers like APIs and CLI calls.
  • The compute provided my Lambda is largely hands off for operations teams. Once the function is deployed, the management overhead is minimal since there are no servers to maintain.
  • Lambda's pricing can be very cost effective given that users are only charged for the time the function runs and associated costs like network or storage if those are used. A function that executes quickly and is not called often can cost next to nothing.
  • Developing test cases for Lambda functions can be difficult. For functions that require some sort of input it can be tough to develop the proper payload and event for a test.
  • For the uninitiated, deploying functions with Infrastructure as Code tools can be a challenging undertaking.
  • Logging the output of a function feels disjointed from running the function in the console. A tighter integration with operational logging would be appreciated, perhaps being able to view function logs from the Lambda console instead of having to navigate over to CloudWatch.
  • Sometimes its difficult to determine the correct permissions needed for Lambda execution from other AWS services.
  • We have simplified log fiie ingestion using Lambda functions. The return has been less time worrying about getting logs from source to ingestion; one the process is in place the team is nearly 100% hands off.
  • We have begun taking a more API focused approach by using API Gateway as the interface to business processes and Lambda as the back end compute. Moving away from server based back ends places us on a path to reducing overall spend in compute costs.
  • Lambda functions allow us to easily interface with third party services through APIs. This simplifies access management since the function can be granted permissions and access to the function can be gated with API keys and other authentication methods.
I have used Azure Functions and Google Cloud Functions. In comparison, AWS Lambda is a bit more difficult to configure out of the gate. But in most cases once the function is in place and running the operation becomes completely hands-off. While I've used Azure Functions and Google Cloud Functions, my team selected Lambda because the rest of our resources already run in AWS. Keeping the functions in the same account as the other resources (like S3 buckets and API Gateways) simplifies access management and deployments.
AWS provides decent documentation and plenty of resources for getting started with Lambda. Our support engineers are readily available to answer questions and if there are ongoing issues, the support process is pretty good. I haven't had any problems with tickets falling through the cracks or issues not being followed up. My team also has a good relationship with our account managers if there is ever a need for escalation but really that's never been the case.

Do you think AWS Lambda delivers good value for the price?

Yes

Are you happy with AWS Lambda's feature set?

Yes

Did AWS Lambda live up to sales and marketing promises?

Yes

Did implementation of AWS Lambda go as expected?

Yes

Would you buy AWS Lambda again?

Yes

I would definitely recommend using Lambda for short-running, event-triggered processes that are dedicated to a single function. This could be for one-off processing or intermediate tasks between other resources like objects stored in buckets and queues for processing those objects. Also, since Lambda executions can be scheduled, processes that need to happen on regular intervals can be implemented with Lambda as well.
I would not recommend using Lambda for anything that needs to run longer than a few seconds. Long running processes like ETL jobs or intensive computations may be better suited for step functions, batch jobs, or even a server based approach.

AWS Lambda Feature Ratings

Scalability
10
Platform management overhead
Not Rated
Workflow engine capability
5
Platform access control
10
Services-enabled integration
10
Development environment creation
8
Development environment replication
10
Issue monitoring and notification
3
Issue recovery
9
Upgrades and platform fixes
10

Evaluating AWS Lambda and Competitors

  • Price
  • Product Features
The tight integration with API Gateway was the main factor for using AWS Lambda.
I would spend more time looking at the CLI projects focused on deploying and managing Lambda functions. Particularly, I mean services like SAM CLI, Serverless, Zappa and Claudia. The majority of the AWS resources operated by my team are created using Terraform which allows us to capture infrastructure as code. However, Terraform may not be the best way to deploy and manage lambda functions. But if all you have is a hammer, every problem looks like a nail. Taking a step back, one of the other tools I mentioned might have allowed for our APIs and functions to be implemented easier.