Perhaps one of the most powerful combinations for AWS Lambda is using autonomous event sources. What I mean by “autonomous event sources” are ways to get a Lambda function triggered without having to explicitly invoke it.
Starting with examples...
Say you want to send a confirmation email every time someone posts a certain request in your application. If you’re using DynamoDB, for example, you could make it trigger a Lambda function automatically whenever a new item is inserted in your database table. Dynamo can also provide the item data with the invocation payload, thus Lambda doesn’t even have to issue a read query, it already gets what it needs to send the email from the invocation itself.
Another example would be having a Lambda triggered when a new object is saved into an S3 Bucket. Consider you provide some sort of media storage and processing service. When a third-party uploads an image, audio, or video file to your bucket, it can trigger a Lambda function automatically, which would carry on with the processing and do whatever it needs with it.
The Power of Event-Driven
With Lambda autonomous event sources, we can coordinate multiple cloud infrastructure resources to accomplish a goal in an event-driven fashion - not to confuse with event-driven programming in the code level, here we discuss cloud architecture.
The main advantages of an event-driven approach in the cloud level are quite similar to the programming level: loose coupling, extensibility, easy to manage.
Going back to the examples above…
If you now want to send an email in another context (say, a user wants to invite a friend to your app), it’s easy to implement. You could either deploy a new Lambda function and make Dynamo trigger it as well, or you could make your initial Lambda adaptive to send different emails depending on the item inserted in your database table.
It’s easy to manage such infrastructures because the event which causes the action is responsible for triggering your application response to it. You don’t have to worry about keeping track of what’s happening and making sure your application responds accordingly. AWS takes care of it for you.
Even better: AWS does that for free. There are no additional costs to activate these autonomous triggers. All you pay is the ordinary Lambda, Dynamo, S3 or other services costs.
What else can we event-drivenize?
I admit it, drivenize is a rather ugly word invention, but, anyway, you get the idea.
There are a plethora of services that can trigger AWS Lambda automatically for us. Here is a list of them, grouped by the type of invocation:
Synchronous invocations
API Gateway
Using API Gateway with Lambda is cool because you can dynamically respond to HTTP requests with code running on Lambda. Heck, you could even build an entire web application on top of these two services.
Load Balancer
Another way to use Lambda in order to handle HTTP requests is to hooking it up to an elastic load balancer.
Amazon Alexa
Lambda could be used to build new skills for AWS voice-assistants. You could create code to respond and act to virtually any voice command a person can give to Amazon Echo, for example.
Kinesis
One of our examples above was about media processing. You could use Kinesis, instead, have it to do some pre-processing of the data before sending to Lambda, creating a powerful data processing pipeline.
Cognito
Cognito makes it easier to manage and synchronize user data across multiple devices. It can trigger Lambda upon user sync events, for example, so that you can respond accordingly.
CloudFront
Lambda can be used to customize content served by CloudFront. Which is pretty cool to think we can make static content actually dynamic, but no, it comes from a CDN, must be static. Anyway, it definitely opens up interesting possibilities. For example: customize an image or Javascript code depending on the user browser.
Amazon Lex
Lex allows you to build conversational (voice or text) applications. Similarly to the Alexa integration, Lambda can be used here to give new powers or skills to your Lex bots.
Asynchronous Invocations
S3
As we illustrated above, S3 can trigger a Lambda function when an object is inserted, deleted or modified in a bucket.
SNS
Lambda can get invoked when a message is published to an SNS topic.
SES
If you use SES to receive email messages, you can have a Lambda function processing all incoming emails and acting accordingly.
CloudWatch
Lambda can be used to monitor logs published on a CloudWatch Log stream or to respond to certain metric thresholds produced by CloudWatch Metrics.
CodeCommit
CodeCommit can invoke a Lambda function upon certain events in a repository, such as the creation of a code branch.
Awesome, but what's the catch?
AWS Lambda is a powerful, stable and reliable service, but it naturally comes with its challenges.
It has some limits such as memory (up to 3 Gb) and execution duration (timeout in up to 15 minutes). In the media processing example, you wouldn't be able to ingest a 10 Gb video file or execute processing work that takes hours to complete (unless you can break and batch them).
Monitoring and debugging can also be difficult. Although AWS offers CloudWatch, it's not perfectly suited for Lambda. Services like Dashbird (which is free by the way) can fill these gaps because it was thought out for Lambda from the beginning.
Wrapping Up
AWS had done a great job integrating Lambda with several other services, providing us, developers, with unparalleled flexibility in building autonomous, event-driven architectures. The serverless space is evolving fast and opening up advantages to startups, SMEs and enterprises. We recently published a free ebook about "Serverless Best Practices", which I think you may be interested in reading.
Top comments (0)