AWS Lambda Use Case
AWS Lambda Use Cases in this project:
- Automated Backups
- Serverless Website
- File Conversion
- Simple Email Service
AWS Lambda Architecture of Career Genese
Description of type of serverless microservice
AWS Lambda let us run code without provisioning or managing servers. Lambda is highly integrated with API Gateway. The possibility of making a synchronous call from API Gateway to AWS Lambda enables the creation of fully serverless applications and it is described in our documentation.
Total estimated number of events per month:
Description of any challenge or customer objection overcome to drive a lambda adoption:
The number of Lambda functions deployed.
Following are the various list of our function that are used to create this application :
Deployment Patterns: At least 5 functions, Use of best practice deployment application model (SAM)
Lambda function, DynamoDb,API Gateway, Cognito Service, Simple Storage Service, Simple Email Service.Additionally Serverless. Moreover, AWS Serverless Application Model (AWS SAM) is utilized which is an open-source system we have to make utilization of it to manufacture and convey AWS serverless applications. Code Commit, Code Build, Code pipeline are utilized to mechanize programming.
Workload 1: Connection with at least 3 other AWS Services
For storing static files, AWS storage service S3 is used and all the GET and PUT operation is done by Lambda functions. Cognito is used for signup and sign in whereas Amazon SES is used to notify the administrator if an event is triggered in Lambda function.
Workload 2: Use of servers or containers only in supporting roles
Workload 3: Serverless workload should use AWS Lambda to handle and process the core data flow for the system
Workload 4: Automating Infrastructures provisioning and managing is not serverless
Solution Characteristics 1: IAM Policy Definition
- AttendanceCognitoPolicy(Inline Policy)
- AttendaceDynamodbPolicy(Inline Policy)
- ses-full-access(Inline Policy)
- AWSS3DFullAccess(AWS Managed Policy)
- AttendaceRecognitionPolicy(Inline Policy)
- AttendaceS3Policy(Inline Policy)
- AttendaceSESPolicy(Inline Policy)
Solution Characteristics 2: Managing Failed Executions
- The capacity times out while endeavoring to achieve an endpoint.
- The function fails to successfully parse input data.
We have used python boto3 library in our code. How the exemption is taken care of relies on how the Lambda work was invoked. In this task, some of these event sources are set up to invoke a Lambda function synchronously and others invoke it asynchronously. In specific cases, possibly the info parameters might not be right and code rationale may not consent to the information. In such case, lambda distinguishes the special case and returns a fitting message to the customer side.
Solution Characteristics 3: Management of Multiple Microservice functions
- The API of a microservice is the central entry point for all client requests. The application logic hides behind a set of programmatic interfaces, typically a RESTful web services API.
- Since clients of a microservice are served from the closest edge location and get responses either from a cache or a proxy server with optimized connections to the origin, latencies can be significantly reduced. However, microservices running close to each other don’t benefit from a CDN. In some cases, this approach might even add more latency. It is a best practice to implement other caching mechanisms to minimize the latencies.
- Amazon DynamoDB is used to create a database table that can store and retrieve any amount of data and serve any level of request traffic.
- The Server Side Logic is written in Lambda functions, which are independent microservice functions of AWS.
Solution Characteristics 4: VPC vs No-VPC and concurrency
Solution Characteristics 5: Monitoring of Alarms and Metrics
- For Monitoring the execution of lambda functions, we have used CloudWatch Service of AWS.
- We have monitored different CloudWatch metrics of Lambda by the Name of Function.
- Name of Different Metrics that we monitored for our Lambda includes:
- Invocation per lambda function
- Duration of execution of lambda function
- Error in a lambda function
- Throttles to manage the flow of execution
After moving in the AWS we still saw the way to reduce the cost and we moved towards the serverless service of the AWS, through which we successfully saved $1158 more by integrating with the serverless of AWS.
Dynamo DB Use Case
This recruitment Project is hosted as a serverless in the AWS platform. We have opted Dynamodb as the data storage because dynamodb is a NoSQL database service provided by AWS, and it was quite efficient for the use-case of our client.
The tables we have created during the course of our project development are listed below:
1. Description of Primary Key design for the Tables and Indexes:
Table 1: carer_genese_personaldetail2
Hash Key: Uid
This table stores the personal information of the applicant details. Uid has been used as a hash key which is efficient to perform query operation in the main table and also this table has a minimal number of data stored.
Table 2: carrer_genese_intern_questions
Hash Key: id
This table stores the question collection which is retrieved while the applicant gives their exam. “Uid” is used as ‘Hash Key’.
Dynamodb data items can be accessed in two ways like :
- Scan Operation
- Query Operation
The scan operation on a Dynamodb table with a large number of item count results in ineffective utilization of provisioned throughput where we seek the aid of Global Secondary index to define a new primary key combination of “Name” as Hash Key and “monthvalue” as sort Key. While doing so, the data retrieval of records of a user for a particular month from a query operation is easy and have been efficient;
Table 3: final_recruitment_portal
Hash Key: Uid
This table stores the details of every user of the application. Each user is made identical with each other with the username attribute. Thus, the best option for a primary hash key is to user uid itself.
2. Monitoring and alerting for read and write capacity:
Cloudwatch Alarms are created to notify the system (us) about:
Insufficiency caused in provisioned throughput capacity.
3. Enable Continuous Backup and Data Encryption
Continuous backup, which is enabled in our system, provides point-in-time recovery Backup for a continuous data backup until it is explicitly turned off. By default, dynamodb maintains the continuous backups of the table for the last 35 days. We have enabled the encryption in our database for the security purpose.
The workload for our current system in Dynamodb are as follows:
- Write Capacity Units: Range between 20,000 to 25,000 WCU-Hrs
- Read Capacity Units: Range between 20,000 to 25,000 RCU-Hrs
- Total data storage: less than 5 GB till now
- Global deployment: In only one region (ap-south-1)
5. Data Access patterns and Transaction Volumes:
Our application may require to scan or query the table item to get the stored data. Thus the data access patterns primarily depend upon the usage of the indexes upon which the database has been designed. Generally, we have used the Global secondary indexes on which hash keys and the sort keys have been defined.
6. Deployment Pattern:
Since the use of the database is new to any of the system we implement on. The applications use the dynamodb database as their new primary database which is easy to use and apply for its no SQL feature implementation.
7. Description of any challenge or customer objection overcome to drive a DynamoDB adoption:
This service was quite suitable with the use case of our client project there were not many obstacles created by the client side. The problem only was if the service could work perfectly after the integration with their service.