Patterns for infinitely scaling & cost effective serverless microservices — Part 3
Welcome to the third and final part of the series! In the last two parts, we covered the basic blueprints of building infinitely scalable micro services. You can access the part 1 here and part 2 here.
In this article, we will look at implementation of this pattern using AWS components.
To quickly recap, our architecture involves the following:
- a set of micro-services, each of which execute a specific part of a broader business workflow when triggered.
- A “Workflow Manager” which orchestrates this business workflow.
- Workflow manager and Micro-services talk to each other through a message queue.
All the components of the architecture are event-driven to enable us to deploy them as Server-less.
Now, how do you actually deploy this architecture & reap the benefits?
Let us first look at the real world equivalents of the components we require for this architecture:
AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume — there is no charge when your code is not running.
With AWS Lambda, you can set up your code to automatically trigger from other AWS services such as API Gateway (or) Simple Message Queue (SQS).
Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale micro services, distributed systems, and server less applications.
Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other services to be available.
Now we have obtained two powerful services from AWS that let us build infinitely scalable micro-services!
Reference implementation diagram
Deploying your code as Lambda
If you are a Python shop, you must look at Zappa framework — a powerful Server-less Python Web services framework, which makes deploying your code to AWS Lambda a child’s play!
At FundsCorner, we initially deployed the reference event-driven micro services architecture onto EC2 boxes.
We managed just fine, but ran into a number of issues:
- Forced to switch off machines in the night time to save costs. We felt very uncomfortable doing this. What if someone needs to access our App in the night?
- Forced to add disk volumes to ensure that there is enough storage for logs
- Forced to reboot the EC2 boxes every day morning to ensure that the box does not go out of availability (it did sometimes)
By replacing EC2 boxes with AWS Lambda, we solved all of these issues at one shot!
- No need to switch off anything in the night. Only pay for the amount of milliseconds the code runs!
- All logs written in the code straight into Cloudwatch Logs (for free) & you get to choose how long to retain them!
- No question of rebooting anything. Our services are available 24 by 7!
- Automated CI / CD made super-easy with Zappa. We deploy our services with a single command!! (yes, you heard that right)
In the end, by carefully choosing an event-driven, asynchronous & workflow driven micro-services architecture, coupled with the excellent AWS Services, deployed through Zappa, we not only reduced the cost by more than 70%, the software development once again became romantic for us!
Thanks for reading!