Event-Driven Serverless Computing
Tags: serverless, aws, azure, googlecloud
Published: 2020-07-31 20:53:36


_In a previous post, I wrote about serverless computing and why it should be on your mind while building software applications in today's world._

{% post https://dev.to/gaurav_keswani/what-is-serverless-computing-4pbc %}

---

Wikipedia defines serverless computing as:

> Serverless computing is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources.

Simply put, serverless computing is a paradigm of computing that entirely manages the deployment and execution of the code while allowing the developer to focus on their application logic.


---

# Serverless Design Patterns

Serverless computing has three major design patterns:
- Event-driven data processing
- Web applications
- Event workflows

In this post, I'll go into details for the "Event-driven data processing" pattern and follow up with posts for the other two at a later time.

## Event-Driven Data Processing

One of the most common applications for serverless computing is to trigger actions after an event occurs. This pattern is known as the event-driven data processing pattern.

### Use Case

Allow client applications to upload images to AWS S3 and compress the image.

### Solutions

One way of building a system that does this would be to use a batch process that continuously polls our S3 bucket for newly uploaded images. Once our batch process finds a new image, it can compress it and store the compressed image in the destination S3 bucket.

![Batch Process](https://cdn-images-1.medium.com/max/1320/1*lR4P23hnKvAXZ2ezlAL60A.png)


While this would do the job, one can argue that there is a better way to do it. Instead of having a batch process continuously poll the S3 bucket (which is a massive waste of resources😔), we can have our application submit the image to a message queue (like AWS SQS) and have the queue workers do the job of compression and loading into AWS S3.

![SQS](https://cdn-images-1.medium.com/max/1320/1*XwEgsmmL7BugdqZkmlsOdQ.png)

While the second solution with the message queue is better than the first one, there are two issues with it:
- We must have the queue workers (batch processes that poll for messages from AWS SQS) running at all times😔 irrespective of whether a client is submitting images or not.
- Our client application now has to submit to SQS instead of doing what it was originally supposed to do i.e. store images in S3. While this isn't a huge deal, it leaks unnecessary information to the client.

This is where serverless and the event-driven data processing pattern comes into the picture. The serverless solution would **let the user upload the image to S3 and have a lambda function triggered every time a new image is uploaded**. This lambda function would have to contain the application logic to compress the image and store the compressed image back into the destination S3 bucket.

![Serverless Solution](https://cdn-images-1.medium.com/max/1320/1*gRboAz-3Zbjml5_mFgCoiQ.png)

Apart from being straightforward, using a serverless solution in this scenario is also much cheaper🤑 . This is because you only get charged for compute resources when an image is uploaded and compressed compared to the previous "server-full" solutions where you need to have a process running at all times.

### Summary

At a very high level, event-driven serverless solutions have the following benefits when used in the right scenarios:
- **Developer Agility**: Developers can focus their efforts on application logic and deliver business value quicker rather than focussing on infrastructure issues
- **Elasticity**: The infrastructure scales down all the way to 0 if there are no incoming requests with little to no configuration.
- **Reduced Cost**: We pay nothing for the periods when no requests coming in.



---

Thank you for reading! ❤️