A Cloud-Native Application: GelGit Travel
May 25, 2024
Before diving into the details of our cloud-native project, I would like to extend my heartfelt thanks to Eren Akbaba, who was the instructor for the CS443/683 Cloud Computing course that I took during the Spring Semester of 2023-2024 as part of my Master's program.
I gained an immense amount from his course and his extensive experience. He was always open and exceptionally kind to students, making classes both enjoyable and engaging. His genuine willingness to help with any topic was evident to everyone. He frequently provided real-case scenarios from his work as a solutions architect, which added immense value for me, as I always find learning from others's experiences enriching. This project was made possible thanks to his support and the AWS credits he provided, enabling us to carry out our work effectively. I would also like to express my gratitude to my teammates Ahmet Can Bağırgan, Mehmet Kadri Gofralılar, and Mousa Farshkar Azari for their valuable contributions to this project.
Now, let's delve into the exciting details of our cloud-native project...
Gelgit Travel simplifies transportation for small companies and budget-conscious travelers. It provides an easy-to-use platform where travelers can search for and book transportation based on their preferences, including time and mode of travel. With features like coupons and balance management, travelers can save money and streamline the booking process. Meanwhile, companies can register routes and manage operations efficiently. Administrators oversee the entire platform, ensuring smooth operations and handling tasks such as adding new transportation options and managing promotions. Navigate to the GitHub repository to view the portion of the application by clicking here. Unfortunately, due to the absence of AWS credits, I am unable to provide a link to the live version of the application at this time.
Figure 1: GelGit Travel Application Cloud Architecture
The project architecture provided above offers a comprehensive overview of the project flow. To avoid overwhelming readers with excessive detail, I've opted to highlight the key AWS services utilized and their respective functions within the project.
AWS serves as the cloud provider for the GelGit Travel application. Leveraging its suite of services, the application achieves high availability, scalability, and performance with minimal latency while remaining cost-effective. Moreover, the application prioritizes security, benefiting from various AWS services to ensure robust protection.
It's worth mentioning that the application's backend is powered by AWS Lambda, a serverless compute service known for its high scalability and availability. Utilizing AWS Lambda contributes to the overall affordability of the application, as it is a cost-effective solution.
Amplify: AWS Amplify was set up for connecting it to our GitHub repository and selecting a branch, then configuring the build settings and environment variables to build, deploy, and host our web application automatically. The Auto-build option provided by Amplify enables the CI/CD pipeline.
Cognito: The Amazon Cognito allows authentication and authorization to users and grants access to the web application. To use this service, first a userpool was generated and set the authentication and authorization to be performed via our designed UI. User confirmation was done by utilizing the SES service. Additionally, Amazon Cognito service was connected with API Gateway by creating an Cognito Authorizer which enhance the security application adding extra an authorization layer.
API Gateway: For the API Gateway implementation, a new API Gateway Endpoint was created in the API Gateway console. API methods and resources were defined, and integration with backend services like Lambda were established. Security settings, such as IAM roles, were configured accordingly. Additionally, the authorization was handled by a Cognito Authorizer.
Lambda: Over 40 Lambda functions were implemented for three different user types, namely admin, company, and traveler. Another Lambda function handles the email sending process for notifying our users. Almost all of our backend operations handled with Lambda functions which enables us to provide an automatically scalable and cost effective application. Note that while implementing AWS Lambda functions, necessary libraries that are not provided by default are uploaded such as PyMySQL.
SES: To implement SES, domain or email addresses were verified. Sending and receiving email settings were configured, and email templates were created. SES was integrated with the application to send emails (such as sending informative emails when the user makes a purchase).
EC2: In the application, the EC2 instance allows admins to connect to the database and perform various database operations. An EC2 was launched by selecting an appropriate AMI (Amazon Machine Image), choosing instance type, configuring instance details such as VPC and IAM roles. The Session Manager instance profile was also attached to the existing EC2 instance to be able to connect through Session Manager.
RDS: Initially appropriate database engine (which is MySQL in our case) and version for our use case was selected. Then the DB instance with the necessary settings, such as instance class, storage, VPC subnet, and security groups were configured. Finally, automated backups were enabled, monitoring and alarm for free storage space with CloudWatch were set up, and Multi-AZ deployment for high availability and failover support are configured.
AWS Identity and Access Management (IAM): Users, groups, and roles with specific permissions were created for IAM. Policies to grant or restrict access to AWS services are configured.
Web Application Firewall (WAF): We implemented AWS WAF to protect our web applications from common web exposures by creating a web ACL and defining rules to allow, block, or count web requests based on specified conditions.
CloudTrail: AWS CloudTrail was enabled to log all API calls and operations done by AWS user accounts in the AWS console to secure our organization.
CloudWatch: CloudWatch is used to monitor AWS resources and services and custom metrics (i.e. number of invocations for email lambda since we have email limit for SES service), dashboards, and alarms were created. Log groups were configured to collect and store log data from various services such as Lambda, enabling real-time monitoring and alerting.
VPC: Application contaions two private and two public subnets. The Public Subnet is the segment within the VPC that includes an EC2 instance in one of the availability zones. The admin user of the app could connect to the EC2 instance through an SSH connection or session manager connection. Private Subnet is the segment within the VPC that does not have a direct route to the internet. Resources in this subnet, such as databases or application servers, were only accessible from within the VPC, enhancing security. DB Subnet is a specific type of subnet group used for RDS instances, which spans multiple AZs to ensure database availability and failover support.
You might also be interested in reading this: Updating DistilBERT Stance Detection Model for Streaming Data
Hasan Alp Caferoglu © 2024