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.
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.
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.
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.
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! ❤️
Top comments (0)